Платформенная команда как следующий шаг после сильной эксплуатации

Когда компания вырастает из этапа "один сисадмин решает всё", у неё появляется эксплуатационная команда. Несколько человек, которые знают серверы, умеют деплоить и держат системы в живом состоянии. Это работает. Определённое время.

Потом начинается следующий этап - и он ломает ту же модель, которая раньше спасала.

Где ломается сильная эксплуатация

Проблема не в том, что команда плохо работает. Проблема в том, что число продуктовых команд растёт, каждая из них хочет свою инфраструктуру, и эксплуатация превращается в узкое место. Каждый запрос - отдельный тикет. Каждый деплой - ручная работа. Каждая новая команда учится с нуля, как поднять окружение.

Я видел несколько компаний, где именно в этот момент начинались серьёзные трения. Разработчики жаловались на скорость. Эксплуатация жаловалась на объём запросов. Хаотичность росла, а не падала, несмотря на найм.

Причина простая: эксплуатация делает работу для команд. Платформа делает инструменты, которыми команды работают сами. Та же логика применима к скорости релиза: когда выпуск ограничен эксплуатацией, а не продуктовыми решениями, это перестаёт быть культурной проблемой и становится инфраструктурной.

Что такое платформенная команда

Платформенная команда - это не переименованный Ops. Это смена направления работы.

Вместо того чтобы обслуживать запросы продуктовых команд напрямую, платформенная команда строит внутренние инструменты, окружения и процессы, которые позволяют продуктовым командам обслуживать себя самостоятельно. Она работает на продуктовые команды так же, как SaaS-продукт работает на своих пользователей: через интерфейс, документацию и предсказуемые контракты.

Типичные результаты работы платформенной команды:

• стандартизированные окружения, которые поднимаются без участия Ops;
• общие пайплайны сборки и деплоя;
• инструментарий для логирования, мониторинга, алертов - уже настроенный;
• внутренние стандарты безопасности, встроенные в шаблоны, а не предписанные отдельно.

Продуктовая команда берёт это и идёт работать. Без ожидания тикета.

Почему этот переход трудный

Большинство хороших специалистов по эксплуатации думают операционно: есть проблема - надо решить. Платформенный подход требует другого мышления: есть класс проблем - надо выстроить систему, которая решает их автоматически.

Это не технический вопрос - это вопрос фокуса и модели работы. И этот сдвиг требует явного решения со стороны руководства, а не органического роста.

Кроме того, платформенная команда должна воспринимать продуктовые команды как своих клиентов. Это значит - узнавать их потребности, принимать обратную связь, инвестировать в документацию и удобство использования. Для людей с техническим бэкграундом это непривычно. Более ранняя ступень этой зрелости - переход от разовых запросов к структурированному каталогу услуг - обязательный шаг до того, как платформенная команда вообще имеет смысл.

Когда начинать думать об этом

Несколько признаков, что момент наступает:

• Эксплуатация регулярно является узким местом на пути к деплою.
• Каждая новая продуктовая команда заново решает одни и те же инфраструктурные вопросы.
• Нет стандарта: разные команды используют разные инструменты, несовместимые между собой.
• Разработчики тратят значительное время на инфраструктурные задачи вместо продуктовых.

Если хотя бы два из этих признаков присутствуют одновременно - тема платформенной команды заслуживает серьёзного разговора.

Практический вопрос для ИТ-директора

Спросите себя: если завтра появится ещё одна продуктовая команда, сколько времени займёт у эксплуатации поднять для неё окружение? Если ответ - "несколько дней и несколько человек" - это сигнал. Платформенная команда нужна не тогда, когда всё сломалось. Нужна тогда, когда старая модель перестала масштабироваться.