Работа с ошибками Sentry

Sentry – инструмент мониторинга исключений и ошибок.

Заведение задач для ошибок из Sentry

Разбор ошибок – ежедневная активность в начале рабочего дня, необходимая для мониторинга производительности и проблем в развертываемом сервисе.

Для удобства внутри команды разработки заведены дежурства, по одному дежурному от backend и frontend команд. При смене дежурного новый дежурный пишет в канал Sentry, что он приступил к дежурству. Для удобства отслеживания новых ошибок можно использовать вкладку For review – в ней отражаются все новые ошибки, ошибки старше 7 дней автоматически удаляются из этой вкладки.

Отвечают за разбор ошибок и заведение задач в Трекере разработчики команды.

Обработка ошибок

Если исправление ошибки занимает до 15 минут

Ошибка исправляется без заведения задачи в Трекере.

Если на исправление ошибки требуется до 1 рабочего дня:

• Завести задачу с типом Ошибка в Трекере с указанием ошибки, влиянием на продукт, систему и действий по ее устранению по шаблону с указанием приоритета.

• Задачу перевести в статус “Готова к пополнению”.

• Оповестить менеджера о проблеме и ее критичности в канале стрима.

• Критичные ошибки, напрямую влияющие на пользователя или большое количество пользователей (падения приложения, блокировка ключевых функций и т.п.), заводятся со статусом Блокер и вытаскиваются на доску в статус “В работе” и эскалируются на менеджера.

Если на исправление ошибки требуется больше 1 дня (например, ошибки, которые требуют глобального рефакторинга системы):

• Завести задачу с типом Рефакторинг в Трекере с указанием ошибки, влиянием на продукт, систему и действий по ее устранению по шаблону с указанием приоритета.

• Задачу перевести в статус “Готова к пополнению”.

• Оповестить менеджера о проблеме и ее критичности в канале стрима.

• Критичные ошибки, напрямую влияющие на пользователя или большое количество пользователей (падения приложения, блокировка ключевых функций и т.п.), заводятся со статусом Блокер и вытаскиваются на доску в статус “В работе” и эскалируются на менеджера.

Если ошибку из Sentry не удается воспроизвести за час рекомендуется выполнить следующие шаги:

• Мы видим кусок кода, который падает → добавляем логирование и информацию, которая может помочь в отладке → новые события будут прилетать с информацией, помогающей отладке.

• В ситуациях, где ясна причина, например, пустые данные – можно добавить доп. проверку на пустоту объекта и посмотреть уйдет ли ошибка, а также прикинуть не является ли ошибка следствием плохого дизайна компонента, из-за чего побочный эффект ломает выполнение кода → пробуем улучшить код, сделав его более надежным с точки зрения типов, инициализации объектов и обработки сетевых запросов

Таким образом мы потратим максимум час–полтора на исследование проблемы, добавим контекст и проверим гипотезы в новом релизе. Возможно, часть ошибок разрешится.

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