Не увлекайтесь автоматическими повторами

Это перевод Take it easy on the automatic retries. Автор: Реймонд Чен.

Когда я вижу дискуссию о том, как сделать повтор операции через try/except, используя для вдохновения функцию на Ruby, которая повторяла сетевую операцию три раза, прежде чем вернуть ошибку - я чувствую необходимость предупредить против автоматического повтора.

Вы можете подумать при встрече ошибки, что она вызвана какими-то временными явлениями, так что вы повторяете операцию ещё раз. Второй или третий раз, наконец-то, заработает - и ваша функция сможет продолжить работу. А пользователь не получит раздражающего диалога "Abort, Retry, Cancel" - минус один вызов в вашу тех-поддержку. Что же тут плохого?

Я много раз видел, как всё шло наперекосяк. Это было настолько плохо, что моя личная рекомендация - не используйте автоматический повтор вообще никогда. Если что-то завершается неудачей - просто сообщите об ошибке. Если пользователь хочет повторить операцию, то пусть он и примет это решение.

Вот как всё может пойти не так. Это реальный пример, но имена были удалены; ведь я не хочу никого осмеивать - я хочу, чтобы вы учились. Есть одна возможность (feature), связанная с сетью. Быть ненадёжным - это вполне в природе сетей, так что реализаторы функциональности этой возможности решили пытаться выполнить свою задачу десять раз, прежде чем наконец сдаться и вернуть ошибку. Операция, которую они запускали, реализовывалась другой группой разработчиков, и те тоже решили делать повтор, но уже пять раз. Эта вторая группа разработчиков вызывала сетевую функцию с таймаутом в 30 секунд. А приложение, которое и использовало эту возможность, пыталось повторить операцию 15 раз.

Давайте посчитаем. В самом низу у нас задержка 30 секунд. Пять повторов дают две с половиной минуты. Десять повторов на следующем слое дадут двадцать пять минут. Пятнадцать повторов на самом верхнем слое приложения поднимают это до более шести часов. Операция, которая, по идее, должна была завершиться за тридцать секунд, вернув ошибку, стала, через мультипликативный эффект нескольких слоёв повторов шестичасовым марафоном. И тогда вы получите звонок от очень злого клиента, который будет требовать, чтобы вы доставили ему исправление вчера, потому что из-за этой проблемы у них падают продажи.

(Проводник виновен в этом не менее других. Хотя попытка исправить это патчем shell32.dll обречена на провал, потому что shell32.dll часто обновляется обновлениями безопасности).