7 причин, почему Python-скрипт «работает у меня», но ломается на проде

7 причин, почему Python-скрипт «работает у меня», но ломается на проде

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

— Жёсткие пути к файлам вместо конфигурации через env
— Зависимость от текущей рабочей директории
— Неявные таймауты для HTTP, БД и очередей
— Отсутствие обработки пустых ответов и битых данных

Ещё одна типовая ловушка — асинхронщина и синхронщина вперемешку. Внутри FastAPI или любого asyncio-кода один блокирующий вызов может съесть весь выигрыш от async: запросы копятся, время ответа растёт, а причина прячется в одной библиотеке.

Проверьте, что скрипт умеет падать «красиво»: логирует контекст, не теряет входные данные, корректно закрывает соединения и повторяет только безопасные операции. Для задач парсинга и ETL это особенно важно: один кривой элемент в потоке не должен валить всю пачку.

Если скрипт нельзя поднять в чистом окружении за 10 минут, его уже пора чинить, а не «допиливать позже».