В этом коротком отчете (меньше 40 страниц) несколько инженеров компании Google делятся нюансами SRE подходов, к которым они пришли для своих мобильных приложений, а также приводят примеры конкретных ситуаций, с которыми им приходилось сталкиваться. 

Что же по мнению авторов отличает мобильные приложения от обычного SRE для сервисов и сайтов? Распределенность системы, отсутствие возможности быстрого обновления версии приложения у пользователя, ограничения по работе с сетью и батареей (приходится выбирать, что и когда логировать, как агрегировать и когда отправлять эти данные, чтобы не попасть на первые строчки потребителей аккумулятора в отчете операционной системы), возможность попасть в ситуацию, когда на устройстве не хватает памяти итд. 

Как предлагают бороться? Фиче флаги, постепенная раскатка релизов (Staged Rollout в Google Play и Phased Releases в App Store), контроль конфигураций, более чёткое планирование нагрузки на сервера, анализ SLI и SLO, мониторинг. 

В отчёте также приведены примеры ошибок Google и объяснений и каким последствиям это приводило. 

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

Практические советы от меня

Совет №1
Рекомендую ознакомиться с возможностями, которые предоставляет Firebase Perfomance Monitoring. Даже автоматически собираемых им метрик хватит, чтобы выявить самые частые проблемы, встречающиеся в приложениях, к тому же данные можно сравнивать, чтобы видеть динамику изменения показателей между разными релизами, устройства, странами, версиями ОС

  • время запуска приложения
  • время отрисовки экранов
  • скорость работы сетевых эндпоинтов API

Помимо этого, вы можете собирать интересующие вас параметры, выставлять пороговые значения. Быстро, просто и бесплатно.

Совет №2
В приложении стоит заложить механизм рекомендованного и принудительного обновления. При запуске нужно получить с сервера 2 версии – минимальную и рекомендуемую минимальную. Если версия приложения, ниже минимальной – выводим окно с кнопкой перехода в App Store / Google Play для обновления – это нужно на случай, когда вы больше не поддерживаете старую версию какого-либо из API, имейте в виду, это крайняя мера – пользователь может быть недоволен тем, что приложение больше не поддерживается. Если же версия приложения ниже рекомендуемой минимальную – выводим окно с предложением обновиться, но возможностью отказаться от обновления – это позволит сократить количество пользователей старой версии.