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

Автоматизация ломается не в коде, а в допущениях: 5 мест для проверки Автоматизация в Python обычно стартует с простого скрипта: забрать данные, преобразовать, отправить дальше. И почти всегда падает не на логике, а на краях: пустой ответ, дубли, таймаут, смена порядка полей. Проверьте эти точки до запуска в прод: — входные данные: что делаем с None, пустой строкой, невалидным JSON — идемпотентность: можно ли повторить запуск без двойной записи — ретраи: на каких ошибках повторяем, а на каких сразу стоп — лимиты: есть ли пауза, батчинг, backoff, очереди — логирование: по логам видно, какой шаг сломался и с какими данными Для скриптов, которые ходят во внешние API, полезно отделять транспорт от бизнес-логики. Тогда смена клиента, прокси, способа авторизации или формата ответа не размазывает правки по всему проекту. В Django и FastAPI это особенно заметно: один сервисный слой переживает и Celery, и cron, и ручной запуск. Еще одна типовая ошибка — считать автоматизацию “одноразовой”. Скрипт должен уметь пережить частичный провал: сохранить прогресс, не дублировать записи, продолжить с места остановки. Иначе любой сбой превращается в ручную пересборку пайплайна. Если скрипт нельзя безопасно запустить дважды и нельзя понять его состояние по логам, это не автоматизация, а хрупкая кнопка.