Список ошибок говорит, что сломалось. Страница инцидента отвечает, почему: собирает улики по всем срабатываниям инцидента и делает из них диагноз — вывод о причине, у которого каждое утверждение подкреплено числом, и это число можно проверить.

Всё на этой странице считается, а не угадывается: никакой языковой модели, одни и те же данные всегда дают один и тот же диагноз. ИИ-агент Расследование — отдельный инструмент, и его выводы диагноз не меняют (см. Диагноз и Расследование).

Группа, а не событие

Улики собираются по срабатываниям инцидента за 30 дней до его последнего появления, а не по одному событию. Отдельное событие на обзоре — только пример, и выбирается он как типичное, а не как последнее (см. Пример).

Поэтому «94 % ошибок в Safari 17» — это утверждение про группу. Само по себе оно ничего не значит, пока не сравнено с нормой: если Safari 17 и так у 90 % ваших пользователей, это не улика. Сравнение с нормой и есть контраст.

Улики

Шаги до ошибки

Карточка Шаги до ошибки показывает, что пользователь делал перед ошибкой. Buglapse берёт хлебные крошки 200 последних срабатываний и ищет сценарий — цепочку шагов, которая есть у заметной доли срабатываний в этом порядке. Не обязательно подряд: всё, чем срабатывания различаются, просто выпадает. Сценарий никогда не склеивается из разных сессий: у каждого есть срабатывания, которые прошли ровно так, и одно из них можно открыть кнопкой Открыть пример.

Шаг — это крошка, очищенная от подробностей конкретного случая:

Крошка	Шаг
запрос POST /api/orders/1842 с ответом 500	POST /api/orders/<int> → 500
переход на /checkout?step=2	→ /checkout
клик по кнопке «Оплатить»	click on button "Pay"
пять одинаковых запросов за 2 секунды	request loop: GET /api/cart

Шаги бывают двух видов:

• Действия — то, что делает человек: клики, ввод, переходы, перезагрузка страницы, «яростные» клики.
• Реакции — то, что система делает в ответ: запросы, сообщения в консоли. Они показаны с отступом между действиями.

Сценарий растёт от ошибки назад. Первый шаг должен быть у 20 % срабатываний с крошками, каждый следующий — у 80 % тех, кто прошёл уже найденные шаги, и у каждого шага не меньше 3 срабатываний, чтобы совпадение на горстке событий не выдавалось за закономерность. В сценарии до 8 действий, между ними — реакции, которые есть у 60 % прошедших. Срабатывания, которые в сценарий не попали, дают следующий — Другой путь, всего до трёх.

«Устойчивого сценария нет» — тоже вывод, а не отсутствие данных: у срабатываний нет общих шагов перед ошибкой, значит, ошибка не зависит от того, что делал пользователь. Его карточка показывает, когда срабатываний с крошками набралось хотя бы 10.

Если у проекта есть трейсы, под шагами видно, какие ещё спаны падают в большинстве трейсов с этой ошибкой.

Контраст: чем отличаются эти случаи

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

94 % сессий с этой ошибкой — Safari 17, при 8 % всех сессий · в 180× чаще (не меньше 95×)

С чем сравнивается

Норма зависит от того, к чему привязаны срабатывания. Под заголовком карточки написано, какая выбрана:

Норма	Когда	Что сравнивается
Сессии	хотя бы половина срабатываний принадлежит сессии, которую прислал SDK	сессии с этой ошибкой против всех сессий проекта
Запросы	иначе, если хотя бы половина попала в трейсы проекта	запросы с ошибкой против всех запросов (трейс, у которого нет сессии, сам считается сессией)
Ошибки	во всех остальных случаях	срабатывания этого инцидента против остальных ошибок проекта за то же время

Сессии — лучшая норма: она говорит, сколько у вас пользователей в Safari 17, а не сколько у вас ошибок в Safari 17. Ошибка бэкенда тоже считается в сессии пользователя, если браузер передал бэкенду трейс (traceparent, см. Распределённый трейсинг): тогда и серверный инцидент сравнивается с сессиями, причём в том проекте организации, откуда пришло большинство этих сессий.

Норма читается как воспроизводимая выборка — около 20 000 сессий или запросов за то же время, что и срабатывания, одни и те же при каждом расчёте. Сравниваются:

• браузер с мажорной версией (Safari 17), ОС с версией, тип устройства;
• страница: для сессии — страница входа, для запроса или ошибки — страница, на которой всё случилось (с параметризованным путём: /orders/<int>);
• маршрут (тег route), релиз и окружение.

Норма, у которой ничего, кроме релиза и окружения, не записано (данные из времени до того, как Buglapse стал их описывать), пропускается в пользу следующей — так что «ни один атрибут не отличает» всегда значит, что сравнение было.

Как читать фактор

Для каждого значения считается относительный риск: во сколько раз ошибка вероятнее с этим значением, чем без него.

• 94 % — доля случаев с этим значением (покрытие).
• при 8 % — доля нормы с тем же значением (база).
• в 180× чаще — относительный риск.
• не меньше 95× — нижняя граница его 95-процентного доверительного интервала. Это главное число: на малом числе случаев риск может выглядеть огромным случайно, а нижняя граница честно говорит, сколько из него точно не случайность.

Когда в одной из клеток пусто — например, все случаи в Safari 17 или в норме нет ни одной такой сессии, — риск сверху не ограничен, и карточка говорит только «не меньше чем в N× чаще».

Значение становится фактором, только если у него не меньше 5 случаев, оно покрывает хотя бы 20 % из них и нижняя граница риска — от 1,5×. Пары значений из разных атрибутов («Safari 17 и /checkout») проверяются тоже, но принимаются, только если пара заметно сильнее каждого значения по отдельности.

Минимальный набор факторов

Карточка показывает не все сильные значения, а минимальный набор, до трёх: сначала сильнейший фактор, потом сильнейший среди случаев, которые первый не объясняет, и так далее. У каждого написано, какую долю случаев он объясняет. Поэтому атрибут, который просто ходит вместе с первым (Safari почти всегда на macOS), второй строкой не появится.

Вердикты

• Факторы — список выше.
• Ни один атрибут не отличает эти случаи от нормы: ошибка не зависит от окружения. Это вывод: ошибка одинаково случается везде, искать причину в браузере или странице бессмысленно.
• Мало данных — меньше 10 случаев, контраст не считается.

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

Как сделать контраст точнее

• Оставьте включённой интеграцию сессий (она включена по умолчанию) — без неё нормой будут другие ошибки, а не пользователи.
• Передавайте трейс с фронтенда на бэкенд (traceparent) — серверные ошибки получат сессии пользователей.
• На сервере включите трейсинг — запросы станут нормой для ошибок без сессии.

Что изменилось

Если инцидент появился или вернулся в релизе, а у организации есть ссылки на код и подключённый репозиторий, карточка Что изменилось называет коммиты релиза, которые меняли строки или файлы стека, — или говорит, что релиз стек не трогал и его код вряд ли причина. Как они ищутся — в разделе Что изменилось.

Пример

Карточка Пример показывает одно срабатывание целиком — стектрейс, хлебные крошки, трейс и запись сессии. Это не последнее событие, а типичное: одно из тех, что прошли первый сценарий шагов до ошибки ровно так; из них — то, у которого есть запись сессии, потом трейс, потом больше всего крошек. Крошки, которые и есть шаги сценария, подсвечены. Если сценария нет, пример — срабатывание с записью сессии, трейсом или самым длинным следом крошек среди 1000 последних.

Переключатель в карточке показывает и другие: Последнее и Первое (самое раннее из тех, что ещё хранятся).

Похоже на дубликат

Если группировка разделила, вероятно, одну ошибку — стеки почти совпадают, сообщения похожи, — на обзоре появляется карточка Похоже на дубликат с кнопкой сравнения бок о бок, где выделены кадры, из-за которых инциденты разошлись, и кнопкой объединения. Нужна функция своей группировки в тарифе, как и для объединения.

Диагноз

Карточка Диагноз стоит в начале обзора. Это вывод из улик выше: какого типа причина, на чём она основана, насколько уверенно и чего не хватило. Он пересчитывается в фоне — когда инцидент появляется, объединяется или разъединяется, когда находятся подозрительные коммиты, когда число срабатываний удваивается и при регрессии, — поэтому у только что появившегося инцидента карточка сначала пишет, что диагноз считается.

Типы выводов

Диагноз состоит из одного или нескольких выводов, сильнейший первым; они могут сочетаться: «пришла с релизом 2.4.0; возникает только при Safari 17».

Вывод	Что значит	На чём основан
Регрессия релиза	«Пришла с релизом 2.4.0: 3,1 % сессий против 0 % в 2.3.9» или «участилась с релизом…»	Частота ошибки в каждом из 10 последних релизов против ближайшего предыдущего, где есть данные (пустой хотфикс перешагивается). Частота — на сессию, если релиз прислал сессии, иначе на ошибку. Если Что изменилось нашло коммит, он назван
Окружение	«Возникает только при Safari 17: 94 % случаев против 8 % всех сессий»	Факторы контраста, которые вместе объясняют хотя бы половину случаев
Данные	«Сосредоточена на 1842: 87 % случаев Order <int> not found из 40 разных значений»	Переменные части сообщения ошибки (числа, id, email…) самого частого шаблона: до трёх значений одного параметра держат половину случаев, у параметра хотя бы 5 разных значений, и случаи пришли хотя бы от 3 разных пользователей, сессий или запросов — один застрявший пользователь фактором данных не считается. Email и IP не показываются, только факт и ссылка на пример
Путь пользователя	«62 % случаев проходят эти шаги перед ошибкой»	Самый частый сценарий шагов до ошибки с действием, если его проходит хотя бы половина срабатываний с крошками. С обычными сессиями он пока не сравнивается, поэтому уверенность здесь никогда не бывает высокой
Не установлено	«Ни один фактор не прошёл порог»	Честный ответ: по имеющимся данным причину назвать нельзя, а список Не хватило говорит, каких данных для этого нет

Пороги у всех выводов те же, что у контраста: относительный риск с нижней границей доверительного интервала от 1,5×. При меньше чем 10 случаях диагноз ничего не утверждает.

Под выводами — Триггер: последнее действие самого частого сценария, после которого случается ошибка.

Уверенность

Уверенность — высокая, средняя или низкая — считается, а не оценивается на глаз, и рядом перечислено, из чего она сложилась:

• сильный главный вывод (нижняя граница риска от 3×; у окружения первый фактор ещё и покрывает 80 % случаев) — два балла, иначе один;
• коммит релиза менял падающий код — плюс балл;
• ещё один независимый вывод согласуется — плюс балл;
• релиз не трогал стек — минус балл.

Три балла и больше — высокая, два — средняя. При меньше чем 30 случаях, или когда главный вывод — путь пользователя, уверенность не выше средней.

Не хватило

Список Не хватило называет данные, которые сделали бы диагноз точнее, — это прямые подсказки, что настроить:

Пункт	Что сделать
у случаев нет релиза	Передайте release в SDK — см. Релизы
нет предыдущего релиза для сравнения	Появится со следующим релизом
у предыдущего релиза нет сессий или ошибок для сравнения	Включите сессии
в плане нет ссылок на код / репозиторий не подключён	Ссылки на код
ни один коммит релиза не менял строки стека	Ничего: это само по себе улика против кода релиза
случаи не связаны с сессиями или запросами	Сессии в браузере, traceparent на бэкенд, трейсинг на сервере — см. выше
нет breadcrumbs: шаги до ошибки неизвестны	Не отключайте хлебные крошки
шаги не сравнивались с обычными сессиями	Ничего: так пока устроен вывод о пути пользователя

При регрессии

Когда решённый инцидент возвращается, текущий диагноз сохраняется, и после пересчёта карточка показывает рядом До регрессии — тип прежнего вывода. Если раньше была регрессия релиза 2.4.0, а теперь окружение Safari 18, исправление, скорее всего, было правильным, а вернулось что-то другое.

Где ещё виден диагноз

• Экспорт инцидента (Markdown и JSON, на английском) — разделы «Diagnosis», «Steps to the error» и «Contrast».
• MCP: get-issue возвращает диагноз структурой и одной строкой.
• Автоисправление и Расследование получают его как факты для проверки, а промпт Исправить локально — как раздел «Computed evidence».

Диагноз и Расследование

На странице инцидента может быть две карточки с выводами о причине, и это разные вещи:

	Диагноз	Расследование агента
Кто делает	Buglapse, по правилам	ИИ-агент, по запуску Расследования
Из чего	Все срабатывания инцидента	Пример, стек, код репозитория, данные проекта по запросу агента
Что говорит	Тип причины, условия, коммит, уверенность — каждое число можно пересчитать	Где именно ломается в коде и почему — гипотеза агента
Нужен ли тариф	Во всех тарифах	Функция Расследование и ИИ-провайдер

Агент получает диагноз на вход как факты, которые стоит проверить, но его ответ диагноз не меняет: вычисленный вывод остаётся тем же, пока не поменяются данные.