Post Автоматизация ломается не на коде, а на мелочах вокруг него

Автоматизация ломается не на коде, а на мелочах вокруг него Если скрипт «иногда работает», почти всегда проблема не в Python, а в допущениях: файл уже готов, API отвечает всегда, формат не меняется, задача запускается только вручную. Автоматизация живёт там, где каждый из этих пунктов может сломаться в любой момент. Перед тем как отдавать скрипт в cron, очередь или CI, проверь четыре вещи: — идемпотентность: повторный запуск не должен дублировать данные; — таймауты и ретраи: зависшие запросы не должны вешать весь процесс; — валидация входа: пустой CSV, битый JSON и лишняя колонка не должны валить пайплайн; — логирование: по логу должно быть ясно, на каком шаге всё упало. Отдельно стоит следить за состоянием. Если скрипт пишет в БД, S3, Redis или файлы, нужен понятный маркер прогресса: что уже обработано, что можно безопасно повторить, где хранится курсор. Без этого любой сбой превращает автоматику в ручной разбор полётов. И ещё одна типовая ошибка: смешивать бизнес-логику и запуск. Когда в одном файле и парсинг, и отправка, и запись, и планировщик, поддержка становится дороже самой задачи. Разносите на функции, а точку входа держите тонкой. Если автоматизацию нельзя запустить дважды без сюрпризов — это ещё не автоматизация, а хрупкий скрипт.