Перейти к содержимому
Flag Autopsy

Расследование инцидентов с флагами функций

Найдите изменение флага, которое сломало прод.

Flag Autopsy сопоставляет журнал изменений флагов с графиком ошибок или задержки, находит момент начала всплеска и ранжирует каждое изменение по вероятности того, что виновато именно оно. Вы получаете главного подозреваемого, время, за которое его отключили, и отчёт для разбора инцидента.

Как он решает
CASE 0421ошибки оплаты
  1. 1pricing_cache 25% → 50%
  2. 2checkout_v2 0% → 50%Главный подозреваемый
  3. 3dark_mode вкл.

Что это

Инструмент для расследования инцидентов, вызванных флагами функций. Читает журналы изменений из LaunchDarkly, Unleash, Flagsmith, GrowthBook, вашей таблицы аудита или обычные заметки.

Для кого

Для дежурных инженеров, менеджеров релизов и SRE, которым нужно быстро понять, какой переключатель вернуть, и для команд, которые потом пишут разбор инцидента.

Какую проблему решает

Когда ошибки резко растут, за последний час могли поменяться пять флагов. Вместо догадок вы видите, какое изменение совпадает со всплеском и какие этому есть улики.

Проведите вскрытие

Вставьте журнал изменений и, если есть, метрику вокруг инцидента. Всё анализируется на этой странице, ничего не загружается.

Строки JSON, массив JSON или обычные строки вида: 14:02 mira turned on checkout_v2 in prod 50%

Время и значение в каждой строке, например ⁦14:03,2.9⁩. Подойдёт доля ошибок, число 5xx или задержка p95. Необязательно.

Нужно, только если метрики нет. Например 14:03 или ⁦2026-10-21 14:03⁩.

Здесь появятся выводы

Вставьте журнал изменений и нажмите «Начать вскрытие» или откройте пример, чтобы увидеть полный отчёт.

Как он решает

Оценка показывает улики, а не доказательство. Она подсказывает, куда смотреть в первую очередь.

  1. Поиск всплеска

    Каждая точка сравнивается с медианой предыдущих. Всплеск начинается, когда значение хотя бы вдвое выше обычного уровня и заметно выходит за пределы привычного шума.

  2. Время

    Выше всего оцениваются изменения, сделанные за несколько минут до всплеска. В течение следующего часа оценка снижается, а изменения намного позже начала не учитываются.

  3. До и после

    Для каждого изменения сравнивается метрика за 15 минут до и после. Резкий рост повышает оценку.

  4. Охват

    Включение флага или рост раскатки усиливает подозрение, тем сильнее, чем больше скачок. Отключение или изменение вне прода его снижает.

  5. Подтверждение

    Если после отключения флага метрика восстановилась в течение 20 минут, это самая сильная улика.

  6. Гигиена

    Отдельно он отмечает привычки, которые делают инциденты более вероятными: пропуск стейджинга, огромные скачки, частые переключения, ночные изменения и изменения без автора.

Как пользоваться

  1. Выгрузите журнал

    Скопируйте журнал аудита вашего сервиса флагов за время инцидента или запишите изменения вручную со временем.

  2. Добавьте метрику

    Выгрузите долю ошибок или задержку с дашборда в виде времени и значения. Если метрики нет, укажите начало инцидента.

  3. Прочтите вывод

    Посмотрите на главного подозреваемого, его улики и график. Метки показывают, когда именно было сделано каждое изменение.

  4. Поделитесь отчётом

    Скопируйте отчёт в канал инцидента или скачайте его в Markdown для разбора.

Полезно знать

  • Время без часового пояса читается как записано. Время с поясом переводится в UTC, поэтому держите оба ввода в одном поясе.
  • Обычный текст лучше всего понимается на английском. Поля JSON работают на любом языке.
  • Совпадение по времени ещё не причина. Деплой или всплеск трафика в тот же момент здесь не видны.
  • Ничего не покидает ваш браузер. Уберите секреты и личные данные, прежде чем делиться отчётом.

Вопросы

С какими сервисами флагов он работает?

С любым, чей журнал аудита можно скопировать. Распространённые поля вроде key, flag, environment, user, from, to и rollout распознаются автоматически.

А если метрики нет?

Укажите время начала инцидента. Тогда изменения ранжируются только по времени, охвату и среде.

Почему изменение на стейджинге получило ноль?

Изменение на стейджинге не может напрямую сломать прод, поэтому оно исключается. Но для последующих изменений в проде оно засчитывается как шаг стейджинга.

Оценка подозрения это вероятность?

Нет. Это взвешенная сумма улик с потолком 95, потому что такой инструмент никогда не может быть уверен до конца.

Связаться с автором

Есть вопрос, идея или предложение о работе? Напишите в X или Telegram.

Поддержать автора

Если инструмент сэкономил вам время, можно отправить чаевые на этот EVM адрес из своего кошелька.

0xd28Fd90eD69092bd01598f237aad33a0cc9c3EeA