У Sevdesk около 15 команд и 80–90 инженеров, и именно на таком масштабе особенно быстро выясняется неприятная вещь: облачный комплаенс легко внедрить так, что платформа начнет воевать с разработчиками. В своем выступлении Davide de Paolis разобрал, как команда platform engineering в Sevdesk пыталась навести порядок в AWS без сценария «с понедельника все ломается», и для русскоязычных команд это полезный разбор без декоративного DevOps-романтизма.
По данным InfoQ, de Paolis описал довольно типичную историю зреления платформенной команды. Sevdesk, немецкий вендор бухгалтерского ПО для малого бизнеса и фрилансеров, с самого начала жил в AWS. По мере роста компании там собрали отдельную платформенную команду из сильных инженеров продуктовых подразделений. Дальше случилось знакомое многим: команда замахнулась на внутреннюю платформу, каталог сервисов и чуть ли не собственный cloud center of excellence, но при этом слишком увлеклась борьбой с vendor lock-in. Вместо того чтобы использовать нативные сервисы AWS, в стек добавили EKS, Keycloak, Rancher, Longhorn, Harbor и набор самодельных решений. Поддержка патчей, обновлений и всей этой красоты съела ресурс, команда выгорела и в итоге была распущена.
Новая итерация началась уже с менее героического и более полезного подхода. В Sevdesk ушли от single-account-схемы и перешли к AWS Organizations с разделением аккаунтов по средам, командам и доменам. Логика тут не в красивой архитектурной диаграмме, а в очень приземленных вещах: изоляция данных и доступа, отдельные квоты, более точный учет затрат и разные режимы контроля для sandbox и production. Затем часть сторонних компонентов заменили на нативные сервисы AWS: Keycloak сменили на IAM и Single Sign-On, Longhorn на EBS, Harbor на ECR, а сканирование образов отдали Inspector. Вместе с командой безопасности подключили Security Hub, AWS Config и GuardDuty. Для security это выглядело как победа, а вот для разработчиков начался тот самый «улучшенный опыт», который обычно хочется отменить откатом.
Проблема оказалась не в самих политиках, а в цене перехода. Раньше команды жили с одной учетной записью и относительно прямым путем в production. После перестройки им пришлось переключаться между аккаунтами, переделывать пайплайны, переносить публикацию образов из Harbor в ECR и отдельно выстраивать промоушен артефактов между окружениями. Платформенная команда, пытаясь не повторить ошибки предшественников, подготовила документацию, провела kickoff-встречи и открыла Slack-канал для вопросов. Но документация получилась длинной, местами устаревшей и плохо пригодной для реальной эксплуатации. Разработчики жаловались на деградацию developer experience, а платформа все чаще ловила себя на мысли «мы же все написали, почему никто не читает». Это тот этап, где внутренний комплаенс обычно начинает пахнуть корпоративной гражданской войной.
Разворот произошел на, казалось бы, скучной теме тегов. Sevdesk решила не тащить старую политику с 25–30 тегами, а сократила требования до действительно нужных полей: owner, service, user data, criticality и confidentiality. Главным стал тег owner, потому что после реорганизаций в компании часть ресурсов жила в AWS практически как бездомные коты: кто за них отвечает, было непонятно. Сначала команда попыталась идти через жесткие Service Control Policies, которые запрещают создавать, например, Lambda-функции, кластеры или базы данных без нужного тега. Но на практике всплыли ограничения по длине SCP, ограничения по количеству политик и разный характер работы тегов в сервисах AWS. Вместо идеи «закрыть все сразу» команда выбрала более земной путь: сосредоточиться на heavy hitters, то есть сервисах, которые сильнее всего влияют на расходы и используются чаще других. Для приоритизации применили Steampipe, чтобы SQL-запросами пройтись по AWS API и понять, что именно вообще имеет смысл жестко контролировать.
Самая полезная часть доклада начинается там, где платформа не спешит нажать красную кнопку. Перед включением жесткого enforcement команда сначала использовала Resource Tagging Standard в Security Hub и просто дала системе сутки на сбор картины. Результат был неприятный: нетегированных ресурсов оказалось слишком много, причем заметная часть принадлежала самой платформенной команде. Это, пожалуй, самый здоровый фрагмент всей истории: прежде чем воспитывать остальных, платформа увидела, что у нее самой бардак не хуже. После этого в Sevdesk выстроили двухконтурную схему обратной связи. Первый контур — еженедельные Slack-отчеты по legacy-ресурсам, где каждой команде показывали, сколько у нее несоответствий и как меняется ситуация неделя к неделе. Второй — почти мгновенные предупреждения о новых нетегированных ресурсах. Для этого связали AWS Config, EventBridge, Lambda, очередь и Slack через AWS Chatbot, который к моменту доклада уже переименовали в Amazon Q. Очередь понадобилась по понятной причине: один деплой может породить пачку ресурсов, и если слать по сообщению на каждый, люди начнут не исправлять проблему, а мутить канал.
Отдельно de Paolis честно проговорил, почему автоматизация здесь быстро превращается в небольшой детектив. Если у ресурса нет owner-тега, неясно, кому вообще писать в Slack. Автоматический created-by-tag не спасает: в IaC-сценариях и CI/CD он часто указывает не на команду, а на роль GitHub runner или другой технический аккаунт. Поэтому платформенной команде пришлось вытаскивать контекст из нескольких источников, включая пайплайны и CloudTrail, и уже по ним восстанавливать связь между ресурсом и владельцем. Зато на выходе получилось не просто «мы вас поймали», а рабочая модель мягкого давления: сначала показать данные, затем дать время на планирование, потом повторять цикл и только после этого думать о настоящих запретах. Собственно, так и выглядит облачный комплаенс, если его делают не ради галочки в Confluence, а ради того, чтобы система пережила рост компании.
В финале доклада de Paolis формулирует довольно трезвую мысль: platform team, security и product могут сделать многое, но не все сразу. Поэтому вместо тотальной стерилизации инфраструктуры он предлагает minimum viable governance — минимальный набор действительно важных правил, подкрепленных метриками, регулярной коммуникацией и встроенной помощью командам. В Sevdesk для этого даже использовали формат embedded expert, когда инженер платформы временно подключается к продуктовым командам и помогает разгребать изменения руками. Для российского рынка, где platform engineering часто колеблется между «всем все запретим» и «пусть каждая команда живет как хочет», это, пожалуй, главный вывод: зрелый облачный комплаенс начинается не с запрета, а с внятного выбора, что именно вы готовы контролировать, зачем и какой ценой для тех, кто выпускает продукт.