Это частая история: локально всё работает, на сервере часть пользователей видит ошибку, а в логах пусто или почти пусто. В таком случае нужно не паниковать, а идти по понятному пути: проверить входные данные, сравнить окружения, посмотреть логи, воспроизвести сценарий, затем уже чинить. Ниже даю порядок действий, который помогает быстро сузить круг поиска.
Что делать по шагам
Шаг 1. Сначала проверяйте не код, а данные. Часто баг появляется только на конкретном типе пользователя, например с пустым полем, длинным именем, редкой валютой или старой версией приложения.
Шаг 2. Сравните окружения. Проверьте версию API, переменные среды, настройки базы данных, кеш, права доступа и внешние сервисы.
Шаг 3. Посмотрите не только ошибку, но и путь до нее. Иногда падает не сам endpoint, а одна из зависимостей, например платежный шлюз, очереди или сторонний сервис авторизации.
Шаг 4. Воспроизведите ошибку вручную. Возьмите тот же пользовательский сценарий, те же параметры и прогоните запросы через curl, Postman или тестовый стенд.
Шаг 5. Если ошибка плавающая, включите дополнительное логирование именно на этот кейс. Логи должны показывать входные данные, ответ внешнего сервиса и итоговое решение системы.
Шаг 6. После фикса обязательно добавьте тест, чтобы ошибка не вернулась.
Небольшой пример проверки
Пользователь жалуется, что не создается заказ только с определенного телефона.
Проверяем формат номера, длину, код страны, пробелы и скрытые символы.
Дальше смотрим, не ломается ли валидация на одной из языковых версий.
Затем повторяем сценарий на staging с тем же payload.
Когда баг проявляется только у части пользователей, я всегда начинаю с сегментации. Смотрю, у кого именно ломается сценарий, и разбиваю по признакам: браузер, версия приложения, регион, тип аккаунта, время суток, наличие кеша. Очень часто причина оказывается в одном узком сегменте, а не в общей логике. После этого полезно сравнить реальные payload’ы успешного и неуспешного запроса, а не просто читать код. Разница бывает буквально в одном символе, пробеле или неожиданном null.
Я бы еще проверил инфраструктуру вокруг API, особенно если ошибка «плавающая». Например, не отваливается ли один из подов, не упирается ли БД в лимиты соединений, не растет ли latency на стороне внешнего сервиса. Иногда кажется, что проблема в приложении, а на деле это перегрузка на уровне базы или кеша.
Самый полезный шаг для QA в таких случаях, это ручное повторение сценария с точным копированием данных пользователя. Не в общем виде, а буквально как было у него. Если есть возможность, сохраните его запрос, заголовки, токены, параметры и повторите в тестовой среде. Потом уже пишите регрессионный тест, который фиксирует этот сценарий. Так вы не только чините баг, но и строите защиту от повтора.
В таких кейсах я советую сразу добавить технический триггер. Например, если ошибка возникает на одном и том же шаге, пусть система отправляет короткое уведомление в админ-чат с кодом ошибки, user_id и временем. Это сильно ускоряет реакцию, особенно если проблема повторяется у нескольких пользователей подряд. Еще хорошо помогает простой флаг диагностики, который можно включить только для конкретного аккаунта или клиента, чтобы не шуметь логами на весь сервис.
С точки зрения данных, важно смотреть не только на факт ошибки, но и на частоту. Если баг возникает у 1% пользователей, а не у 30%, то у вас уже есть гипотеза, что проблема связана с конкретным сегментом. Статистика помогает не чинить лишнее.