<b>Автоматизация ломается не на коде, а на неучтённых входных данных и побочных эффектах</b>

<b>Автоматизация ломается не на коде, а на неучтённых входных данных и побочных эффектах</b>

Если скрипт «работает у меня», это не признак готовности. В автоматизации обычно падают не алгоритмы, а края: пустые поля, дубликаты, таймауты, смена порядка колонок, неожиданный HTML, битые UTF-8 строки.

Перед запуском в проде проверь базу:
— есть ли идемпотентность, чтобы повторный запуск не плодил дубликаты;
— что делать при частичном успехе: откат, повтор, ручная очередь;
— где хранится состояние, чтобы процесс можно было продолжить после падения;
— какие ошибки считаются нормальными, а какие сразу стопят пайплайн.

Отдельно смотрите на логирование. Если в логах нет входных данных, идентификатора задачи и причины отказа, отладка превращается в угадайку. Для фоновых задач полезно писать не только traceback, но и короткий контекст: источник, шаг, размер пачки, время ответа.

Ещё один частый провал — скрытые зависимости: локальный путь на диске, переменная окружения без значения, внешний сервис с неявным лимитом, cron без блокировки параллельного запуска. Скрипт должен либо явно проверять такие вещи на старте, либо падать сразу и понятно.

Автоматизация живёт долго только там, где каждый шаг можно повторить, остановить и безопасно запустить снова.