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

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

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

  • Scale — масштаб может быть значительным, устройств миллиарды, а моделей устроств тысячи и не всегда ясно в чем именно проблема
  • Control — контроль над нативными приложениями очень ограничен, т.к. в отличие от серверных приложений мы зачастую не можем форсировать загрузку нового бинарника и не контролируем устройство, на котором развернуты приложения
  • Monitoring — в условии такой вариативности нам стоит собирать отдельные метрики, а не их комбинации, которых слишком много. Плюс надо учитывать сайд эффекты логгирования в виде потребления трафика и батареи
  • Change Management — в отличие от деплоя server side приложений в мобильном мире мы не можем сделать roll back, поэтому надо релизиться аккуратно и возможен только roll forward

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

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

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

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

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

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

  • Design low-latency error ratios with high-confidence denominators (to control for normal traffic fluctuation) — это позволяет наблюдать за изменениями сразу после отправки изменений
  • Design metrics such that the metrics derived from device telemetry include the configuration state as a dimension — это позволяет отфильтровать клиентскую телеметрию с устройств, которые получили нужный фикс

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

  • White-Box Monitoring — метрики, которые публикуют данные о внутренней работе приложения
  • Black-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 флага не сломает приложение
  • Иногда при апгрейде есть side effects, которые нельзя устранить. В этом случае можно организовать что-то похожее на эффект плацебо и сделать похожий эффект для старого приложения (например, замедление первичного старта приложения после запуска эксперимента), чтобы эксперимент был проведен корректно и выводы были значимы.

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

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

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

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

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

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

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

  • 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.
  • Monitor the app in production by measuring critical user interactions and other key health metrics (e.g., responsiveness, data freshness, and crashes). Design your success criteria to relate directly to the expectations of your users as they move through your apps’ critical journeys.
  • Release changes carefully via feature flags so that they can be evaluated using experiments and rolled back independently of binary releases.
  • Understand and prepare for the app’s impact on servers, including preventing known bad behaviors, e.g., the “thundering herd” problem. Establish development and release practices that avoid problematic feedback patterns between apps and services.

Источники

  1. Engineering Reliable Mobile Applications by Kristine Chen, Venkat Patnala, Devin Carraway, Pranjal Deo
  2. Site Reliability Engineering edited by Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara and Stephen Thorne
  3. The Site Reliability Workbook edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy
  4. Building Secure and Reliable Systems by Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield
  5. A/B тестирование — Wikipedia
  6. Feature Toggles (aka Feature Flags) by Martin Fowler

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store