Куда смотреть при возникновении проблем для дебага?

Что проверяют

Есть ли у вас порядок действий, или вы сразу открываете отладчик и начинаете гадать. Следом обычно дают ситуацию: на проде растёт число ответов 500, локально всё работает, с чего начнёте.

Как отвечать

Покажите путь от симптома к причине:

• масштаб: у всех или у одного пользователя, с какого момента, совпадает ли с релизом, сменой конфига или миграцией. Половина проблем находится уже здесь;
• traceback: читается снизу вверх, последняя строка это тип исключения. Фразы «During handling of the above exception» и «The above exception was the direct cause» показывают цепочку, и первопричина обычно в самом верхнем блоке;
• логи: logging с уровнями и контекстом, сквозной request_id между сервисами, в except вызов logger.exception, который пишет стек. Ошибки удобно собирать в трекер вроде Sentry, там видно, с какого релиза они пошли;
• метрики и трейсы: Prometheus и Grafana для времени ответа и доли ошибок, OpenTelemetry для трейсов, чтобы понять, в каком сервисе или запросе к базе ушло время;
• воспроизведение: breakpoint() в коде, python -m pdb script.py, после падения pdb.pm() для разбора упавшего кадра. В Python 3.14 pdb умеет подключаться к работающему процессу через -p PID;
• зависания и память: py-spy dump --pid снимает стеки живого процесса без перезапуска, faulthandler печатает стек при сегфолте или по таймауту, tracemalloc показывает, где растёт память, cProfile отвечает на вопрос «что медленно».

Закончите тем, что найденную ошибку закрываете тестом, который падал до исправления.

Где спотыкаются

Пишут logger.error(e). В логе остаётся строка текста без стека, и место ошибки приходится искать заново.

Глушат исключения через except Exception: pass или молча возвращают None, после чего ошибка всплывает в другом месте непонятным AttributeError.

Ищут баг в коде, не проверив окружение: версии зависимостей в pip freeze, переменные окружения, различия данных между стендами. Код может быть тем же, что вчера, а поменялось всё вокруг.