В чём проблема DevOps
Каждый раз, когда появляется новый громкий термин, в индустрии начинается традиционный спор «умрет ли старое». Так было с DevOps, когда все хоронили админов. Так же сейчас пытаются похоронить DevOps в пользу Platform Engineering. Но, по моему опыту и как человека, который последние годы строит облачную инфраструктуру под сотни проектов, это не история про смерть — это история про эволюцию. И про болезненное взросление.
Проблема ведь в чём: количество сервисов в компаниях растет быстрее, чем инфраструктурная команда успевает их обслуживать. Это особенно видно у тех, кто переходит от нескольких монолитов к десяткам микросервисов. У нас в Облакотеке есть клиенты, у которых за один квартал число сервисов выросло вдвое — и DevOps просто физически не успевали обслуживать весь цикл.
Типичная сцена: команда разработки просит поднять новый стенд, DevOps говорит «в очереди пять задач», релиз сдвигается — и все начинают ворчать, что «DevOps тормозят бизнес». На самом деле это просто предел масштабируемости ручной работы.
Когда пора создавать платформенную команду: признаки из реальной жизни
Я вижу несколько очень четких сигналов, что компания уже доросла до Platform Engineering:
- DevOps превращаются в «машину по выдаче инфраструктуры». Если 70–80% времени уходит на однотипные запросы: создать кластер, выдать CI/CD пайплайн, залатать окружение, подключить мониторинг — это значит, что процессы не автоматизированы до уровня «самообслуживания».
- Непредсказуемые сроки релизов. В одной компании, с которой мы работали, среднее время между «мы готовы выкатывать» и фактическим релизом доходило до 10 дней. Причина — узкое горлышко в DevOps. После внедрения платформенной команды этот показатель сократился до пары часов.
- Усталость DevOps и высокий bus factor. Когда все знают, что, если «Лёша DevOps» внезапно заболеет, релизы встанут. Это не DevOps-культура — это хрупкость.
- Разработчики боятся трогать инфраструктуру. Если любая мелочь требует обращения «куда-то наверх», это уже не DevOps. DevOps предполагает shared responsibility. А платформа — это инструмент, который делает эту модель рабочей.
По-хорошему платформа должна дать разработчикам возможность нажать кнопку и получить готовую инфраструктуру в рамках заранее определенных правил. И вот именно это — зона ответственности Platform Engineering.
Где заканчивается DevOps и начинается Platform Engineering
Я бы сформулировал так:
- DevOps — это культура и практики. Как команда работает, как она автоматизирует, как она снижает разрыв между Dev и Ops.
- Platform Engineering — это продукт. Конкретный, живой, эволюционирующий продукт, который предоставляет разработчикам стандартизированную инфраструктуру как сервис.
У DevOps фокус — на процессах. У платформенной команды — на пользовательском опыте разработчика. Когда у вас 5–7 команд разработки, DevOps вполне хватает. Когда команд становится 10+, а сервисов — десятки, DevOps начинают утопать в рутине. Именно тогда появляется запрос на платформу.
Почему Platform Engineering часто буксует
Тут, увы, много боли. Во-первых, многие компании воспринимают платформу как «еще один опт-код DevOps» — и пытаются сделать то же самое, только по-другому назвав. Ничего не меняется.
Во-вторых, платформенная команда часто отрывается от реальности. Рисует красивый каталог сервисов, но в нем нет того, что реально нужно разработчикам. Я несколько раз видел такие истории у клиентов: платформа есть, но все продолжают писать в Slack «ребят, поднимите стенд». Это значит, что платформа сделана не под разработчика, а под внутреннюю презентацию.
В-третьих, платформа не появляется из ниоткуда. Это всегда техдолг, стандартизация, политика доступа, IAM, мониторинг, CI/CD, security-by-default. Кому-то надо этим заниматься системно. И тут требуется команда, которая мыслит долгосрочно, а не гасит пожары.
Как измерять эффективность платформы
Метрики здесь очень прозрачные. Мы в облаке видим их у разных команд:
- Скорость деплоя. До платформы: релиз — событие. После — рутинное действие в пару минут.
- MTTR. Хорошая платформа имеет стандартизированный мониторинг и алертинг — время восстановления падает в несколько раз.
- Onboarding time. Было: две недели, чтобы новому разработчику разобраться, «куда тут вообще деплоить». Стало: один рабочий день.
- Когнитивная нагрузка. Моя любимая. Если разработчик не бегает между Terraform, Helm, Vault и Kubernetes, а работает через единый интерфейс — это самое честное измерение успеха.
Условно, если платформа не уменьшила количество контекстов, в которых живет разработчик, — это не платформа, а «набор инструментов в коробке».
Технический долг платформы
Про него любят молчать. Но платформа стареет еще быстрее, чем код в продуктах.
Я видел компании, где внутренняя платформа на Kubernetes пять лет не обновлялась — просто потому, что все думали «ну работает же». Итог: боль при миграции, сломанные пайплайны, хаос с версиями, невозможность внедрить нормальный security baseline.
Платформа должна развиваться как отдельный продукт: роадмап, регулярные обновления, SLA, обратная связь с разработчиками. Если этим не занимается команда — платформа деградирует.
Так Platform Engineering — смерть DevOps или нет?
Нет, это логичное продолжение. DevOps никуда не исчезает — он просто уезжает «внутрь платформы». Все best practices DevOps — автоматизация, CI/CD, мониторинг, IaC — становятся компонентами платформы. А расчистка рутинных задач позволяет DevOps перейти на уровень архитектуры, стабильности и безопасности, а не на уровень «подними мне стенд». По сути, Platform Engineering — это DevOps в масштабе.
Компании взрослеют, систематизируются, перестают зависеть от конкретных людей и строят реальные инженерные продукты внутри. И это всегда признак того, что бизнес перешел к следующей фазе роста.
И если уж совсем честно, платформа делает DevOps-инженеров только нужнее. Просто теперь это инженеры, которые думают как продуктовые менеджеры и отвечают за опыт разработчика, а не за конфигурацию кластера.
