Post Автоматизация ломается не в коде, а в предположениях о данных

Автоматизация ломается не в коде, а в предположениях о данных Чаще всего скрипт пишут под «идеальный» вход: один формат даты, один тип файла, один ответ API. Потом прилетает пустое поле, лишний пробел или другой порядок колонок — и весь пайплайн молча едет в мусор. За неделю в репах я бы проверял 4 вещи: — явная схема входа: pydantic, проверки типов, обязательные поля; — идемпотентность: повторный запуск не должен дублировать записи; — раздельные ошибки: парсинг, сеть, запись в БД, внешние лимиты; — логирование с контекстом: что пришло, на каком шаге упало, какой ключ сломан. Отдельная ловушка — «тихие» падения. Скрипт завершился успешно, но половина строк не обработалась, потому что фильтр слишком узкий или исключение проглотили в helper-функции. Для automation это хуже явного traceback: потом нечего расследовать. Если скрипт нужен не «на раз», а в работе, начинайте не с ускорения, а с контракта на данные, повторного запуска и понятных ошибок. Тогда автоматизация не превращается в набор магии, который чинят вручную по ночам.