Платформенная инженерия после волны DevOps: что меняется для ИТ-руководителя
Как идея internal developer platform трансформирует роль ИТ в компании и почему это стратегический, а не только операционный вопрос.
2023 год стал годом, когда термин "platform engineering" перестал быть нишевым и вошёл в широкое употребление. Gartner включил его в список ключевых трендов, крупные компании начали формировать выделенные platform teams, появились специализированные инструменты и сообщества. Стоит разобраться, что за этим стоит и почему это важно не только для технических директоров.
Откуда это выросло
DevOps как подход решил важную проблему: убрал барьер между разработкой и эксплуатацией. Команды стали сами деплоить свои сервисы, отвечать за них в продакшне, думать об операционных характеристиках.
Но по мере роста масштаба возникла другая проблема. Каждая команда разработки тратит значительную часть времени не на бизнес-логику, а на инфраструктурные задачи: настройку CI/CD, управление конфигурациями, работу с облачными ресурсами, логирование, мониторинг. Это работа, которая воспроизводится десятки раз в разных командах с небольшими вариациями.
Platform engineering - это ответ на этот вопрос. Выделенная команда берёт на себя создание и поддержку "золотого пути" для разработчиков: набор готовых шаблонов, инструментов и процессов, который позволяет создать новый сервис и вывести его в продакшн быстро и предсказуемо.
Чем это отличается от классической ИТ-инфраструктуры
Ключевое слово - "продукт". Platform team строит внутренний продукт для внутренних клиентов (разработческих команд). Это означает, что к платформе применяются те же принципы, что к внешним продуктам: ориентация на пользователя, итеративное развитие, сбор обратной связи, измерение удовлетворённости.
Это принципиальное отличие от традиционного подхода "ИТ как сервисная служба", где стандарты спускаются сверху и от разработчиков ожидается их соблюдение. Platform engineering - это "инфраструктура как продукт", которым хотят пользоваться.
Если разработчики обходят платформу и строят собственные решения - это сигнал, что платформа не решает реальные потребности. Не плохие разработчики, а плохой продукт.
Почему это меняет разговор о ИТ-бюджете
Платформенная команда - это инвестиция в производительность всей разработки, а не операционные расходы конкретного сервиса. Это означает другую логику обоснования бюджета.
Если platform team сокращает время от "идея фичи" до "фича в продакшне" на 30% - это можно посчитать в деньгах. Если она сокращает количество инфраструктурных инцидентов - это тоже измеримо. Если она снижает стоимость онбординга новых разработчиков - это видно в бюджете найма.
Платформенная инженерия хорошо поддаётся обоснованию через бизнес-метрики, не только через технические показатели.
Признаки того, что это актуально для вашей компании
- Несколько команд разработки, каждая со своими инфраструктурными практиками.
- Повторяющиеся жалобы на время, которое уходит на инфраструктурные задачи, а не на бизнес-задачи.
- Сложности с онбордингом новых разработчиков.
- Трудности с поддержанием единых стандартов безопасности и операционного контроля.
- Рост числа сервисов при нехватке времени на их поддержку.
Если эти признаки узнаются - разговор о platform engineering имеет смысл начать. Не как технический проект, а как инвестицию в операционную эффективность разработки.
Простой вопрос для проверки
Если взять нового разработчика и попросить его создать, оттестировать и задеплоить простой сервис с нуля - сколько это займёт и сколько инструкций из разных мест ему придётся изучить?
Если ответ - "несколько дней и много мест" - это и есть проблема, которую решает platform engineering.