Привет! Меня зовут Евгений, я Lead DevOps в EXANTE. В статье расскажу о том, что получилось, когда мы решили быстро стать Cloud Native и запихнули всё подряд в Kubernetes. Вы узнаете, какие ошибки мы допустили, как они отразились на скорости разработки и релизах, и почему теперь мы смотрим на инфраструктуру совсем иначе.
EXANTE — это брокерская компания с собственной трейдинговой платформой. Через неё можно торговать на более чем 50 рынках по всему миру с единого мультивалютного счёта. Наши основные клиенты — профессиональные трейдеры и институциональные инвесторы. Наши сервисы очень разные: от лёгких приложений до тяжёлого легаси со statefulset’ами на десятки CPU и сотни гигабайт памяти, долгим стартом (15+ минут) и огромными кешами на PVC.
Всё это накладывает ограничения и делает инфраструктурные решения не абстрактными экспериментами, а реальной инженерной необходимостью. Особенность бизнеса - доступность за миллисекунды и нам важно всегда это контролировать и обеспечивать быстрый отклик благодаря инфраструктуре.
Для нас нормальная практика, когда любой технически грамотный человек — разработчик, тестировщик — приходит с идеей по инфраструктуре. Иногда такие обсуждения превращаются в холивары, но чаще они двигают нас вперед. К тому же, каждое решение мы принимаем аргументированно: обсуждаем и анализируем, считаем value, оцениваем последствия.
Ожидания: стать Cloud Native
В конце 2023 года мы с руководством сформулировали цели:
Наш продукт становится Cloud Native.
Инфраструктура легко развёртывается в любых облаках.
Финансы становятся прозрачными — мы хотим понимать, за что платим и где дороже.
Сокращается time to market новых фич.
На тот момент у нас был настоящий зоопарк технологий: OVH и HTZ, Avela, managed-сервисы в GCP и AWS. У каждой технологии были свои правила и ограничения, поэтому управление зоопарком было похоже на дрессировку стаи диких животных.
Далее я расскажу про GCP, потому что там мы допустили больше всего ошибок.
Реальность
Мы хотели ускорить time to market. У нас был Terraform, Chef для VM, Flux CD для GitOps. Вроде всё звучало красиво - мигрируем сервисы в GKE и получаем моментальный профит, и мы решили: перевозим в GKE даже legacy.
Среди сервисов были монстры:
statefulset’ы на 36 CPU и 70 GB RAM,
startup time 15+ минут, кэши, скачивающиеся при старте приложения по 25-30 GB на PVC и необходимость периодически чистить PVC,
protobuf в чистом виде, стриминг, костыли.
И мы подумали: «Да нормально, Kubernetes всё вывезет». Но результат оказался примерно таким:
Замедлился time to market. Команды разработки и тестирования не были готовы перестраивать пайплайны под GKE.
Усложнились релизы. Релиз-инженеры были шокированы количеством ручных шагов и долгого старта сервисов.
Снизилась утилизация ресурсов. На старте взрывное потребление, потом резкое падение.
Пострадал GitOps. Flux CD банально задыхался, если деплоить больше шести тяжёлых сервисов одновременно. Queue, зависания, ручное вмешательство.
Усложнился анализ инцидентов. Новая инфраструктура — новая боль для девов и саппорта.
Поломалась коммуникация. DevOps’ы требовали изменений в коде сервисов, а разработчики справедливо говорили: «У нас продуктовый roadmap, мы не можем сейчас выделить полкоманды на рефакторинг ради инфраструктуры».
Какие выводы мы сделали
Наше стремление к Cloud Native оказалось самурайством ради самурайства. Мы гнались за быстрыми результатами, но без долгосрочного плана инфраструктурные quick wins превратились в hard fails. И вот, что мы поняли:
Стратегия важнее хайпа. Kubernetes — инструмент, а не самоцель, и не всё legacy нужно в него тащить. Есть сервисы, которые проще и дешевле оставить вне Kubernetes и автоматизировать их развёртку там.
Инфраструктура ≠ DevOps-игрушка. Это часть продукта, при изменении которой нужно учитывать планы разработки и бизнеса. DevOps и разработку важно синхронизировать: миграция сервисов должна идти рука об руку с их развитием.
Ошибки и болезненные эксперименты в начале пути заставили нас остановиться и перестроить мышление. В итоге факап стал для нас точкой роста. Теперь мы чётко понимаем: Cloud Native — это не запихнуть всё в Kubernetes, а нащупать баланс между техническим драйвом, здравым смыслом и реальной ценностью для бизнеса.
Infrastructure 2.0: перезапускаем платформу
К проекту Infrastructure 2.0 мы подошли более зрело и прагматично. У него есть сроки, роадмап, ответственные, а главное — задачи с реальным value для продукта и команды. Это не миграция ради миграции, а внятная стратегия развития, где каждое решение обосновано. Сейчас мы находимся в процессе её внедрения.
1. Сеть и фундамент
Начали с самого уязвимого места — сетевых связей. Раньше любой сбой отзывался по всей системе. Поэтому мы внедряем устойчивые интерконнекты между OVH и облаками (AWS/GCP) с BGP/OSPF/BFD.
Второй шаг — распределённый Consul Cluster: это «единый справочник сервисов». Благодаря ему Kafka, наши инфраструктурные и другие сервисы будут находить друг друга по консистентным DNS-именам, а не через костыли.
2. DevOps-платформа
Flux CD показал нам свои пределы. Мы внедряем ArgoCD, чтобы получить прозрачность и предсказуемость. Разработчики смогут видеть деплои, тестировщики — откатывать изменения, а ApplicationSet позволит поднимать временные окружения за минуты.
Istio выбрали не случайно: нам нужен единый вход, mTLS по умолчанию и контроль доступа на уровне сети.
Karpenter добавляем для автоматического управления нодами: чтобы система сама понимала, когда и сколько ресурсов нужно.
Nomad готовим для легаси, которое не хочется ломать. Это компромисс: контейнеры без боли Kubernetes.
3. Требования к разработке
Для разработки мы вводим единые правила: контейнеры, stateless, JSON-логи и Prometheus-метрики. Каждый сервис должен иметь паспорт и runbook. Может показаться бюрократией, но на деле это избавление от хаоса. Теперь разработчики будут идти по рельсам, а DevOps перестанут тонуть в исключениях.
4. Наблюдаемость и финансы
Мы внедряем полный сбор метрик и FinOps-дашборды. Пилотные отчёты уже показывают, что некоторые сервисы съедают в разы больше ресурсов, чем мы думали. Это позволяет нам закладывать экономику заранее.
5. Безопасность
Безопасность - всегда была с нами, но теперь мы выводим ее на новый уровень.
Везде mTLS (через Istio).
Централизованный Vault.
Базовые Docker-образы проходят ревью SecOps.
Образы сканируются AquaSecurity.
6. Операции и инциденты
Мы готовим DR-окружение в GCP. Секреты и GitOps-состояния будут синхронизироваться автоматически. Документация и runbooks пишутся параллельно, чтобы команды могли работать по инструкции, а не по наитию.
Что нам даст Infrastructure 2.0
Переход на Infrastructure 2.0 — результат не только инженерной работы, но и культурной трансформации: прозрачность, зрелость, ориентация на реальное value. Это системное изменение подхода к проектированию, развитию и поддержке инфраструктуры.
И вот его ключевые принципы:
Скорость и гибкость. Теперь мы можем быстро поднимать feature-окружения, тестировать гипотезы и откатывать изменения без недельных согласований. Это напрямую сокращает time-to-market и даёт разработке больше свободы.
Надёжность и отказоустойчивость. У нас есть горячий standby в GCP, автоматическая синхронизация секретов и GitOps-состояния, а значит — даже серьёзный инцидент не парализует бизнес.
Прозрачность затрат. FinOps-дашборды позволяют видеть, какие сервисы и окружения реально потребляют ресурсы, и принимать взвешенные решения — где оптимизировать, а где вкладываться.
Удобство для разработки. Стандарты на метрики, логи, переменные окружения и универсальные Helm-чарты снимают хаос и снижают порог входа. Новый сервис теперь можно запустить по готовым рельсам, а не изобретать велосипед.
Безопасность по умолчанию. mTLS, централизованный Vault, проверенные базовые образы и политика ротации секретов закрывают многие уязвимости ещё до того, как они попадают в прод.
Накопление знаний. Runbooks, документация и регулярные пост-мортемы формируют базу знаний, которая помогает новым людям быстро включаться, а опытным инженерам — не наступать на старые грабли.
И главное — мы перестаём воспринимать инфраструктуру как расходный ресурс. Для нас это полноценный продукт, который должен быть удобен для бизнеса, разработки, саппорта и SecOps. Мы уверены, что он позволит нам быстрее выводить новые фичи, минимизировать стоимость простоя, снижать расходы за счёт прозрачного управления ресурсами, и, самое важное — создавать платформу, которая растёт вместе с бизнесом, а не тормозит его.
И да, Kubernetes в этой картине по-прежнему важен. Но теперь это не путь самурая, а часть стройной экосистемы, где каждая технология занимает своё место и работает на общую цель.
Следите за нашими успехами в следующих статьях — впереди ещё много экспериментов, поражений и побед!