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

Автоматизация ломается не на коде, а на неучтённых входных данных и побочных эффектах Если скрипт «работает у меня», это не признак готовности. В автоматизации обычно падают не алгоритмы, а края: пустые поля, дубликаты, таймауты, смена порядка колонок, неожиданный HTML, битые UTF-8 строки. Перед запуском в проде проверь базу: — есть ли идемпотентность, чтобы повторный запуск не плодил дубликаты; — что делать при частичном успехе: откат, повтор, ручная очередь; — где хранится состояние, чтобы процесс можно было продолжить после падения; — какие ошибки считаются нормальными, а какие сразу стопят пайплайн. Отдельно смотрите на логирование. Если в логах нет входных данных, идентификатора задачи и причины отказа, отладка превращается в угадайку. Для фоновых задач полезно писать не только traceback, но и короткий контекст: источник, шаг, размер пачки, время ответа. Ещё один частый провал — скрытые зависимости: локальный путь на диске, переменная окружения без значения, внешний сервис с неявным лимитом, cron без блокировки параллельного запуска. Скрипт должен либо явно проверять такие вещи на старте, либо падать сразу и понятно. Автоматизация живёт долго только там, где каждый шаг можно повторить, остановить и безопасно запустить снова.