ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА
Образование · 3 сентября 2026 г.
ДОБАВИЛИ РЕТРАИ, А СТАЛО ХУЖЕ. ПОЧЕМУ? — 3 сентября 2026 г. в 09:59:34.432
ДОБАВИЛИ РЕТРАИ, А СТАЛО ХУЖЕ. ПОЧЕМУ? Хочу продолжить тему после последнего разбора задачи. Первый момент, который описан в задаче - это то, что разрабы добавили ретраи. И тут мне попалась интересная статья от Ozon Bank про то, как retry и timeout, которые должны повысить надежность, при кривой настройке, эту самую надежность и убивают. Те, кому интересно могут почитать. Она годная, но я тут в кратце накидаю мыслей, которые можно забрать аналитикам. ➖➖➖ 1️⃣ НАДО ПОМНИТЬ ПРО ТО, ЧТО РЕТРАИ (ПОВТОРЫ) ЗАПРОСОВ МОГУТ УСИЛИТЬ ПРОБЛЕМУ. Кейс ребят Представьте, что у вас 10.000 запросов в минуту и 10% из них падает. Если мы накидываем ретраи, то даже с одной дополнительной попыткой - это плюс тысяча запросов, то есть уже около 11.000, а если попыток три, то до трех тысяч сверху. И прилетают эти запросы именно тогда, когда сервису и так плохо 🥲 С точки зрения отдельного клиента - логика нормальная: не прошел запрос просто повторяем его, но если так делают тысячи клиентов одновременно, то retry превращается из механизма устойчивости в механизм усиления сбоя. Поэтому, про это надо помнить. Еще момент про который надо помнить с РЕТРАЯМИ - это то, что повторения могут привести к каскадному отказу сервисов. Это как? Представьте, что у вас есть цепочка из Сервисов и API: API → сервис A → сервис B → сервис C. Если сервис C начинает затупливать, а сервис B из-за этого решает, что это временный сбой и начинает делать повторные вызовы, а сервис A видит, что B отвечает медленно, и тоже начинает ретраить, то при ретрае в три раза - это увеличение количество запросов до 9 вместо 1. Поэтому, возникает каскад отказов и система становится нестабильной. Поэтому при сильной связанности сервисов про это надо помнить и с ретраями работать очень аккуратно. ➖➖➖ 2️⃣ НАДО ПРАВИЛЬНО РАБОТАТЬ С ТАЙМАУТАМИ Часто аналитики доверяют разрабам эту темку и опираются на стандартные паттерны по таймаутам, но если по стандарту таймауты у нас короткие, то из-за этого могут возникнуть обрывы соединения на ровном месте. При этом сервер об этом не знает и может дальше продолжить выполнять наш запрос. И из-за этого у нас может начаться возьня с дублями. При этом длинные таймауты излишне держат соединение. Поэтому, не забиваем на эту тему и стараемся работать с ними и прописывать в требованиях. Мне понравился механизм определения, который предложили коллеги из 🛍. Смотреть на реальную latency сервиса, например, на p99 и добавлять небольшой буфер, но также стоит опираться на другие критерии, например SLA. Короче, учитываете эти моменты и будет вам счастье на проекте 😘 Было полезно ставим 🔥 ➖➖➖ Места на курсе потихоньку уменьшаются ➡️ -15 ИЗ 40 МЕСТ