Практикум: расследование кейса

Финальная практика модуля: трёхактный детектив. Воспроизводим три типовые аварии и находим их по трейсам, применяя приёмы уроков 4.1–4.3.

Подготовка: намеренно больной сервис

Добавьте в свой сервис endpoint /checkout со скрытыми «дефектами» (переключатели через env):

• BUG_N1=1: цикл из 10 SQL-запросов (N+1);
• BUG_LOCK=1: удержание локальной блокировки 800 мс в критической секции (пустой промежуток в корневом спане);
• BUG_EXT=1: внешний HTTP-вызов с таймаутом 2с и тремя ретраями.

Акт 1. «p99 вырос, никто ничего не деплоил»

1. Включите BUG_N1=1 и запустите нагрузку;
2. Поиск: Service + Min Duration 1s;
3. В waterfall найдите паттерн «10 одинаковых последовательных SELECT»;
4. Вывод, который должен сформулироваться сам: батч/JOIN вместо цикла.

Акт 2. «Все процессы живы, а запросы висят»

1. Выключите N1, включите BUG_LOCK=1;
2. Поиск по длительности; трейс показывает промежуток без детей в корне — сервис «жил своей жизнью»;
3. Атрибуты корневого спана/события подскажут, на какой секции;
4. Урок кейса: трейс видит не только внешние вызовы — «пустые промежутки» это тоже диагноз.

Акт 3. «Внешний партнёр тормозит»

1. Включите BUG_EXT=1, найдите трейсы с хвостовыми длинными спанами HTTP;
2. Обратите внимание: 3 ретрая = 3 клиентских спана + общий таймаут; сравните два трейса (удачный и ретрайный) — разница сегментов очевидна;
3. Включите critical path: почти всё время — внешний вызов. Решение: кеш, circuit breaker, асинхронное подтверждение.

Разбор вслепую (главное упражнение)

Попросите коллегу (или случайный генератор) включить один из трёх BUG-флагов без вашего ведома. Ваша задача — методом поиска и чтения waterfall назвать дефект за ≤ 5 минут и оформить мини-отчёт:

• Запрос поиска в UI;
• Скриншот/описание найденного трейса;
• Гипотеза причины + предлагаемые изменения кода.

Эталонные цифры