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

Автоматизация ломается не на коде, а на исключениях и повторном запуске Чаще всего скрипт пишут как «счастливый путь»: данные пришли, API ответил, файл сохранился. В реальной автоматизации важнее другое — что будет при таймауте, пустом ответе, дубле, частичном падении и повторном запуске после сбоя. Держите базовый чек-лист: — idempotency: повторный запуск не должен дублировать записи; — retries: только для временных ошибок, с ограничением и паузой; — checkpoints: сохраняйте прогресс, а не только финальный результат; — logging: пишите не «упало», а что именно, на каком объекте и почему. Если есть очередь, cron или планировщик — отдельно проверьте, что задача не запускается параллельно сама с собой. Иначе один и тот же файл, заказ или строка таблицы обработается дважды, а потом это будет выглядеть как «странная бизнес-ошибка», хотя проблема была в конкуренции. Еще одна типовая ошибка — смешивать загрузку, обработку и запись в один монолитный скрипт. Когда всё в одном блоке, любой сбой заставляет гонять процесс заново. Разносите этапы: вход, валидация, трансформация, выход. Тогда каждый шаг проще тестировать и безопаснее перезапускать. Если автоматизация должна жить долго, проектируйте ее как цепочку повторяемых шагов, а не как одноразовый запуск.