Один из моих "любимых" кейсов)

В проде внезапно поползли каскадные таймауты. Сервис приёма документов валился, за ним оркестратор, за оркестратором ещё пара сервисов по цепочке. Меня подключают уже во время инцидента в роли L4 - специалиста по нагрузке.

Смотрю логи и вижу знакомую картину. Клиент отправляет батч не на 10 документов, как было в протоколе нагрузочного тестирования, а целых… господи… 37!!!. Протокол был чёткий: 10 документов за один запрос проходят без таймаутов. Всё, что сверху, вызывает таймаут и мы это уже фиксировали как риск. Но бизнес решил, что "таких случаев якобы не должно быть", и рекомендацию добавить лимитер проигнорировали. Работа на один-два спринта для одного разработчика плюс неделя на регресс и фикс - отложили в бэклог с пометкой "как-нибудь поправим". И вот "как-нибудь" наступило в 9 утра, когда я (как подобает сове) спал, ведь мой старт был с 11.

Меня позвали именно потому, что я помнил этот кейс, помнил выданные рекомендации и мог сразу сказать, где ограничение и что делать. Эксперта НТ зовут на инцидент не чинить код, а восстанавливать контекст: какие сценарии мы гоняли, где проходила граница, какие рекомендации были выданы и проигнорированы. Это экономит часы расследования, потому что заключение уже лежит в документации, нужно только поднять и показать пальцем. А дальше команда либо вводит лимитер в экстренном порядке, либо откатывает проблемный функционал.

С тех пор в наших заключениях по НТ появился отдельный раздел: "Риски при игнорировании рекомендаций". Коротко, без драмы, но так, чтобы во время пожара любой мог открыть и понять, где именно сейчас рванёт.

#sre #loadtesting #incidentmanagement #oncall #productionincidents #qa #performancetesting #rootcauseanalysis #engineeringcommunication #riskmanagement