Спроектируйте CI/CD-платформу для команды из 10 микросервисов: от коммита до продакшена. Какие этапы, окружения и меры безопасности вы заложите?
Короткий ответ
- Этапы CI: линтеры, тесты, сборка образа, сканирование уязвимостей
- Образ собирается один раз и промоутится между окружениями
- Теги образов — иммутабельные, по SHA коммита
- CD через GitOps: Argo CD сверяет кластер с git-репозиторием
- Прод — через canary или blue-green с автоматическим откатом
- Секреты через OIDC и хранилище, доступ пайплайна минимален
- Шаблонизация пайплайнов, чтобы 10 сервисов не расходились
Схема «один артефакт — промоушен по окружениям — GitOps-деплой» с качеством и безопасностью, встроенными в пайплайн.
Как сказать вслух
пример ответаЯ бы разделил CI и CD. В CI на каждый коммит — линтеры, юнит-тесты, сборка Docker-образа с тегом по хэшу коммита и сканирование на уязвимости; образ собирается один раз и дальше только продвигается между окружениями. Деплой — через GitOps: в отдельном репозитории описано, какая версия где стоит, а Argo CD приводит кластеры к этому состоянию. В стейджинг раскатываем автоматически с интеграционными тестами, в прод — канареечно с автооткатом по метрикам. Пайплайны делаю шаблонными для всех десяти сервисов, а секреты — через короткоживущие токены, а не статические ключи.
Подробный ответ
Основной ответ
CI: на pull request — линтеры, статический анализ, юнит-тесты с кэшированием зависимостей; после merge — сборка образа (тег = SHA коммита, immutable), SBOM и сканирование (trivy), публикация в registry, подпись артефакта (cosign). Принцип build once, promote many: окружения получают один и тот же образ, различия — только в конфигурации. CD через GitOps: репозиторий окружений (Helm/Kustomize overlays), PR меняет версию, Argo CD синхронизирует; это даёт аудит, ревью и лёгкий откат через revert. Стейджинг — автодеплой плюс интеграционные и smoke-тесты; прод — canary (Argo Rollouts) с анализом метрик и автооткатом. Безопасность: OIDC-федерация вместо статических секретов, минимальные права деплой-ролей, policy-проверки манифестов (Kyverno), защита веток. Для 10 сервисов — общие шаблоны пайплайнов и единый базовый образ. Метрики платформы: lead time, частота деплоев, доля неудачных, время восстановления (DORA).
Ключевые моменты
- Build once, promote many. Пересборка на каждое окружение запрещена: тестируется ровно тот артефакт, что едет в прод.
- GitOps как CD. Git — источник истины о версиях в окружениях: аудит, ревью и откат через историю коммитов.
- Качество как gate. Тесты, сканы уязвимостей и policy-проверки блокируют продвижение, а не просто информируют.
- Масштабирование на команду. Шаблоны пайплайнов и переиспользуемые модули не дают десяти сервисам разъехаться в практиках.
Практический контекст
Классическая system-design-задача на senior DevOps: проверяется способность собрать целостную платформу, а не перечислить инструменты. В реальности такую схему строят на GitHub Actions/GitLab CI плюс Argo CD, и большинство решений из ответа — ежедневные рабочие темы: флаки интеграционных тестов, время пайплайна, права деплоя. Сильный кандидат сам проговаривает компромиссы: монорепо или мультирепо, скорость против полноты проверок, где нужен ручной approve.
Частые ошибки
- Пересобирают образ для каждого окружения, теряя гарантию «тестировали то, что деплоим»
- Описывают только CI, забывая стратегию деплоя, откат и миграции
- Хранят статические облачные ключи в CI вместо OIDC и короткоживущих токенов