Платформенная инженерия: от команды ops к внутреннему продукту
Platform engineering - не просто новое слово для DevOps. Это сдвиг в том, как инфраструктурная команда думает о своей работе и кто является её клиентом.
В середине 2010-х DevOps звучал как ответ на вопрос, как ускорить выпуск программного обеспечения. Убрать барьер между разработкой и эксплуатацией. Дать командам возможность деплоить самостоятельно. Это работало и продолжает работать.
Но по мере того как организации росли и количество команд разработки увеличивалось, появилась новая проблема: каждая команда самостоятельно решала одни и те же задачи. Настраивала CI/CD, управляла контейнерами, разбиралась с мониторингом. Дублирование усилий нарастало, а когда что-то шло не так - никто не был явным владельцем.
Платформенная инженерия - это ответ на этот вопрос.
Что такое платформенная команда
Платформенная команда создаёт и поддерживает внутренний продукт для других команд разработки. Этот продукт называется Internal Developer Platform - IDP. В нём может быть: способ развернуть приложение, инструменты мониторинга и алертинга, управление секретами, пайплайны для тестирования, справочные окружения.
Ключевой сдвиг мышления: платформенная команда думает о разработчиках как о своих пользователях. У неё есть беклог, она собирает обратную связь, она измеряет adoption. Не "мы поддерживаем инфраструктуру", а "мы делаем продукт, который помогает другим командам работать быстрее и надёжнее".
Почему это важно для руководителей
Без платформенной команды в больших организациях происходит следующее: несколько команд разработки делают примерно одно и то же по-разному. Когда появляется новое требование - поддержка ещё одного облака, новые требования безопасности - каждая команда решает это самостоятельно. Стоимость умножается на количество команд.
С платформенной командой это решается один раз и становится частью продукта. Остальные команды просто используют.
Второй эффект: снижение cognitive load разработчиков. Когда есть понятный, документированный способ развернуть сервис или настроить мониторинг - разработчик занимается продуктом, а не инфраструктурой.
Где это не работает
Платформенная команда не работает там, где она создаёт инфраструктуру, которую никто не хочет использовать. Это случается, когда:
- команда создаёт продукт исходя из своих представлений, а не потребностей разработчиков;
- adoption принудителен, а не добровольный;
- обратная связь не собирается или не влияет на приоритеты;
- платформа сложнее, чем то, что она должна заменить.
Внутренний продукт подчиняется тем же законам, что и внешний: если им не пользуются - значит, он не решает настоящую проблему.
Признаки готовности к переходу
Не каждой организации нужна выделенная платформенная команда. Это обоснованно, когда:
- в компании несколько продуктовых команд с похожими инфраструктурными потребностями;
- каждая команда тратит значительное время на задачи, не связанные с продуктом;
- есть повторяющиеся инциденты из-за несогласованных инфраструктурных решений;
- onboarding нового разработчика занимает недели вместо дней из-за сложности окружения.
Если два-три пункта про вас - это сигнал, что стоит серьёзно рассмотреть этот подход. Не обязательно начинать с отдельной командой: часто достаточно начать с явного владельца и продуктового мышления применительно к инфраструктуре.