Маленький баг — огромный убыток: как компании теряют миллионы из-за ошибок в коде

Например, в России летом 2025 года массовые сбои в расписании рейсов из-за нарушений в системе управления расписанием и логистики привели к потерям компании, превышающим 20 млрд руб. за сутки. И это только для авиакомпаний. Даже если сбой не был единичным техническим сбоем — багом, масштаб ущерба наглядно демонстрирует уровень потенциальных рисков.

Цепная реакция

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

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

• времени отклика;

• количества ошибок при обработке операций;

• потребления CPU и памяти.

Такой подход позволяет заранее смоделировать экстремальные сценарии (например, резкий рост количества одновременных операций) и выявить скрытые проблемы. Если этого не сделать, пользователи столкнутся с зависшими заказами, «провалами» оплат и сообщениями об ошибках при попытке завершить действие.

Превентивная терапия

Мы внедрили систему управления тестированием — это единая платформа, где собираются все тесты, результаты проверок и информация о качестве продукта. По сути, это «центр управления полетами» для QA-команды (англ. quality assurance — процесс обеспечения качества программного обеспечения. — Прим. ред.): видно, что уже проверено, что сломалось и какие ошибки нужно исправить.

Кроме того, мы настроили автоматизированный процесс доставки обновлений — CI/CD (англ. continuous integration/continuous delivery — непрерывная интеграция/непрерывная доставка. — Прим. ред.)

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

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

Имитация перегрузки

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

• оформление заказов;

• оплаты;

• обновления статусов заказов.

Тестирование выявило, что при большом числе параллельных операций:

• время отклика увеличивалось примерно с 1–2 секунд до 10–15, в сценариях с большим количеством пользователей до 60 секунд;

• часть действий пользовательского сценария, написанного для нагрузочного тестирования (что именно не работало, не могу рассказать из-за соглашения о конфиденциальности), зависала;

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

Что сделали, чтобы устранить слабые места:

• пересмотрели, как устроена система внутри: перестроили логику так, чтобы действия пользователей проходили быстрее и не блокировали друг друга;

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

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

В результате платформа выдерживает нагрузку выше плановой без сбоев: аналитика при расчетах среднего числа пользователей, которые будут посещать веб-приложение, указывала на 1–1,5 тыс. Нагрузочное тестирование помогло увеличить этот показатель на 20–25%.

Масштабирование как уязвимость

Когда бизнес растет, меняется статистика входящих событий. Это могут быть заказы:

• платежи;

• обращения клиентов;

• интеграционные запросы от партнерских сервисов;

• плотность трафика;

• число внешних зависимостей;

• поведение клиентов в компаниях и у партнеров.

Хвосты задержек

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

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

Я столкнулся с этим во время тестирования распределенной платформы: под нагрузкой часть микросервисов вместо нормальных 150–200 мс начинали отвечать за 800–1200 мс. Один «медленный» сервис блокировал дальнейшую обработку. Остальные сервисы ждали его ответа, поэтому вся последовательность операций останавливалась.