23 июля 2026 года InfoQ разобрал кейс, который многим знаком безо всяких конференций: команда platform engineering пришла улучшать процессы, а в итоге сначала ухудшила жизнь разработчикам. История полезна не только платформенным командам, но и техлидам, DevOps-инженерам и IT-руководителям: комплаенс работает заметно лучше, когда его встраивают в повседневную разработку, а не приносят как отдельную форму наказания.
Речь идет о выступлении Давиде де Паолиса, который на Dev Summit Munich рассказал, как в компании появилась выделенная платформенная команда. В нее собрали сильных инженеров из продуктовых команд с DevOps- и cloud-бэкграундом, после чего команда взялась за амбициозную дорожную карту: сервисный каталог, внутреннюю developer platform и cloud center of excellence. На бумаге все выглядело как взросление инженерной организации. На практике, как пишет InfoQ, разработчики внезапно получили новые workflow, несколько AWS-аккаунтов вместо одного, больше переключения контекста, обновления конфигов и набор новых правил, которые еще надо было успеть понять.
Проблему усугубила документация. Она была длинной, местами устаревшей и плохо пригодной для быстрого ответа на прикладной вопрос вроде «что именно мне нужно сделать, чтобы задеплоить сервис без лишней бюрократии». Результат предсказуем: поток запросов в платформенную команду вырос, раздражение тоже, а developer experience пошел вниз. Это важный момент для любой команды platform engineering: даже технически здравая инициатива быстро становится токсичной, если у продукта под названием «внутренняя платформа» плохой UX. Разработчик не обязан любить ваши governance-практики только потому, что они логичны с точки зрения безопасности или облачной архитектуры.
Самый показательный пример в истории де Паолиса связан с тегированием ресурсов. Раньше компания уже пыталась внедрить теги, но инициатива не взлетела: ownership оставался размытым, cost attribution был неполным, а governance держался на ручной работе. Новая команда не стала повторять старый сценарий с десятком обязательных полей и угрозой блокировок. Вместо этого она сократила набор обязательных тегов до минимально нужного, стандартизировала их через AWS Tag Policies и Service Control Policies и настроила проверку так, чтобы не давать создавать ресурсы без корректных тегов. Параллельно использовали AWS Security Hub Resource Tagging Standard для поиска уже существующих ресурсов, которые не соответствовали требованиям. Это и есть тот случай, когда комплаенс перестает быть PDF-документом и превращается в набор понятных ограничителей в самой платформе.
Ключевой прием был не в самих AWS-инструментах, а в порядке их включения. Команда сначала показывала проблему, потом мягко подталкивала к исправлению, и лишь затем усиливала контроль. Сначала visibility, затем soft enforcement, и только после этого более жесткие guardrails. Для инженеров разница принципиальная. Если с понедельника все деплои внезапно начинают падать из-за новой политики, платформенную команду будут воспринимать как внутренний отдел согласований. Если же команда заранее объясняет, какие теги отсутствуют, зачем они нужны для cost visibility, ownership и accountability, а потом дает простой путь исправления через IaC и platform defaults, сопротивление снижается. Не потому, что разработчики внезапно полюбили правила, а потому что им оставили рабочий путь без лишнего трения.
Из этого де Паолис делает вывод, который многим компаниям стоило бы распечатать и повесить рядом с backlog платформенной команды: можно делать многое, но нельзя делать все сразу. В сфере compliance и security соблазн особенно велик. У вас тысячи findings, десятки рекомендаций от аудиторов, длинный список best practices от облачного провайдера и еще собственные архитектурные долги. Но если пытаться закрыть все одним кварталом, получится знакомый жанр: поток инициатив, из которых ни одна не доведена до реального принятия. Поэтому команда сфокусировалась на minimum viable governance model и выбирала то, что действительно важно для бизнеса. Это не означает игнорировать риски, которые пока не горят. Это означает не путать приоритетность с громкостью сигнала.
Еще одна практичная часть кейса касается коммуникации. Де Паолис прямо говорит: объяснение изменений — это часть платформы, а не факультатив к ней. Команда старалась заранее объяснять контекст и влияние будущих изменений, использовала RFC, внутреннюю документацию, живые Q&A-сессии и модель Tour of Duty, когда инженеры временно переходят в платформенную команду или наоборот. Для русскоязычной аудитории здесь особенно интересен именно последний прием. В компаниях, где есть хронический конфликт «платформа против продукта», такие временные ротации часто дают больше пользы, чем еще один портал с правилами. Люди возвращаются в свои команды уже не с абстрактным знанием про guardrails, а с пониманием, почему платформа вводит те или иные ограничения и где они реально экономят время или снижают риск.
С точки зрения бизнеса вывод тоже довольно земной. Комплаенс обычно продают через страх: аудиты, инциденты, штрафы, доверие клиентов. Но в реальной инженерной среде эта аргументация быстро изнашивается, если разработчики видят только новые запреты. Кейс показывает более рабочую формулу: compliant path должен быть самым простым маршрутом. Тогда security и governance начинают восприниматься не как отдельная дисциплина для «других людей», а как часть нормальной поставки продукта. Для CTO, VP Engineering и платформенных лидов здесь есть неприятная, но полезная мысль: если adoption не происходит, проблема может быть не в «ленивых командах», а в том, что вы внедряете правильные идеи неудобным способом.
На фоне общего бума platform engineering эта история звучит особенно вовремя. Внутренние платформы давно перестали быть просто набором Terraform-модулей и golden path-шаблонов; от них теперь ждут, что они одновременно ускорят разработку, упорядочат облако и помогут с требованиями безопасности и аудита. Но чем шире зона ответственности платформенной команды, тем выше риск снова скатиться в роль внутреннего регулятора. Поэтому главный вопрос на ближайшие годы звучит не «как добавить еще политик», а «как сделать так, чтобы комплаенс ощущался как помощь разработчику, а не как очередной корпоративный квест». Именно на этом рубеже platform engineering либо становится реальным ускорителем бизнеса, либо еще одним источником инженерного раздражения.