Как следить за состоянием мобильного приложения?

Знакома ли вам ситуация, когда вы спокойно работаете, а клиентская служба передаёт вам странный репорт: несколько пользователей жалуются, что в приложении не грузятся картинки, но у вас всё работает. Или пользователь пишет в Google Play, что приложение занимает несколько гигабайт, и вы не понимаете, сколько таких пользователей и что с этим делать. Нужно ли срочно бросаться чинить, или это может подождать следующего планового релиза?

Согласитесь, было бы здорово узнавать о проблемах раньше, чем пользователи начнут жаловаться в поддержку. Сегодня я расскажу, как мы в Циан создавали Техническую Мобильную Аналитику (ТьМА) и получили возможность в любой момент времени ответить на вопрос: «Всё ли в порядке с приложением?»

---

Оглавление

1. Какую проблему решаем

2. Понятия технических метрик

3. Технический инструментарий
   3.1 Устройство кластера телеметрии в Циан
   3.2 Реализация телеметрии в мобильных приложениях
   3.3 Создание метрики
   — Что мерить?
   — Сбор данных
   — Построение графиков
   — Настройка алертов
   — Расследование проблем

4. Вывод

Какую проблему решаем

Меня зовут Денис Конопелькин, и я работаю в команде Платформы в Android-гильдии Циан. Последние пару лет я занимаюсь развитием системы мониторинга надежности нашего Android-приложения. 

В процессе работы мы не раз сталкивались с ситуациями, когда стандартные инструменты для отслеживания ошибок и производительности, такие как Crashlytics и Tracer, не давали достаточной информации. Так возникла необходимость создать собственную систему мониторинга, которая могла бы не только собирать и анализировать данные о работе приложения, но и своевременно уведомлять разработчиков о возникающих проблемах для оперативной реакции. 

Наше приложение постоянно расширяется: добавляются новые компоненты, а существующие становятся более сложными и охватывают всё больше бизнес-сценариев. С увеличением сложности возрастает вероятность возникновения ошибок.

Мы предпринимаем меры по снижению этой вероятности, включая написание Unit-тестов и UI-тестов. Наши разработчики и QA-специалисты тщательно проверяют новую функциональность. Однако, несмотря на все эти меры, ошибки всё же могут попасть в продакшн. И это абсолютно нормально. Ненормально, когда о серьезной проблеме мы впервые узнаем из жалоб пользователей. Чтобы реагировать на проблемы в продакшене быстрее, чем пользователи заметят проблему, мы внедряем SLO для компонентов.

Понятия технических метрик

Если вы когда-либо интересовались мониторингом работоспособности информационных систем, то, вероятно, слышали о таких понятиях, как SLO, SLI и SLA. Рассмотрим их подробнее и объясним, как мы в Циан интерпретируем эти термины.

Service Level Indicator (SLI) — количественная оценка работы сервиса, обычно связанная с удовлетворенностью бизнеса надёжностью, отзывчивостью и производительностью приложения или сервиса за определенный период времени (месяц, квартал, год). Примеры SLI:

• время загрузки экрана в миллисекундах;

• количество ошибок;

• значение CrashFree Users в %, знакомое мобильным разработчикам по Firebase.

Иными словами, SLI — это индикатор, представляющий конкретное значение в определенных единицах измерения.

Service Level Objective (SLO) — целевое значение нашего SLI, к которому мы стремимся. Например, у нас есть внутренняя договоренность, согласно которой CrashFree Users для приложения должен быть больше 99,9%. Если новая версия приложения не соответствует этому порогу, мы не будем выпускать её на всех пользователей до устранения проблем, приводящих к сбоям.

Service level agreement (SLA) – публичное соглашение с нашими внутренними и внешними пользователями о последствиях несоблюдения SLO. Гипотетический пример: рост средней задержки выполнения поискового запроса в прайм-тайм до 500 мс влечёт за собой уплату штрафа всем партнерам, которым предоставляется сервис. Отмечу, что рассмотрение SLA выходит за рамки данной статьи, просто знайте, что такое существует.

Простая аналогия из жизни: показания скорости на спидометре автомобиля — это SLI. Максимально разрешенная ПДД скорость — SLO. Штраф за превышение скорости — SLA.

Более подробно о терминологии SLI и SLO можно прочитать в статье «Цели уровня обслуживания — опыт Google» Антона Касимова (для доступа из РФ потребуется VPN).

Алерт — уведомление о проблеме. В зависимости от важности компонента уведомления могут быть разными: от самых ненавязчивых — письма на корпоративную почту, до самых экстренных — звонков на мобильный телефон ответственного. Важно не то, куда может прийти сообщение, а то, что мы знаем, что оно придет, и разработчик его увидит. Обычно для этого используется соответствующий канал в корпоративном мессенджере.

Метрика — совокупность одного или нескольких SLO, отображенных на графике или графиках, позволяющая утверждать, что компонент работает корректно. Желательно, чтобы у метрики также был настроен алерт.

Подобные технические метрики можно сравнить с автоматизированными end-to-end тестами, только их выполняют пользователи, а вы снимаете показатели и настраиваете алерты.  Необходимо стремиться к тому, чтобы мониторить минимальное количество событий, но достаточное для утверждения, что «проверяемый сценарий работает». Иными словами, метрика не должна отвечать на вопрос «В какой части компонента возникла проблема?», но должна сигнализировать, если компонент перестал работать должным образом.

Чтобы проиллюстрировать эту идею, рассмотрим гипотетический пример функционального компонента, отвечающего за пополнение пользователем баланса. Поскольку статья ориентирована на мобильных разработчиков, я намеренно беру пример с бэкенда, чтобы скрыть понимание работы компонента. Вероятно, этот компонент обращается к внешнему API провайдера платежного шлюза, и можно настроить алерты на количество запросов к этому шлюзу и на коды ответов, которые он возвращает. Также под капотом компонента может быть очередь, которая по cron’у или по более сложной логике обрабатывает зачисление средств, поэтому можно дополнительно настроить алерты на количество ошибок в cron’е, а еще, вероятно, стоит мониторить размер очереди… и всё равно легко упустить какой-нибудь важный сценарий.

Я рекомендую, насколько это возможно, абстрагироваться от деталей реализации компонента и смотреть на него как на чёрный ящик.

Давайте подумаем, что делает компонент с точки зрения бизнеса. У нас есть операция пополнения баланса, которая началась в определённое время и завершилась в другое с одним из двух возможных результатов: либо изменением баланса пользователя, либо ошибкой. Именно на результат и нужно ориентироваться, забыв про очереди, шлюзы и прочую внутреннюю логику. Не страшно, если по алерту SLO метрики сразу не будет понятно, что конкретно сломалось — для этого есть другие инструменты (о них в самом конце). Лучше получить алерт вида «где-то в компоненте что-то не работает» и начать разбираться, где именно проблема, чем настроить алерты на тысячу мелких сценариев и упустить тысяча первый.

Формирование корректного SLO и построение метрик для компонентов мобильного приложения — задача не всегда простая. Здесь важна практика. Далее я приведу пример метрики, которая соответствует нашим критериям качества, и опишу сами критерии. Но сначала давайте рассмотрим инструменты, которые помогут нам достичь этой цели.

Технический инструментарий

Устройство кластера телеметрии в Циан

Под кластером телеметрии мы понимаем связку из следующих приложений: Graphite, StatsD и Grafana.

Graphite — кластер серверов баз данных для телеметрии. В Graphite телеметрия представлена в виде наборов { «ключ», «значение», «дата и время» }. Точный способ хранения данных в Graphite не столь важен; главное — на основе этих данных можно построить график, где по оси X будет отложено время, а по оси Y — значение метрики.

Grafana — это web-UI приложение, которое предоставляет возможность строить графики из различных источников данных, таких как логи микросервисов, телеметрия из приложений, метрики из инфраструктуры и т.д. В Grafana можно легко создавать графики на основе данных и настраивать на них алерты. Более подробно об этом инструменте можно прочитать в документации.

Главное преимущество связки Grafana + Graphite + StatsD заключается в возможности отображения метрик на графиках с применением различных функций их объединения.

Kafka — система обмена сообщениями между различными приложениями. В нашем случае она используется как временное хранилище для событий телеметрии для проведения расследований. Аналитические события, которые отправляет мобильное приложение, сохраняются в Graphite для последующей работы через Grafana в сильно урезанном виде. Поэтому в Grafana мы не можем получить дополнительную информацию, которая также может быть полезна. Данные в сыром виде, как они поступили на бэкенд, сохраняются в Kafka для дальнейшей работы с ними.

Теперь, когда кластер телеметрии понятен, давайте посмотрим, что происходит на стороне клиента.

Реализация телеметрии в мобильных приложениях

За процесс формирования метрик и их целевых значений (SLI и SLO) по компонентам, а также за реагирование на алерты, у нас отвечают тимлиды продуктовых команд. Для взаимодействия мобильных разработчиков с кластером телеметрии мы разработали специальную библиотеку.

Под капотом это довольно сложный инструментарий, который собирает данные как с iOS, так и с Android, и поддерживает Kotlin Multiplatform. Нюансы работы этой библиотеки заслуживают отдельной статьи. Однако в общих чертах она реализует следующие функциональные требования:

• Отправка событий различных типов: разработчики могут отправлять события для реализации метрик заранее определенных типов: размер, время ответа ручки (Response Time), время от момента открытия экрана до возможности с ним взаимодействовать (Time To Interactive), количество действий, ошибки и некоторые другие.

• Регулярная синхронизация данных: библиотека регулярно синхронизирует метрики с бэкендом и гарантирует, что данные будут доставлены.

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

• Агрегация данных на клиенте: если мы многократно логируем событие одного и того же действия с одинаковыми параметрами, такие события будут суммироваться на клиенте, и на бэкенд передадим одно событие с количеством повторов.

На этом закончим разбор инструментария. В конце статьи я оставлю опрос — если будет интерес, смогу рассказать больше о внутреннем устройстве серверной и клиентской частей. А сейчас переходим к самому интересному — созданию метрики. Условно разделим этот процесс на три этапа: сбор данных, построение графиков и настройка алертов.

Создание метрики

Прежде чем переходить непосредственно к созданию метрики, давайте определим, что мы хотим получить в результате, и установим критерии качества для нашей метрики. Помимо того, что её SLO должен отвечать на вопрос «проверяемый сценарий работает?», мы выделили несколько обязательных критериев, без которых метрика, вероятно, не будет приносить пользу:

• Метрика должна быть легко читаемой. Простой пример, который приводил Сергей Боиштян @willykolepniyв докладе «Здоровье вашей Gradle-сборки»: градусник — это одна шкала, один показатель и простое условие: если температура >37, значит, есть проблема. Чем проще метрика, тем легче понять, соблюдаете ли вы SLO или нет.

• Алерты должны быть стабильными. Здесь всё как в сказке про мальчика, который кричал «Волки!». Если ваши алерты будут срабатывать, когда проблемы нет, то в случае настоящей проблемы на неё никто не обратит внимания.

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

Что мерить?

Чтобы понимать, насколько хорошо работает загрузка изображений, у нас реализованы три ключевые метрики:

1. Величина потока — или трафик. В нашем случае трафик определяется количеством событий о том, что изображение успешно загружено.

2. Скорость потока — время загрузки изображений.

3. Качество потока — процент успешно завершённых загрузок по отношению к общему количеству загружаемых изображений.

В рамках статьи предлагаю сфокусироваться на последней метрике, так как процент успешных действий, или Success Rate, — это типовая метрика, которая может быть полезна практически для любого программного компонента.

Давайте опишем SLO и SLI для нашей метрики. Для качества потока SLI будет определяться как процент успешной загрузки изображений за 15 минут.

Мы договорились с бизнесом о целевом показателе доступности на уровне 98%. Это означает, что если на каждые 100 начатых загрузок не загружаются 2 изображения, это допустимый процент ошибок. Здесь важно отметить, что мы стремимся обеспечить достаточный уровень доступности, не пытаясь снизить количество ошибок ниже этого порога. Достижение ещё меньшего числа ошибок, например, 1 на 100 загрузок, потребовало бы неоправданно больших ресурсов. Поэтому наш SLO формулируется так: «98% изображений у пользователей за 15 минут загружаются успешно».

Отлично! Мы определили, какой результат хотим видеть. Теперь давайте отправим данные для этой метрики!

Сбор данных

Чтобы вычислить Success Rate, целевое действие можно представить как процесс, который начинается в определенный момент времени и завершается в другой момент. При этом результат может быть как успешным, так и завершиться ошибкой.

Загрузка изображений идеально подходит под этот сценарий. В данном случае нас не интересует длительность загрузки — важны только факт её начала и результат.

Для примера выше мы будем отправлять три события в формате {Key : Value}:

• ImageLoadingStartedEvent : 3

• ImageLoadingFailedEvent : 1

• ImageLoadingCompletedEvent : 2

Внимательные читатели могут заметить, что одно из этих событий — лишнее, ведь количество начатых загрузок можно выразить как сумму успешных и неудачных завершений. С арифметической точки зрения это верно. Однако, поскольку данные отправляются с клиента не единым запросом, а порциями, и затем проходят обработку в StatsD, точность может снижаться. Поэтому честнее фиксировать начало загрузки на клиенте и отправлять её отдельно. В этом контексте лучше отправлять событие начала действия (ImageLoadingStartedEvent) и событие успешного завершения (ImageLoadingCompletedEvent). На основе этих двух событий мы можем рассчитать Success Rate следующим образом:

События ImageLoadingFailedEvent, уведомляющие об ошибке, действительно не участвуют в вычислении SLI, но они важны для дальнейшего расследования проблем.

Данные отправлены, теперь давайте перейдем к построению графиков.

Построение графиков

Для начала откроем Grafana Dashboard, нажмём Add Panel и выберем пункт меню Add New Panel.

Перед нами откроется панель построения графика. Пока на графике нет данных, чтобы их добавить, убедимся, что источником данных выбран Graphite, и нажмём на кнопку + Query.

Указываем путь в Graphite до события ImageLoadingStartedEvent и видим, что значения начинают отображаться.

В терминах Graphite, мы создали серию (Series). Свежесозданная серия имеет имя A. При желании его можно изменить, но для простоты оставим как есть. Теперь давайте познакомимся с функциями Graphite.

Во-первых, зададим имя нашему графику. Назовём его «Loading Started». Для этого используем функцию Alias. Нажимаем на + в разделе Functions, выбираем Alias и указываем имя.

Теперь в легенде графика изменилось название.

Во-вторых, для сглаживания графика, чтобы он меньше напоминал кардиограмму, применим функцию summarize. Эта функция принимает первым параметром временной интервал, за который значения будут агрегироваться, а вторым — функцию агрегации. В нашем случае наиболее подходящей функцией агрегации будет sum. При выборе интервала нужно помнить, что чем больший интервал вы выберете, тем более сглаженный будет график, но при этом снизится точность. Давайте выберем 5 минут.

Теперь представление графика изменилось.

Посмотрим на схему того, что произошло с данными. Значения были разбиты на группы по 5 минут и просуммированы. Обратите внимание, что масштаб по оси Y также изменился.

Это лишь малая часть возможностей, которые предоставляют функции Graphite, но пока нам этого достаточно. Аналогичным образом создадим второй график — количество успешно завершённых событий. Для этого нажимаем на кнопку копирования.

Видим, что появилась новая series B.

Заменяем в поле редактирования ImageLoadingStartedEvent на ImageLoadingCompletedEvent и строку «Loading Started» на «Loading Completed», после чего нажимаем на иконку карандаша, чтобы выйти из режима редактирования текста в конструктор. В итоге у нас получается вот такая серия B.

На графике отобразится вторая линия.

Теперь можно представить одну серию как процент от другой. Для этого создаём новую серию C и используем функцию asPercent. Нажимаем + Query и на карандаш появившейся серии.

В поле копируем следующую функцию:

Graphite нарисует для нас заветную линию Success Rate в процентах, но в текущем масштабе её может быть не видно.

Чтобы увидеть Success Rate, можем отключить отображение для Series A и B.

Теперь мы видим нужный Success Rate.

Наш первый SLI готов. Он показывает, какой процент изображений загружался у пользователей в каждом из 5-минутных интервалов. Давайте дадим имя графику. На панели справа есть пункт Panel Options → Title. Назовём график и сохраним изменения.

Но помните пример с градусником — метрика должна легко читаться.

Скопируем получившийся график. Для этого вернёмся на дашборд и в выпадающем меню выберем пункт Duplicate. После чего откроем новый график в режиме редактирования.

Для нового графика выберем тип диаграммы Gauge.

Перейдём в меню Value Options и попросим Grafana выводить последнее значение из Query с Alias = Success Rate.

Скрытый текст

Также выставим значения:

• Standard options → Min = 0

• Standard options → Max = 100

Добавим threshold, чтобы при значении <98% визуализация становилась красной.

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

Вы можете настроить внешний вид по своему усмотрению. Мои графики стали выглядеть следующим образом:

• Первый позволяет увидеть значение метрики «в моменте».

• Второй показывает, как менялось значение в динамике.

Поздравляю вас — графики построены! Теперь осталось настроить алерты!

Настройка алертов

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

• если алерт срабатывает, но проблемы нет, необходимо изменить условия срабатывания алерта;

• если проблема есть, но алерт не сработал, также нужно скорректировать условия алерта;

• если проблема есть, алерт сработал, но её не нужно срочно решать, значит, это не проблема уровня алерта, и такой алерт следует удалить.

Для начала давайте рассмотрим параметры, которые есть у алерта. Переходим на вкладку Alert нашего графика, и первое, что мы видим — это имя и период проверки. Зачем это нужно?

Представим, что у нас есть график, который показывает одну линию. Если значение 2 и выше — всё хорошо, если падает ниже — есть проблема. Однако мы знаем, что у метрики могут быть кратковременные просадки, и не хотим, чтобы алерт срабатывал в таких случаях.

Параметр Evaluate Every определяет, как часто будет проверяться условие. В нашем случае — раз в минуту. Но есть ещё один параметр For, который указывает, в течение какого времени значение может быть «плохим», и это будет считаться допустимой просадкой. В нашем примере алерт сработает только если 5 минут подряд график будет ниже заданного значения.

Эта логика подразумевает, что у алерта есть статус. Для наглядности его можно представить цветами светофора: зелёный — всё работает хорошо, жёлтый — вероятно, есть проблема, но это может быть временная просадка, красный — всё плохо, пора бить тревогу! Подобные переходы статусов Grafana отображает вертикальными линиями, называемыми OK, PENDING и FIRING соответственно.

Конечно, важно соблюсти баланс. Если установить значение For слишком малым, алерт будет срабатывать на каждую просадку и «флудить» уведомлениями. Если же установить For слишком большим, вы узнаете о проблеме позже, чем хотелось бы.

Теперь рассмотрим другую ситуацию:

По графику видно, что он почти всегда ниже нормального значения, но у него стабильно случаются «вылеты в норму». Из-за этого алерт почти всегда находится в статусе PENDING, но из-за достаточно большого значения For он не переходит в статус FIRING и не уведомляет о проблеме. Таким образом, делать выводы на основании одной точки графика нельзя. Нужно сделать условие срабатывания более комплексным. Для этого Grafana предлагает блок Conditions.

Grafana позволяет задать условие, которое будет учитывать значения нескольких точек. Также можно использовать несколько условий, связывая их логическими операторами OR или AND. Для нашего графика достаточно одного условия, анализирующего медианное значение по десяти точкам, чтобы сгладить кратковременные просадки.

Для этого после WHEN в качестве применяемой функции выбираем median(), затем задаём интервал и имя серии, на значения которой нужно смотреть, и граничное значение.

Теперь наш алерт для графика с «вылетами в норму» будет работать корректно, так как на любом 10-минутном интервале медиана будет равна единице.

Давайте обсудим последний момент, касающийся алертов, — точку срабатывания. Рассмотрим ещё один пример.

Как наш алерт поведёт себя на следующем графике?

• На отрезке с 1-й по 10-ю минуту медиана равна 3. Обозначим это как [1..10] = 3. Статус алерта OK; 

• Аналогично [2..11] = 3 и так далее до [5..14]. Статус алерта OK; 

• Далее на отрезке [6..15] медиана становится равной 2. Но наш condition имеет строгое равенство IS BELOW 2, поэтому статус алерта остаётся OK; 

• Начиная с отрезка [7..16], медиана становится равной 1. Условие IS BELOW 2 сработало, и алерт перешёл в статус PENDING;

• В дело вступает параметр Evaluate Every 1m For 5m. Он будет ежеминутно проверять condition следующие 5 минут, чтобы убедиться, что это не flak;

• И только спустя 5 минут, когда будет проверен отрезок [12..21], алерт получит статус FIRING и о проблеме будет отправлено уведомление.

Таким образом, проблема произошла на 11-й минуте графика, алерт перешёл в статус PENDING на 16-й минуте, а уведомление было отправлено на 21-й минуте, когда проблема была подтверждена.

Таким образом, используя медиану по нескольким точкам и механизм Evaluate Every… For…, мы снизили количество ложных срабатываний, но в случае реальной проблемы алерт перейдёт в статус FIRING не раньше чем через 10 минут после начала проблемы. Теперь вы знаете, как рассчитывать момент срабатывания алерта и можете подобрать свой собственный баланс между чувствительностью к вылетам и задержкой оповещения.

В Grafana описанная выше ситуация будет визуализирована с помощью вертикальных линий, показывающих изменения статуса алерта.

Теперь, когда мы понимаем, какой параметр за что отвечает, можем вернуться к Success Rate. Настроим следующее поведение: если медианное значение нашего Success Rate за 15 минут <98% и не поднимается выше в течение 5 минут — пора уведомить об этом.

На этом почти всё! Но прежде взглянем ещё раз на функцию query, первым параметром которой является имя серии, вторым — длина интервала, а третьим — правая граница интервала. В нашем примере границы отрезка будут [now-15, now]. Тут есть неочевидный момент: если к серии D был применён summarize(1m,…), то медиана будет вычисляться по 15 точкам. А если для того же графика применён summarize(5m,…), то в этот интервал будет включено уже не 10 точек, а три.

Но это не значит, что нужно выбирать между визуально приятными сглаженными графиками и точностью данных, на которых основывается condition. Мы можем иметь одну серию данных для отображения в приятном глазу виде, а другую — для настройки condition.

Соответственно, для алерта мы можем построить Alert Rate, который будет скрыт, но предоставит для condition больше точек для вычисления медианы.

Сложно давать рекомендации в общем случае о том, какое суммирование выбрать для алерта. Обычно для метрики приходится экспериментально подбирать значения в зависимости от того, насколько сильно её может «штормить».

Мы научились формулировать SLO, рисовать графики по ним и настраивать алерты. Но у нас остался ещё один туз в рукаве: эту же систему можно использовать для расследования проблем.

Расследование проблем

Помните, я говорил, что метрика должна отвечать на вопрос: «Работает ли компонент должным образом?» Но что, если нет? Где искать причину проблемы? Мы отправляем не только данные о старте загрузки и её успешном завершении — хотя этих данных достаточно для построения Success Rate — но также событие ошибки, которое можно обогатить любыми дополнительными сведениями.

Таким образом, если Success Rate падает ниже установленного значения, вы можете подключиться к Kafka и посредством SQL-запроса получить детализированные данные об ошибках.

Вывод

Это всё, что я хотел продемонстрировать. Надеюсь, мне удалось показать, что настройка SLO для работоспособности компонентов не такое уж сложное дело. Конечно, сначала придется инвестировать определенные ресурсы для того, чтобы развернуть телеметрию и научиться собирать данные. Но мы пришли к выводу, что результат точно стоит затраченных усилий!

Немного о том, как изменилась наша жизнь с тех пор, как мы внедрили Техническую Мобильную Аналитику:

• уменьшилось влияние сбоев на пользователей, поскольку сократилось время реакции на проблемы;

• снизилась нагрузка на клиентскую службу, так как многие проблемы исправляются раньше, чем пользователи начнут их замечать;

• расширился инструментарий для точечных расследований причин проблем;

• появилась возможность оценивать успехи технических инициатив не только качественно, но и количественно. Это позволило точнее описывать цели и понимать, насколько мы их достигли.

Теперь мы можем с уверенностью сказать, что внедрение Технической Мобильной Аналитики позволило мобильной команде быть уверенными в работоспособности критически важной функциональности и своевременно узнавать о проблемах раньше, чем об этом напишут пользователи.

Действительно, наши коллеги на бэкенде уже давно мониторят великое множество показателей, а мобильные разработчики часто остаются в стороне. Давайте перенимать опыт наших коллег! Если вы ещё не начали собирать техническую аналитику с мобильных приложений, я очень рекомендую составить список критически важных компонентов и метрик, которые можно отслеживать описанным методом. Это позволит оценить целесообразность внедрения технической аналитики в вашем проекте.

P.S. Эта публикация не задумывалась как цикл статей, но в процессе подготовки оказалось, что невозможно раскрыть все аспекты, не превратив статью в «монстра». Я лишь мельком коснулся многих вопросов, но если вам интересно узнать подробнее о том, что осталось за рамками, пожалуйста, выберите наиболее интересное для вас направление.