Платформенная инженерия снова напомнила, что главный дефицит в больших IT-командах — не очередной кластер и не модный фреймворк, а способность говорить на одном языке о надежности, стоимости и рисках. Команда, о которой рассказал Sergiu Petean, ввела 20% обязательных операционных инвестиций для продуктовых скводов, четырежды перестраивала архитектуру и пришла к выводу, который многим будет неприятно услышать: без культуры разговоров на данных платформа быстро превращается в дорогой внутренний сервис без влияния на бизнес.
История, о которой сообщает InfoQ, выросла из задачи дать компании SRE as a service. Для этого команда создала внутренний центр экспертизы, запустила Federated SRE-модель и добавила новые роли: production manager и technical tribe lead. В сухом остатке это не про красивую оргсхему, а про попытку связать разработку, эксплуатацию и бизнес без классического пинг-понга между «нам надо быстрее» и «у нас опять инцидент».
Petean рассказывал об этом подходе в докладе From Legacy to Sovereignty: Driving the Future of Insurance through Platform Engineering на Dev Summit Munich 2025, а затем отдельно объяснил логику в материале InfoQ от 4 июня 2026 года. По его словам, технически описать процессы и подобрать инструменты для новой observability stack оказалось сравнительно просто. Куда сложнее было научить команды-потребители переводить свои потребности в автоматизируемые процессы и замкнуть рабочую петлю обратной связи. И это важная деталь для любой компании, которая строит внутреннюю платформу: tooling обычно переоценивают, а организационную работу — систематически недооценивают.
Чтобы платформа не осталась инициативой «для платформенной команды», компания начала измерять эффект сразу в двух плоскостях: операционной и финансовой. В операционной использовали DORA-метрики, в финансовой — cost per change, то есть стоимость внесения изменений. Это хороший сдвиг оптики. Пока надежность обсуждают только через uptime, разговор быстро скатывается в религиозные войны про SLA. Когда рядом появляются скорость поставки и цена каждого изменения, платформенная инженерия перестает быть внутренним клубом любителей инфраструктуры и становится предметом разговора с бизнесом.
Самый практичный элемент этой модели — Federated SRE. Речь не о выделенной элитной группе, которая сидит отдельно от продуктовой разработки, а о внутреннем сообществе инженеров, которые тратят около 20% времени на операционные задачи: управление уязвимостями, SRE-практики, SLA, расширение CI/CD и API. Параллельно появилась роль production manager — технического человека, который централизует полный цикл incident management: от отчетности и реакции до улучшений и контроля SLA. Еще одна роль, technical tribe lead, поставлена рядом с бизнес-руководителем внутри tribe. Идея проста: если технический голос слышен только после аварии, это уже не архитектурное влияние, а посмертный комментарий.
По словам Petean, именно через Federated SRE и новые роли команда смогла «демократизировать» SLO и SLA внутри организации. Переводя с конференционного языка на нормальный: показатели надежности перестали быть собственностью эксплуатации и стали общим предметом разговора. Это дало инженерам на местах больше полномочий учитывать не только доступность, но и стоимость, безопасность, производительность и compliance. Для русскоязычной аудитории здесь особенно интересен не сам набор ролей, а принцип. Во многих компаниях SLO все еще живут в презентациях архитекторов, а SLA — в договорах и обещаниях менеджеров. Пока эти два мира не встречаются в одной таблице и на одном созвоне, платформа не управляет рисками, а просто обслуживает их.
Отдельный слой этой истории — рост когнитивной нагрузки. Когда команда создала reference architecture для AI cloud-native, она фактически стала мультиплатформенной. При этом численность и уровень таланта остались примерно теми же, а задач стало больше: несколько платформ, больше интеграций, больше требований по безопасности и соответствию. Petean формулирует это без романтики: команде пришлось делать значительно больше меньшими силами. И здесь платформенная инженерия выглядит не как способ «упростить жизнь разработчикам» в абстрактном смысле, а как борьба за выживание команды, которая иначе утонет в собственной сложности.
Рецепт выживания оказался болезненно знакомым и потому убедительным: непрерывно упрощать. Petean говорит, что архитектуру разрушали и собирали заново как минимум четыре раза. Любое изменение — новый tenant, новая линия бизнеса, облачная миграция — использовали как шанс переписать то, что обычно годами никто не трогает. В этом месте многие узнают свои компании: архитектурные компромиссы у нас любят называть «наследием», хотя чаще это просто отложенные решения с растущим процентом. Четыре пересборки — звучит жестко, но альтернатива обычно хуже: бесконечно носить на спине платформу, которую никто уже не может до конца объяснить.
Еще один вывод Petean выглядит особенно актуально на фоне разговоров о зависимости от крупных облаков: суверенитет и устойчивость должны быть встроены в проектирование платформы с самого начала. Он предлагает задавать неприятные, но необходимые вопросы заранее: сколько будет стоить и сколько займет переход от hyperscaler к private cloud или в собственный дата-центр, где находится способность компании создавать технологии внутри, а не только закупать сервисы снаружи, и есть ли у технологии представительство на уровне совета или хотя бы верхнего управленческого слоя. По его мнению, курс на sovereignty начинается не с патриотических лозунгов, а с двух вещей: внутренней инженерной компетенции и реального технического лидерства на board-level.
Для разработчиков и руководителей это, пожалуй, главный вывод всей истории. Платформенная инженерия работает не тогда, когда у команды появился портал self-service и каталог шаблонов, а когда бизнес соглашается оплачивать операционную дисциплину, инженеры получают полномочия говорить о стоимости и надежности на языке цифр, а архитектура не считается священной коровой. Следующий большой вопрос для рынка звучит уже не как «нужна ли нам внутренняя платформа», а как «готовы ли мы перестроить вокруг нее ответственность, метрики и право менять то, что раньше считалось неприкасаемым».