Кто украл качество? Реальное расследование ночного инцидента на продакшне

Вступление

29 апреля 2025 года начался как обычный рабочий вторник. И тут кто-то вспомнил недавнюю историю…

…Команда разработчиков уверенно двигалась к релизу новой версии проекта, с нетерпением ожидая завершения долгого цикла тестирования и подготовки. Вроде бы всё было готово. Не было поводов для беспокойства. Все баги были исправлены, функционал проверен, все отчеты о тестировании — чистые. Мудрые прогнозы в день релиза указывали на положительный результат.
И всё бы шло как по маслу, если бы не… та самая ночная катастрофа.

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

Всё началось с падения

Казалось бы, все шло по плану. Продукт почти готов, тесты были проведены, и мы ожидали релиза с минимальными рисками. Но ночью, в момент наибольшей уверенности (и нашего спокойствия), случилось непредсказуемое. Ошибки начали сыпаться, как снег. Чат службы поддержки, которая обычно спокойна и не перегружена сообщениями, буквально взорвался.

🥎»Пользователи не могут оформить заказы!»
🥎 «Корзина не работает!»
🥎»Авторизация выбрасывает пользователей на стартовую страницу!»

Как вы понимаете, когда баги сыплются в таком количестве, это не просто баг — это преступление. И нам нужно было понять, кто виноват. Сначала мы подумали, что это просто серверные сбои. Быстро начали перезагружать серверы, проверяли сетевые соединения, но быстро стало очевидно, что проблема глубже. Нужно было провести расследование.

Экспертиза. Подключаем тестировщиков

Ситуация начала выходить из-под контроля, и мы поняли, что не обойтись без помощи опытных тестировщиков. Начали внимательно смотреть логи и проводить дополнительные анализы. Ведь в таких случаях важно разобраться, что именно стало причиной сбоя.
Первая подсказка пришла через логи запросов. Ошибки проявлялись в основном у пользователей с историей заказов. Новые пользователи, как ни странно, могли спокойно продолжать использовать сервис. Этот момент стал для нас важным ориентиром.

Что мы обнаружили?

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

Кто виноват?

В этот же момент мы начали рассматривать список подозреваемых, которые могли стоять за сбоями. Кто мог быть ответственным за это преступление качества?

• Код — главный подозреваемый
  Судя по всему, именно код должен был быть первым в списке. Мы начали с того, что проверили все последние изменения и запустили дополнительные автотесты. Всё начиналось с корзины — она не могла корректно обрабатывать данные пользователей. Но что не так? Мы нашли несколько inconsistencies в старой логике обработки корзины. Однако быстро поняли, что это не единственная проблема.
• Тестирование — подследственный с алиби
  Тесты, хотя и были проверены перед релизом, не показали всех уязвимостей. Почему? Мы использовали тестовые данные, которые не отражали реальной ситуации. И вот результат — баги, которые не были зафиксированы на этапе тестирования. Тестировщики не могли учесть все возможные вариации данных, с которыми система столкнется в реальных условиях.
• Время — главный соучастник
  Подсознательно все в команде считали, что релиз уже почти готов, и под давлением времени начали снижать требования к деталям. Проблемы с продакшн-данными стали очевидными, только когда все столкнулись с реальными сбоями. Мы начали проверять логи и заметили, что никто не подумал об исторических данных, тех, что пользователи накопили за время работы с платформой.

Следы багов, или что скрыто за каждым сбойным запросом?

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

Откуда же они взялись эти старые данные? Мы ведь тестировали систему с новыми пользователями! Ответ оказался прост: тесты не учли всех пользователей с нестандартными заказами, с разными статусами и уникальными товарами. И это стало тем моментом, когда мы нашли «главного виновника» — недостаточность данных для тестирования.

Виновный найден — расследование завершено

Когда мы разобрались с основной причиной сбоя, то, наконец, могли «закрыть дело». В чём же заключалась суть проблемы? В новой версии был переписан код, который касался работы корзины, но не учтено, что многие пользователи уже сделали заказы с особыми статусами.
В тестах использовались «чистые» данные — новые аккаунты без истории. Но на реальном продакшн-окружении ситуация была совсем другой. Некоторые пользователи оставляли заказы с нестандартными скидками, статусами и товарами, которые не могли быть обработаны новой логикой работы корзины.
Это открывает глаза на важный момент: если вы не тестируете продукт с реальными, «грязными» данными, то результат может быть неожиданным. Тестирование должно учитывать все вариации и данные, с которыми система будет работать на практике.

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

• Для будущих релизов будет обязательным тестирование на «грязных» данных.
• Будет введён дополнительный процесс проверки новых фич на реальных пользовательских сценариях.
• Обязательно проводить дополнительную проверку функционала при изменениях в работе с данными.

Зачем же, получается, вообще нужно тестирование?

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

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

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

Финальное. И кто украл качество?

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

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

Проблемы будут всегда.
Вопрос в том, кто их найдёт первым: вы или ваши клиенты. Тестирование — ваша система раннего оповещения. И ваш последний шанс исправить ситуацию до того, как станет поздно.