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

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

Автоматизация в Python обычно стартует с простого скрипта: забрать данные, преобразовать, отправить дальше. И почти всегда падает не на логике, а на краях: пустой ответ, дубли, таймаут, смена порядка полей.

Проверьте эти точки до запуска в прод:
— входные данные: что делаем с None, пустой строкой, невалидным JSON
— идемпотентность: можно ли повторить запуск без двойной записи
— ретраи: на каких ошибках повторяем, а на каких сразу стоп
— лимиты: есть ли пауза, батчинг, backoff, очереди
— логирование: по логам видно, какой шаг сломался и с какими данными

Для скриптов, которые ходят во внешние API, полезно отделять транспорт от бизнес-логики. Тогда смена клиента, прокси, способа авторизации или формата ответа не размазывает правки по всему проекту. В Django и FastAPI это особенно заметно: один сервисный слой переживает и Celery, и cron, и ручной запуск.

Еще одна типовая ошибка — считать автоматизацию “одноразовой”. Скрипт должен уметь пережить частичный провал: сохранить прогресс, не дублировать записи, продолжить с места остановки. Иначе любой сбой превращается в ручную пересборку пайплайна.

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