Чек-лист для DevOps перед праздниками: чтобы не чинить 1 января

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

И все это накладывается на:

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

В итоге предновогодний DevOps — это не про "просто проверим сервер". Это про системную подготовку, где важно предусмотреть все, что может сломаться в худшее время года для инцидентов.

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

1. Проверьте инфраструктуру: железобетон перед нагрузкой

Праздничная нагрузка усиливает любой слабый элемент системы.

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

CPU / RAM / Disk / IOPS

• нет ли резких пиков?
• достаточно ли запасов под сезонный трафик?
• хватает ли памяти под воркеры, очереди, контейнеры?

Диск:

• место (особенно /var/log, /tmp, базы и резервные каталоги);
• скорость (IOPS — зимой это частый bottleneck).

Сетевые параметры:

• пропускная способность;
• latency между узлами;
• корректность firewall-правил после обновлений.

Пример:

В одной финтех компании сервис упал 30 декабря, потому что в /var/log накопились архивы логов. В итоге эта ошибка стоила команде 2 часа downtime.

2. Проверьте мониторинг: алерты должны быть адекватными, не снежной лавиной

Основные сигналы:

• ошибка 5xx > порога;
• рост latency;
• очереди растут;
• отказ внешнего API;
• ошибки биллинга;
• отказ push/SMS/e-mail сообщений;
• рост dead letter queue;
• рост retry.

Что сделать:

• пересмотреть пороги (декабрь — пиковый месяц);
• убрать "шумные" и неэффективные алерты;
• добавить алерты для критичных сервисов на праздники;
• проверка каналов доставки алертов (Slack, Telegram, Opsgenie).

Пример:

Некоторые команды получают по 150+ алертов в день в декабре — на фоне шума легко пропустить критические сигналы.

3. Проверьте авто-масштабирование: декабрь = непредсказуемость

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

• триггеры autoscaling (CPU / RAM / время ответа);
• работу авто-масштабирования при резком скачке нагрузки;
• корректное удаление лишних инстансов после пиков.

Ошибка, которую DevOps делает каждый год:

autoscaling включен, но IAM-права не дают создать новые инстансы.

4. Проверьте бэкапы: не формально, а по-взрослому

Что сделать:

• убедиться, что бэкапы действительно создаются;
• проверить целостность архивов;
• проверить возможность восстановления;
• протестировать восстановление staging из бэкапа;
• убедиться, что retention-политики не удаляют нужные данные.

Пример:

Одна аутсорс-компания делала бэкап БД PostgreSQL ежедневно... но в декабре узнала, что архивы повреждены уже 4 месяца. В итоге, восстановиться было уже невозможно.

5. Проверьте обновления и патчи: никаких сюрпризов

Правила декабря:

• не обновлять ядро без крайней необходимости,
• не обновлять Docker / Kubernetes,
• не выкатывать новые версии драйверов или критичных зависимостей,
• не мигрировать базы,
• не менять конфиги nginx на проде без синтетических тестов.

Допустимо:

• закрыть критичные security-патчи;
• обновить внутренние либы, если протестированы.

Пример:

Обновление OpenSSL в декабре без тестов может привести к падению TLS на ingress. Как итог — несколько часов downtime.

6. Проверьте очереди, фоновые задачи и cron-джобы

В декабре фоновые процессы ломаются чаще, чем веб.

Проверьте:

• не растут ли очереди (RabbitMQ / Kafka / SQS);
• нет ли зависших задач;
• обновились ли cron-джобы после deploy;
• проверены ли retry-политики;
• нет ли фоновых заданий, которые запускаются 31 декабря в полночь.

Пример:

Один e-commerce обнаружил, что их nightly async-задачи запускаются в 00:00 UTC, а не по локальному времени — в результате вся система была перегружена 1 января.

7. Проверьте интеграции: внешний мир в декабре нестабилен

Сервисы, которые чаще всего падают в декабре:

• платежные шлюзы,
• SMS-провайдеры,
• email-сервисы,
• API доставки,
• антифрод-системы.

Что сделать:

• проверить fallback-поведение;
• протестировать timeouts и retries;
• добавить логирование всех внешних ошибок;
• снизить агрессивность запросов (чтобы не банили по rate limit).

Пример:

У сервиса доставки API "встал намертво" 29–31 декабря. Система без fallback зависла — все заказы оказались в подвешенном состоянии.

8. Проверьте биллинг: финансы — самая чувствительная зона

Мини-чек-лист:

• корректность комиссий;
• целостность событий оплаты;
• обработка отказов;
• защита от двойных списаний;
• корректность timezone;
• повторные попытки при ошибке;
• логирование отказов.

Пример:

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

9. Проверьте S3, CDN, файлы, кеш

Проверьте:

• есть ли лимиты;
• не переполнены ли бакеты;
• корректно ли инвалидируются кеши;
• не устарела ли CDN-конфигурация;
• не истекли ли SSL-сертификаты.

Пример:

31 декабря CDN может перестать отдавать новый баннер акции, потому что инвалидация была настроена на 24 часа.

10. Проверьте CI/CD: декабрь — враг ручной работы

Проверьте:

• пайплайны работают без ручных шагов;
• есть автотесты;
• есть pre-deploy проверки;
• есть post-deploy проверки;
• есть rollback-кнопка;
• окружения dev / stage / prod синхронизированы.

Пример:

Классическая ошибка — выкладывать релиз в декабре и забыть про миграции на staging. На проде — падение сразу после старта.

11. Пересмотрите алерты дежурств: праздники → другие метрики

Важно: В праздники трафик может проседать, а может выстреливать — в зависимости от продукта.

Настройте специальные алерты:

• billing failures;
• рост retry;
• высокое latency внешних API;
• рост ошибок интеграций;
• резкое увеличение неуспешных оплат;
• падение push/SMS.

Проверьте:

• кто дежурит?
• как быстро обязан реагировать?
• есть ли замена?
• есть ли shift-plan?
• кто уведомляет заказчиков при инцидентах?

12. Документация: декабрь — худшее время "догадываться"

Проверьте:

• инструкции по деплою;
• инструкции по откату;
• инструкции по аварийным сценариям;
• контакты всех внешних сервисов;
• график дежурств;
• ручные команды для быстрого восстановления.

Если документации нет — создайте мини-файл "README_holidays.md" хотя бы на 1 страницу.

13. Сценарии восстановления: потренируйтесь заранее

Мини-тренировки на 20–30 минут могут спасти весь праздник

Прогоните 2–3 worst-case сценария:

• падение базы
• сбой платежки
• отказ CDN
• резкий скачок нагрузки
• зависание очередей
• рост ошибок 500

Задача — убедиться, что команда понимает:

• что смотреть первой;
• куда идти в логах;
• как делать откат;
• как уведомлять пользователей.

Заключение

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

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

Ваша задача — построить инфраструктуру, которая переживет пиковую нагрузку без вас. Это значит:

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

Тогда 1 января DevOps-команда будет заниматься тем, чем должен заниматься любой человек в праздник: отдыхать, быть с близкими, а не чинить инфраструктуру.