Сообщить об ошибкеКороткий ответ
Единого правильного ответа нет — организация должна заранее определить допустимый уровень риска и иметь задокументированный (пусть и редко используемый) запасной путь ручного/локального релиза, доступ к копии критичных секретов для деплоя и альтернативный способ сборки и публикации артефакта в обход недоступного SaaS CI, явно принимая компромисс между стоимостью поддержки резервного пути и вероятностью такого отказа.
Как это работает подробнее
зависимость от одного внешнего CI-провайдера — single point of failure для всего релизного процесса; план восстановления обычно включает документированную процедуру ручной сборки и деплоя с локальной машины доверенного инженера (с теми же проверками безопасности, что и обычный пайплайн, насколько это возможно), резервную копию необходимых секретов в отдельном защищённом хранилище, независимом от CI-платформы, и заранее протестированный (хотя бы раз в квартал/полгода) runbook для такого сценария.
Пример кода
Runbook (фрагмент) — Emergency manual release when CI is down:
1. Подтвердить инцидент у CI-провайдера (statuspage).
2. Получить доступ к emergency-секретам из отдельного Vault-инстанса
(не зависящего от CI).
3. Собрать образ локально: docker build + push с подписанной учётной записи.
4. Применить изменение через kubectl/helm с bastion-хоста, с обязательным
вторым инженером для code review "через плечо".
5. Задокументировать факт ручного релиза и провести его post-mortem.Сравнение
- Компромисс. инвестиции в полное резервирование CI-платформы снижают риск простоя до минимума, но стоят дорого и редко окупаются; минимальный документированный ручной fallback дешевле, но требует дисциплины регулярного тестирования и осознанного решения, какой уровень риска организация готова принять для разных классов релизов (security-патч против обычной фичи).
Что использовать на практике
- На практике. полноценное дублирование всей CI/CD-инфраструктуры (второй независимый CI-провайдер, готовый к немедленному переключению) оправдано только для организаций с очень высокой ценой простоя релизного процесса; для большинства компаний достаточно задокументированного ручного пути как fallback именно для критичных security-патчей, а не для обычных релизов. Важно также учитывать GitOps-модель — если состояние описано декларативно в Git, применить изменение можно напрямую через `kubectl apply`/`helm upgrade` с локальной машины, минуя сломанный CI, при наличии прямого (но контролируемого) доступа к кластеру.
- Пример. Задача для обсуждения: кандидату — оценить, какие шаги этого runbook реалистичны для организации с их текущим уровнем доступа и безопасности, и что нужно подготовить заранее, чтобы runbook действительно сработал в стрессовой ситуации.
Подводные камни
- Частые ошибки. вообще не имеют задокументированного плана на этот случай, полагаясь на «такого никогда не случится»; имеют план, но никогда его не тестировали, из-за чего в реальной ситуации обнаруживаются неактуальные доступы или забытые шаги.