SRE практики в разработке мобильных приложений

Компания Google щедро делится своими практиками на тему построения надежных сервисов (подробнее в источниках 2, 3, 4), а в прошлом году был выпущен отчет по инжинирингу надежных мобильных приложений (подробнее в 1), который показался мне крайне интересным. В этой статье я сделаю краткую выжимку этого отчета.

И начнем мы с обсуждения особенностей мобильных приложений, которые важны для SRE:

  • Scale — масштаб может быть значительным, устройств миллиарды, а моделей устроств тысячи и не всегда ясно в чем именно проблема

Безотносительно особенностей мобильных приложений для измерения их надежности требуется собирать показатели.

Измерение показателей

Для мобильных приложений сложно ответить на вопрос о доступности, т.к. сложно понять как она считается. Для ответа на этот вопрос точно не хватит серверных логов, а нужна клиентская телеметрия для измерения и обеспечения видимости (visibility). Но даже без развесистой телеметрии можно ориентироваться на статистику по крашам, которая может кластеризироваться и группировать проблемы по похожести.

Как и в обычном SRE нам важны

  • SLI (service-level indicators) — фиксируем что и как измеряем, на стороне клиента обеспечиваем инструментуализацию и отправляем нужные события на backend, там и производим рассчеты собственно индикаторов. Если действовать так, то отправляемые события могут участвовать в рассчете разных SLI

После того, как мы определились с SLI и SLO приходит время поговорить о их мониторинге.

Мониторинг реального времени

Команды SRE любят мониторинг в режиме реального времени, так как он позволяет максимально оперативно реагировать на проблемы. Но в мобильном мире resolution time увеличен, т.к. доставка изменений зачастую выполняется в polling режиме. Это приводит к тому, что стабилизация клиенстких метрик после отправки измений может занимать часы. Поэтому для широко релизящихся приложений, телеметрия с которых поступает постоянно, было выработано 2 подхода работы с ней:

  • Design low-latency error ratios with high-confidence denominators (to control for normal traffic fluctuation) — это позволяет наблюдать за изменениями сразу после отправки изменений

Для мониторинга используются два подхода:

  • White-Box Monitoring — метрики, которые публикуют данные о внутренней работе приложения

Оба подхода комплиментарны друг другу и только совместно дают достаточно надежное представление о происходящем с мобильным приложением.

Отдельный вопрос сбор информации о производительности приложения и потребления им ресурсов. Важность этого вопроса обусловлена тем, что приложения работают используя общие ресурсы, потребление которых серьезно ограничено. Командам в Google требуется определять их сценарии (use cases), которые могут повлиять на метрики производительности, причем как для обоих случаев: screen on и screen off.

Мониторинг — это хорошо, но не менее важным вопросом является доставка изменений пользователям, за что отвечает

Менеджмент изменений

Использование лучших практик для управления изменениями очень важно, так как rollback практическик не возможен и некоторые проблемы, найденные в production, являются нестранимыми (например, окирпичивание устройств).

В мобильной разработке для доставки новых бинарников используется поэтапная выкладка (Staged Rollout в Android и Phased Releases в iOS). Выглядит она так, как представлено ниже

Рис.1 “Staged Rollout”

В отличие от традиционных сервисов мобильные приложениия работают в очень разнообразной экосистеме, где все параметры могут серьезно отличаться от устройства устройству (cpu, memory, network bandwith, etc). Если ориентироваться на метрики, собираемые сразу после релиза новой версии, то можно получить искаженные данные, так как зачастую новые приложения сразу ставят энтузиасты с мощными устройствами и хорошей сетью. Для устранения этой ассимитричности рекомендуется разделять релиз новых приложений и запуск нового поведения. Причем запускать изменения в поведении через a/b тесты (подробнее про a/b тестирование в 5). Причем для запуска этих экспериментов надо использовать feature flags (подробнее про feature flags в 6). Есть два момента, которые важно обсудить при использовании флагов:

  • Очень важно тестировать, что rolling back флага не сломает приложение

Большое количество релизов приводит к длинному хвосту старых версий, которые остаются на устройствах клиентов. И нам требуется внятная политика поддержки старых версий.

Поддержка старых версий

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

И финальным рассматриваемым вопросом является то, как изменения в мобильных приложениях влияют на server side сервисы.

Влияние на бекенд сервисы

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

Важно понимать как связаны изменения на клиентской стороне с изменением характера использования связанных сервисов и тестировать перед выкладкой, что эти изменения не будут фатальными:)

Case Studies

Около половины содержания отчета Engineering Reliable Mobile Applications приходится на описание конкретных примеров, которые действительно интересны. Я рекомендую вам их изучить самостоятельно. А книга заканчивается разделом, суммирующим содержимое всего отчета. Причем раздел назван красиво

SRE: Hope Is Not a Mobile Strategy

В нем авторы выделяют следующие лучшие практики из своего опыта:

  • Design mobile applications to be resilient to unexpected inputs, to recover from management errors (however rare), and to roll out changes in a controlled, metric-driven way.

Источники

  1. Engineering Reliable Mobile Applications by Kristine Chen, Venkat Patnala, Devin Carraway, Pranjal Deo

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.