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

Автоматизация ломается не на коде, а на неучтённых краях процесса Если скрипт «вроде работает», проверь не бизнес-логику, а входы и выходы: пустые поля, дубли, частичные записи, неожиданный формат даты, лимиты API. Чаще всего ручной труд возвращается именно там, где автоматизация молча проглатывает мусор. Перед запуском любого job полезно держать короткий чек-лист: — есть ли идемпотентность, чтобы повторный запуск не создавал дубликаты; — есть ли таймауты и ретраи, но с ограничением по числу попыток; — пишет ли скрипт понятные логи, по которым можно восстановить цепочку; — умеет ли он останавливаться безопасно и продолжать с места сбоя. Отдельно проверь стык между задачами. Если один шаг пишет в файл, а другой читает его же, нужен договор по схеме, кодировке, имени, времени жизни и атомарной записи. Иначе баг будет выглядеть как «иногда не нашёл данные», хотя проблема в гонке или неполной записи. Самая полезная привычка — не «автоматизировать всё», а сначала описать ручной процесс в 5-7 шагов и убрать из него всё, что нельзя измерить или повторить. Тогда код становится не магией, а заменой конкретной операции.