Почему системы падают в дни, о которых все знали заранее?
Системы падают в предсказуемые пиковые дни потому, что их никогда не тестировали в таком масштабе, а не потому, что они были сломаны. Один компонент — обычно база данных или внешний API — первым упирается в предел, и остальной стек выстраивается за ним в очередь. Лекарство — репетиция, а не переписывание: измерить цель, нагрузить до поломки, убрать первое узкое место, повторить. Этот список мы проходим с клиентами за четыре–шесть недель до дня Х. Ставки коммерческие, а не технические: исследование Deloitte по розничным сайтам показало, что ускорение мобильной загрузки на 0,1 секунды поднимало конверсию примерно на 8% (Deloitte, 2020), а зависшее оформление заказа в пиковый день — тот же эффект наоборот.
Как измерить до дня Х?
Задайте цель в цифрах, проведите нагрузочный тест, ведущий себя как реальные покупатели, и запустите дашборды до пика, а не после. Без цифры не узнать, прошли ли вы; без реалистичного теста узкое место найдётся в 10:03 в день Х; без дашбордов не понять, какой компонент отказывает. Core Web Vitals от Google дают готовую пользовательскую цель — LCP до 2,5 секунды и INP до 200 миллисекунд на 75-м перцентиле (web.dev, 2024), — а Chrome UX Report позволяет сравнить свои полевые показатели с конкурентами ещё до старта.
- 1. Цель в цифрах. Ожидаемые запросы в секунду, одновременные пользователи и заказы в минуту на пике — из прошлогодних данных с учётом роста, а не по ощущениям.
- 2. Нагрузочный тест, похожий на реальность. Сценарии k6 или Locust, которые ходят по каталогу, ищут, кладут в корзину и платят, на окружении, близком к продакшену, — пока что-нибудь не сломается. Цель — найти первое узкое место, а не «пройти».
- 3. Дашборды и алерты до дня Х. Перцентили задержки, доля ошибок, глубина очередей, соединения с БД, время ответа внешних сервисов. Чего не видно — того не починить в 10:03.
Как убрать очевидные узкие места?
Снимите чтения с базы кэшем, уберите медленную работу из запроса в очередь и дайте каждому внешнему вызову таймаут и запасной путь. Эти три хода закрывают большинство инцидентов, которые мы видим, потому что именно на базу и внешние API пиковый трафик давит сильнее всего. Кэширование — самый дешёвый выигрыш: страницы каталога, фасеты поиска и цены не зависят от пользователя, так что CDN и Redis отдают их, не трогая базу. Руководство Google SRE по каскадным отказам говорит о том же с другой стороны: цель — сбросить или отложить нагрузку до того, как насытится самая медленная зависимость (Google SRE, 2016).
- 4. Кэшировать всё, что не зависит от пользователя. Страницы каталога, фасеты поиска, цены: CDN и Redis снимают основную массу чтений с базы.
- 5. Очереди для всего медленного. Письма, счета, синхронизация с ERP, события аналитики — принять заказ, остальное в очередь.
- 6. База: индексы, пулы, реплики. Разобран лог медленных запросов, включён пул соединений, реплики чтения для отчётов, чтобы дашборд не мог остановить оформление заказа.
- 7. Внешние сервисы с таймаутами и запасными путями. Платёжные, логистические и налоговые API получают строгие таймауты, повторы с задержкой и деградированный сценарий (например, «стоимость доставки рассчитаем после заказа»).
Кэш или очередь: что решает ваше узкое место?
Используйте кэш, когда проблема — слишком много чтений одних и тех же данных; используйте очередь, когда проблема — медленная работа внутри запроса. Они решают разные половины пика: кэш защищает базу от толпы, которая просматривает каталог, очередь защищает оформление заказа от всего, что происходит после заказа. Большинству высоконагруженных систем нужны оба, и таблица показывает, как по симптому понять, какой из них требуется.
| Критерий | Кэш (CDN, Redis) | Очередь (Redis, RabbitMQ, SQS) |
|---|---|---|
| Какой симптом лечит | CPU базы и задержка чтения растут с трафиком | Время запроса растёт из-за писем, синхронизаций, PDF |
| Что меняет | Отдаёт повторные чтения без обращения к источнику | Выносит работу из запроса в воркеры |
| Типичные цели | Каталог, фасеты поиска, цены, сессии | Письма, счета, синхронизация ERP/CRM, аналитика |
| Главный риск | Устаревшие данные; лавина запросов при истечении | Незаметный рост очереди; дублирующая обработка |
| Страховка | TTL, версионированные ключи, блокировки от лавины | Алерты на глубину очереди, идемпотентные задачи, повторы |
| Трудоёмкость | Часы–дни | Дни; нужны воркеры и мониторинг |
Как подготовиться к аккуратному отказу?
Заранее решите, что выключите, докажите, что масштабирование работает, прежде чем на него полагаться, и запишите, кто что делает, когда цифры покраснеют. Аккуратный отказ — это когда магазин продолжает продавать с выключенными рекомендациями, а не когда ничего никогда не ломается. Автомасштабирование — пункт, который чаще всего предполагают и реже всего репетируют: квоты облака, время прогрева и лимиты соединений с базой ограничивают, насколько далеко реально уйдёт расширение. Столп надёжности AWS Well-Architected формулирует ту же мысль как правило: тестируйте процедуры восстановления и проектируйте горизонтальное масштабирование до пика, а не во время него (AWS, 2024).
- 8. Feature-флаги на всё дорогое. Рекомендации, живые остатки, персонализация — отключаются одним кликом.
- 9. Автомасштабирование проверено, а не предположено. Расширение отрепетировано под нагрузкой; лимиты и квоты уточнены у облачного провайдера.
- 10. Runbook и дежурный. Кто смотрит, что делает при росте очереди, как откатить. Записано, один раз отрепетировано.
Десять пунктов, ни одного экзотического. Системы, прошедшие список, переживают день; системы, пропустившие его, попадают в новости. Если ваш пик близко — запросите аудит готовности к нагрузке.