#ИИ_и_Автоматизация Скрипт падает из-за 502? Как просто и грамотно «автоматизировать повтор» на Python

Знакомо раздражение от того, что ваш автоматизированный процесс обрывается на самом банальном месте — например, при 502-ошибке от API? Честно, я сталкивался с этим десятки раз — и признаюсь: особенно раздражает, когда сбой временный и решается банальным «попробовать еще раз через пару секунд».

На деле таких случайных сбоев бояться не стоит — они бывают даже у крупнейших сервисов: сервер перегружен, шлюз не ответил вовремя, сеть дернулась. Самый частый вариант — 502 (Bad Gateway), чуть реже 503 или 504 (Service Unavailable, Gateway Timeout). Но! Есть простой паттерн: если научить свой скрипт повторять попытку с небольшой задержкой (это называют «retry с задержкой»), автоматизация становится куда надежнее — и ваши задачи заканчиваются не ошибкой, а результатом.

Как решаю это я — человек, увлечённый автоматизацией, но не гуру-разработчик? Использую вайбкодинг-инструменты (Copilot, Claude Code), чтобы получить простую, рабочую функцию, понятную даже тем, кто далёк от промышленной разработки.

Мой рабочий пример:

import time import requests

def get_with_retry(url, retries=3, delay=2): for attempt in range(1, retries+1): try: response = requests.get(url) if response.status_code in (502, 503, 504): print(f'Попытка {attempt}: получили {response.status_code}, жду {delay} секунд...') time.sleep(delay) elif response.status_code >= 400 and response.status_code < 500: print(f'Ошибка клиента: {response.status_code}. Повторять не стану.') return None else: return response except Exception as e: print(f'Ошибка: {e}, жду {delay} секунд...') time.sleep(delay) print('Все попытки исчерпаны.') return None

Пример: result = get_with_retry('https://example.com/api')

В этом подходе повторяются только «временные» технические сбои: 502, 503, 504. Если ошибка клиентская (например, 400 или 404 — значит, запрос был неправильный), функция не будет зря перезапрашивать. Кстати, иногда полезно увеличивать время ожидания после каждой неудачной попытки — это называют exponential backoff: с каждой неудачей пауза между запросами растёт. Достаточно добавить delay *= 2 внутри цикла.

На что стоит обратить внимание? — Не злоупотреблять числом повторов (иначе сервису может стать ещё хуже — да и скрипт зависнет надолго). — Никогда не повторять те запросы, которые изменяют данные, если нет механизма «идемпотентности» (иначе можно нечаянно дублировать результат на сервере). — Не стоит использовать retry для ошибок, связанных с неправильными входными данными — их исправляет только человек или внимательная логика скрипта. — Всегда учитывайте политику внешних API: некоторые не любят частые повторы, для них retry — инструмент, а не «пожарный топор».

Самый частый мой сценарий — отчёты, выгрузки данных, массовые загрузки из сторонних систем. Без автоматического «retry» эти задачи были бы крайне хрупкими, а с ним работают ожидаемо устойчиво, без «ручных» перезапусков.

Мой совет: относитесь к retry-логике как к «подстраховке» — просто, разумно и очень экономит нервы. Но всегда думайте о деликатности: повтор — это не повод вызвать DDOS случайно.

А как вы решаете вопросы автоматического повтора запросов в своих сценариях работы с API? С какими граблями сталкивались — и какие инструменты вам зашли больше всего? Давайте обменяемся опытом!