Чек-лист готовности веб-приложения к запуску

1. Проверьте пользовательские сценарии снаружи

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

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

• Публичный HTTPS-адрес и маршруты
• Основной сценарий от входа до результата
• Репрезентативные данные и профиль нагрузки
• Согласованные показатели времени ответа и ошибок

2. Проверьте доставку уведомлений о сбое

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

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

• Метрики и логи критических сценариев
• Условия уведомлений и ответственные
• Реальная проверка доставки тестового сообщения
• Инструкция для первого действия при сбое

3. Восстановите резервную копию

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

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

• Копии данных, конфигурации и необходимых ключей
• Отдельное размещение и правила доступа
• Практическое восстановление в изолированной среде
• Измеренное время восстановления и дата последней проверки

4. Отрепетируйте релиз и откат

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

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

• Версия кода, образа и конфигурации
• Предыдущая рабочая версия и инструкция отката
• Совместимость изменений данных
• Проверка версии и поведения после выпуска

5. Передайте доступы и ответственность

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

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

• Ответственные за домен, инфраструктуру и данные
• Проверенные роли и ограниченные технические доступы
• Инструкции выпуска, восстановления и диагностики
• Список открытых вопросов и решение о запуске

Дополнительные материалы

• Google SRE: показатели и цели уровня сервиса