Почему ваша команда разработки замедляется, даже если вы продолжаете нанимать людей
Несколько лет назад в одной продуктовой команде, с которой я работал, было пятнадцать инженеров. Они выпускали фичи каждые две недели. Руководство решило удвоить размер команды, чтобы ускорить поставку. Через шесть месяцев, имея тридцать инженеров, они выпускали фичи раз в три недели. Все были в недоумении. Инженеры не были ленивы. Они не были менее квалифицированы. Что-то невидимое их замедляло.
Это невидимое — то, что мы сейчас называем когнитивной нагрузкой. И это главная причина, по которой существует платформенная инженерия.
Скрытая работа перед написанием кода
Представьте, что вы разработчик, которому поручили создать новую фичу. Прежде чем написать хотя бы одну строку бизнес-логики, вам нужно:
- Настроить новый репозиторий с правильными правилами защиты веток
- Создать пайплайн сборки и пайплайн тестирования
- Настроить среду разработки, которая подключается к базе данных для разработки
- Разобраться, как разворачивать на стейджинге
- Изучить процесс деплоя в продакшн в компании
- Понять, как откатывать изменения, если что-то пошло не так
- Настроить мониторинг и логирование для вашего сервиса
Каждая из этих задач требует переключения контекста. Вам нужно помнить, какой инструмент команда использует для CI, какой облачный провайдер хостит стейджинг, какая версия базы данных совместима и у кого спрашивать доступ к продакшену.
Для разработчика, который хочет сосредоточиться на создании фич, видимых пользователям, это выматывает. И дело не в навыках. Даже старшие инженеры замедляются, когда им приходится жонглировать знаниями об инфраструктуре вместе с логикой фичи.
Реальная цена: когнитивная нагрузка
Когнитивная нагрузка — это объем умственных усилий, необходимых для выполнения задачи. Когда вы пишете фичу, ваш мозг обрабатывает бизнес-логику, потоки данных, граничные случаи. Это уже много. Теперь добавьте команды деплоя, переменные окружения, конфигурацию пайплайнов и процедуры отката. Ваш мозг теперь делит свою мощность между двумя совершенно разными областями.
Результат предсказуем: фичи занимают больше времени, ошибки случаются чаще, а инженеры чувствуют себя опустошенными в конце дня. Не потому, что они плохо делают свою работу, а потому что вынуждены удерживать в голове слишком много вещей одновременно.
Эта проблема усугубляется по мере роста компании. Команда из трех-пяти человек может делиться знаниями неформально. Все знают, как каждый деплоит. Но когда у вас десять продуктовых команд, у каждой свои предпочтения, хаос умножается. Одна команда использует Jenkins. Другая — GitLab CI. Третья — GitHub Actions. Одна команда деплоит напрямую в продакшн. Другая требует три уровня ручного одобрения. Одна команда работает с Kubernetes. Другая — с обычными виртуальными машинами.
Теперь платформенная или DevOps-команда перегружена, потому что каждой команде нужна помощь с разными настройками. А продуктовые команды все еще медленные, потому что тратят половину времени на инфраструктуру.
Платформенная инженерия — это не очередной инструмент
Вот тут и появляется платформенная инженерия. Но важно понять, чем она является, а чем нет.
Платформенная инженерия — это не создание красивой панели управления и не покупка нового инструмента. Это смена мышления: инфраструктура и пайплайны больше не являются побочными проектами, которыми команды занимаются, когда есть время. Они становятся внутренними продуктами, которые должны проектироваться, создаваться и поддерживаться с той же тщательностью, что и продукты, которые используют ваши клиенты.
Основная идея проста: вместо того чтобы каждая команда строила свой пайплайн с нуля, платформенная команда предоставляет готовый к использованию путь. Вместо того чтобы каждая команда училась деплоить в продакшн, платформа предоставляет проверенный, безопасный механизм деплоя. Продуктовые команды сосредотачиваются на коде и фичах. Платформа берет на себя инфраструктуру и накладные расходы на пайплайны.
Это кардинально снижает когнитивную нагрузку. Разработчикам больше не нужно помнить, как настраивать окружения, как конфигурировать мониторинг или как выполнять откаты. Платформа делает это. Они просто пишут код и запускают уже существующий пайплайн.
Ловушка универсального подхода
Но вот где многие попытки создания платформы проваливаются. Они пытаются заставить каждую команду работать по одному и тому же процессу. Это не работает, потому что у команд разные потребности. Одним нужны быстрые циклы деплоя. Другим — строгие шлюзы утверждения. Третьи используют специфические базы данных или языки программирования, требующие особого подхода.
Если платформа слишком жесткая, команды будут ее обходить. Они создадут свои обходные пути, и вы вернетесь к исходной проблеме фрагментированной инфраструктуры и высокой когнитивной нагрузки.
Хорошая платформа учитывает различия, не заставляя команды снова управлять всем самостоятельно. Она предоставляет стандартный путь, покрывающий общие случаи, но позволяет командам делать выбор там, где это важно. Здесь и появляется концепция золотого пути, которую мы подробно рассмотрим позже.
Что это значит для вашей команды
Если ваша команда разработки растет, а скорость поставки — нет, посмотрите на невидимую работу. Спросите своих разработчиков: что вам нужно знать или сделать, прежде чем вы сможете начать писать фичу? Ответы покажут, где когнитивная нагрузка самая высокая.
Цель платформенной инженерии — не контролировать команды. Это устранение трения, которое их замедляет. При правильном подходе это позволяет разработчикам оставаться в состоянии потока, создавая фичи, которые имеют значение, пока платформа занимается остальным.
Практический чеклист
Прежде чем начать создавать платформу, задайте эти вопросы:
- Какие задачи разработчики повторяют для каждой фичи или сервиса?
- Какие задачи по инфраструктуре требуют больше всего времени на изучение или отладку?
- Где команды создают свои обходные пути, потому что существующий процесс не подходит?
- Что нужно знать разработчику, чтобы развернуть новый сервис с нуля сегодня?
- Какие части пайплайна вызывают больше всего беспокойства или задержек во время релизов?
Вывод
Ваша команда замедляется не потому, что плохо делает свою работу. Она замедляется, потому что несет невидимый груз. Платформенная инженерия — это про снятие этого груза, а не про добавление новых инструментов. Начните с понимания того, с чем ваши разработчики действительно борются, а затем постройте путь, который сделает эти проблемы незаметными.