Праздничные дни — это не только культовая классика по ТВ и тонны салатиков с фейерверками. Для бизнеса это рост продаж, всплеск трафика и сотни автоматических задач. Для инженерной команды это еще и проверка на прочность: достаточно одного забытого cron-а, одного просроченного сертификата или одной горячей рассылки — и вы получаете массовый инцидент в самый неудобный момент. 

В статье разберем, почему именно новогодние и рождественский ажиотаж становится проверкой для сервисов и систем. Посмотрим реальные сценарии фейлов и разборов, которые можно сразу положить в on-call playbook. Берите свое новогоднее настроение, прошу всех под кат.

Новый год — это не просто пик трафика

Весь год все было хорошо, и вдруг в декабре что-то пошло не так. Почему? Потому что все те люди, которые в последние дни перед Новым годом ходят по торговым центрам в поисках подарков и горошка по акции, вдруг разом решили пойти на ваш сайт. И вместо тысячи онлайн-заказов все обернулось чем-то в духе «Извините, сайт временно недоступен».

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

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

Арендуйте GPU за 1 рубль!

Выберите нужную конфигурацию в панели управления Selectel. *

Подробнее →

Почему в праздники все может пойти не так

Thundering Herd: «Грохочущее стадо» 

Первый типичный триггер — это thundering herd (или, как его называют в интернете, «Грохочущее стадо»): когда толпа запросов одновременно обращается к одному кэш-ключу. Представьте: в крупном маркетплейсе стартует акция «Товар дня» по суперцене. Тысячи людей одновременно открывают карточку товара, а в этот момент запись о цене в кэше удаляется. В кэше пусто (cache miss). Приложение использует кэширование по принципу сквозного чтения и код выглядит примерно так:

public V readSomeData(K key) {
  Element element;
  if ((element = cache.get(key)) != null) {
    return element.getValue();
  }
  // note here you should decide whether your cache
  // will cache 'nulls' or not
  if (value = readDataFromDataStore(key)) != null) {
    cache.put(new Element(key, value));
  }
  return value;
}

Все потоки видят отсутствие данных и одновременно идут в базу с одинаковым SELECT-запросом. Если app-серверов десять, база получает в десять раз больше нагрузки без необходимости.​

В праздники ситуация усугубляется. Трафик растет в разы, TTL на каталоге товаров или промо-странице истекает, сотни воркеров пытаются сгенерировать один и тот же объект — база данных и основной сервер не справляются, кэш остается пустым.​

Решение — BlockingCache: первый поток захватывает блокировку на уровне ключа, идет в БД, а остальные ждут его завершения, чтобы прочитать уже готовый результат из кэша.

Backpressure: механизм обратного давления 

Второй триггер — отсутствие механизмов обратного давления (backpressure) и очереди задач. Представьте: внешний сервис (например, платежный шлюз или SMS) начал тормозить или отдавать ошибки. Система, пытаясь доставить все сообщения, начинает агрессивно повторять попытки, то есть ретраить.

При резком росте сбоев «мусорные» задачи на повтор начинают плодиться в геометрической прогрессии. Внутренние очереди растут, время жизни каждой задачи в системе тоже, и запускается каскад. Нагрузка от этих неудачных попыток начинает конкурировать с полезным трафиком за одни и те же ресурсы.

В праздничные пики: очереди переполняются, воркеры перестают справляться с объемом, и SLA по задержкам срывается. В итоге система начинает «отстреливать» даже здоровые запросы по таймаутам просто потому, что они стоят в очереди за тысячами безнадежных.  

Решение, как ни странно, — научить систему отказывать. Вместо накопления задач система мгновенно сбрасывает новые запросы при переполнении очередей (Fast Fail), временно блокирует обращения к упавшим внешним сервисам (Circuit Breaker) и растягивает повторные попытки во времени с помощью прогрессивных пауз (Backoff). Проще говоря, архитектура жертвует частью трафика, чтобы предотвратить полный паралич всего сервиса.

Resource Exhaustion: истощение ресурсов

На этом фоне появляется третий триггер — истощение ресурсов (Resource Exhaustion). Это стадия, когда проблемы с очередями и кэшем транслируют нагрузку напрямую на железо. При средней нагрузке их не видно, но в пике рождественских распродаж ситуация меняется: доли процента дополнительных запросов, долгих транзакций или блокировок выедают доступные лимиты: CPU, дисковый I/O или пул соединений к базе. Решение — делить систему на изолированные отсеки и выделять для критичных операций отдельные пулы ресурсов.

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

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

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

Как раз об этом пишут инженеры Selectel в своем блоге: практикующие специалисты рассказывают, как грамотно строить высоконагруженные системы — в том числе с использованием AI-сервисов. Подробные гайды можно найти в Академии →

Ну ладно, хватит теории — переходим к реальным случаям. Что там интересного случалось в праздники?

Кейсы: сценарии фейлов в праздники

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

AWS us-east-1: Рождественский коллапс

На дворе 7 декабря 2021 года, 10:30 по восточному времени. Все готовятся к праздникам. И тут самый загруженный регион Amazon — US-EAST-1 (Северная Вирджиния) — ушел в многочасовой сбой. Вместе с ним в небытие ушли Netflix, Disney+, рейсы Delta Airlines и даже умные пылесосы с камерами Ring. Миллионы людей не могли зайти домой или посмотреть сериал, а сам Amazon не мог отгружать товары — встали даже внутренние складские сканеры. 

Запуск новых инстансов, контейнеров (Fargate, ECS, EKS) и API-запросов встал наглухо: уже работающие ВМ жили, но управление ими заблокировалось из-за отказа CloudWatch, Gateway API и Secure Token Service. Восстановление растянулось до конца дня — самый долгий инцидент в этом регионе за годы, дольше даже S3-сбоя 2017.​

Это была иллюстрация того самого thundering herd, о котором мы говорили. Автоматика AWS решила масштабировать один из внутренних сервисов. Но что-то пошло не так: вместо плавного роста произошел взрывной выброс запросов. Тысячи внутренних клиентов сети AWS разом ломанулись в узкое горлышко между внутренними и основными сетями. Интересная деталь: Service Health Dashboard не обновлялся часами (сам упал из-за той же конгестии), а создание тикетов в поддержку заблокировалось — пользователи шутили в твиттере про «реальный статус региона» и отсутствие апдейтов.​

AWS признал «значительный ущерб клиентам» и пообещал переработку статус-страницы (выпустили в 2022 с переключением на запасной регион).  Сюрприз в том, что даже «распределенные» системы оказались уязвимы: сервис управления адресами (Route 53) тоже прошел через us-east-1, делая все бесполезным. 

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

Уже 15 декабря в западных регионах (us-west-1/2) начались проблемы с сетевой связностью, что окончательно подтвердило: праздничные пики трафика — самое опасное время.

Microsoft: BGP-хаос

25 января 2023 года утро для миллионов сотрудников по всему миру началось не с кофе, а с массового вылета Azure, Teams, Outlook и SharePoint. Пока люди гадали, что с интернетом, системы мониторинга (ThousandEyes) фиксировали недоступность сервисов: пакеты данных просто исчезали в никуда, а уровень потерь достигал 100%. Виновником стала сама Microsoft. Все началось с внешнего BGP-изменения: роутеры AS 8075 (их автономная система) внезапно отозвали и переобъявили префиксы (/24 и summary /12), что вызвало хаос в глобальных таблицах маршрутизации.​

Интересный момент — это не разовый сбой. Сначала отключались прямые пути обмена трафиком, то есть пиринг (например, к AS 16552), из-за чего данные пошли через транзитных провайдеров с длинным AS_PATH. Затем связь восстанавливалась, система пыталась вернуться на прежние пути, но ситуация повторялась. За 90 минут инцидента произошло несколько таких волн. 

Мониторинг ThousandEyes зафиксировал нестабильность маршрутов с 7:10. Пик пришелся на 7:40, а финальный всплеск — на 8:45. Потери сетевых пакетов напрямую коррелировали с этими колебаниями. Чтобы минимизировать ущерб, Microsoft пришлось перенаправлять DNS-трафик в обход проблемных участков сети.

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

Steam/Epic Games и как тут замешан AWS

Успели урвать по скидке игру в Steam или получить бесплатно в Epic Games? Возможно, из-за вас в том числе, в ночь на католическое Рождество 25 декабря 2025 года сервисы одновременно вышли из строя, оставив миллионы геймеров без новогоднего чилла доступа к платформам в пик праздничного трафика.

Epic Games столкнулась с аварией около 22:00 по московскому времени. Тысячи жалоб на недоступность Fortnite и лаунчера — статус‑страница Epic подтвердила деградацию сервисов. Самое интересное здесь — взаимное влияние. Как только одна платформа начинала сбоить, геймеры массово перебегали на другую, тем самым создавая еще более мощную волну трафика на оставшиеся живыми сервисы. Восстановление заняло часы, но точные причины не раскрыты публично. 

Важно отметить, что Epic Games Store арендует серверы в основном у AWS, и как-то подозрительно совпало, что примерно днем ранее, 24 декабря 2025 года, Amazon Web Services столкнулся с волной пользовательских жалоб на глобальные сбои. На Downdetector график аномалий взлетел вертикально — с 20:41 по североамериканскому времени количество жалоб подскочило до 3 659 к 22:52. 

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

Но Amazon официально опроверг сбой, назвав отчеты Downdetector «ненадежными и часто ошибочными» и указав на «событие в другом месте интернета». В ответ на пост финансового издания The Kobeissi Letter, где инцидент назвали уже третьим крупным провалом AWS за 2025 год, в Amazon ответили: единственный источник истины — наша статус-страница, а там «все зеленое». 

И это правда уже третий подобный скандал после октябрьского DNS-сбоя в us-east-1, затронувшего Disney+, Reddit и United Airlines, где ошибка в резолвере привела к каскаду по 70+ сервисам.​

Даже если корень проблемы не в самом облаке, а, например, в перегрузке внешних CDN-сетей или DNS, итог один — потери бизнеса. Миллионы пользователей, яростно нажимающих кнопку «Обновить», создают нагрузку. Официальные опровержения не возвращают игрокам доступ к серверам, а ритейлерам — сорванные заказы.

Но вернемся к Steam. Сбоить он начал в одно время с EGS. Игроки не могли авторизоваться, запустить или купить игру, что подтверждалось количеством жалоб на Steam Status и Downdetector. Платформа работала с перебоями несколько часов, вероятно, из-за перегрузки серверов от одновременных подключений и фоновых обновлений.

А подозрительно то, что с EGS все понятно (AWS-сбой → Epic down), но почему отвалился Steam — загадка. Он не использует AWS в качестве основного или единственного облачного провайдера, а полагается на собственную глобальную сеть доставки контента (CDN) и множество других провайдеров (Akamai, Level3), то есть для инфраструктуры Steam это не первостепенный вариант.

Y2K: Переход 1999–2000 

Сложно представить что-то масштабнее за последнее время, чем новый 2000 год, целый переход в новое тысячелетие. Представьте себе утро 1 января 2000: огромное количество строк кода в COBOL, Fortran и других языках, которые хранили годы в двух цифрах (например, «99»), сменились на «00». Но для машин в их компьютерных мозгах «00» — это не 2000, а 1900. Ломаются вычисления дат, сортировки, лицензии и отчеты. 

Масштаб угрозы оценивали в триллионы долларов: правительства и корпорации потратили $300–600 млрд на аудит и патчи 800+ тысяч систем, но полная переписка legacy-кода была нереальной — вместо этого шли тесты, эмуляторы.

Проблемы 1 января 2000 года в целом считались незначительными: сбои не всегда проявлялись ровно в полночь, поскольку многие программы активировались позже, а часть инцидентов была не напрямую связана с Y2K. Апокалипсиса не случилось — инцидентов было мало, инфраструктура выдержала благодаря превентивным фиксам. 

Но было несколько ярких случаев. В США спутниковая разведка NRO вышла из строя на три дня из-за патча, а не бага — обновление сломало станции. В Японии на АЭС «Сика» в префектуре Исикава через секунды после полуночи отказал мониторинг радиации (без риска для населения), а на 13 станциях временно не выдавали билеты. 

В Южной Корее в домах встали 902 системы отопления на срок от 19 до 24 часов. Больницы ошибочно записали новорожденного в 1900 год и выдали счета с той же датой, видеомагазин в Кванджу начислил штраф за 100 лет (~7 000$), а Корейский университет разослал дипломы за 13 января 1900.​

В Греции сразу ~30 000 касс (10% от всех) печатали чеки с 19 веком. А в США 150 слотов лотереи Делавэра встали, Нью-йоркский видео-магазин выставил счет на 91 250$ за «столетнюю» аренду, чикагский Fed Reserve не перевел 700 000$ налогов за день. В Бразилии порт Сантос 10 января не читал 20 000 старых таможенных реестров.​

Почему не случился полный коллапс? Крупные компании быстро пофиксили проблему, а исправления, правительства ввели обязательные проверки (в США — закон Year 2000 Act с отчетами GAO и советом FEMA, в ЕС — директивы). 

Остатки неисправленного старого кода в госсекторе и малом бизнесе вызвали только локальные проблемы: ошибки дат запускали повторные попытки, перегружали старые мейнфреймы и только путали.

Но а пока готовимся к новой беде — проблеме 2038 года в Unix-системах. 32-битный счетчик времени переполнится 19 января 2038 в 03:14:07 и обнулится. Срочно мигрируйте на 64-бит. Или все-таки торопиться не стоит, а все проблемы — просто мыльный пузырь? Пишите свое мнение в комментариях.

Заключение

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