Перейти к основному содержимому

Мониторинг и отчёты о сбоях

Понимать, что на самом деле происходит с приложением и сервером в production: сбои, ошибки, задержки и то, что тихо перестало работать. Альтернатива — узнавать об этом из отзыва на одну звезду.

Почему это важно. Большинство проблем в production так и не превращаются в обращение в поддержку. Пользователь пробует ещё раз, сдаётся и уходит. Без телеметрии такие отказы не видны: приложение выглядит совершенно исправным ровно до того момента, когда об обратном скажут цифры удержания.

Что нужно понимать​

  • Что нужно знать, чтобы поставить диагноз, не воспроизводя проблему
  • Какие сигналы говорят, что пользователю плохо, а какие — лишь о том, что сработала строчка в логе
  • Ради чего стоит будить человека ночью, а что достаточно вывести на дашборд
  • Отсутствие ошибок — это здоровье системы или слепота наблюдения
  • Какие персональные данные собирает ваша телеметрия — намеренно или нет

Основные темы​

Сбои и ошибки​

  • Нативные сбои и исключения Dart — и разница в том, что вы получаете на выходе
  • Символикация и деобфускация, загрузка карты символов на этапе сборки
  • Группировка, чтобы тысяча отчётов складывалась в одну проблему
  • Нефатальные ошибки — обычно именно они и есть главная беда
  • Доля сессий без сбоев (crash-free rate) как главная цифра

Контекст​

  • Что прикладывать: версию, маршрут, действие пользователя, устройство, состояние сети
  • Цепочка событий (breadcrumbs), которая привела к сбою
  • Идентификаторы пользователя, которыми может воспользоваться поддержка и которые не нарушают приватность
  • Достаточно данных, чтобы воспроизвести, но не дневник чужой сессии

Не только сбои​

  • Задержки и доля ошибок на границе API
  • Отказы, от которых приложение оправилось и о которых никому не сообщило
  • Бизнес-сигналы: регистрации, покупки, отправки — и их отсутствие
  • Структурированные логи, по которым действительно можно строить запросы

Оповещения​

  • Оповещать о симптомах, которые чувствует пользователь, а не о каждой аномалии
  • Пороги, которые учитывают нормальный разброс значений
  • Оповещения на тишину: задача перестала запускаться, метрика легла в ровную линию
  • Усталость от оповещений: то, что никто не читает, хуже, чем ничего

Реакция​

  • Триаж: насколько всё плохо, скольких затронуло, с какого момента
  • Сопоставление с релизом
  • Замыкание цикла: от инцидента к тесту или защитной проверке

Уровни​

УровеньКак это выглядит
JuniorПодключает систему сбора отчётов о сбоях и заглядывает в неё, когда попросят.
MiddleДобавляет полезный контекст и цепочки событий, сообщает о нефатальных ошибках, следит за crash-free rate вокруг релизов.
SeniorИзмеряет то, что реально испытывает пользователь, настраивает оповещения по симптомам и замыкает путь от инцидента к его предотвращению.

Практика​

Для начала​

  • Сломайте приложение намеренно Вызовите сбой в release-сборке и убедитесь, что отчёт дошёл — читаемым и с восстановленными символами.

  • Приложите контекст Добавьте текущий маршрут и последнее действие и посмотрите, насколько быстрее ставится диагноз.

  • Сообщите о проглоченной ошибке Найдите catch, который прячет сбой, и отправьте его как нефатальную ошибку.

Глубже​

  • Оповещение по симптому Настройте оповещение на то, что чувствует пользователь, и доводите его до состояния, когда ему можно доверять.

  • Оповещение на тишину Сделайте так, чтобы пропавшая метрика поднимала тревогу.

  • Понаблюдайте за релизом Сравните crash-free rate и долю ошибок с предыдущей версией, задав порог, при котором раскатка останавливается.

Проверьте себя​

  • Как вы узнаете, что приложение падает на одной-единственной модели устройства?
  • Какой у вас crash-free rate и каким он был в прошлом релизе?
  • Какие ошибки приложение проглатывает, никуда о них не сообщая?
  • Какой контекст приходит вместе со сбоем и хватает ли его для диагноза?
  • Какие из ваших оповещений команда научилась игнорировать?
  • Что подскажет, что фоновая задача перестала выполняться месяц назад?

Ресурсы​

  • Google SRE Book: Monitoring Distributed Systems — симптомы против причин и четыре золотых сигнала. Глава, после которой люди иначе выбирают, на что настраивать оповещения.
  • Error reporting in Flutter — как правильно перехватывать ошибки Dart и самого фреймворка; без этого сообщать попросту не о чем.
  • Firebase Crashlytics — самый распространённый выбор для мобильных приложений: загрузка символов, отправка нефатальных ошибок.
  • Sentry for Flutter — покрывает приложение и сервер в одном месте, с хорошей документацией по цепочкам событий и здоровью релиза.
  • Google SRE Workbook: Alerting on SLOs — как настраивать оповещения по целям, заметным пользователю, а не по сырым метрикам, вместе с математикой burn rate.