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

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

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

Держите базовый чек-лист:
— idempotency: повторный запуск не должен дублировать записи;
— retries: только для временных ошибок, с ограничением и паузой;
— checkpoints: сохраняйте прогресс, а не только финальный результат;
— logging: пишите не «упало», а что именно, на каком объекте и почему.

Если есть очередь, cron или планировщик — отдельно проверьте, что задача не запускается параллельно сама с собой. Иначе один и тот же файл, заказ или строка таблицы обработается дважды, а потом это будет выглядеть как «странная бизнес-ошибка», хотя проблема была в конкуренции.

Еще одна типовая ошибка — смешивать загрузку, обработку и запись в один монолитный скрипт. Когда всё в одном блоке, любой сбой заставляет гонять процесс заново. Разносите этапы: вход, валидация, трансформация, выход. Тогда каждый шаг проще тестировать и безопаснее перезапускать.

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