До соответствия продукта рынку (product-market fit) у команды одна настоящая задача: выяснить, чего хотят люди. Инфраструктура здесь то, что помогает выпустить следующий эксперимент. Скрипт развёртывания, который понимает один человек, окружения, настроенные вручную, мониторинг, добавленный после первого сбоя. На этом этапе это правильный компромисс.
После того как соответствие найдено, те же привычки начинают стоить денег. Приходит больше инженеров, один сервис превращается в несколько, клиенты спрашивают про доступность и безопасность, а каждая команда решает одни и те же задачи по-своему. Многие растущие компании приходят к платформенной инженерии как к ответу на это. В этой статье разберём, что это такое, что входит во внутреннюю платформу для разработчиков, как понять, что она работает, и как строить её небольшими шагами.
Почему больно после соответствия продукта рынку, а не до
Когда в одной комнате пять инженеров, знания передаются разговорами. Все знают, как устроен релиз, потому что каждый его делал. Когда инженеров тридцать и команд шесть, это перестаёт быть правдой, и симптомы знакомы:
- Новому инженеру нужны недели, прежде чем первое изменение попадёт в продакшен. Большая часть времени уходит на доступы, настройку и выяснение, кто что знает.
- Каждый сервис развёртывается чуть иначе, поэтому переход между командами означает учиться заново.
- Инфраструктуру держат несколько человек, и каждая команда ждёт в их очереди.
- Вопросы безопасности и комплаенса приходят в конце, в виде проверки, которая блокирует релиз.
- Инциденты долго диагностируются, потому что каждый сервис пишет логи и отчитывается по-своему.
Никто здесь не виноват. Так бывает, когда число команд растёт, а способ работы остаётся тем, что подходил одной команде. Платить приходится вниманием инженеров. Время, которое должно уходить на продукт, уходит на служебную обвязку, причём одну и ту же обвязку строят по нескольку раз.
Что такое платформенная инженерия
Платформенная инженерия относится к инструментам и инфраструктуре, которыми пользуются инженеры, как к продукту, а клиентами считает собственных разработчиков компании. Небольшая команда создаёт и поддерживает набор возможностей самообслуживания (self-service), чтобы продуктовые команды могли создавать, выпускать и эксплуатировать ПО, не заводя заявку и не ожидая.
Она выросла из DevOps и не заменяет его. «Вы это построили, вы это и эксплуатируете» хорошо работает, пока от каждой команды не начинают ждать экспертизы в сетях облака, конвейерах, секретах и мониторинге в придачу к собственной предметной области. Платформа оставляет ответственность за продуктовой командой и избавляет от необходимости собирать всё из деталей.
Слово «продукт» здесь важно. Платформой, которую никто не просил и которую внедрили приказом, пользуются неохотно и обходят её. Платформу, построенную на реальных проблемах команд, принимают, потому что с ней проще всего сделать работу.
Что входит во внутреннюю платформу для разработчиков
Набор бывает разным, но большинство платформ покрывают одни и те же области:
- Шаблоны сервисов. Новый сервис начинается с шаблона, где уже подключены сборка, тесты, развёртывание, логирование и проверки работоспособности, так что работа первого дня уходит на функциональность.
- Окружения по запросу. Окружения для разработки, предпросмотра и staging, создаваемые из описания в коде и достаточно близкие к продакшену, чтобы результатам можно было доверять.
- Единый конвейер поставки. Один путь от влитого изменения до продакшена, с одинаковыми этапами для каждого сервиса.
- Инфраструктура как код. Базы данных, очереди и хранилище запрашиваются через описания, проходящие ревью, с разумными значениями по умолчанию.
- Секреты и доступы. Одно место для учётных данных и один способ выдавать и отзывать доступ.
- Наблюдаемость (observability). Логи, метрики и трассировки собираются везде одинаково, а дашборды и оповещения существуют с первого развёртывания.
- Каталог сервисов. Список сервисов с их владельцами, документацией, зависимостями и состоянием.
Сверху может стоять портал с удобным интерфейсом, но строить его надо в последнюю очередь. Ценность в самих возможностях и в их согласованности.
Проторённая дорога (paved road)
Платформу удерживает вместе идея проторённой дороги, которую иногда называют «золотым путём» (golden path): один хорошо ухоженный, хорошо документированный способ делать каждое типовое дело. Выбираете его, и развёртывание, мониторинг и безопасность идут в комплекте. С дороги можно сойти, но тогда вы сами несёте всё, что берёте на себя.
Это не правило, запрещающее всё остальное. Команда с необычной потребностью по-прежнему может пойти своим путём. Дорога должна быть лишь настолько удобнее, чтобы для ухода с неё нужна была причина.
Часть выгоды в головах инженеров. Каждое решение об инфраструктуре, которое инженеру не нужно принимать, оставляет внимание для продукта. Меньше способов делать одно и то же, значит меньше всего, что надо обновлять, документировать и объяснять.
Единый конвейер и встроенные ограждения (guardrails)
Когда каждая команда пишет свой конвейер, каждый конвейер становится маленьким продуктом со своими ошибками. Улучшения, сделанные в одном месте, не доходят до остальных, а при аудите приходится изучать каждый. Общий конвейер, используемый через шаблон с несколькими параметрами, превращает одно исправление в исправление для всех.
Больше всех выигрывает безопасность. Во многих растущих компаниях безопасность сводится к проверке ближе к концу: кто-то смотрит изменение, находит проблемы, и релиз ждёт. Ограждения переносят эти проверки на саму дорогу:
- Сканирование зависимостей и контейнеров в каждом конвейере.
- Обнаружение секретов до того, как изменение влито.
- Доступы описаны в коде и проходят ревью, как любое другое изменение.
- Политики проверяются автоматически: шифрование включено, публичных хранилищ нет, обязательные метки на месте.
- Журнал того, кто что и когда развернул, появляется побочным продуктом самого развёртывания.
Результат противоположен тому, чего обычно ждут от работы по безопасности. Релизы становятся быстрее, потому что проверки идут минуты на каждое изменение и перестают быть совещанием. Для компании, продающей регулируемым клиентам, доказательства, которые просит аудитор, уже существуют.