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

Автоматизация ломается не в коде, а в предположениях о входных данных Скрипт для парсинга, отчётов или синхронизации обычно пишут под «нормальный» кейс: один формат, одна схема, один источник. Потом в бою прилетает пустое поле, лишний символ, дубль или таймаут — и пайплайн молча портит данные. Что помогает держать автоматизацию живой: — валидировать вход на границе: pydantic, явные проверки, whitelist полей; — делать операции идемпотентными: повторный запуск не должен плодить дубли; — отделять сбор данных от записи: сначала сырой слой, потом преобразование; — логировать не только ошибки, но и «подозрительные успехи»: пустые ответы, частичные выборки, неожиданные типы. Ещё одна типовая ошибка — смешивать бизнес-логику и инфраструктуру. Когда парсер сам решает, как ретраить, как маппить поля и куда слать уведомление, его трудно тестировать и ещё труднее менять. Лучше держать шаги отдельно: fetch → validate → transform → store → notify. Если автоматизация должна жить долго, проектируйте её как набор маленьких повторяемых операций, а не как один «магический» скрипт: так она переживёт любой шум во входных данных.