Что происходит после отката: проверка, что восстановление действительно сработало

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

Но работает ли система на самом деле?

Откат или откат вперёд — это не конец инцидента. Это его середина. Настоящий вопрос в том, не привело ли само восстановление к новым проблемам: не оставило ли оно остаточные данные, не сломало ли интеграции с другими сервисами. Без надлежащей проверки после восстановления вы можете объявить инцидент разрешённым, в то время как система всё ещё сломана — просто проблемы проявятся только через несколько часов.

Скрытые риски восстановления

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

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

Вот почему проверка после восстановления — не опция. Это страховочная сетка, которая ловит проблемы, созданные самим восстановлением.

Начните с дымовых тестов

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

Хороший дымовой тест для веб-приложения может включать:

  • Могут ли пользователи войти?
  • Видят ли они главную панель?
  • Могут ли они отправить форму или завершить транзакцию?
  • Есть ли ошибки в логах приложения?

Эти проверки должны быть автоматизированы. Если ваш дымовой тест требует ручного кликанья по экранам, его пропустят, когда команда устала и находится под давлением после инцидента. Автоматизируйте его так, чтобы в течение нескольких минут после завершения восстановления дымовой тест запускался и выдавал чёткий результат: пройден или провален.

Например, простой автоматизированный дымовой тест с использованием curl может выглядеть так:

#!/bin/bash
# Простой дымовой тест после отката

BASE_URL="https://my-app.example.com"

# Проверка эндпоинта health
if ! curl -f -s -o /dev/null "$BASE_URL/health"; then
  echo "FAIL: Health endpoint unreachable"
  exit 1
fi

# Проверка загрузки страницы логина
if ! curl -f -s -o /dev/null "$BASE_URL/login"; then
  echo "FAIL: Login page not loading"
  exit 1
fi

# Проверка, что API возвращает 200 для критического эндпоинта
if ! curl -f -s -o /dev/null "$BASE_URL/api/v1/status"; then
  echo "FAIL: API status endpoint failed"
  exit 1
fi

echo "PASS: All smoke tests passed"

Сравните метрики до и после

Дымовые тесты говорят, что приложение работает. Метрики говорят, работает ли оно хорошо.

Сравните ключевые метрики до инцидента, во время инцидента и после восстановления. Метрики, которые важны, зависят от вашего приложения, но общие включают:

  • Запросов в секунду
  • Уровень ошибок (процент неудачных запросов)
  • Среднее время ответа
  • Использование памяти и CPU
  • Задержка запросов к базе данных

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

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

Проверка базы данных требует особого внимания

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

Вам нужно проверить:

  • Приемлема ли потеря данных с бизнес-точки зрения?
  • Можно ли восстановить критически важные данные из логов или других систем?
  • Нет ли осиротевших записей, оставленных новой версией, с которыми старая версия не может работать?

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

Проверьте интеграции с другими системами

Ваше приложение не существует в изоляции. После восстановления старая версия может быть несовместима с API, которые другие команды изменили, пока ваш деплой был в процессе. Или хотфикс мог изменить формат данных, отправляемых в системы мониторинга, логирования или аналитики.

Проверьте соединения:

  • Может ли ваше приложение по-прежнему вызывать внешние API?
  • Возвращают ли эти API ответы, которые ваша версия может распарсить?
  • Получают ли нижестоящие сервисы данные, которые они ожидают?

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

Проверьте с точки зрения пользователя

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

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

Документируйте то, что нашли

После завершения проверки запишите, что произошло. Эта документация служит двум целям:

  1. Она предоставляет доказательство того, что восстановление прошло успешно и система вернулась в норму.
  2. Она помогает команде улучшить процесс деплоя и восстановления в следующий раз.

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

Практический чек-лист верификации

Вот краткий чек-лист для использования после любого восстановления:

Следующая блок-схема иллюстрирует последовательность верификации с точками принятия решений на каждом шаге:

flowchart TD A[Начать восстановление] --> B[Дымовые тесты] B -->|Пройдены| C[Сравнить метрики] B -->|Провалены| F[Расследовать и исправить] C -->|Норма| D[Проверка базы данных] C -->|Отклонения| F D -->|Целостность ОК| E[Проверить интеграции] D -->|Найдены проблемы| G[Документировать потерю данных] G --> E E -->|Всё работает| H[Проверить с точки зрения пользователя] E -->|Сбой| F H -->|Норма| I[Документировать результаты] H -->|Проблемы| F F --> B I --> J[Объявить разрешённым]
  • Дымовой тест пройден для всех критических функций
  • Уровень ошибок вернулся к уровню до инцидента
  • Время ответа в норме
  • Использование ресурсов (CPU, память, диск) стабильно
  • Целостность базы данных проверена, потеря данных задокументирована
  • Все внешние интеграции работают
  • Пользовательские метрики показывают нормальное поведение
  • Результаты задокументированы для будущих справок

Настоящий конец инцидента

Проверка после восстановления — не формальность. Это последняя линия обороны перед тем, как объявить инцидент разрешённым. Без неё вы рискуете назвать систему здоровой, когда она всё ещё сломана — и это приведёт к более крупному инциденту позже.

Момент, когда вы подтверждаете, что система действительно работает, — вот когда инцидент по-настоящему заканчивается. Всё до этого — просто восстановление.