Что это
Инструмент для расследования инцидентов, вызванных флагами функций. Читает журналы изменений из LaunchDarkly, Unleash, Flagsmith, GrowthBook, вашей таблицы аудита или обычные заметки.
Расследование инцидентов с флагами функций
Flag Autopsy сопоставляет журнал изменений флагов с графиком ошибок или задержки, находит момент начала всплеска и ранжирует каждое изменение по вероятности того, что виновато именно оно. Вы получаете главного подозреваемого, время, за которое его отключили, и отчёт для разбора инцидента.
Инструмент для расследования инцидентов, вызванных флагами функций. Читает журналы изменений из LaunchDarkly, Unleash, Flagsmith, GrowthBook, вашей таблицы аудита или обычные заметки.
Для дежурных инженеров, менеджеров релизов и SRE, которым нужно быстро понять, какой переключатель вернуть, и для команд, которые потом пишут разбор инцидента.
Когда ошибки резко растут, за последний час могли поменяться пять флагов. Вместо догадок вы видите, какое изменение совпадает со всплеском и какие этому есть улики.
Вставьте журнал изменений и, если есть, метрику вокруг инцидента. Всё анализируется на этой странице, ничего не загружается.
Строки JSON, массив JSON или обычные строки вида: 14:02 mira turned on checkout_v2 in prod 50%
Время и значение в каждой строке, например 14:03,2.9. Подойдёт доля ошибок, число 5xx или задержка p95. Необязательно.
Вставьте журнал изменений и нажмите «Начать вскрытие» или откройте пример, чтобы увидеть полный отчёт.
Оценка показывает улики, а не доказательство. Она подсказывает, куда смотреть в первую очередь.
Каждая точка сравнивается с медианой предыдущих. Всплеск начинается, когда значение хотя бы вдвое выше обычного уровня и заметно выходит за пределы привычного шума.
Выше всего оцениваются изменения, сделанные за несколько минут до всплеска. В течение следующего часа оценка снижается, а изменения намного позже начала не учитываются.
Для каждого изменения сравнивается метрика за 15 минут до и после. Резкий рост повышает оценку.
Включение флага или рост раскатки усиливает подозрение, тем сильнее, чем больше скачок. Отключение или изменение вне прода его снижает.
Если после отключения флага метрика восстановилась в течение 20 минут, это самая сильная улика.
Отдельно он отмечает привычки, которые делают инциденты более вероятными: пропуск стейджинга, огромные скачки, частые переключения, ночные изменения и изменения без автора.
Скопируйте журнал аудита вашего сервиса флагов за время инцидента или запишите изменения вручную со временем.
Выгрузите долю ошибок или задержку с дашборда в виде времени и значения. Если метрики нет, укажите начало инцидента.
Посмотрите на главного подозреваемого, его улики и график. Метки показывают, когда именно было сделано каждое изменение.
Скопируйте отчёт в канал инцидента или скачайте его в Markdown для разбора.
С любым, чей журнал аудита можно скопировать. Распространённые поля вроде key, flag, environment, user, from, to и rollout распознаются автоматически.
Укажите время начала инцидента. Тогда изменения ранжируются только по времени, охвату и среде.
Изменение на стейджинге не может напрямую сломать прод, поэтому оно исключается. Но для последующих изменений в проде оно засчитывается как шаг стейджинга.
Нет. Это взвешенная сумма улик с потолком 95, потому что такой инструмент никогда не может быть уверен до конца.