Extreme DevOps Automation - доклад от Revolut на QCon 2025 (Рубрика #PlatformEngineering) Интересный доклад c QCon 2025 от Sérgio Amorim про работу их DevOps команды. Суть в том, что у ребят из Revolut практичный подход к своей платформе разработки - они плотно сидят на Google Cloud, одновременно добавляя кастомные автоматизации сверху. При таком подходе у них получается, что 15 инженеров могут поддерживать масштаб порядка 1.3к инженеров, 1.2к микросервисов и 1.1к баз данных (что ребята из платформенной команды поддерживают сами). В итоге, получается чуть меньше 1 сервиса и 1 бд на одного инженера:) Для управления всем этим используется три столпа - Каталог сервисов в виде внутреннего решения Tower - это главный источник истины - Паттерны и стандарты для унификации подходов - Автоматизации GitOps при помощи внутренней системы Rhea А теперь давайте подробнее глянем под капот 1. Tower (каталог сервисов IDP) Здесь существует минимальный набор параметров для сервиса: стек (Java/Python/Scala/ML), владелец, связи с БД/сервисами, окружения, критичность (tier), SLO, стоимость, "качество метаданных" и пр. В итоге, это не "статичная CMDB", а портал, откуда начинается управление и в который возвращается обратная связь (качество, аптайм, стоимость). Меньше полей - выше заполненность и точность данных → тем надёжнее автоматика. 2. Паттерны как "сужение свободы" ради скорости и соответствия Малое число поддерживаемых стеков и шаблонов развёртывания. Это повышает повторяемость, упрощает владение и даёт выигрыш в соответствие требованиям - стандартизация автоматически реализует корпоративные и регуляторные правила 3. Автоматизация как Control Plane Rhea «транспилирует» данные из Tower в коммиты (реализуя подход GitOps): - генерирует пайплайны TeamCity и права на деплой для нужных команд (~10к управляемых пайплайнов) - создаёт политики доступа к секретам (Vault) ровно по зарегистрированным связям сервис↔база (~37к политик секретов) - создаёт ресурсы в Kubernetes/облаке - формирует шаблонные алерты/дашборды/правила (~20к стандартных алертов и ~3к кастом‑алертов) Всё это - без ручных действий команд Для сервисов важен и вопрос observability - все начинается со SLO, которые тоже настраиваются в Tower, дальше автоматика генерирует стандартизованные алерты по сервисам и БД, а внутренний диспетчер шлёт единообразные сообщения в Slack командам‑владельцам. Слишком "шумные" системы признаются техдолгом: при накоплении баг‑тикетов включается стопор изменений до улучшения стабильности (этакая реализация error budget). Кстати, у сервисов всего 4 типовых уровня доступности (99.99/99.9/99.8/99.5) Отдельно автор доклада рассказал про управление базами данных, а точнее Postgres, для которых не используются managed решения от Google, а команда DevOps сама оперирует ими, чтобы катать спокойно мажорные обновления СУБД + играть с репликами как хочется. Если проанализировать устройство платформы, то можно отметить, что это работает из-за ряда факторов - Минимальная платформа поверх облака - можно использовать облачную инфру провайдера, а поверх делать только необходимое - Governance вшит прямо в happy path платформы - важные правила (SLO, алерты, секреты, права) применяются автоматически, потому что единственный удобный путь запуска системы - через каталог и паттерны. Ничего "донастраивать руками" не нужно и часто нельзя. - Каталог систем + GitOps. Tower фактически становится "API компании" для всего инженерного ландшафта. Один набор артефактов порождает пайплайны, политики, ресурсы и мониторинг. Это снижает расхождение реальности и деклараций. - Стандарты на масштабе ускоряют, а не тормозят. Ограничение стеков + шаблоны деплоя убирают вариативность, ускоряя онбординг и снижая операционный риск. - SLO/алерты как механизм управления продуктом. Унифицированный шумомер и error‑budget freeze принуждают команды держать стабильность, а не "продавливаться" релизами любой ценой. - Фокус DevOps‑платформы - не "поддержка руками", а инжиниринг инструментов и продуктовая работа над DX. #Software #Engineering #Management #Architecture #Processes