Планы восстановления для высокорисковых изменений инфраструктуры

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

Что дальше?

Прежде чем кто-то запустит terraform apply или нажмет кнопку деплоя, вам нужен план восстановления. Не толстый документ, пылящийся на полке. Практичный, конкретный, выполнимый план действий на случай, если что-то пойдет не так.

Начните с одного вопроса

Весь план восстановления строится вокруг одного вопроса: если это изменение провалится, что нужно сделать, чтобы вернуть все в безопасное состояние?

Ответ зависит от того, что вы меняете и насколько далеко простирается радиус поражения. Простое изменение конфигурации одной security group может иметь короткий ответ: применить старую конфигурацию. Изменение сетевой архитектуры или миграция базы данных потребуют гораздо более детального ответа.

Не усложняйте. План восстановления должен быть соразмерен риску. План из пяти строк подходит для низкорискового изменения. Многошаговая инструкция (runbook) уместна для того, что может обрушить критический сервис.

Три вещи, которые нужны в каждом плане восстановления

Полезный план восстановления состоит из трех компонентов, и все они должны быть явными.

Конкретные шаги восстановления. «Откатиться к предыдущей версии» — это не шаг. Запишите точные команды, серверы, на которых их выполнять, используемые параметры и способ проверки, что восстановление действительно сработало. Если нужно зайти по SSH на bastion-хост и выполнить конкретную команду Terraform с конкретным файлом состояния — напишите это. Если нужно восстановить базу данных из снапшота — укажите имя снапшота и процедуру восстановления.

Вот конкретный пример того, как выглядят такие шаги восстановления для изменения security group в AWS:

# Recovery Plan: Revert Security Group Change
# Target: sg-12345678 (production web tier)

# Step 1: Revert security group rules
aws ec2 revoke-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 10.0.0.0/16

# Step 2: Verify the rules are correct
aws ec2 describe-security-groups \
  --group-ids sg-12345678 \
  --query 'SecurityGroups[0].IpPermissions'

# Step 3: Confirm service is reachable
curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health

Кто принимает решение о запуске восстановления. Когда что-то идет не так, люди паникуют. Они начинают принимать решения самостоятельно. Одни захотят откатить изменения немедленно. Другие — сначала разобраться в проблеме. Вам нужен один человек или роль, уполномоченные сказать: «Стоп, мы запускаем восстановление». Во время инцидента это не демократический процесс. Укажите имя человека или роль явно в плане.

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

  • По времени: если система не стабилизируется в течение 15 минут после применения изменения, запускайте восстановление.
  • По влиянию: если уровень ошибок превышает 5 процентов или пользователи сообщают, что не могут получить доступ к сервису, запускайте восстановление.

Запишите эти пороговые значения. Не рассчитывайте, что люди запомнят их во время инцидента.

Чек-лист перед применением

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

Типичные пункты:

  • Сделан последний снапшот
  • Создана резервная копия файла состояния инфраструктуры
  • Подтвержден доступ к системам восстановления
  • Члены команды знают свои роли во время восстановления
  • Настроен канал связи для координации инцидента

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

Следующая диаграмма показывает полный поток от проверки изменения до предварительных проверок, применения, мониторинга и выполнения восстановления при необходимости.

flowchart TD A[Change Review] --> B[Pre-Apply Checks] B --> C[Apply Change] C --> D[Monitor System] D --> E{System Stable?} E -->|Yes| F[Change Complete] E -->|No| G[Assess Impact] G --> H{Activate Recovery?} H -->|No| I[Continue Investigation] H -->|Yes| J[Run Recovery Commands] J --> K[Verify Recovery] K --> L[System Restored]

Чек-лист предварительных действий также служит принудительной мерой. Он заставляет команду остановиться и убедиться, что восстановление действительно возможно, прежде чем вносить изменения. Если вы не можете отметить все пункты, не применяйте изменение.

Кто утверждает план восстановления

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

Должность не важна. Важно, чтобы утверждающий мог оценить, достаточен ли план восстановления или есть пробелы. Он должен уметь задавать вопросы вроде «Что произойдет, если откат тоже не удастся?» или «Как мы проверим, что система работоспособна после восстановления?»

Это не формальность. Если утверждающий недостаточно понимает план, чтобы его оценить, он не должен его утверждать.

Храните план там, где его найдут

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

Поместите план в общее место, к которому все участники могут быстро получить доступ. Вики команды, общий диск или даже файл, прикрепленный к pull request'у с изменением инфраструктуры. Цель — убрать любое трение между «что-то пошло не так» и «у нас есть план перед глазами».

Краткий практический чек-лист

Перед применением высокорискового изменения инфраструктуры проверьте следующее:

  • Шаги восстановления расписаны с точными командами и параметрами
  • Назначен конкретный человек, принимающий решение о запуске восстановления
  • Определены временные пороги или пороги по влиянию для активации восстановления
  • Подтверждена доступность последнего снапшота или резервной копии
  • Создана резервная копия файла состояния инфраструктуры
  • Все члены команды знают свои роли во время восстановления
  • План хранится в месте, доступном всем участникам
  • Кто-то с полномочиями проверил и утвердил план

Настоящая проверка происходит во время выполнения

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

Но это тема для другого обсуждения. Сейчас главное — иметь готовый план до применения изменения. Хороший план восстановления не гарантирует, что все пройдет гладко, но он означает, что вам не придется принимать решения в темноте, когда что-то сломается.