Добро пожаловать в очередной выпуск микрознаний от Microsoft на М365FM. Ваш ведущий – Мирку Петтерс. Сегодняшняя тема знакома почти всем, но мало кто понимает ее до конца – платформенная инженерия. Вы наверняка слышали о DevOps, идее о том, что разработчики и операционные команды работают вместе без швов, но в какой-то момент все пошло не так. Разработчики начали выполнять работу сисадминов, и эта система сломалась. К концу выпуска вы поймете, что пошло не так с DevOps, что такое внутренняя платформа разработчика, как «золотые пути», упрощают работу командам и почему лучшие инженерные коллективы уже внедряют их. Беспорядок, оставшийся после DevOps. Давайте вернемся к истокам. DevOps был отличной идеей с простой целью – разрушить барьеры между разработкой и эксплуатацией. Больше никакой передачи кода через забор в надежде на лучшее. Сдвиг влево, перенос нестеравания, безопасности и операции на более ранние этапы процесса.

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

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

Сегодня инструменты и позволяют разработчикам писать код быстрее, чем когда-либо в 10, 20 и даже 30 раз больше кода в день. Но весь этот код по-прежнему нуждается в инфраструктуре, безопасности и мониторинге. Больше кода без качественной системы – это просто путь к хаосу. Если вам кажется, что вы тонете в YML и Terraform, вы не одиноки. Это не ваша личная неудача. Это системная проблема. Текущая модель исказила само понятие платформенной инженерии. Так как же все исправить? Решение – платформенная инженерия, и вот как проще всего об этом думать. Эта дисциплина создает внутренний слой, который берет на себя всю сложность для разработчиков. Представьте, что вы заходите в большое офисное здание. Вам не нужно беспокоиться о том, у кого есть доступ на этаж, какой пропуск сработает или где находятся пожарные выходы. Стойка регистрации берет все это на себя, а вы просто входите и приступаете к работе.

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

Представьте ее как систему самообслуживания, которая автоматизирует всю рутинную работу. Подготовка инфраструктуры, CI, CD-пайплайны, проверки безопасности, мониторинг – все это встроено и стандартизировано. Вот конкретный пример. Если разработчик хочет развернуть новый сервис без такой платформы, он тратит дни на настройку инфраструктуры, написание пайплайнов и конфигурацию мониторинга. С IDP он просто нажимает «развернуть» в интерфейсе или вводит одну команду, и платформа делает все сама – подготовку ресурсов, тесты, мониторинг и деплей – за минуты, а не за дни. Итак, что это значит для вас? Вы перестаете быть мастером на все руки в инфраструктуре и становитесь специалистом по своему продукту. Ваша работа снова сводится к созданию полезных для клиентов функций, а не к отладке поврежденного файла состояния терраформ. В этом и заключается главная суть. Внутренняя платформа разработчика простыми словами.

Давайте разберем, что же на самом деле представляет собой внутренняя платформа разработчика. Это движок, который объединяет все в единую систему. Ваши CI, CD-пайплайны, шаблоны инфраструктуры, политики безопасности, мониторинг и логирование. Вместо шести отдельных инструментов, которые нужно связывать между собой. Вот вам аналогия. Представьте разницу между готовкой с нуля и использованием торгового автомата. Готовка с нуля – это покупка продуктов, нарезка овощей, дозировка специй, слежка за плитой. Множество решений, множество шагов и множество шансов все испортить. Торговый автомат выдает результат нажатием одной кнопки. Меньше решений, быстрее результат, стабильное качество. IDP – это и есть такой торговый автомат. Разработчику не нужно знать, как разворачивается инфраструктура или где хранятся секреты. Он просто нажимает кнопку. Что внутри этого торгового автомата? Основные компоненты довольно стандартны.

CI, CD-шаблоны для стабильных сборок, подготовка инфраструктуры для автоматического запуска окружений, управление секретами, чтобы пароли не разлетались по конфигам, и логирование со встроенной наблюдаемостью для быстрого устранения неполадок. Все это предварительно настроено, протестировано и поддерживается командой платформы. Вот конкретный пример. Разработчик вводит команду создания нового сервиса в консоли или нажимает кнопку на портале. За кулисами IDP разворачивает новый репозиторий с нужной структурой, создает пайплайн сборки с автотестами, деплоит сервис в среду разработки и добавляет инпоинты проверки состояния с логированием. Все это происходит за считанные минуты. Разработчик при этом не коснулся ни одного терраформ-файла и не настраивал кубернет-османифест. Просто ввел команду и получил работающий сервис. Почему это важно? Согласованность. Главная причина. Когда каждая команда создает свои пайплайны и пишет свои скрипты деплоа, вы получаете уникальные снежинки в конфигурациях.

50 разных сервисов, 50 разных способов работы. Когда что-то ломается, никто не может это исправить, кроме того, кто это создал. А если этот человек уволился из компании, удачи. IDP устраняет это, заставляя каждый сервис следовать одним шаблонам, каждый деплай использовать один пайплайн, а каждую команду получать одинаковые настройки по умолчанию. Когда что-то ломается, шаблоны уже знакомы, а исправление задокументировано. Итак, что это значит для вас? Если в вашей организации 50 команд выполняют деплай 50-10 разными способами, IDP — это ваше решение. Это не значит, что команды теряют автономность. Это значит, что скучные, повторяющиеся и подверженные ошибкам части стандартизируются, чтобы интересная творческая работа могла быть разнообразной. Это компромисс, на который стоит пойти. Золотые пути — это направление, а не клетка. Давайте поговорим о «золотых путях». Вы наверняка слышали это название, но идея проста.

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

Они оптимизируют все ради архитектурной частоты, соответствия стандартам или внутренних правил, которые никто вне команды не понимает. На доске все выглядит отлично, но пользоваться этим неудобно. Разработчики тихо находят обходные пути, охват падает, а платформа-команда недоумевает, почему никто не ценит их усилия. Решение простое, но его трудно реализовать. Нужны аварийные выходы. Если путь не подходит для задачи разработчика, у него должен быть способ выйти. Возможность переопределить настройки, использовать свой пайплайн или вовсе выйти за пределы платформы. И вот что здесь важно. Когда они сходят с пути, это не провал, это обратная связь. Каждый раз, когда разработчик покидает «золотой путь», это дает вам важную информацию. Либо пути не хватает функции, либо этот случай действительно не вписывается в стандарты. Оба сигнала ценны. Хороший «золотой путь» на практике выглядит так. Команде нужно развернуть новый бэкенд-сервис.

Они выбирают этот путь. Он дает им шаблон-репозитория с правильной структурой, про тестированный CI, CD-пайплайн, встроенное логирование и мониторинг, а также откат в один клик. Все занимает минуты вместо дней, и поскольку команда поддерживает путь, при поломках они сами все исправляют. Разработчику не нужно становиться экспертом по отладке пайплайнов. Что это значит для вас? Меньше сюрпризов. Вы поставляете продукт быстрее, потому что путь уже проверен. Вы делаете это безопаснее, так как защита и мониторинг встроены. Вы уверены в результате, потому что откат занимает один клик. Путь существует, чтобы помогать вам, а не сдерживать. Пользуйтесь им. Снижение когнитивной нагрузки. Вот где проявляется настоящая выгода. Когда платформа берет на себя всю тяжелую работу, разработчики могут сосредоточиться на коде. Им не нужно знать, какая версия Kubernetes сейчас запущена. Им не нужно обновлять модули Terraform каждый раз, когда облачный провайдер меняет API.

Они просто пишут функции. Инженеры платформы берут эту сложность на себя. Они решают, что разработчикам нужно видеть, а что должно оставаться скрытым. Это реальный выбор дизайна, а не просто техническое решение. Важно определить, какие детали действительно важны для пользователя, а какие — лишь лишний шум. Вот конкретный пример. Разработчику, внедряющему новый сервис, не важны размеры узлов кластера, типа инстанцев или пороги автомасштабирования. Их волнует только работоспособность сервиса и скорость его отклика. Поэтому платформа заранее настраивает все это в зависимости от уровня приложения. Небольшой сервис — вот подходящие настройки. Сервис с высокой нагрузкой — вот другая конфигурация. Разработчик не принимает эти решения, потому что в этом нет необходимости. Почему это важно? Потому что выгорание снижается, когда разработчики не жонглируют 15-ю задачами одновременно. Некоторые зрелые платформенные команды сократили когнитивную нагрузку почти вдвое.

На 40-50% меньше ментальных усилий. Это колоссальные перемены. Это разница между уходом с работы с запасом сил и разглядыванием терминала в 10 вечера с вопросом, почему упал пайплайн. Но вот предостережение. Не создавайте иллюзий. Некоторые платформенные команды попадают в ловушку. Они скрывают настройки, не давая разработчикам понять, что происходит под капотом. Это не абстракция, это обман, который выходит боком. Как только что-то идет не так, разработчики упираются в стену, которую не могут разглядеть, и платформа внезапно становится черным ящиком, работающим против них. Это называется дырявая абстракция. Вы скрываете сложность, но в конечном итоге она проявляется наружу. База данных тормозит, деплы не проходят. Политика безопасности блокирует что-то неожиданное. И у разработчика нет понимания ситуации, потому что платформа никогда его не давала. Прозрачность важна. Показывайте разработчикам-то, что им нужно знать, и тогда, когда это действительно необходимо.

Не скрывайте все подряд в надежде на лучшее. Что это значит для вас? Меньше переключений контекста и больше состояния потока. Вы не начинаете утро с мысли об обновлении кластера Kubernetes, вы начинаете его с работы над функцией, которая нужна на следующей неделе. Ваша работа снова становится именно вашей работой. Отношение к платформе как к продукту. Сегодня мы говорим о том, что меняет работу внутренних инструментов. Многие думают, что платформенная команда – это просто команда инфраструктуры. Это не так. Платформенная команда – это продуктовая команда, а использующие платформу разработчики, их клиенты, а не те, кто просто подает заявки. Это меняет все. Продуктовая команда общается с клиентами, выясняет, что им действительно доставляет боль, приоритизирует функции на основе реальных потребностей, измеряет уровень использования, не бросает проект после релиза, а постоянно его дорабатывает.

Так как же продуктовая команда выглядит на практике? Они работают не как служба поддержки. Разработчик создает тикет, а команда платформы выполняет его вручную. Это не платформенная инженерия, это просто централизованные операции под новым названием. Это не масштабируется, не снижает когнитивную нагрузку, а лишь переносит узкое место из одной команды в другую. Вот что они делают вместо этого. Они измеряют правильные показатели. Время до первого дипла, скорость онбординга новых членов команды, уровень удовлетворенности разработчиков. Это те метрики, которые показывают, помогает ли платформа людям или просто добавляет еще один уровень сложности. Spotify – хороший пример. Их платформенная команда работает как полноценная продуктовая организация. У них есть дорожные карты, есть ОКР, они обсуждают с разработчиками, что работает, а что нет. Они относятся к платформе как к чему-то, что должно доказывать свою ценность каждый день.

И в этом главная мысль. Платформа, которую никто не использует, это просто проект, пылящийся в углу. Принятие пользователями – это высшее подтверждение качества. Если разработчики выбирают вашу платформу, они создают свои инструменты, вы добились успеха. Если они ее избегают, никакое техническое совершенство этого не исправит. Что это значит для вас? Это значит, что если вы создаете платформу, не начинайте с архитектурных диаграмм, не начинайте с кластеров Кубернетес или модулей Терраформ. Начните с интервью с пользователями, поговорите с разработчиками, которые будут использовать вашу платформу. Выясните, что именно причиняет им боль. Создайте что-то одно, что решает реальную проблему, а затем развивайте это. Именно так создается-то, чем люди действительно хотят пользоваться. Почему именно сейчас? Волна ИИИ. Итак, почему мы говорим об этом сейчас? Почему не пять лет назад? Ответ ИИИ. ИИИ-инструменты для Кудинга, такие как GitHub Капайлот, позволяют разработчикам выпускать код с невиданной ранней скоростью.

В 10-20 раз больше кода в день, чем было возможно всего пару лет назад. Это звучит потрясающе, и так оно и есть. Но вот в чем подвох. Для всего этого кода все еще нужна инфраструктура. Ему все еще нужна безопасность. Его все еще нужно развертывать, тестировать и обслуживать. Больше кода без лучшей системы не делает вас быстрее. Это просто ускоряет хаос, если ваши разработчики уже тонут в IML и Terraform. И этого не исправят. Это лишь значит, что они будут тонуть быстрее, создавая при этом еще больше кода, который нужно поддерживать. Прямо сейчас около 55% организаций уже внедрили платформенную инженерию в том или ином виде. Гартнер прогнозирует, что к концу 2026 года этот показатель достигнет 80%. Это немедленный тренд. Это сдвиг, который происходит прямо сейчас. Компании понимают, что не могут масштабировать свои инженерные команды без платформенного уровня. Старый подход, при котором каждая команда делает все сама, просто не работает, когда вы выпускаете код со скоростью I.

Вот что многие упускают из виду. IML не просто создает потребность в платформах. Он также помогает их создавать. Платформенные команды используют и для генерации Terraform модулей, написания документации и отладки конвейеров. Та же технология, что создает срочность, предоставляет инструменты для ее решения. Теперь несколько слов предостережения. IML усиливает то, что у вас уже есть. Если у вас солидная база, хорошая архитектура и продуманная платформа, IML сделает вас в 2-3 раза продуктивнее. Но если основы слабы, IML лишь поможет вам быстрее совершать более крупные ошибки. Плохие конфигурации, дыры безопасности, сломанная инфраструктура все это попадает в продакшн раньше, чем кто-либо успеет заметить. IML не исправляет плохую базу. Он ее обнажает. Вот реальный пример. Компания с хорошей внутренней платформой для разработчиков позволяет даже неинженерам безопасно развертывать и инструменты.

Платформа обеспечивает защитные барьеры. Она обеспечивает соблюдение политик безопасности. Она берет на себя инфраструктуру. Так что менеджер по продукту может запустить и прототип, не вникая в кубернетис или облачные сети. Это впечатляющая возможность. Именно это отличает команды, готовые кэри и... от тех, кто останется позади. Что это значит для вас? Окно возможностей для создания платформы закрывается. Не потому, что технология исчезает, а потому, что разрыв между командами с платформами и без них быстро растет. С каждым месяцем ожидания команды, у которых уже есть платформы, уходят все дальше вперед. Они быстрее выпускают продукты, меньше выгорают и скорее адаптируются к новым инструментам. Команды без платформ все больше отстают. Выбор за вами. Начните с одного золотого пути. Итак, с чего же начать на самом деле? Если вы сидите и думаете, что нужно строить всю внутреннюю платформу с нуля, остановитесь.

Это самый быстрый способ убить проект, даже не начав его. Самая большая ошибка команд пытаться построить все и сразу. Они месяцами проектируют идеальную платформу, добавляя туда все функции, которые приходят в голову. Затем они запускают ее и... Тишина. Никто ее не использует. Почему? Потому что она решает проблемы, о которых никто не просил. А чтобы просто начать, нужно прочитать целое руководство. Суть в том, что так делать не надо. Вместо этого начните с малого. Действительно общайтесь с разработчиками, а не с архитекторами, не с менеджерами и не опирайтесь на собственные предположения. Найдите тех, кто пишет код и создает функции каждый день. Спросите их, что доставляет им больше всего боли. Найдите рабочий процесс, который занимает больше всего времени, раздражает многих, или которого стараются избегать. Затем создайте ровно один золотой путь от начала до конца. Возможно, это создание и развертывание нового микросервиса.

Возможно, это настройка среды разработки с нуля. Возможно, это выпуск хатфиксов продакшн без поломок. Выберите то, что болит сильнее всего, и постройте путь, который избавит от этой боли. Создайте его, протестируйте с реальными пользователями, соберите отзывы и доработайте. Затем добавьте еще один путь, а после него еще один. Не пытайтесь решить все проблемы сразу. Решите одну проблему действительно хорошо и позвольте импульсу двигать вас вперед. Как понять, что это работает? Измерите правильные вещи. Время от идеи до первого релиза, количество исключенных ручных этапов

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

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