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

[Sentry](https://docs.sentry.io/) – инструмент мониторинга исключений и ошибок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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