8.4 Платформенная инженерия и опыт разработчика

Обзор и мотивация

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

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

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

Ключевые принципы

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

Компромиссы: плюсы и минусы

Выбор	Плюсы	Минусы	Лучше всего подходит
Платформа как продукт (по желанию)	Заслуживает принятие; остаётся полезной	Медленнее достигает полного охвата	Большинство организаций
Обязательная платформа	Быстрая стандартизация	Обида; обходные пути	Только сильные нужды управления
Покупка портала/платформы	Быстрее к ценности	Менее подогнано; цена лицензий	Команды, желающие фору
Построение внутри	Подходит точным нуждам	Высокая цена построения и сопровождения	Большие, своеобразные организации
Только жёсткие золотые пути	Максимальная согласованность	Блокирует законные крайние случаи	Очень однородные нагрузки
Гибкие пути с аварийными выходами	Уравновешивает согласованность и автономию	Некоторое расхождение для управления	Разнообразные нужды команд

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

Вопросы для обсуждения с командой

Как вы узнаете, что платформа снижает когнитивную нагрузку, а не добавляет ещё один инструмент для изучения? Когнитивная нагрузка это общее умственное усилие, которое инженер тратит на работу, и платформа, добавляющая понятия и переключения контекста, может ухудшить её, даже выглядя впечатляюще. Примите один тест для каждой функции: снижает ли она нагрузку на команды, которые ею пользуются, или увеличивает? В масштабе это решающе, потому что платформа стоит перед сотнями инженеров, и запутанная абстракция облагает налогом их всех ежедневно. Принесите свидетельства: со сколькими инструментами и порталами разработчик имеет дело, чтобы отгрузить изменение, время до первого развёртывания для нового сотрудника и качественную обратную связь о том, где люди застревают. Если платформа разрастает набор инструментов, а не сокращает, вы построили налог, а не проторённую дорогу.
Какие стандарты принуждают ваши карты оценок и что на самом деле происходит с сервисом, получившим плохую оценку? Карты оценок измеряют каждый сервис относительно ожиданий вроде покрытия тестами, позиции безопасности, готовности к дежурствам и документации, а их ценность рушится, если красная оценка не влечёт последствий. Решите, будут ли карты оценок чисто рекомендательными, питать рецензию или ограничивать определённые возможности, и решите, кто владеет стандартами. В регулируемых организациях карты оценок могут давать надзорным органам непрерывную видимость позиции соответствия, заменяя ручную отчётность, поэтому планка, которую вы задаёте, важна. Принесите ваши черновые стандарты и выборку реальных сервисов, оценённых по ним, и обсудите, где команды законно возразят. Карта оценок, по которой никто не действует, это панель; карта оценок, привязанная к ясным ожиданиям, меняет поведение.
Ведёте ли вы платформу как настоящий продукт, с дорожной картой, исследованиями пользователей и метриками принятия, или как мандат? Центральная ставка этой главы в том, что стандартизация должна быть привлекательной, а не принудительной, и это держится, только если вы воспринимаете внутренних инженеров как клиентов, которых нужно завоевать. Решите, кто играет менеджера продукта платформы, как вы собираете нужды разработчиков и какие числа принятия и удовлетворённости определяют успех. Для больших организаций мандат соблазнителен, потому что стандартизирует быстро, но порождает обходные пути и обиду, когда инструменты замедляют людей. Принесите нынешние доли добровольного принятия, сигналы удовлетворённости и главные точки трения, о которых сегодня сообщают команды. Если бы команды бросили платформу в момент снятия мандата, вы построили не продукт, а политику.
Когда команда достигает края золотого пути, каков аварийный выход и кто решает, расширять ли путь или держать линию? Золотой путь это поддерживаемый категоричный маршрут с разумными умолчаниями, и его ценность идёт от того, что большинство команд остаётся на нём, однако путь без выхода превращается в шлагбаум, выталкивающий действительно необычную работу с платформы совсем. Договоритесь заранее, как команда запрашивает отклонение, кто его рецензирует и как отличить разовое исключение от сигнала, что сам путь должен измениться. Для большой организации это разница между платформой, поглощающей разнообразие, и платформой, распадающейся на теневые инструменты в момент, когда команда чувствует себя заблокированной. Принесите нынешнее число команд, ушедших с пути, названные причины и сколько времени занимает одобрение исключения. В корпоративной и государственной среде привяжите каждый аварийный выход к средствам контроля соответствия, которые он обходит, так что отклонение от проторённой дороги никогда тихо не станет отклонением от базы безопасности или аккредитации.
Строите ли вы платформу внутри или покупаете и честно ли вы оценили постоянную цену любого пути? Платформа сама продукт с жизненным циклом, и выбор «построить или купить» задаёт вашу структуру затрат на годы: внутренний портал подходит вашим точным нуждам, но требует финансируемой команды для сопровождения, тогда как купленная платформа быстрее достигает ценности ценой лицензий и посадки, которая никогда не идеальна. Решите, какие возможности достаточно отличительны, чтобы строить, а какие товар, который следует покупать, и пересматривайте эту линию по мере зрелости поставщиков. Для большой команды ставки это рычаг: неверное решение строить топит дефицитных старших инженеров в сантехнику, которую обработал бы продукт, а неверное решение покупать запирает сотни разработчиков в чужую дорожную карту. Принесите реалистичную оценку совокупной стоимости для каждого варианта, включая сопровождение, обновления и цену выхода. В корпоративных и государственных закупках добавьте условия аккредитации и переносимости данных и предпочитайте контракты, позволяющие уйти, не бросая каталог сервисов и карты оценок, построенные поверх.
Как финансируется платформенная команда и каков её размер относительно разработчиков, которых она обслуживает, и что с ней происходит, когда бюджеты сжимаются? Платформа отрабатывает своё содержание рычагом, поскольку малая команда умножает продуктивность гораздо большей популяции разработчиков приложений, но эта же рамка делает её лёгкой мишенью, когда финансы ищут сокращения, а выгода рассеяна и не относится к одной продуктовой линии. Решите модель финансирования, соотношение платформенных инженеров к разработчикам, которых они поддерживают, и как вы будете защищать это вложение свидетельствами, а не верой. Для большой организации недофинансированная платформа хуже отсутствия: команды зависят от неё, она разлагается, и трение возвращается с привязанной зависимостью. Принесите штат платформы, тренд её принятия и удовлетворённости и оценку возвращённых часов разработчиков по организации. В государственных и регулируемых корпорациях формулируйте платформу как место, где соответствие закодировано один раз, так что сокращение её не экономит деньги, а заново рассыпает работу по аудиту и безопасности по каждой команде, которой теперь придётся делать её вручную.

Взгляд по секторам

Стартап. С горсткой инженеров и без запаса не поднимайте платформенную команду; постройте один шаблонный репозиторий золотого пути, который новый сервис может клонировать и запустить за час. Заранее подключите к нему CI, сборку контейнера, линтинг и проверку здоровья и пусть он распространяется потому, что явно экономит время, а не потому, что кто-то его предписывает. Покупайте каждую товарную возможность, какую можете, держите набор инструментов малым и воспринимайте когнитивную нагрузку, а не покрытие, как то, что нужно защищать.

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

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

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

Примеры

Стартап. У стартапа из двенадцати человек нет платформенной команды, поэтому один старший инженер тратит несколько пятниц на построение единого шаблонного репозитория «новый сервис», заранее подключённого к CI, Dockerfile, линтингу и проверке здоровья. Любой инженер может клонировать его и получить работающий сервис в промежуточной среде за час, вместо копирования конфигурации из старого проекта и догадок о пробелах. Шаблон и есть золотой путь, и поскольку он явно экономит время всем, вся команда принимает его, и никому не приходится говорить.

Крупная организация. Большая страховая компания формирует платформенную команду, выпускающую внутренний портал разработчика. Он каталогизирует каждый сервис с его владельцем, документацией и картой оценок здоровья. Новые сервисы создаются из шаблонов золотых путей, заранее подключённых к CI/CD, проверкам безопасности, наблюдаемости и проверкам соответствия. Базы данных и среды готовятся по самообслуживанию через портал. Время вхождения нового инженера падает с недель до дней, а свидетельства аудита производятся автоматически, потому что каждый сервис следует одной проторённой дороге. Принятие платформы добровольное, и она распространяется потому, что использующие её команды отгружают заметно быстрее.

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

Бизнес-обоснование: мотивы, ROI и TCO

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

По TCO цена принятия реальное постоянное вложение: финансируемая платформенная команда, инструменты (построенные или купленные) и дисциплина ведения платформы как продукта с непрерывным улучшением. Цена непринятия рассеяна, но велика: каждая команда многократно платит тот же инфраструктурный налог, несогласованные безопасность и соответствие, медленное вхождение и старшие инженеры, выгорающие на рутине. Для руководства довод лучше всего строить в терминах рычага. Скромная, хорошо управляемая платформенная команда умножает продуктивность гораздо большей популяции разработчиков приложений и кодирует управление один раз, а не полагается на то, что каждая команда сделает всё верно.

Антипаттерны и ловушки

Платформа навязана, а не предложена. Предписание платформы, которую разработчики не любят, порождает обходные пути и обиду.
Платформенная команда в башне из слоновой кости. Строительство без понимания реальных нужд разработчиков производит инструменты, которые никому не нужны.
Шлагбаумы вместо проторённых дорог. Ограждения, блокирующие законную работу, заставляют команды вообще обходить платформу.
Единая метрика продуктивности. Сведение продуктивности к одному накручиваемому числу искажает поведение и разъедает доверие.
Измерение как слежка. Метрики DevEx, используемые для ранжирования отдельных людей, разрушают психологическую безопасность, нужную платформе.
Золотой путь без аварийного выхода. Жёсткие пути, не гнущиеся для настоящих крайних случаев, становятся препятствиями.
Недофинансированная платформа. Воспринимание платформы как побочного проекта морит её голодом и гарантирует плохой опыт.

Модель зрелости

Уровень 1: Начальный. Платформы нет. Каждая команда собирает собственные инструменты и инфраструктуру реактивно, с тяжёлыми передачами по заявкам, дублированными решениями и высокой когнитивной нагрузкой. Каждая команда решает подготовку, развёртывание и соответствие сама, непоследовательно.

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

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

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

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

Идеи для обсуждения

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

Главные выводы

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

Источники и дополнительное чтение

Matthew Skelton and Manuel Pais, Team Topologies.
Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, et al., “The SPACE of Developer Productivity” (paper).
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate.
Gregor Hohpe, The Software Architect Elevator.
Camille Fournier, The Manager’s Path.
Cloud Native Computing Foundation, platform engineering white paper.

8.4 Платформенная инженерия и опыт разработчика

Обзор и мотивация

Ключевые принципы

Рекомендации

Стройте платформу как продукт

Предоставляйте золотые пути и проторённые дороги

Обеспечьте подлинную инфраструктуру самообслуживания

Предлагайте порталы разработчика, каталоги сервисов и карты оценок

Измеряйте опыт разработчика сбалансированными рамками

Снижайте когнитивную нагрузку как первоклассную цель