👀 Постмортем инцидента с перегрузкой в Yandex Go в 2024 году

Кейс хоть и прошлогодний, но далеко не устаревший.

В системе Yandex Go из 500 микросервисов произошел часовой сбой всей инфраструктуры. После обновления в сервисе заказов возникли массовые ошибки, вызванные багом с сегфолтом на таймаутах Redis. Несмотря на откат обновления, система не восстанавливалась из-за перегрузки CPU (100% у многих сервисов). Пришлось ограничить трафик до 1% пользователей, а затем постепенно наращивать нагрузку до 5%, чтобы вернуть стабильность.

Причина:

Изначально ретраи с экспоненциальным бэкоффом и джиттером решали проблему таймаутов в сервисе ценообразования. Однако во время инцидента ретраи усилили нагрузку: оркестратор генерировал 3x нагрузку, а общая нагрузка выросла до 9x. Система не могла само-восстановиться после устранения триггера (отката релиза). Ретраи задерживали восстановление, увеличивая очередь запросов.

Следствие:

Сбой привел к остановке всех сервисов на час. Перегрузка CPU и рост запросов замедлили восстановление даже после устранения бага, что выявило уязвимость системы к ретраям в условиях длительного даунтайма.

Решение:

Команда решила внедрить бюджет ретраев с лимитом 10% от успешных запросов, дополнив существующий экспоненциальный бэкофф. Это минимизирует дополнительную нагрузку при сбоях. Также рассмотрели срезание нагрузки на сервере с порогом 50% и deadline propagation для прерывания запросов,. Улучшили алерты и тесты на таймауты Redis.

Выводы:

Ретраи с экспоненциальным бэкоффом не являются универсальным решением — они лишь откладывают перегрузку, а при длительных сбоях усиливают проблему. Ключ — в адаптивном управлении ретраями (бюджет или брейкер) и контроле нагрузки.

@DevOpsKaz 😛