Что делать, если логи не показывают ничего интересного, а проблема остается
Что проверяют
Умеете ли вы сужать область поиска, когда подсказки нет, и понимаете ли, что пустота в логах это тоже факт, а не тупик. Заодно смотрят, не отдадите ли вы задачу разработчику с одной фразой о том, что ничего не воспроизводится.
Как отвечать
Сначала убедиться, что смотрели там. Частые промахи: другой сервис или другая реплика, не тот интервал времени из-за часового пояса, уровень логирования выше нужного, ротация уже срезала нужный кусок, сборщик логов отстаёт.
Если смотрели верно, пустота сама по себе сильный сигнал. Она обычно означает одно из двух: запрос до кода не дошёл, то есть остановился на балансировщике, прокси, авторизации или вообще не ушёл с клиента; либо ошибка перехвачена и проглочена пустым обработчиком.
Дальше сужать:
- сравнить рабочий и нерабочий случай, меняя по одному условию: пользователь, данные, окружение, версия клиента;
- посмотреть сеть со стороны клиента: какой запрос ушёл, какой код ответа, что в теле;
- пройти по сквозному идентификатору через все сервисы, если есть трассировка, и увидеть, на каком участке цепочка обрывается;
- проверить инфраструктуру: таймауты, ответы пятой сотни на балансировщике, перезапуски и нехватку памяти, рост очередей;
- заглянуть в базу и проверить, появилась ли там запись.
И отдельным результатом завести задачу на наблюдаемость. Если такой сбой не видно в логах, это дефект логирования, и чинить его надо наравне с самим багом.
Где спотыкаются
Считают чистые логи концом работы. В отчёте должно быть написано, где смотрели, за какой период и на каком уровне, иначе разработчик пройдёт тот же круг заново.
Ищут не в той среде. Стенд вместо контура, где дефект нашли, одна реплика из нескольких, время в другом поясе. На нескольких инстансах без общего сборщика логов это почти гарантированный промах.
Меняют сразу несколько условий при попытке воспроизвести и не записывают шаги. Проблема перестаёт проявляться, а понять, что именно на неё повлияло, уже невозможно.