Да, все так, конечно метрика «хороший\плохой» релиз она обобщенная и для понимания. У каждого свои метрики. Но, кстати, метрика "!302/301/200/403"/ «количество запросов» будет немного удачнее, чем «кол-во 5xx / общее кол-во запросов» мне кажется. Но я думаю с вашей стороны это тоже был пример.
А вот с 404 нужно быть аккуратнее, ее можно получить и без проблем в коде, лучше мониторить отдельно и эмперически добавлять к основной именно тогда, когда она вызвана именно продуктом.
Посмотрел слайды, любопытно.
Может по слайдам просто непонятно, но я не очень согласен со «Сквозное конфигурирование? Нет». Оно там есть, при установке базового чарта можно передать конфигурацию зависимым. Но, возможно, оно не про это. Если не про это — скажите про что, интересно:)
На счет транзитивных зависимостей — да, их можно сказать что нет, точнее есть, но ломаются часто из-за кросс зависимостей.
В целом, я стараюсь вообще их избегать и деплоить в несколько шагов то, что можно деплоить в несколько шагов, но если очень надо — попробуйте Degasolv. Он универсальный, но тут тоже сгодится, заменяет requirement.yaml, но правда добавляет один шаг на собственно сборку зависимостей. Лечит дубликаты зависимостей и подобные штуки.
Но тут я согласен, да. Helm далеко не идеален.
За автора не отвечу, но могу рассказать из своего опыта.
Error Budget в целом высчитвывается статистически на основании требований бизнеса и текущей реальности.
Все ошибаются. Иногда что-то идет не так. Это факт. Допустим, мы волевым решением и на основании статистики принимаем решение что 3 релиза из 100 могут пойти не так. То есть для нас Error Budget — 3% (это достаточно высоко, в реальности бюджет не должен превышать 1, максимум 2 процентов).
После этого мы просто начинаем учитывать это в выкатке релизов, т.к. это является аггрегированным показателем качества.
Если ребята катят и не выходят за пределы бюджета, значит в целом качество кода хорошее и можно не боясь катиться практически в любое время.
Если команда начинает выходить за пределы бюджета, то процесс релизов приостанавливается до принятия мер, так как превышение бюджета явно свидетельствует о том, что что-то идет на так в команде, качество когда упало, возникла нестабильность и непонятно где оно стрельнет в следующий раз.
А обоснование для бизнеса простое — мы наблюдаем проблемы с качеством новых версий приложения. Или мы притормаживаем, разбираем инциденты, выясняем проблему и решаем ее, чтобы все было хорошо, или рано или поздно и скорее всего в ближайшее время у нас будут большие проблемы, которые дестабилизируют продукт с непредсказуемыми последствиями. Обычно такого объяснения для бизнеса достаточно, т.к. факты и статистика в наличии и однозначны в трактовке.
В случае облаков проще брать как сервис (если есть).
Если не облака или нет нужно базы — можно внутри, главное чтобы стораджи позволяли динамическое монтирование и имели достаточную скорость.
Есть, я в свое время в одиночку вполне разобрался. Поначалу сложно, но после понимания концепции пойдет легче.
Преимущество, он же недостаток — гибкость. Очень широкий спект применения, отсюда очень много моментов, где можно споткнуться и сделать не так. Но решаемо.
BGP и IP-in-IP по началу не нужен совсем. Большинство CNI просто работают при условии соблюдения инструкции по установке.
В общем не все так страшно.
Во, хороший шанс обратиться как к автору доклада:
1. Для ускорения получения контейнеров можно использовать Dragonfly. Это P2P система хранения с поддержкой Docker Registry протокола.
2. Kubernetes уже 1.11 вышел. Secret давно стабильны. Плюс еще много чего появилось, но думаю вы вкурсе.
3. Для локальной разработки можно (и возможно нужно) использовать Skaffold. Очень интересная утилитка, поддерживает Helm.
4. Для роутинга между подами и сервисами, ингресов, трейсов и еще кое-чего можно использовать Istio.
5. Споты в Kops тоже конечно же давно есть. Но это опять же, просто презентация старая.
6. На счет глобального роутинга — тут federation конечно поможет, но очень зависит от инфраструктуры под ногами.
7. На счет нескольких кластеров… тут важен объем. В ином случае Labels, Taints, NodeSelectors, Limits и Affinity решают вопросы разделения ресурсов и уплотнения. Но можно и несколько кластеров, конечно. Хотя без всех этих штук все равно сложно обойтись.
8. Автоскейлингом занимается Pod Autoscaler, он platform-agnostic. А вот Node Autoscaler в режиме AWS действительно скелит ноды.
9. У Helm, хоть я его не очень и люблю, есть свои dependency между чартами и hooks, что позволяет деплоить и обновлять продукт вместе со всеми зависимостями в правильном порядке, храня только 1 (ну или сколько удобно) конфигурационный файл для stage. Не очень понятно зачем нужны еще какие-то инструменты поверх него (или рядом).
Ну 60 евро весьма чувствительный штраф, все-таки.
В целом в Европе это действительно распространено.Для примера еще могу Краков привести.
Стоимость проезда 2.7 pln или 3.4 pln по городу, в зависимости от времени поездки, штраф за безбилетный проезд — от 250 до 500 pln. Контролеры встречаются достаточно часто (если много катаешься, за день разок да встретишь).
Средняя ЗП по городу кстати около 4200 pln до налогов, это 2993 pln на руки, так что штраф очень чувствительный.
Тем не менее, безбилетники вполне себе встречаются. Черт его знает что ими движет.
GitHub uses the open source Linguist library to determine file languages
Надо просто немного поинтересоваться, а не молча (или в комментариях на хабре) страдать.
Ну и кстати, язык репы тоже можно отлично выставить руками, тот же запрос, следующая ссылка.
Вообще то я категорический противник нынешнего яваскриптового безумия
Да можно быть сколько угодно противником чего угодно, но если есть набор инструментов, который помогает делать работу — его нужно освоить. Стек очень широк, экспертом во всем не стать, но основы на уровне «могу пользоваться» знать можно и нужно. Даже если это относится к эксплуатации.
Кстати, хорошие результативные программисты как раз умеют пользоваться базовым набором инструментов эксплуатации и понимают как это работает, равно как и хороший инженер по эксплуатации должен знать как собрать\поправить код, а лучше всего и уметь хотя бы базового его отладить, если что-то идет не так.
По крайней мере иных сочетаний хороших специалистов мне не попадалось за почти 10 лет работы.
Лично для меня проблема продуктов от MS в том, что они один из них ничего не делает по настоящему хорошо, за некоторыми исключениями, но о них ниже.
Azure у них так себе, если вне их стека, Google Cloud и Amazon мощнее и дешевле;
Windows хороша (для работы), но MacOS все-таки удобнее для работы (IMHO) и многие вещи там решены лучше. Игры не упоминаю, а то придется консоли вспоминать:)
.Net стек — интересный, весьма популярный, но опять же пока в пределах платформы, да и тут Java та же весьма конкурентна и ей часто отдается предпочтение.
MS SQL — неплох, но Postgres/Oracle могут так же или лучше.
Windows Mobile — ну тут комментарии излишни. Хотя система кстати была неплохая, у меня аж 2 трубки на ней было. Но — как то вот так.
Остальные их продукты я сходу не вспомню, в повседневной жизни не встречаются особо, по крайней мере вокруг меня.
Особняком стоит Visual Studio — это действительно классная среда для разработки по совокупности характеристик и лучше нее наверно не делает никто.
Так же — Office и Exchange. Тут альтернатив толковых и правда нет.
Для меня вот у Гитлаба одна очень нужная фича, замену которой я найти не могу — встроенный container registry с нормальной системой прав. Не знаете случайно альтернативу?
На соурсфрже например в настройках проекта можно просто подклюить нужный сервис — вики там или форум или еще десяток. И оно нигде само не торчит — надо дал прямую ссылку в реадми. Вот такое было бы очень удобно.
Ну так храните все на SourceForge, в чем проблема то? И остальных заодно убедите, что там лучше, а то что они как идиоты на гитхабе все:)
Вот об этом и речь — вместо отредактировать и указать нужный тег я должен куда то отправлять багрепорт и ждать пока чьето величество на него отреагирует — мне больше нечем заняться?
То есть опенсорсными продуктами пользоваться, в которые вложены миллионы часов, это всегда пожалуйста, а багрепорт написать (не говоря уже о том, чтобы пойти и поправить), так нечем заняться, так получается?
. Я програмист а не админ и хочу заниматся програмированием а не осваивать профессию тыжпрограмист и помнить всякие тулзы, конфиги, мудреные команды и прочее в продуктах которые появляются нынче каждый день сотнями и уходят на свалку быстрее чем я о них услышал.
Ну тут даже сказать нечего. И это говорит человек, который ноду упоминал тут?:)
А развивать есть куда — то же юзабилити которое заточено на линуксоидов которые любят набирать стопицот команд вместо просто ткнуть пальцем как принято в 21 веке.
Ну, со всеми системами из «21 века» все отлично, пока они работают. А вот когда они ломаются и надо разобраться какую магию запускает кнопка «пыщ» и что с ней не так — вот тут начинаются проблемы… А вообще, нормальный у Гитхаба юзабилити.
Почему нельзя к проекту подключить что то типа форума или каких то коментариев как на хабре чтобы кто то кто заинтересовался проектом мог просто задать вопрос.
Есть Issues, есть Wiki. Для комьюнити есть платформа StackExchange, Slack и еще куча инструментов. Зачем все в одном? Чтобы выбора небыло?
И какого хрена я не могу указать технологии — гитхад пометил мои проекты как яваскрипт когда у меня проекты на ПХП.
Он не пометил их как «яваскрипт», он просто определил языки, используемые в проекте. Если там есть Javascript, то какие претензии то?
Можно посмотреть в результаты Openbenchmark, на время компиляции ядра.
AMD Ryzen 2700X — 72.81c
AMD Ryzen 2700 — 87.81c
AMD Ryzen 1800X и 1700X практически одинаково — 81.50с
AMD Ryzen 1700 — 119.59с
Для сравнения, мой домашний сервер на базе рабочей станции Dell T3600, купленный в сборе на Ebay за 450 евро полгода назад (я поставил туда только старенькую SSDшку SmartBuy), дает в этом тесте 109.74с, вот результат.
Процессор Intel Xeon E5-4650L, 32Гб DDR3 ECC памяти двумя плашками по 16Гб PC3-8500R 1066MHZ CL7, судя по part number.
То есть в общем то он да, быстрее считай на треть при том же количестве ядер. Правда все портит ценник, для компиляции можно найти что-то с лучшем соотношением цена\скорость, даже БУ, что для серьезного оборудование не беда.
Ну комментатор даже не факт что иммингрант, можно 10 лет к ряду каждый день общаться по-английски, живя в не-англоязычной стране. Глобализация-с…
А на счет спокойно относятся — по моим наблюдениям все зависит от целей. У них тоже есть свои «граммар наци» со всеми вытекающими, но в целом, по крайней мере в рамках рабочего процесса, если ты говоришь достаточно хорошо, чтобы тебя однозначно понимали, то в целом всем все равно совершенно.
При этом, как бы правильно и грамотно ты не говорил, акцент может быть таким, что лучше бы ты артикли путал.
А вообще, нельзя смешивать дифференциацию «свой\чужой» и язык. Для проявления ксенофобии достаточно внешности, манер и выражения лица, которые видно задолго до того, как человек откроет рот. А если уже и остальные факторы не отличаются от местных и вы так глубоко ассимелировались, то вряд ли ваш язык на столько плох.
Другой случай: крупный ит-финтех (вч трейдинг) далеко не в англоязычной стране (я бы сказал язык полный антипод английскому). И опять помешанность на устном общении и не только собеседование на английском, а ещё умение проводить на нём ежедневные многочасовые митинги.
Спросил зачем?
Польза митингов на 30-50 человек более чем сомнительна, объективный предел и правда где то в районе "двух пицц", а вот на счет разговорного английского — тут как раз все просто.
В IT это де-факто единственный общий язык всех представителей индустрии. В случае подбора команды без учета географического признака, английский просто нужен для регулярной коммуникации, тут вариантов то особых и нет, кроме крайне больших внутренних рынков а-ля Китай, где зачастую хватает знания китайского.
Так обычно сейчас и набирают нормальные команды в крупных стартапах, потому что в пределах одной локации может просто не хватить людей с нужной компетенцией или они будут дороги. Плюс — если команды находятся в более чем одной стране, вопрос знания английского языка еще более острый.
Откуда эта помешанность на общении у бизнеса и иллюзия видимости качества если разрабы много или умело общаются вместо того чтоб разрабатывать?
К сожалению, никаких релевантных исследований я не изучал на эту тему, но опираясь на собственный, не такой уж маленький, опыт коммуникации в IT (в основном с позиции системного администратора/инженера/девопса в сторону разработчиков и менеджмента), навык общения очень важен.
Он не дает гарантию того, что человек пишет хороший код, но его отсутствие практически дает гарантию того, что работать будет сложно. Исключение — специалисты экстра-класса, которым действительно коммуникация особо и не нужна, они просто научились уже думать за себя и немного за других. Но вероятность его появления на горизонте невелика, я за 10 лет работы не в самых худших компаниях встретил 4 человека (с натяжкой), которых можно так характиризовать, из нескольких сотен, с которыми приходилось так или иначе пересекаться.
В обычной средней команде, которых подавляющее большинство, умение много и продуктивно общаться важно, т.к. тебе и нужно часто объяснять что ты делаешь, и придется спросить бизнес о том, что делать, и решение надо иногда принять коллективно, и послушать мнения сторон, да море ситуаций, на самом деле.
Отгараживаться же тимлидом/ПМом/начальником отдела от подобных коммуникаций не всегда можно и полезно, они, если нормальные, и так пытаются свести количество коммуникаций к необходимому минимуму, ниже которого будет страдать качество итогового продукта.
Честно сказать, я и сам митинги не люблю, но я воспринимаю это как еще один инструмент, которым надо владеть в достаточной степени. Но, необязательно любить стамеску, чтобы уметь ей пользоваться.
А вот с 404 нужно быть аккуратнее, ее можно получить и без проблем в коде, лучше мониторить отдельно и эмперически добавлять к основной именно тогда, когда она вызвана именно продуктом.
Может по слайдам просто непонятно, но я не очень согласен со «Сквозное конфигурирование? Нет». Оно там есть, при установке базового чарта можно передать конфигурацию зависимым. Но, возможно, оно не про это. Если не про это — скажите про что, интересно:)
На счет транзитивных зависимостей — да, их можно сказать что нет, точнее есть, но ломаются часто из-за кросс зависимостей.
В целом, я стараюсь вообще их избегать и деплоить в несколько шагов то, что можно деплоить в несколько шагов, но если очень надо — попробуйте Degasolv. Он универсальный, но тут тоже сгодится, заменяет requirement.yaml, но правда добавляет один шаг на собственно сборку зависимостей. Лечит дубликаты зависимостей и подобные штуки.
Но тут я согласен, да. Helm далеко не идеален.
Error Budget в целом высчитвывается статистически на основании требований бизнеса и текущей реальности.
Все ошибаются. Иногда что-то идет не так. Это факт. Допустим, мы волевым решением и на основании статистики принимаем решение что 3 релиза из 100 могут пойти не так. То есть для нас Error Budget — 3% (это достаточно высоко, в реальности бюджет не должен превышать 1, максимум 2 процентов).
После этого мы просто начинаем учитывать это в выкатке релизов, т.к. это является аггрегированным показателем качества.
Если ребята катят и не выходят за пределы бюджета, значит в целом качество кода хорошее и можно не боясь катиться практически в любое время.
Если команда начинает выходить за пределы бюджета, то процесс релизов приостанавливается до принятия мер, так как превышение бюджета явно свидетельствует о том, что что-то идет на так в команде, качество когда упало, возникла нестабильность и непонятно где оно стрельнет в следующий раз.
А обоснование для бизнеса простое — мы наблюдаем проблемы с качеством новых версий приложения. Или мы притормаживаем, разбираем инциденты, выясняем проблему и решаем ее, чтобы все было хорошо, или рано или поздно и скорее всего в ближайшее время у нас будут большие проблемы, которые дестабилизируют продукт с непредсказуемыми последствиями. Обычно такого объяснения для бизнеса достаточно, т.к. факты и статистика в наличии и однозначны в трактовке.
Если не облака или нет нужно базы — можно внутри, главное чтобы стораджи позволяли динамическое монтирование и имели достаточную скорость.
Преимущество, он же недостаток — гибкость. Очень широкий спект применения, отсюда очень много моментов, где можно споткнуться и сделать не так. Но решаемо.
BGP и IP-in-IP по началу не нужен совсем. Большинство CNI просто работают при условии соблюдения инструкции по установке.
В общем не все так страшно.
1. Для ускорения получения контейнеров можно использовать Dragonfly. Это P2P система хранения с поддержкой Docker Registry протокола.
2. Kubernetes уже 1.11 вышел. Secret давно стабильны. Плюс еще много чего появилось, но думаю вы вкурсе.
3. Для локальной разработки можно (и возможно нужно) использовать Skaffold. Очень интересная утилитка, поддерживает Helm.
4. Для роутинга между подами и сервисами, ингресов, трейсов и еще кое-чего можно использовать Istio.
5. Споты в Kops тоже конечно же давно есть. Но это опять же, просто презентация старая.
6. На счет глобального роутинга — тут federation конечно поможет, но очень зависит от инфраструктуры под ногами.
7. На счет нескольких кластеров… тут важен объем. В ином случае Labels, Taints, NodeSelectors, Limits и Affinity решают вопросы разделения ресурсов и уплотнения. Но можно и несколько кластеров, конечно. Хотя без всех этих штук все равно сложно обойтись.
8. Автоскейлингом занимается Pod Autoscaler, он platform-agnostic. А вот Node Autoscaler в режиме AWS действительно скелит ноды.
9. У Helm, хоть я его не очень и люблю, есть свои dependency между чартами и hooks, что позволяет деплоить и обновлять продукт вместе со всеми зависимостями в правильном порядке, храня только 1 (ну или сколько удобно) конфигурационный файл для stage. Не очень понятно зачем нужны еще какие-то инструменты поверх него (или рядом).
В целом в Европе это действительно распространено.Для примера еще могу Краков привести.
Стоимость проезда 2.7 pln или 3.4 pln по городу, в зависимости от времени поездки, штраф за безбилетный проезд — от 250 до 500 pln. Контролеры встречаются достаточно часто (если много катаешься, за день разок да встретишь).
Средняя ЗП по городу кстати около 4200 pln до налогов, это 2993 pln на руки, так что штраф очень чувствительный.
Тем не менее, безбилетники вполне себе встречаются. Черт его знает что ими движет.
Форма говорит, что нужно имя компании и ASка.
Третья строчка в гугле по запросу «How github detects the repository language» ведет сюда — help.github.com/articles/about-repository-languages и там написано:
Надо просто немного поинтересоваться, а не молча (или в комментариях на хабре) страдать.
Ну и кстати, язык репы тоже можно отлично выставить руками, тот же запрос, следующая ссылка.
Да можно быть сколько угодно противником чего угодно, но если есть набор инструментов, который помогает делать работу — его нужно освоить. Стек очень широк, экспертом во всем не стать, но основы на уровне «могу пользоваться» знать можно и нужно. Даже если это относится к эксплуатации.
Кстати, хорошие результативные программисты как раз умеют пользоваться базовым набором инструментов эксплуатации и понимают как это работает, равно как и хороший инженер по эксплуатации должен знать как собрать\поправить код, а лучше всего и уметь хотя бы базового его отладить, если что-то идет не так.
По крайней мере иных сочетаний хороших специалистов мне не попадалось за почти 10 лет работы.
Azure у них так себе, если вне их стека, Google Cloud и Amazon мощнее и дешевле;
Windows хороша (для работы), но MacOS все-таки удобнее для работы (IMHO) и многие вещи там решены лучше. Игры не упоминаю, а то придется консоли вспоминать:)
.Net стек — интересный, весьма популярный, но опять же пока в пределах платформы, да и тут Java та же весьма конкурентна и ей часто отдается предпочтение.
MS SQL — неплох, но Postgres/Oracle могут так же или лучше.
Windows Mobile — ну тут комментарии излишни. Хотя система кстати была неплохая, у меня аж 2 трубки на ней было. Но — как то вот так.
Остальные их продукты я сходу не вспомню, в повседневной жизни не встречаются особо, по крайней мере вокруг меня.
Особняком стоит Visual Studio — это действительно классная среда для разработки по совокупности характеристик и лучше нее наверно не делает никто.
Так же — Office и Exchange. Тут альтернатив толковых и правда нет.
Ну так храните все на SourceForge, в чем проблема то? И остальных заодно убедите, что там лучше, а то что они как идиоты на гитхабе все:)
То есть опенсорсными продуктами пользоваться, в которые вложены миллионы часов, это всегда пожалуйста, а багрепорт написать (не говоря уже о том, чтобы пойти и поправить), так нечем заняться, так получается?
Ну тут даже сказать нечего. И это говорит человек, который ноду упоминал тут?:)
Ну, со всеми системами из «21 века» все отлично, пока они работают. А вот когда они ломаются и надо разобраться какую магию запускает кнопка «пыщ» и что с ней не так — вот тут начинаются проблемы… А вообще, нормальный у Гитхаба юзабилити.
Есть Issues, есть Wiki. Для комьюнити есть платформа StackExchange, Slack и еще куча инструментов. Зачем все в одном? Чтобы выбора небыло?
Он не пометил их как «яваскрипт», он просто определил языки, используемые в проекте. Если там есть Javascript, то какие претензии то?
AMD Ryzen 2700X — 72.81c
AMD Ryzen 2700 — 87.81c
AMD Ryzen 1800X и 1700X практически одинаково — 81.50с
AMD Ryzen 1700 — 119.59с
Для сравнения, мой домашний сервер на базе рабочей станции Dell T3600, купленный в сборе на Ebay за 450 евро полгода назад (я поставил туда только старенькую SSDшку SmartBuy), дает в этом тесте 109.74с, вот результат.
Процессор Intel Xeon E5-4650L, 32Гб DDR3 ECC памяти двумя плашками по 16Гб PC3-8500R 1066MHZ CL7, судя по part number.
То есть в общем то он да, быстрее считай на треть при том же количестве ядер. Правда все портит ценник, для компиляции можно найти что-то с лучшем соотношением цена\скорость, даже БУ, что для серьезного оборудование не беда.
А на счет спокойно относятся — по моим наблюдениям все зависит от целей. У них тоже есть свои «граммар наци» со всеми вытекающими, но в целом, по крайней мере в рамках рабочего процесса, если ты говоришь достаточно хорошо, чтобы тебя однозначно понимали, то в целом всем все равно совершенно.
При этом, как бы правильно и грамотно ты не говорил, акцент может быть таким, что лучше бы ты артикли путал.
А вообще, нельзя смешивать дифференциацию «свой\чужой» и язык. Для проявления ксенофобии достаточно внешности, манер и выражения лица, которые видно задолго до того, как человек откроет рот. А если уже и остальные факторы не отличаются от местных и вы так глубоко ассимелировались, то вряд ли ваш язык на столько плох.
Польза митингов на 30-50 человек более чем сомнительна, объективный предел и правда где то в районе "двух пицц", а вот на счет разговорного английского — тут как раз все просто.
В IT это де-факто единственный общий язык всех представителей индустрии. В случае подбора команды без учета географического признака, английский просто нужен для регулярной коммуникации, тут вариантов то особых и нет, кроме крайне больших внутренних рынков а-ля Китай, где зачастую хватает знания китайского.
Так обычно сейчас и набирают нормальные команды в крупных стартапах, потому что в пределах одной локации может просто не хватить людей с нужной компетенцией или они будут дороги. Плюс — если команды находятся в более чем одной стране, вопрос знания английского языка еще более острый.
К сожалению, никаких релевантных исследований я не изучал на эту тему, но опираясь на собственный, не такой уж маленький, опыт коммуникации в IT (в основном с позиции системного администратора/инженера/девопса в сторону разработчиков и менеджмента), навык общения очень важен.
Он не дает гарантию того, что человек пишет хороший код, но его отсутствие практически дает гарантию того, что работать будет сложно. Исключение — специалисты экстра-класса, которым действительно коммуникация особо и не нужна, они просто научились уже думать за себя и немного за других. Но вероятность его появления на горизонте невелика, я за 10 лет работы не в самых худших компаниях встретил 4 человека (с натяжкой), которых можно так характиризовать, из нескольких сотен, с которыми приходилось так или иначе пересекаться.
В обычной средней команде, которых подавляющее большинство, умение много и продуктивно общаться важно, т.к. тебе и нужно часто объяснять что ты делаешь, и придется спросить бизнес о том, что делать, и решение надо иногда принять коллективно, и послушать мнения сторон, да море ситуаций, на самом деле.
Отгараживаться же тимлидом/ПМом/начальником отдела от подобных коммуникаций не всегда можно и полезно, они, если нормальные, и так пытаются свести количество коммуникаций к необходимому минимуму, ниже которого будет страдать качество итогового продукта.
Честно сказать, я и сам митинги не люблю, но я воспринимаю это как еще один инструмент, которым надо владеть в достаточной степени. Но, необязательно любить стамеску, чтобы уметь ей пользоваться.