1 сентября: школьный трафик приходит за одну ночь

MAATRIX

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

Чем 1 сентября отличается от календарной распродажи

К чёрной пятнице или новогодней ночи готовятся по одной и той же схеме: реклама разогревает аудиторию за недели, трафик растёт постепенно в течение вечера, а сама покупка растянута — кто-то оформляет заказ в 00:01, кто-то в 9 утра, кто-то через два дня после начала акции. У школьного трафика вокруг 1 сентября этой растянутости почти нет. Все участники синхронизированы одним и тем же внешним триггером — официальной датой начала учебного года, — и у большинства нет причины заходить раньше: расписание на новый год чаще всего появляется в системе не за неделю, а в последние дни августа, иногда буквально к вечеру 31-го числа.

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

Второе отличие — детерминированность момента. У чёрной пятницы старт часто размыт: магазин может открыть цены на сайте в полночь, а может постепенно в течение утра. У 1 сентября старт жёстко привязан к календарной дате, известной всем участникам одновременно: педагогам, родителям, ученикам, приёмным комиссиям. Нет способа растянуть этот момент рекламной кампанией — весь спрос физически сконцентрирован в нескольких часах.

Кто именно создаёт трафик и когда

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

• Электронный дневник / журнал успеваемости. Пик приходится на два интервала: сразу после полуночи (родители-полуночники и подростки, которым интересно посмотреть класс и расписание) и с 6:30 до 8:30 утра (массовая проверка расписания перед выходом в школу). Второй пик обычно выше первого по абсолютным цифрам, потому что затрагивает практически всех одновременно, а не только самых нетерпеливых.
• Школьный сайт / портал расписаний. Похожая картина, но добавляется третий всплеск около полудня 1 сентября — просмотр фотографий и новостей с линейки, который в отличие от первых двух пиков не связан с авторизацией и легче переживается статическим кешированием.
• Порталы поступления в колледжи и вузы (приёмные комиссии). Здесь пик может быть даже острее: у части абитуриентов 31 августа — последний день для подачи документов или подтверждения зачисления, и нагрузка складывается из двух разных типов действий — просмотра списков (много чтения, легко кешируется) и подачи форм/загрузки документов (запись в базу, куда сложнее применить кеш).
• Системы, создающие новые аккаунты по факту зачисления. Первоклассники, новые ученики, переведённые классы — для таких пользователей 1 сентября часто оказывается первым в жизни входом в систему, то есть нагрузка идёт не на существующие сессии, а на создание новых учётных записей, что тяжелее для базы данных, чем обычный логин.

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

Почему рушится именно аутентификация

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

Каждый вход — это, как правило, несколько дорогих операций подряд: проверка пароля с хешированием (bcrypt/argon2 намеренно медленные, чтобы затруднить перебор), запись новой сессии, часто — запрос к базе за профилем ученика, расписанием, оценками. Когда десятки тысяч человек одновременно проходят этот путь в пределах 15-20 минут, а не размазанным по часу трафиком, упирается в потолок не веб-сервер, а конкретно:

• Пул соединений к базе данных. Если приложение открывает по соединению на каждый запрос вместо использования пула, база быстро упирается в лимит подключений — подробнее о том, как это работает, в статье про connection pool.
• Очередь на прослушивающем сокете (backlog). Когда клиенты подключаются быстрее, чем приложение успевает их принимать, очередь на уровне ОС переполняется, и часть пользователей получает не медленный ответ, а сразу отказ в соединении — механика разобрана в статье про backlog очереди и отказ в соединении.
• Хранилище сессий. Если сессии пишутся в ту же базу, что и остальные данные, всплеск новых сессий конкурирует за те же ресурсы, что и чтение расписания — притом что оба нужны одновременно.
• Rate limiting, настроенный на обычный трафик. Защита от брутфорса, которая в обычный день режет по IP несколько неудачных попыток входа подряд, в ночь на 1 сентября может начать банить целые школы и офисы — за одним IP-адресом (NAT провайдера, общая сеть учебного заведения) вход пытаются сделать десятки разных людей за минуту, и без поправки на это легитимные пользователи получают блокировку вместо доступа.

Отдельная неприятность — сброс паролей. Часть родителей и учеников за лето забывает пароль от дневника, и в ту же ночь, когда система и так под нагрузкой, включается поток запросов на восстановление доступа через почту или SMS — ещё одна цепочка операций (токен, письмо, запись в базу), которая либо учтена заранее, либо становится вторым узким местом поверх первого.

Отличие по последствиям: не отменённый заказ, а испорченное утро

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

Родитель, которому нужно узнать номер класса ребёнка к линейке в 8:30, не может «вернуться за покупкой завтра» — ему нужно решение сейчас, и если дневник не открывается, он либо звонит в школу (перекладывая нагрузку на секретаря), либо пишет гневный отзыв, либо и то, и другое. Абитуриент, не успевший загрузить документ до полуночи 31 августа из-за упавшего портала, теряет не покупку, а потенциально год — несопоставимо более серьёзная претензия, чем недоставленный заказ.

Отсюда две практических особенности:

• Жалобы концентрируются не в течение дня, а в первые же минуты — сбой в 00:05 получает первую волну гневных сообщений в родительских чатах и соцсетях школы в течение получаса, а не через день, когда «отписался бы» недовольный покупатель.
• У школьного трафика почти нет варианта graceful degradation в духе «покажем упрощённую версию каталога» — расписание либо доступно, либо нет; частичная деградация (например, показывать вчерашние кешированные данные при явной пометке «данные могут быть неактуальны») спасает ситуацию только отчасти, но лучше, чем белый экран ошибки.

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

Как готовиться заранее к известной дате

Главное преимущество этого пика — дата известна за месяцы, что открывает пространство для подготовки, недоступное при погодных или новостных всплесках.

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

Пересмотр лимитов rate limiting под режим «много людей за одним IP». Временное (на ночь 31 августа — 1 сентября) смягчение порогов по количеству попыток входа с одного адреса, или переход на капчу после N неудачных попыток вместо жёсткой блокировки IP целиком — дешевле, чем терять легитимных пользователей за компанию с реальными брутфорс-атаками.

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

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

Отдельный пул соединений или реплика базы только под чтение расписаний. Для проектов с ограниченным бюджетом хорошо работает разделение: тяжёлые операции с записью (создание аккаунтов, восстановление пароля) идут через основной пул с приоритетом, а массовое чтение расписаний — через read-реплику или отдельный кеш-слой, чтобы одно не забивало очередь другому.

Что делать в момент самого всплеска

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

• Живой мониторинг с 23:30 до 9:00, а не просто настроенные алерты — при таком узком окне пика счёт идёт на минуты, и лучше, чтобы человек видел график в реальном времени, а не ждал срабатывания порогового алерта.
• Готовый план деградации, прописанный заранее: что показывать пользователю, если база перегружена — очередь с честным сообщением о загрузке лучше, чем случайные тайм-ауты и белый экран. Ответ через 20 секунд с пометкой «высокая нагрузка» воспринимается спокойнее, чем ошибка 500.
• Быстрый канал эскалации. Если дежурный инженер один, у него должен быть заранее согласованный контакт того, кто может оперативно добавить мощности — искать ответственного за доступ в 00:20 первого сентября не лучший момент для знакомства с процедурой эскалации.
• Отдельное наблюдение за очередью писем и SMS, если восстановление пароля идёт через них — заторможенная очередь отправки в пиковую ночь создаёт вторичный поток жалоб «прислали код только через час», который выглядит отдельным инцидентом, а на деле следствие первого.

Типичные ошибки при подготовке

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

• Масштабирование «по факту», когда алерт уже сработал. Ручное добавление мощности после того, как нагрузка уже обвалила сервис, почти всегда опаздывает — пока инженер получил алерт, зашёл, поднял и прогрел новый инстанс, самое узкое пиковое окно (15-30 минут) может уже пройти, а репутационный урон остаться.
• Автомасштабирование, настроенное на постепенный рост. Правила, рассчитанные на плавное увеличение нагрузки за полчаса, могут не успеть за почти вертикальным скачком — лучше заранее вручную поднять базовый уровень мощности перед известным пиком, а автомасштабирование оставить страховкой сверху.
• Тестирование только «happy path» существующего пользователя. Нагрузочный тест, где виртуальные пользователи уже имеют аккаунт и просто логинятся, не показывает нагрузку от создания новых учётных записей — а именно этот сценарий массово случается у первоклассников и абитуриентов.
• Забытая на лето команда поддержки. Если ключевые люди, знающие систему, в отпуске до 2 сентября, а дежурство передано без подробного плана действий — цена ошибки в эту ночь выше, чем в обычный будний день, а ресурсов для реакции меньше.
• Игнорирование эффекта NAT и общих сетей. Жёсткие правила rate limiting по IP без учёта того, что за одним адресом может сидеть целая школа или офис, банят не одного нарушителя, а десятки легитимных пользователей разом.

Частые вопросы