Сотни тысяч серверных ошибок и то, что из них действительно горит

Живой продовый сервер сыплет ошибками непрерывно. Большая часть повторяется, часть вообще не ваша, и в списке все они выглядят одинаково. Вопрос не "сколько было ошибок", а "что чинить сегодня".

Собирается, не трогая код заказчика

Ошибки тянутся из фида самой системы раз в пять минут, с курсором, от которого продолжают. Подключённые трекеры ошибок (Sentry, Rollbar, Bugsnag, Application Insights) опрашиваются раз в час. Агента ставить не надо, библиотеку в код добавлять не надо: собирается то, о чём система и так сообщает.

Одна подпись, одна группа

Одна и та же ошибка повторяется тысячи раз и не является тысячей бед. Каждому событию считается подпись из трёх частей (модуль, функция и нормализованное сообщение), и события с одинаковой подписью попадают в одну группу со счётчиком.

Не всякая ошибка является вашим багом

Каждая группа раскладывается на три вида: настоящая ошибка, внешняя служба (SMS, почта) и шум: боты, сканеры, проверки несуществующих адресов. Раскладка сделана явными правилами, а не догадкой, и умолчание тут "настоящая": то, что мы не опознали, не прячется.

Оценка, которая говорит, что вперёд

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

Слагаемое "рост частоты" намеренно не введено: у накопленной истории не хватает глубины, а показатель, который нельзя посчитать честно, выглядел бы как измерение.

Письмо о новой и отдельное письмо о вернувшейся

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

Текст ошибки и в письме, и на экране проходит маскирование идентификаторов. В сообщении об ошибке лежит то, что ввёл пользователь (номер удостоверения в параметре, телефон из формы), а ушедшее письмо уже не отозвать.

Откуда в коде это пришло

Из стека вызовов достаётся имя класса, в котором ошибка упала. Работает это не всегда: стек приходит не с каждой ошибкой, и в нём не всегда есть наш собственный кадр.

Области, чтобы спросить "что у нас сломано в платежах"

Группам можно проставить метку области (платежи, регистрация, админка), и тогда вопрос перестаёт быть "какая ошибка чаще всех" и становится "что не в порядке вот в этой части системы". Сейчас заведено 8 таких меток.

Первый прогон не заваливает письмами обо всём, что было

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

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

Отсюда открывается задача

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

И честно: на живом проекте такая задача заведена одна, а решение записано у нуля групп из 902. Механизм есть, материала в нём пока нет.

Что видит заказчик

Не список ошибок. Экраны ошибок принадлежат исполнителю. Заказчик видит плитку здоровья системы: всё в порядке или сколько мест сейчас с ошибками, и когда была последняя проверка. Под ней короткий список инцидентов месяца: какая область, когда началось, когда закончилось. Без стека вызовов, без серьёзности и без технических имён. Остальное доходит до него тем, что стало задачей или отчётом.

Частые вопросы