Пилот с ускорением деплоев на 77% звучит как железный аргумент, но на практике этого оказалось мало. История, которую на KubeCon & CloudNativeCon Europe рассказали Лукас Хорнунг и Кристиан Маттеаи, хорошо показывает, почему платформенная команда может строить технически сильную платформу и все равно проигрывать в adoption: бизнес не понимает, за что платить вниманием и бюджетом, а разработчики не видят, зачем менять привычный способ работы.
О кейсе 16 июля 2026 года сообщил InfoQ. Хорнунг и Маттеаи описали типичную для крупных инженерных организаций ситуацию: платформа уже существует, инженеры ею гордятся, но массового использования внутри компании нет. Их формула выхода из тупика выглядела почти обидно нетехнической: быть заметными для менеджмента, регулярно говорить со стейкхолдерами, мерить эффект через DORA-метрики, объяснять изменения через истории, а не через схемы, и делать скрытую боль эксплуатации личной и понятной.
Самый интересный момент здесь не в списке советов, а в том, кто их озвучивает. Хорнунг прямо сказал: они сумели превратить техническое видение в то, что понял бизнес и чего захотели разработчики, причем сделали это как инженеры, без продуктового менеджера и без спущенного сверху мандата. Для многих платформенных команд это болезненно узнаваемый сюжет. Обычно им кажется, что если платформа объективно лучше старого процесса, то пользователи рано или поздно сами «дорастут». На деле никто ничего не «обнаруживает магическим образом». Если команда не видна, ее работа легко превращается в фоновую инфраструктуру, которую замечают только при сбое.
Отсюда первый вывод: платформенная команда работает не только с YAML, CI/CD и внутренними сервисами, но и с внутренней политикой компании. После ухода руководителя у команды Хорнунга вообще возник вопрос о собственном будущем. Маттеаи вспоминал, что в этот момент его попросили коротко выступить перед менеджментом и объяснить, кто он и почему одна техническая тема вообще заслуживает внимания. В качестве рабочего принципа они взяли простую идею Саймона Синека: если аудитория нетехническая, начинать надо не с того, как устроено решение, а с того, зачем оно нужно. Для русскоязычной IT-аудитории в этом мало романтики, но много практики: платформенный бэклог редко выигрывает конкуренцию за ресурс, если его защищают на языке Flux, GitOps и pipeline optimization, а не на языке скорости вывода фич и снижения операционного шума.
Второй важный слой истории связан с метриками. Команда начала опираться на DORA и показывать показатели внутри компании, чтобы разговор о платформе стал бизнес-разговором, а не спором инженеров о вкусе. Судя по реакции, это сработало: как только появились цифры, внимание в комнате сразу выросло. Но дальше произошел полезный, хотя и неприятный эпизод. На первом этапе команда не смогла корректно ответить на вопрос, каковы реальные показатели по компании. Затем они провели пилот и получили красивый результат: деплои стали быстрее на 77%. После этого нашлась проблема в методике. Замер не учитывал скрытую асинхронную обработку в полной цепочке поставки изменений, и итоговая картина оказалась менее линейной, чем хотелось. Хорнунг признал ошибку публично. Для зрелой аудитории это, возможно, главный фрагмент всей истории: даже хорошие метрики не спасают, если они собраны слишком узко. DORA открывает дверь в кабинет, но внутри все равно придется объяснять контекст и ограничения.
Третий урок еще неприятнее для инженеров, потому что он бьет по любимой иллюзии о рациональности. Хорнунг и Маттеаи признали, что долго пытались убеждать разработчиков пилотами и техническими доводами, но реальный перелом наступил только тогда, когда они начали рассказывать истории через узнаваемые роли. Не абстрактный инженер, а условный junior Hans-Peter, который вручную выкатывает релиз в пятницу. Не абстрактный on-call, а Olaf, которого будит пейджер в два часа ночи. Не абстрактный продуктовый приоритет, а Fiona, которой нужна фича, а не новая лекция о правильной архитектуре. Смена framing была принципиальной. Месседж перестал звучать как «GitOps технически лучше» и стал звучать как «GitOps дает шанс нормально спать ночью». Для платформенной команды это почти руководство по выживанию: adoption часто упирается не в отсутствие функций, а в неумение связать платформу с реальными болями конкретных групп пользователей.
В более широком контексте эта история хорошо ложится на текущий тренд platform engineering. Последние годы компании активно собирают внутренние платформы, developer portals, self-service инфраструктуру и золотые пути для команд. Но чем больше таких инициатив, тем чаще всплывает неудобный вопрос: а кто вообще клиент у этой платформы и как понять, что она нужна? Если платформа измеряет свой успех количеством компонентов, а не сокращением lead time, снижением ручных операций и уменьшением аварийной нагрузки, она быстро превращается в еще один внутренний продукт без product-market fit. В этом смысле кейс Хорнунга и Маттеаи полезен не только SRE и DevOps-лидам. Его стоит читать CTO, engineering manager и тем, кто отвечает за внутренние инструменты: инженерам все чаще приходится не просто строить систему, а еще и упаковывать ее ценность так, чтобы ее можно было защитить перед бизнесом и продать соседней команде без административного нажима.
Для российской и русскоязычной IT-среды здесь есть отдельный узнаваемый нерв. Во многих компаниях платформенная команда все еще воспринимается как «ребята, которые про инфраструктуру», а не как функция, влияющая на скорость бизнеса. Из-за этого разговор о внутренних платформах часто застревает на уровне выбора технологий, хотя реальная развилка проходит в другом месте: умеет ли команда показать, сколько ручного труда она убирает, сколько ночных инцидентов предотвращает и насколько дешевле становится доставка изменений. Если нет, даже хороший стек рискует остаться игрушкой для узкого круга энтузиастов.
Главный вопрос после этого кейса звучит не «нужны ли платформам метрики» и даже не «нужен ли платформенным инженерам storytelling». Вопрос в том, готовы ли компании признать, что внутренняя инженерная платформа давно стала продуктом со своей аудиторией, маркетингом и конкуренцией за внимание. Пока платформенная команда считает, что достаточно просто написать хороший код, она будет проигрывать тем, кто умеет связать техническое решение с человеческой болью и бизнес-результатом.