CI/CD и надёжность
Два вопроса решают, выкатывает ли команда с уверенностью. Как изменение доезжает до прода безопасно и повторяемо? — это CI/CD. Как работающий сервис остаётся надёжным и как понять, что это не так? — это SRE. Это две стороны одной монеты: пайплайн, который выкатывает десять раз в день, — актив только если каждый выкат откатывается за секунды, а плохой ловится раньше, чем сожжёт всю базу пользователей.
Половина про доставку — это дисциплина мышления раньше, чем инструмент. Вы собираете артефакт один раз, помечаете его commit SHA и продвигаете ровно эти байты через dev, staging и prod — никогда не пересобираете под окружение, никогда не гоняетесь за изменяемым тегом latest. Стратегию выката — rolling, blue-green или canary — выбираете, обменивая ёмкость на радиус поражения. И разделяете деплой (код на машине) и релиз (фича включена для пользователей) через feature-флаги.
Половина про надёжность — про измерение правильного и про мягкую деградацию. Вы задаёте SLI, ставите SLO и тратите вытекающий из него бюджет ошибок, гейтя им скорость выката. Следите за четырьмя золотыми сигналами. И делаете сбой переживаемым: повторы с backoff, jitter и бюджетом, прикрытые идемпотентностью и circuit breakers, чтобы одна медленная зависимость деградировала, а не каскадила.
Карта темы
- Конвейеры CI/CD — CI против Continuous Delivery и Continuous Deployment, fail-fast стадии, build-once-promote-many, rolling/blue-green/canary, feature-флаги, секреты пайплайна и метрики DORA.
- Надёжность и SRE — SLI/SLO/SLA, бюджеты ошибок, золотые сигналы, toil, безвинные постмортемы, MTTR, retry storm, идемпотентность, circuit breakers и graceful degradation.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Пересобирать артефакт под каждое окружение | Вы тестируете один бинарник, а выкатываете другой — «в staging работает, в prod ломается» |
Выкатывать изменяемый тег latest | Под уже запущен на latest, поэтому выката не происходит и откатываться не на что |
| Путать blue-green с canary | Обещаете мгновенный свитч, а описываете постепенный трафик, или закладываете 2x ёмкости под canary |
| Считать целью доступность 100% | Замораживаете все релизы в погоне за невозможным числом вместо траты бюджета ошибок |
| Повторять сразу, без backoff и jitter | Частичный отказ становится полным — тот самый retry storm, что вы устроили |
| Повторять неидемпотентный вызов | «Безопасный» повтор дважды списывает деньги или дважды пишет |
Значение для собеседований
CI/CD и SRE спрашивают, чтобы увидеть, мыслите ли вы системами и компромиссами или пересказываете названия инструментов. Фраза «собрать один раз, пометить SHA, продвигать тот же артефакт и гейтить следующую стадию по золотым сигналам» сразу читается как человек, который держал прод.
Что обычно проверяют:
- Точную границу между CI, Continuous Delivery и Continuous Deployment.
- Почему
latestне даёт выката и что чинит build-once-promote-many. - Blue-green против canary: мгновенный свитч и 2x ёмкости против постепенного трафика по метрикам.
- Как бюджет ошибок превращает SLO в решение о скорости выката.
- Почему повторам нужны backoff, jitter, бюджет и идемпотентность — и что такое retry storm.
Типичный неверный ответ: «просто добавь повторы, и станет надёжно». Наивные повторы — классический способ усилить отказ; надёжность даёт backoff с jitter, бюджет повторов, circuit breakers и мягкая деградация вместо долбёжки раненой зависимости.