Четыре команды. Ноль согласованности. Так начался один из моих enterprise-проектов — и именно он научил меня тому, чего не пишут в вакансиях: настоящая работа DevOps — это согласовать кросс-функциональные команды, а не собрать pipeline. С pipeline всё было в порядке. Люди, которые через него катили релизы, гребли в четыре разные стороны.
Product хотел фичи ещё вчера. Security блокировал каждый деплой, который не прошёл ревью. Cloud engineering жил по своему плану миграции. TechOps ставил стабильность выше всего. И каждый из этих приоритетов был по-своему правильным. А раз никто их не связывал — каждая команда тихо становилась узким местом для трёх остальных.
DevOps — это не команда. Это мост.
Когда ты — точка контакта по DevOps сразу на нескольких enterprise-проектах, твою ценность меряют не в коммитах. Её меряют в том, смогут ли четыре команды с противоречащими интересами выкатить одно и то же без политического скандала. Бывали месяцы, когда я проводил на встречах по согласованию больше времени, чем писал код, — и раньше меня это бесило. Пока я не увидел, что происходит, когда я перестаю это делать.
Лучшие DevOps-инженеры не просто деплоят код. Они деплоят согласованность. А согласованность даётся тяжелее любого Helm chart, который я когда-либо писал.
Первым чинится не pipeline, а карта ответственности
За восемь лет и с десяток индустрий я научился в первый день игнорировать тулинг. Первое, что я собираю, — это framework координации, и он до неловкости простой:
- Границы ответственности. Кто за что отвечает — записано, без разночтений. Половина всех межкомандных конфликтов — это когда двое уверены, что «этим занимается та команда».
- Общие сроки с явно прописанными зависимостями. Не Gantt-диаграмма для галочки, а честный список «X не стартует, пока не выкатят Y».
- Понятные пути эскалации. Чтобы, когда всё встало, ты эскалировал конкретному человеку, а не в пустоту Slack, и никого не ставили перед фактом.
- Еженедельные кросс-командные синки с логом решений. Не протокол. Решения. Кто что решил, когда и кто был в комнате.
Я, честно, ненавижу встречи. Но один час согласования экономит десять часов «стоп, я думал, ЭТИМ занимается ТВОЯ команда». Никаких встреч без результата. Каждое решение записано и роздано всем.
Перелом на том проекте случился на третьей неделе — когда люди начали читать лог решений раньше, чем писать мне. Вот тогда это перестало держаться на моей голове и стало системой.
Разблокируй зависимости, пока они не стали блокерами
Настоящая суперсила — не тушить пожары, а увидеть столкновение за две недели и тихо его убрать:
- Security нужно policy review — ставим его в календарь заранее, до окна миграции, а не утром того же дня.
- Cloud engineering меняет API — product-команда узнаёт об этом в тот же день, а не из упавшего билда.
- TechOps поднимает вопрос стабильности — он идёт в architecture review, пока не превратился в продакшн-инцидент в два часа ночи.
Без человека, который это делает, команды сидят заблокированные и ждут друг друга, а каждая задержка накапливается. С таким человеком воркстримы идут параллельно, и решения реально принимаются.
Стек меняется. Человеческая проблема — нет.
Этот же сценарий я прогонял в совершенно разных доменах:
- FinTech — согласовать ревью на соответствие PCI DSS так, чтобы оно не сваливалось как снег на голову перед релизом.
- AdTech — свести multi-tenant миграцию на GCP по 8 проектам и нескольким группам стейкхолдеров, которые до этого вообще не общались.
- Manufacturing — состыковать глобальные commerce-команды и cloud-инфраструктуру через таймзоны, которые почти не пересекались.
Технический стек менялся каждый раз. Человеческий вызов — никогда. Самые тяжёлые задачи в DevOps — это проблемы людей в костюме инженерных проблем. А доверие не автоматизируешь.
Четыре команды, четыре приоритета, один pipeline
Тот первый проект уехал в прод. Не потому что pipeline стал лучше — с ним всё это время было нормально, — а потому что четыре команды наконец посмотрели в одну сторону. Я провёл в согласовании больше часов, чем в терминале, и именно это дало доставку.
Так что вот вопрос, который я задаю себе — и задам тебе: сколько в твоей неделе реально кода, а сколько — согласования? Потому что чем дольше я в профессии, тем сильнее подозреваю, что именно второе число и выкатывает продукт.