Вместо интро

Я думаю каждый сотрудник IT-компании, где есть эта выделенная роль, особенно проектный менеджер, сталкивался с этим: есть отдельный мир конфигураций и скриптов, где изолирована коммуникация и технический тикет основное средство общения. Обычно CTO ставит их под свой колпак, изолируя от остальных команд и создавая эффект “касты избранных”. Простые запросы превращаются в бесконечные уточнения, а работа стоит в ожидании“благословения”. Я уверен, ты догадался о ком я.

Предупреждение: пост пронизан иронией с целью привлечь внимание к проблеме, а не очернить кого-то

Этот пост у меня зрел давно. И решил таки его написать, когда размышлял, а почему всякие аджайлы часто не заводятся у компаний. Кейсов релевантных истории было полно, но вот два моих любимых:

1. Мы жестко сорвали релиз супераппа на важное гео из-за критичного бага. Причем в случившемся есть мой косяк как менеджера — я не составил полный план выхода с роллбэком. Однако нюанс ситуации в том, что баг возник из-за кривого конфига Nginx, который правился по хорошему на лету. Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);

2. У нас достаточно жестко проседали сроки и я долго не мог понять в чем дело, пока на одной из встреч QA не пожаловались на то что сборки собираются медленно. Я открыл гитлаб и что я вижу — пайплайн тестовой сборки идет в среднем 35 минут. Отправился бить челом к devops и оказывается наши выделенные раннеры больше не наши, а общие, ибо так им удобнее. На этом история застряла где-то на полгода.

Безусловно менеджеры также любят городить свои проектные офисы и обмазываться КСУП, сторипойнтами и гантами. Однако мне интересно в данном стать происследовать природу явления и привлечь внимание к теме. Почему вдруг в компании возникает такое явление.

Изолированный мир DevOps

Я думаю любому кто работал в продуктовой компании прошедшей через трансформацию и трансляцию DevOps as Service описанное ниже будет знакомо, как родное.

Устройство быта DevOps

• В типичной DevOps-команде 1-3 штуки инженеров

• Их день начинается с проверки Slack-бота дежурных и того, дергало ли кого-то, почты с Tier-1 алертам по Golden Metrics

• Основные задачи — контролировать свободное место на дисках серверов, следить за успешным прохождением бэкапов, проверять корректность создания и масштабирования нод в ClickHouse и других кластерах

• Всё хранится в закрытом проекте GitLab: Ansible-плейбуки, Terraform-модули и Vault-секреты, к которым доступ имеют только они

• Для тестовых стендов действует жёсткий принцип: только DevOps могут создать или свичнуть окружение по заранее прописанным правилам

• Документация — это гигантская папка .md-файлов во внутренней вики, где все описано максимально кратко

DevOps-повадки

• Общение почти исключительно через Jira-таски с детальными описаниями — неполные заявки сразу возвращают на доработку

• Еженедельные 20-минутные стендапы для планирования крупных работ по переездам, вне их встреч обсуждения считаются отвлечением

• Любая попытка изменить конфиги или Vault воспринимается как угроза стабильности и этоневашазонаотвественности

• Slack-каналы — закрытая экосистема для обсуждения только релевантных вопросов. Обычно есть группы Infra, Core, Alerts и бот для дежурств

• Вместо фото аватарки и на созвонах не включают камеру;

• Крайне рады в целом если созвона не будет или возможности с него уйти. Если звать на созвон, на котором они считают что не нужны — идут жаловаться CTO

Ощущение «пальцев веером» любые попытки вмешательства воспринимаются как угроза, а дистанция между DevOps и остальными командами приводит к напряжённости и недоверию. Да чего уж там, часто я и мои коллеги проджекты просто напросто были в контрах с Devops.

CTO как хранитель «святости»

CTO считает DevOps ключевым элементом, который отвечает за стабильность всей инфраструктуры компании. Они ему понятны, ведь часто CTO — это бывший самый первый бекенд разработчик в компании. Чтобы не допустить ошибок и лишних вмешательств, он лично контролирует каждый запрос в команду, доступы, миграции и тд. В целом минимизируя человеческий фактор, что вроде есть хорошо, если бы не нюансы.

Иногда это доходит до того, что даже тимлидам разработчиков запрещают участвовать в обсуждениях или вносить изменения, ибо работает не трогай. Такая жесткая защита естественно создаёт ощущение особого статуса у DevOps.

Масло в огонь подливает то что часто (хотя возможно только в моем опыте было такое) у DevOps достаточно детализированный технический роадмап миграций на новые версии БД, настройки датацентров и тд., а у команд это отдано на самотек. Немного, но нотку зависти вызывает.

Но вместе с тем это только усиливает их замкнутость и создаёт дополнительный барьер между DevOps и остальными командами. Да и просто они бесить начинают. В итоге мы вступаем в цикл: devops изолируются→на них раздражаются→devops изолируются

Очень красноречивая ветка на реддите про это: https://www.reddit.com/r/devops/comments/1k5a862/devops_why_are_you_guys_so_annoying_and_full_of/

Как мы докатились до жизни такой, что DevOps это отдельные пафосные инженеры

Продолжатtли сисадминов и идей SRE

DevOps вырос из противостояния: разработка гнала фичи, админы держали прод на замке. Концепция возникла как мост между этими мирами, но на практике стала эволюцией старых сисадминских привычек — главное, чтобы не падало, а всё остальное вторично. Можно нанять универсала которые и на связи 24/7 и сможет жонглировать всем зоопарком тех ландшафта один.

Когда писал наткнулся на отличную статью, очень советую https://www.everythingdevops.dev/blog/a-brief-history-of-devops-and-its-impact-on-software-development

Забавно, что многие компании восприняли DevOps как чисто техническую роль — «новый сисадмин, только со скриптами»

Спрос только за аптайм и восстановление

Метрики успеха для DevOps обычно предельно просты:

• аптайм (uptime)

• среднее время до восстановления (MTTR)

• иногда — скорость отката к предыдущей версии (если гитлаб на premium-плане, можно удобно мерить)

Успех оценивается не по тому, насколько удобно работать другим командам, а по отсутствию аварий и стабильности сервисов. Отсюда и недоверие ко всем внешним «инициативам», особенно если они могут помешать стабильности. Сценарий классический: если всё работает — лучше ничего не трогать.

Процессные практики не транслируются

На всех популярных roadmap’ах для DevOps, том же https://roadmap.sh/devops блоки про процессы, ITIL, ITSM и CMDB обычно где-то в самом низу —- если вообще есть. Прокачка идёт по Linux, CI/CD, Docker, Kubernetes, облакам, мониторингу и скриптам, а вот про ITSM или Service Line редко кто вспоминает. Формализованные процессы воспринимаются как “бюрократия”, которую проще обойти, чем внедрять. В результате про построение зрелых сервисных процессов не вспоминают, а от инцидент менеджмента мы имеем только способ обнаружения постфактум. Зато быстро!

Про хайп и элитарность я опущу, кажется это уже проходит, как и в целом “золотая эра IT” как “особенной” сферы. Хотя я помню как писались такие статьи в свое время… https://habr.com/ru/articles/469277/

Бесполезные передасты

Это я про то как выглядят проектные менеджеры часто.

На мой взгляд причины конфликтов между devops-инженерами и проектными менеджерами (упаси боже скрам-мастерами) лежат сугубо в этих 3 плоскостях:

Противоборство целей

Менеджер фокусируется на попадании в ожидания заинтересованных лиц, а DevOps на стабильности инфраструктуры, автоматизации и частоте выпуска (но не всегда про последнее). Эти цели явно вступают в конфликт, особенно когда надо в сжатые сроки

Каждое изменение для DevOps — это буквально failure, риск падения стабильности, поэтому у Ops-команды естественное стремление замедлить и тщательнее контролировать выпуски.

Неприязнь к бюрократии

DevOps-культура!!!! зародилась в инженерной среде, а там ценят автоматизацию и сниженение участия человека, поэтому традиционные менеджерские практики (регламенты, миты, отчеты) воспринимаются как бюрократическая шляпа.

Обычно девопсы — это бывшие сисадмины или разработчики, не горящие энтузиазмом от Scrum-ритуалов или документации. Если проектный менеджер настойчиво требует от DevOps-команды следовать формальным процессам это типично провоцирует агрессию. Интровертивные инженеры часто избегают чрезмерной коммуникации, а тут их заставляют “играть по правилам” Agile, ага, щас.

Критика компетентности менеджеров

Поскольку работа DevOps требует изрядного уровня технического погружения, многие инженеры скептически относятся к людям, не обладающим таким же уровнем техглубины. Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредником

Последствия для бизнеса

В целом более подкованный товарищ все изложил тут https://habr.com/ru/companies/moex/articles/594509/, но я повторюсь:

• Пока DevOps-барьер стоит непроходимым, Lead Time и Time-to-Market медленно, но верно растут → конкуренты выкатывают новые фичи быстрее, а мы зависаем в бесконечных согласованиях

• Для проектных менеджеров это превращается в марафон эскалаций и попыток пробиться сквозь джиру → в какой-то момент выгораешь и перестаёшь верить, что можно договориться по-человечески

• В командах накапливается раздражение: каждое новое обращение превращается в мини-конфликт, где уже не задача обсуждается, а воюют за территорию и ресурсы

• В конечном счёте компания теряет и в скорости, и в качестве → срываются сроки, страдает пользователь, и вместо движения вперёд все буксуют на ровном месте

Зато можно выступить на DevOps Days с кейсом нового витка развития IaC.

Рекомендации по взаимодействию

Идите на встречу друг другу.

Проектным менеджерам и вообще менеджерам

• Не бойтесь подтянуть базовый системный дизайн и разобраться, как устроена ваша инфраструктура — это проще, чем кажется и сразу сокращает количество недопониманий. Когда вы говорите на одном языке это приятно. Хорошая книга https://www.litres.ru/book/aleks-suy/system-design-podgotovka-k-slozhnomu-intervu-67193183/

• Найдите время и честно попросите DevOps провести вам экскурсию по техландшафту компании: как работают основные сервисы, где лежат ключевые конфиги и тд. Возможно даже вы поймете только четверть. Но даже один такой разговор снижает предубеждения

DevOps

• Ведите в Confluence FAQ или просто небольшой справочник по инфраструктуре, а ещё хотя бы раз в месяц устраивайте «дни открытых дверей» — собирайте коллег, рассказывайте и отвечайте отвечайте на вопросы о том, как и почему всё так устроено

• В таск-трекерах почти всегда можно настроить шаблоны задач: пусть любой запрос к DevOps проходит по чёткому брифу с ответами на ключевые вопросы (версия сервиса, окружение, цель запроса и т.д.). Это не только облегчает жизнь DevOps, но и позволяет автоматически выставлять SLA по каждой категории — прозрачнее, быстрее, честнее для всех

CTO:

• Следите, чтобы в развитии DevOps-инженеров появлялись не только новые «технические игрушки», но и хотя бы базовые процессные компетенции — понимание ITSM, навыки коммуникации и сервисное мышление для внутреннего клиента.

• И, кстати, самим CTO полезно хотя бы раз пролистать руководство по ITIL 4, чтобы не превращать свою инфраструктурную команду в касту брахманов

Я не знаю кто автор этого чуда, но вот нашел папку про ITIL и там много на русском https://disk.yandex.ru/d/NgmkI3yYY4p1bA

Вместо послесловия

Порызмышляв, я пришел к выводу что образ “высокомерного DevOps” – не вымысел, а следствие конкретных организационных ошибок и культурных перекосов.

Предугадывая комментарии я не только размышлял, но и поообщался с парой банков и телекомов.

Отдельный DevOps-отдел, отсутствие общей ответственности, дефицит коммуникации и поддержка сверху без баланса – это приводит к тому, что сервисная команда обособляется и начинает смотреть свысока на остальных, а те отвечают ей недоверием и неприязнью. Для продуктовой компании это крайне опасно: вместо паверапа Dev и Ops мы возвращаемся в эру кабинетных войн. Те же яйцп, только в профиль

Цель этой статьи — не очернить всех DevOps-инженеров (среди них множество отличных командных игроков), а привлечь внимание к этим тревожным сигналам.

Update: в комментах и сообществе посоветовали еще 2 отличных статьи на эту тему, добавлю сюда:

• https://habr.com/ru/articles/646581/

• https://habr.com/ru/articles/811429/

Если вдруг интересно — мой канал https://t.me/junior_pm