🎯 Зачем спрашивают
- Проверить, понимает ли кандидат разницу между разработкой кода и эксплуатацией продукта (DevOps-культура, поддержка в проде).
- Узнать, знает ли он, что ошибки нужно фиксировать и анализировать системно, а не «ловить в консоли руками».
- Оценить зрелость кандидата: думает ли он только о фичах или учитывает качество и надежность продукта.
- Проверить знакомство с инструментами индустрии (Sentry, Bugsnag, Rollbar, Jira/YouTrack).
- Посмотреть, как кандидат приоритизирует баги: по числу пользователей, по бизнес-ценности, по критичности.
📝 Ответ
Error tracker — это инструмент для сбора, группировки, визуализации runtime-ошибок в вашем приложении. Может уведомлять о проблемах в реальном времени и предоставляет доп. информацию: stack trace, окружение.
Как правило состоит из двух частей:
- отдельное приложение админка, где вы можете видеть и анализировать ошибки
- SDK, подключаемое в ваш проект для сбора ошибок
Данные инструменты позволяют собирать подробную статистику об ошибках. Пример:
- частотность (кол-во событий)
- охват (кол-во уникальных пользователей с данной ошибкой)
- мета-информация (информация об устройстве пользователя, ОС)
Если информации в событиях недостаточно, то инструмент позволяет насыщать события любой кастомной информацией: userId, userEmail или любой другой проектно специфичной информацией.
Это позволит вам фильтровать issues, чтобы проще было идентифицировать и локализовать проблему.
На слуху следующие популярные решения:
- Sentry
- BugSnag
- Rollbar
⚖️ Компромиссы
✅ Плюсы | ❌ Минусы |
Быстрое выявление и локализация багов. | Шум (слишком много событий без нормальной фильтрации). |
Снижение MTTR (mean time to recovery). | Не всегда ловят бизнес-ошибки (например, неправильные данные, а не выброс ). |
ㅤ | Цена (SaaS-инструменты дорогие при большом трафике), но некоторые сервисы предоставляю self-hosted решение |
🔎 Встречные вопросы
- Чем отличается bug tracker от error tracker?
- Как интегрировать баг-трекер в CI/CD-процесс?
- Как бороться с «alert fatigue» (шумом от алертов)?
- Как вы приоритизируете ошибки (по числу пользователей или по бизнес-ценности)?
- Как считаете критичность? Какие показатели учитываете?
🚩 Красные флаги
- Bug tracker нужен просто, чтобы видеть ошибки в консоли.
- Это для того, чтобы фронтендер не писал
try/catch.
- Игнор метрик типа охвата и влияния на пользователей.