Когда изменения инфраструктуры ломают всё: пошаговое руководство по восстановлению

Пайплайн покраснел. Terraform apply, который должен был занять две минуты, выполняется уже пятнадцать. Панель мониторинга показывает пять ресурсов, которые не удалось создать, а проверки работоспособности балансировщика возвращают 503. В чате пока тихо, но вы знаете, что эта тишина не продлится долго.

Это момент, которого боится каждый инженер инфраструктуры. Не сам сбой, а неопределённость, которая за ним следует: что делать в первую очередь? Откатывать сразу? Пытаться исправить на месте? Как понять, что всё действительно вернулось в норму?

Разница между контролируемым восстановлением и хаотичной суетой — это наличие чёткой последовательности действий до того, как они понадобятся. Вот практическое руководство по восстановлению, когда изменения инфраструктуры пошли не так.

Шаг 1: Подтвердите сбой

Первый признак проблемы не должен исходить от жалобы пользователя. Он должен поступать из вашего пайплайна и систем мониторинга. Хорошо спроектированный CI/CD-пайплайн для изменений инфраструктуры включает контрольные точки, которые проверяют каждый шаг: создался ли ресурс успешно? Корректна ли конфигурация? Продолжает ли сервис правильно отвечать?

Вот как на практике выглядит типичное подтверждение сбоя:

# Проверка вывода плана Terraform на наличие ошибок
terraform plan -var-file=production.tfvars

# Пример вывода, показывающего явную ошибку
# Error: Error creating security group: InvalidGroup.Duplicate: The security group 'web-sg' already exists
#   on main.tf line 42, in resource "aws_security_group" "web":
#   42: resource "aws_security_group" "web" {

# Проверка логов пайплайна для упавшей задачи
curl -s https://pipeline.internal/api/v1/jobs/12345/logs | tail -50

# Пример фрагмента лога
# [ERROR] Terraform apply failed: Error creating security group: InvalidGroup.Duplicate
# [INFO] Retry attempt 1/3...
# [ERROR] Terraform apply failed: Error creating security group: InvalidGroup.Duplicate

Когда контрольная точка не срабатывает, пайплайн останавливается и сигнализирует о проблеме. Но прежде чем переходить в режим восстановления, уделите минуту подтверждению, что сбой реален. Оповещения мониторинга могут срабатывать по многим причинам: временный сетевой сбой, таймаут, который разрешается при повторной попытке, или ложное срабатывание от неправильно настроенной проверки здоровья.

Что проверить:

  • Посмотрите логи пайплайна. Ошибка постоянная или периодическая?
  • Проверьте, выполняется ли та же операция успешно при ручном повторении.
  • Убедитесь, что оповещение мониторинга не является известным ложным срабатыванием.

Если сбой подтверждён, переходите к следующему шагу. Если это была временная проблема — задокументируйте её и двигайтесь дальше. Нет смысла запускать полное восстановление из-за мелкой неполадки.

Шаг 2: Выберите стратегию восстановления

Здесь окупается наличие заранее написанного плана восстановления. В пылу момента вы не хотите спорить, стоит ли откатывать, применять старое состояние или переключаться на резервное окружение. Эти решения уже должны быть задокументированы и согласованы командой.

Ключевой фактор в этом решении — время. В большинстве планов восстановления определено окно отката: период после изменения, в течение которого полный откат безопасен. Если сбой обнаружен в течение нескольких минут, откат к предыдущему состоянию обычно является лучшим вариантом. Инфраструктура ещё не успела измениться, и зависимые ресурсы вряд ли адаптировались к новой конфигурации.

Следующая блок-схема обобщает процесс принятия решения:

flowchart TD A[Сбой подтвержден] --> B{В окне отката?} B -- Да --> C{Изменение распространилось на другие ресурсы?} C -- Нет --> D[Полный откат] C -- Да --> E[Повторное применение состояния] B -- Нет --> F{Доступно резервное окружение?} F -- Да --> G[Переключение на резерв] F -- Нет --> H[Повторное применение состояния] D --> I[Выполнить восстановление] E --> I G --> I H --> I

Но если прошёл час и изменение уже распространилось на другие ресурсы, простой откат может создать больше проблем, чем решить. Другие системы могли начать зависеть от новой конфигурации. В этом случае лучшей стратегией может быть применение старого состояния вперёд или переключение на резервное окружение, которое никогда не затрагивалось неудачным изменением.

Три распространённые стратегии восстановления:

  • Полный откат: Возврат к точному предыдущему состоянию с помощью вашего инструмента Infrastructure as Code.
  • Повторное применение состояния: Применение последней известной рабочей конфигурации без отката других изменений.
  • Переключение: Направление трафика в отдельное окружение, не затронутое изменением.

Решение должно основываться на вашем плане восстановления, а не на том, что кажется правильным в данный момент.

Шаг 3: Выполните восстановление

Как только стратегия выбрана, выполняйте её в точности так, как задокументировано. Сейчас не время для импровизации. Если ваш план предписывает запустить terraform apply с определённым файлом состояния — запустите эту команду. Не пробуйте другой флаг или более новую версию инструмента, потому что думаете, что это может быть быстрее.

Во время выполнения записывайте каждое действие. Отмечайте время, команду, вывод и любое неожиданное поведение. Эти логи нужны не только для пост-мортемов. Они помогают отслеживать, что было сделано, на случай, если само восстановление вызовет новые проблемы.

Если стратегия включает переключение, активируйте механизм, который вы подготовили ранее. Это может означать обновление DNS-записей, смену целей балансировщика или изменение конфигурации маршрутизации. Конкретные шаги зависят от вашей инфраструктуры, но принцип тот же: следуйте плану, а не интуиции.

Шаг 4: Проверьте восстановление

Восстановление не завершено, пока вы не убедились, что всё вернулось в норму. Не предполагайте, что раз Terraform apply выполнился успешно, инфраструктура здорова. Не предполагайте, что раз сервер онлайн, приложение работает.

Проверка означает проверку нескольких уровней:

  • Состояние ресурсов: Находятся ли ресурсы инфраструктуры в ожидаемой конфигурации?
  • Здоровье сервисов: Запущены ли сервисы и отвечают ли на запросы?
  • Поведение приложения: Может ли приложение выполнять свои основные функции?
  • Зависимые системы: Здоровы ли нижестоящие сервисы, которые полагаются на эту инфраструктуру?

Запустите те же проверки, которые ваш пайплайн выполнял бы при обычном развёртывании. Если у вас есть автоматизированные smoke-тесты — запустите их. Если есть ручные шаги верификации — выполните их. Цель — быть уверенным, а не надеяться.

Шаг 5: Сообщите о результате

После завершения проверки сообщите остальной команде. Другие инженеры могут ждать стабилизации вашей инфраструктуры, чтобы развернуть свои изменения. Операционные команды могут отслеживать те же оповещения и задаваться вопросом, нужно ли эскалировать.

Чёткое сообщение должно включать:

  • Что пошло не так
  • Что было сделано для восстановления
  • Было ли восстановление успешным
  • Любые текущие риски или наблюдения

Это предотвращает пересекающиеся изменения и уменьшает путаницу. Это также помогает другим командам скорректировать свои планы при необходимости.

Практический чек-лист восстановления

Когда давление нарастает, простой чек-лист помогает сохранять фокус. Вот тот, который вы можете адаптировать для своей команды:

  • Подтвердите, что сбой реален (не временная проблема или ложная тревога)
  • Проверьте окно отката: сколько времени прошло с момента изменения?
  • Выберите стратегию восстановления из заранее написанного плана
  • Выполните шаги восстановления в точности, как задокументировано
  • Записывайте каждое действие и его результат
  • Проверьте состояние инфраструктуры, здоровье сервисов и поведение приложения
  • Сообщите результат команде

Настоящая работа начинается после восстановления

Инфраструктура вернулась в норму. Оповещения сняты. Команда может выдохнуть. Но процесс восстановления не завершён, пока вы не ответили на один вопрос: Почему это произошло, и что мы можем сделать, чтобы предотвратить это в будущем?

Оценка после восстановления — это то, где вы улучшаете свои процессы. Возможно, пайплайну нужны более качественные проверки перед развёртыванием. Возможно, в плане восстановления не хватало шага. Возможно, команде нужна более чёткая политика окна отката. Какой бы ни был урок, зафиксируйте его и обновите свои планы соответствующим образом.

Неудачное изменение инфраструктуры — это не провал команды. Это сигнал о том, что систему нужно улучшить. Команды, которые хорошо восстанавливаются, — это не те, которые никогда не терпят неудач. Это те, у кого есть чёткий, отработанный и повторяемый процесс на случай, когда что-то идёт не так.