Нагрузки и стабильность в транспортных IT-системах: что ломается первым и как этого избежать

Почему транспортные системы падают именно в час пик

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

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

Что ломается первым: типичная цепочка отказа

За годы работы с нагруженными системами выстраивается довольно предсказуемая последовательность. Зная её, можно заранее усилить слабые звенья.

• База данных и блокировки. Первым обычно сдаётся не «железо», а БД. Длинные транзакции, отсутствие нужных индексов, блокировки строк при списании средств с карты — всё это превращает запрос в очередь. Один медленный запрос под нагрузкой начинает удерживать соединения, и пул соединений исчерпывается.
• Пул соединений. Когда свободные соединения к БД заканчиваются, новые запросы встают в ожидание. Внешне это выглядит как «всё зависло», хотя сервер базы данных ещё не перегружен — просто к нему невозможно достучаться.
• Синхронные внешние вызовы. Платёжный шлюз банка, SMS-провайдер, картографический сервис отвечают медленнее обычного. Если код ждёт ответа синхронно и без таймаута, каждый такой вызов «съедает» поток приложения. Через минуту все потоки заняты ожиданием — система жива, но не отвечает.
• Очереди и фоновые задачи. Поток телеметрии с транспорта (координаты, статусы валидаторов) копится быстрее, чем обрабатывается. Очередь растёт, лаг данных увеличивается, диспетчер видит устаревшую картину на карте.
• Каскадный отказ. Один перегруженный сервис тянет за собой соседние, которые от него зависят. Без изоляции отказ одного модуля (например, биллинга) роняет валидацию проезда, хотя технически они могли бы работать раздельно.

Узкие места, специфичные для транспорта

В отличие от обычного интернет-магазина, транспортные системы имеют несколько особенностей, которые усиливают риски под нагрузкой.

Финансовая критичность каждой операции. Списание за проезд должно быть атомарным и идемпотентным. Если валидатор не получил ответ за 200 мс, нельзя ни пропустить пассажира бесплатно, ни списать дважды. Под нагрузкой соблазн «упростить» транзакцию приводит либо к двойным списаниям, либо к потерянной выручке.

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

Поток телеметрии. GPS-координаты с сотен единиц транспорта каждые несколько секунд — это постоянная фоновая нагрузка на запись. Если её писать в ту же базу, что и финансовые операции, телеметрия будет конкурировать с биллингом за ресурсы. Разделение этих потоков — базовое архитектурное решение.

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

Как это предотвратить: практические принципы

Стабильность — не результат одной «волшебной» технологии, а сумма дисциплинированных решений на каждом уровне.

• Таймауты и ретраи везде. Любой внешний вызов (банк, SMS, сторонний API) должен иметь жёсткий таймаут и стратегию повтора с экспоненциальной задержкой. Бесконечное ожидание — главный убийца под нагрузкой.
• Circuit breaker. Если внешний сервис деградировал, система должна перестать его звать на время и отдавать заранее заготовленный ответ или ставить операцию в очередь, а не выстраивать тысячи запросов в очередь к мёртвому шлюзу.
• Асинхронность для всего некритичного. Уведомления, аналитика, запись телеметрии, отчёты — через очередь сообщений, а не синхронно в момент запроса пользователя. Пользователь должен получить быстрый ответ, остальное обрабатывается фоном.
• Идемпотентность операций. Каждый платёж и каждая валидация должны иметь уникальный ключ, чтобы повтор запроса (а под нагрузкой ретраи неизбежны) не приводил к двойному списанию.
• Изоляция модулей. Биллинг, валидация, телеметрия и отчётность должны деградировать независимо. Падение отчётов не должно останавливать продажу билетов.
• Горизонтальное масштабирование без состояния. Серверы приложений должны быть stateless, чтобы под пиком можно было просто добавить экземпляры. Состояние — в БД и кэше, а не в памяти конкретного сервера.
• Кэширование справочников. Маршруты, тарифы, остановки меняются редко, но читаются постоянно. Их место — в кэше, а не в БД при каждом запросе.

Наблюдаемость: нельзя починить то, чего не видишь

Отдельная и недооценённая тема — мониторинг. Очень часто инцидент диагностируют постфактум, по жалобам пользователей, потому что в системе нет метрик. А когда система «зависла», но процессы формально живы, без метрик невозможно понять, что именно сломалось: пул соединений, очередь, внешний шлюз или сама БД.

Минимальный набор для транспортной системы: время ответа по ключевым операциям (валидация, платёж), глубина очередей и лаг обработки, число занятых соединений в пуле, доля ошибок внешних вызовов, использование CPU/памяти/диска. Поверх — алерты на пороги, а не «зелёный дашборд, который никто не смотрит». Важно мониторить не суммарные показатели, а критичные потоки по отдельности: суммарный «онлайн» может выглядеть нормально, пока приём данных по одному узкому каналу давно стоит.

С чего начать, если система уже в продакшене

Если система уже работает и периодически «ложится» на пиках, переписывать всё с нуля не нужно и почти всегда вредно. Разумная последовательность такая: сначала включить наблюдаемость и собрать данные о реальных инцидентах; затем по метрикам найти первое узкое звено (обычно это БД или внешний вызов без таймаута); устранить его и повторить нагрузочный тест со всплесками. Эту итерацию повторяют, пока система не выдерживает пик с запасом. Точечное усиление по данным почти всегда эффективнее «большого переписывания вслепую».