Как был построен процесс контроля в Sentry
Что проверяют
Это вопрос про опыт: был ли у вас налаженный процесс работы с ошибками прода, или Sentry просто был подключён и туда никто не смотрел. Следом спрашивают, кто разбирал ошибки, как боролись с шумом и что происходило после алерта.
Как отвечать
Расскажите процесс по звеньям, на своём проекте и со своими цифрами:
- подключение:
@sentry/reactили@sentry/nextjs,Sentry.initсdsn,environmentиrelease. Безreleaseне работают регрессии и привязка ошибок к версии; - source maps: загружаются в CI через
sentry-cliили плагин сборщика (@sentry/vite-plugin,@sentry/webpack-plugin) и не выкладываются публично. Без них стек из минифицированного бандла не прочитать; - контекст:
Sentry.ErrorBoundaryдля падений рендера,setUserс id без персональных данных, теги (фича, тариф), breadcrumbs; - шум:
ignoreErrors,denyUrlsдля расширений браузера,beforeSendдля фильтрации и вычистки данных, свой fingerprint там, где одна ошибка дробится на десятки issue; - производительность: трассировка с
tracesSampleRateменьше единицы, Web Vitals, Session Replay с маскированием текста и полей; - реакция: алерты на новые issue и всплески в канал команды, правила владения по путям кода, дежурный на неделю, статусы «resolved in next release» и «archived» вместо вечного «unresolved».
Если процесс строили не вы, так и скажите и опишите свою часть: разбирали ли issue, настраивали ли фильтры, чинили ли по записям Replay. Если Sentry у вас не было, расскажите, как ловили ошибки иначе и что настроили бы первым.
Где спотыкаются
Не упоминают source maps. Без них разбор сводится к гаданию по a.b is not a function в первой строке бандла.
Жалуются на Script error. и не знают причину: скрипт с другого домена подключён без атрибута crossorigin и CORS-заголовков, поэтому браузер скрывает детали ошибки.
Приводят круглые проценты вроде «сбоев стало на 30% меньше», а на вопрос, как считали, ответить не могут. Лучше назвать метрику, которую реально смотрели, например crash-free sessions в Release Health.