Деплой и инфра
Rollout strategies: соберите canary, который сам себя откатывает
Читать про progressive delivery — не то же самое, что смотреть, как canary ловит плохой релиз на 5% трафика и сама себя откатывает, пока вы ничего не делаете. Соберите такую, отправьте в неё заведомо сломанную версию и докажите, что gate — а также readiness probe и миграция expand-contract — реально держат.
Превратите ментальную модель раздела в работающий конвейер: canary с метрическим gate, ограничивающая blast radius, readiness probe, предотвращающий сбой ‘502 на выкате’, и миграция expand-contract, сохраняющая rollback безопасным при изменении схемы — каждое доказано экспериментом, а не заявлено.
Развернуть небольшой HTTP-сервис в Kubernetes за автоматическим canary-выкатом, затем доказать свойства безопасности выката: намеренно отправить плохой релиз и изменение схемы и показать, что система сдерживает оба — ограниченный blast radius, отсутствие 502 и rollback, переживающий миграцию.
- Before/after для Эксперимента 1: число ошибок во время выката без probe и с probe, измеренное под одной нагрузкой — не оценочно.
- Логи событий rollout из Эксперимента 2, показывающие автоматическую паузу и rollback, плюс измеренная доля общего трафика, попавшая на плохую версию (должна быть ≤ шага канарейки в 5%).
- Доказательство из Эксперимента 3, что rollback после шага expand по-прежнему корректно работает, и пометка, почему шаг contract отложен в более поздний деплой.
- Абзац с выбором canary против blue-green против rolling для этого сервиса и обоснованием против blast radius, стоимости ресурсов и скорости rollback.
- Добавьте одностраничный runbook релиза: как читать дашборд анализа, когда прерывать вручную и чеклист expand-contract для любого изменения схемы.
- Добавьте smoke/integration-шаг в анализ, который должен пройти до первого шага трафика, чтобы релиз, проваливший базовые проверки, не дошёл даже до 5%.
- Сравните стоимость ресурсов: измерьте пиковое число подов и память во время canary против симулированного blue-green того же сервиса и покажите примерно удвоенный footprint blue-green во время cutover.
- Подключите gate ко второму сигналу помимо error-rate (например, бизнес-метрике вроде успешности checkout) и покажите, как он ловит релиз, технически 200-OK, но функционально сломанный.
Это цикл за каждым безопасным релизом: ограничить blast radius canary с gate, гейтить по реальным SLO-метрикам, чтобы rollback был автоматическим, а не решением в 3 часа ночи, держать readiness probe несущим, чтобы трафик не дошёл до недозагруженного пода, и делать каждое изменение схемы expand-contract, чтобы rollback его пережил. Доказать каждое свойство намеренным сбоем один раз на игрушечном кластере — вот что превращает продакшен-версию в мышечную память.