DevOps-чек-лист перед запуском проекта в продакшен

Короткий ответ

Проект готов к продакшену, когда команда отвечает «да» на семь вопросов:

1. Можем ли мы задеплоить одной командой или кнопкой, без ручных действий на серверах?
2. Узнаем ли мы о падении раньше, чем напишут пользователи?
3. Найдём ли мы в логах, что произошло, за несколько минут?
4. Восстанавливали ли мы бэкап на деле, а не только создавали?
5. Выдержит ли система больше ожидаемого пика?
6. Можем ли мы быстро откатить неудачный релиз?
7. Знает ли дежурный, что делать при типовых инцидентах?

Ниже — чек-лист к каждому вопросу. Пройдите его за одну-две недели до запуска, а не в день запуска.

Автоматический деплой

• Сборка и деплой идут в CI/CD из основной ветки или по тегу; никто не копирует файлы на серверы вручную.
• Один и тот же артефакт (например, Docker-образ) едет сначала на staging, затем в продакшен.
• Конфигурация и секреты хранятся в переменных окружения или менеджере секретов, а не в репозитории.
• Миграции базы выполняются отдельным шагом с логированием.
• Staging достаточно похож на продакшен, чтобы успешный релиз там что-то значил.
• Деплой не вызывает простоя: есть health checks и graceful shutdown.

Мониторинг и алерты

• Uptime-проверки извне вашей сети опрашивают главные страницы и API.
• Собираются базовые метрики: CPU, память, диск, сеть, а также метрики приложения — частота запросов, доля ошибок, задержка.
• Отслеживаются и бизнес-критичные сценарии: регистрации, платежи, создание заказов.
• Алерты приходят в канал, который действительно читают, и есть конкретный дежурный.
• Пороги настроены так, чтобы срабатывать на реальные проблемы: шумный канал алертов перестают читать.
• Заполнение диска и истечение SSL-сертификата имеют отдельные алерты.

Логи

• Логи всех сервисов собираются в одном месте, по ним есть поиск.
• Логи структурированы (например, JSON) и содержат ID запроса или трассировки.
• Персональные данные, пароли и токены в логи не пишутся.
• Настроены хранение и ротация, чтобы логи не забили диск.
• Ошибки фронтенда тоже собираются, не только серверные.

Бэкапы с проверенным восстановлением

Бэкап, который ни разу не восстанавливали, — это лишь надежда.

• Базы данных, загруженные файлы и важная конфигурация бэкапятся автоматически.
• Копии хранятся вне основного сервера и, в идеале, вне основного провайдера или региона.
• Вы знаете свои RPO (сколько данных допустимо потерять) и RTO (сколько может длиться восстановление), и расписание бэкапов им соответствует.
• Полное восстановление выполнено на отдельном окружении, шаги записаны.
• Сбой бэкапа вызывает алерт.

Запас мощности

• Критичные сценарии прошли нагрузочный тест на уровне ожидаемого пика и выше.
• Вы знаете, какой компонент упрётся первым: серверы приложения, база, кэш или внешний API.
• Есть план, как добавить мощность: больше экземпляров, более мощная база, автомасштабирование.
• Для внешних вызовов заданы rate limits и таймауты, чтобы медленный партнёр не подвесил всё приложение.
• Статика и медиа отдаются через CDN или хотя бы корректно кэшируются.

План отката

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

Runbooks и доступы

Runbook — короткая письменная инструкция на конкретную ситуацию. Подготовьте их как минимум для случаев:

• сайт недоступен или отдаёт ошибки;
• база перегружена или закончилось место на диске;
• деплой упал на середине;
• нужно восстановить бэкап;
• утёк секрет или ключ, и его нужно заменить.

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