Когда одного DevOps мало и зачем нужна платформенная команда

Для небольшой команды одного DevOps-инженера обычно вполне достаточно, чтобы закрывать все инфраструктурные вопросы. С ростом бизнеса и продукта число обращений растет, и тут руководство часто решает набрать больше специалистов. Но если модель работы остается прежней, дополнительный наем не поможет решить проблемы и ускорить релизы. Рассказываем, как понять, что одного DevOps стало не хватать, зачем бизнесу платформенная команда и почему ее задача — не забирать инфраструктуру у разработчиков, а давать им больше самостоятельности.

Один за всех

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

Проблемы начинаются, когда нерегулярные запросы превращаются в поток. Разработчики постоянно просят настроить CI/CD, подключить мониторинг или помочь с релизом. И даже если каждая из этих задач не занимает много времени, постоянное переключение между ними постепенно забирает все внимание специалиста.

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

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

В такой момент вместо расширения DevOps-функции компании нужно переходить от отдельных запросов к повторно используемым сервисам. Здесь и появляется платформенная команда.

Смена модели

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

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

Облако и энтерпрайз

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

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

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

Когда пора менять модель

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

Можно выделить три основных признака, что наступило время менять модель:

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

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

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