Вместо интро
Я думаю каждый сотрудник IT‑компании, где есть эта выделенная роль, особенно проектный менеджер, сталкивался с этим: есть отдельный мир конфигураций и скриптов, где изолирована коммуникация и технический тикет основное средство общения. Обычно CTO ставит их под свой колпак, изолируя от остальных команд и создавая эффект «касты избранных». Простые запросы превращаются в бесконечные уточнения, а работа стоит в ожидании»благословения». Я уверен, ты догадался о ком я.
Предупреждение: пост пронизан иронией с целью привлечь внимание к проблеме, а не очернить кого‑то
Этот пост у меня зрел давно. И решил таки его написать, когда размышлял, а почему всякие аджайлы часто не заводятся у компаний. Кейсов релевантных истории было полно, но вот два моих любимых:
Мы жестко сорвали релиз супераппа на важное гео из‑за критичного бага. Причем в случившемся есть мой косяк как менеджера — я не составил полный план выхода с роллбэком. Однако нюанс ситуации в том, что баг возник из‑за кривого конфига Nginx, который правился по хорошему на лету. Если бы devops‑инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);
У нас достаточно жестко проседали сроки и я долго не мог понять в чем дело, пока на одной из встреч 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 изолируются.
Очень красноречивая ветка на реддите про это.
Как мы докатились до жизни такой, что DevOps это отдельные пафосные инженеры
Продолжатели сисадминов и идей SRE
DevOps вырос из противостояния: разработка гнала фичи, админы держали прод на замке. Концепция возникла как мост между этими мирами, но на практике стала эволюцией старых сисадминских привычек — главное, чтобы не падало, а всё остальное вторично. Можно нанять универсала которые и на связи 24/7 и сможет жонглировать всем зоопарком тех ландшафта один.
Когда писал наткнулся на отличную статью, очень советую.
Забавно, что многие компании восприняли DevOps как чисто техническую роль — «новый сисадмин, только со скриптами»
Спрос только за аптайм и восстановление
Метрики успеха для DevOps обычно предельно просты:
аптайм (uptime)
среднее время до восстановления (MTTR)
иногда — скорость отката к предыдущей версии (если гитлаб на premium‑плане, можно удобно мерить)
Успех оценивается не по тому, насколько удобно работать другим командам, а по отсутствию аварий и стабильности сервисов. Отсюда и недоверие ко всем внешним «инициативам», особенно если они могут помешать стабильности. Сценарий классический: если всё работает — лучше ничего не трогать.
Процессные практики не транслируются
На всех популярных roadmap»ах для DevOps, том же https://roadmap.sh/devops блоки про процессы, ITIL, ITSM и CMDB обычно где‑то в самом низу ‑- если вообще есть. Прокачка идёт по Linux, CI/CD, Docker, Kubernetes, облакам, мониторингу и скриптам, а вот про ITSM или Service Line редко кто вспоминает. Формализованные процессы воспринимаются как «бюрократия», которую проще обойти, чем внедрять. В результате про построение зрелых сервисных процессов не вспоминают, а от инцидент менеджмента мы имеем только способ обнаружения постфактум. Зато быстро!
Про хайп и элитарность я опущу, кажется это уже проходит, как и в целом «золотая эра IT» как «особенной» сферы. Хотя я помню как писались такие статьи в свое время…
Бесполезные передасты
Этоя про то как выглядят проектные менеджеры часто.
На мой взгляд причины конфликтов между devops‑инженерами и проектными менеджерами (упаси боже скрам‑мастерами) лежат сугубо в этих 3 плоскостях:
Противоборство целей
Менеджер фокусируется на попадании в ожидания заинтересованных лиц, а DevOps на стабильности инфраструктуры, автоматизации и частоте выпуска (но не всегда про последнее). Эти цели явно вступают в конфликт, особенно когда надо в сжатые сроки.
Каждое изменение для DevOps — это буквально failure, риск падения стабильности, поэтому у Ops‑команды естественное стремление замедлить и тщательнее контролировать выпуски.
Неприязнь к бюрократии
DevOps‑культура!!!! зародилась в инженерной среде, а там ценят автоматизацию и сниженение участия человека, поэтому традиционные менеджерские практики (регламенты, миты, отчеты) воспринимаются как бюрократическая шляпа.
Обычно девопсы — это бывшие сисадмины или разработчики, не горящие энтузиазмом от Scrum‑ритуалов или документации. Если проектный менеджер настойчиво требует от DevOps‑команды следовать формальным процессам это типично провоцирует агрессию. Интровертивные инженеры часто избегают чрезмерной коммуникации, а тут их заставляют «играть по правилам» Agile, ага, щас.
Критика компетентности менеджеров
Поскольку работа DevOps требует изрядного уровня технического погружения, многие инженеры скептически относятся к людям, не обладающим таким же уровнем техглубины. Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps‑инженеры невольно начинают считать его бесполезным посредником.
Последствия для бизнеса
В целом более подкованный товарищ все изложил тут, но я повторюсь:
Пока DevOps-барьер стоит непроходимым, Lead Time и Time-to-Market медленно, но верно растут → конкуренты выкатывают новые фичи быстрее, а мы зависаем в бесконечных согласованиях
Для проектных менеджеров это превращается в марафон эскалаций и попыток пробиться сквозь джиру → в какой-то момент выгораешь и перестаёшь верить, что можно договориться по-человечески
В командах накапливается раздражение: каждое новое обращение превращается в мини-конфликт, где уже не задача обсуждается, а воюют за территорию и ресурсы
В конечном счёте компания теряет и в скорости, и в качестве → срываются сроки, страдает пользователь, и вместо движения вперёд все буксуют на ровном месте
Зато можно выступить на DevOps Days с кейсом нового витка развития IaC.
Рекомендации по взаимодействию
Идите навстречу друг другу.
Проектным менеджерам и вообще менеджерам
Не бойтесь подтянуть базовый системный дизайн и разобраться, как устроена ваша инфраструктура — это проще, чем кажется и сразу сокращает количество недопониманий. Когда вы говорите на одном языке это приятно. Хорошая книга.
Найдите время и честно попросите DevOps провести вам экскурсию по техландшафту компании: как работают основные сервисы, где лежат ключевые конфиги и тд. Возможно даже вы поймете только четверть. Но даже один такой разговор снижает предубеждения.
DevOps
Ведите в Confluence FAQ или просто небольшой справочник по инфраструктуре, а ещё хотя бы раз в месяц устраивайте «дни открытых дверей» — собирайте коллег, рассказывайте и отвечайте отвечайте на вопросы о том, как и почему всё так устроено.
В таск‑трекерах почти всегда можно настроить шаблоны задач: пусть любой запрос к DevOps проходит по чёткому брифу с ответами на ключевые вопросы (версия сервиса, окружение, цель запроса и т. д.). Это не только облегчает жизнь DevOps, но и позволяет автоматически выставлять SLA по каждой категории — прозрачнее, быстрее, честнее для всех.
CTO:
Следите, чтобы в развитии DevOps‑инженеров появлялись не только новые «технические игрушки», но и хотя бы базовые процессные компетенции — понимание ITSM, навыки коммуникации и сервисное мышление для внутреннего клиента.
И, кстати, самим CTO полезно хотя бы раз пролистать руководство по ITIL 4, чтобы не превращать свою инфраструктурную команду в касту брахманов.
Я не знаю кто автор этого чуда, но вот нашел папку про ITIL и там много на русском.
Вместо послесловия
Порызмышляв, я пришел к выводу что образ «высокомерного DevOps» — не вымысел, а следствие конкретных организационных ошибок и культурных перекосов.
Предугадывая комментарии я не только размышлял, но и поообщался с парой банков и телекомов.
Отдельный DevOps‑отдел, отсутствие общей ответственности, дефицит коммуникации и поддержка сверху без баланса — это приводит к тому, что сервисная команда обособляется и начинает смотреть свысока на остальных, а те отвечают ей недоверием и неприязнью. Для продуктовой компании это крайне опасно: вместо паверапа Dev и Ops мы возвращаемся в эру кабинетных войн. Те же яйцп, только в профиль
Цель этой статьи — не очернить всех DevOps‑инженеров (среди них множество отличных командных игроков), а привлечь внимание к этим тревожны м сигналам.
Update: в комментах и сообществе посоветовали еще 2 отличных статьи на эту тему, добавлю сюда:
Если вдруг интересно — мой канал.
