Источник
Краткий обзор на русском
Мой разбор книги на Tell Me About Tech
Engineering Reliable Mobile Applications
Авторы: Kristine Chen, Venkat Patnala, Devin Carraway, Pranjal Deo
Издательство: O'Reilly Media, 2019
Объём: 35 страниц
Mobile SRE от Google: staged rollout, feature flags, клиентская телеметрия и влияние на backend.
ОригиналОсобенности мобильных приложений для SRE
Особенности Mobile SRE
SRE Book
Site Reliability Engineering
Основы SLI/SLO/SLA и error budgets
Измерение показателей
Для мобильных приложений сложно ответить на вопрос о доступности. Для этого точно не хватит серверных логов — нужна клиентская телеметрия для измерения и обеспечения visibility. Даже без развесистой телеметрии можно ориентироваться на статистику по крашам.
SLI (Service Level Indicators)
Фиксируем что и как измеряем. На стороне клиента обеспечиваем инструментализацию и отправляем нужные события на backend, там производим расчёты индикаторов. Отправляемые события могут участвовать в расчёте разных SLI.
SLO (Service Level Objectives)
При наличии высококачественных SLI мы можем выставлять определённые уровни SLO, к которым стремимся. Важно учитывать специфику мобильных устройств.
Мониторинг реального времени
Команды SRE любят мониторинг в режиме реального времени. Но в мобильном мире resolution time увеличен, так как доставка изменений выполняется в polling-режиме. Стабилизация клиентских метрик после отправки изменений может занимать часы.
Low-latency error ratios
Проектируйте метрики с high-confidence denominators для контроля нормальных флуктуаций трафика. Это позволяет наблюдать за изменениями сразу после отправки.
Configuration state as dimension
Метрики из телеметрии должны включать состояние конфигурации как измерение. Это позволяет отфильтровать телеметрию с устройств, которые получили нужный фикс.
White-Box Monitoring
Метрики, которые публикуют данные о внутренней работе приложения. Требует инструментализации кода.
Black-Box Monitoring
Проверка внешнего, видимого поведения приложения. Например, периодические пробы (probes).
Оба подхода комплементарны — только совместно дают достаточно надёжное представление о состоянии приложения.
CI/CD
Grokking Continuous Delivery
Практики непрерывной доставки
Менеджмент изменений
Использование лучших практик управления изменениями критически важно: rollback практически невозможен, а некоторые проблемы, найденные в production, являются неустранимыми (например, «окирпичивание» устройств).
Staged Rollout / Phased Releases
Внутренние тестировщики и dogfooding
В отличие от server-side деплоя, в мобильном мире возможен только roll forward — откат через новую версию
Кейс
Проектирование A/B платформы
Архитектура системы экспериментов для веба и мобильных приложений
Feature Flags и A/B тестирование
Мобильные приложения работают в очень разнообразной экосистеме, где все параметры могут отличаться от устройства к устройству (CPU, memory, network bandwidth). Если ориентироваться на метрики сразу после релиза, можно получить искажённые данные — новые версии первыми ставят энтузиасты с мощными устройствами.
Рекомендация Google
Разделяйте релиз новых приложений и запуск нового поведения. Запускайте изменения в поведении через A/B тесты с использованием feature flags.
Важно тестировать, что rolling back флага не сломает приложение
При апгрейде могут быть side effects, которые нельзя устранить — можно организовать «эффект плацебо» для старого приложения для корректности эксперимента
Поддержка старых версий
Большое количество релизов приводит к длинному хвосту старых версий на устройствах клиентов. Требуется внятная политика поддержки.
Горизонт поддержки
У поддержки старых версий должен быть понятный горизонт — например, один или два года. В противном случае поддерживать весь зоопарк старых версий будет слишком дорого и неэффективно.
Устойчивость
Release It!
Паттерны защиты от cascade failures
Влияние на backend сервисы
Изменения в клиентском коде могут приводить к значимым последствиям на серверной стороне. Например, изменение политики кеширования может увеличить количество запросов на порядок, что может привести к отказу в обслуживании backend систем.
Важно понимать, как связаны изменения на клиентской стороне с изменением характера использования связанных сервисов, и тестировать перед выкладкой, что эти изменения не будут фатальными.
SRE: Hope Is Not a Mobile Strategy
Авторы выделяют следующие лучшие практики из опыта Google:
Design
Проектируйте мобильные приложения устойчивыми к неожиданным входным данным, способными восстанавливаться после ошибок управления и выкатывать изменения контролируемым, metric-driven способом.
Monitor
Мониторьте приложение в production, измеряя критические пользовательские взаимодействияи ключевые метрики здоровья (responsiveness, data freshness, crashes). Критерии успеха должны напрямую соотноситься с ожиданиями пользователей.
Release
Выкатывайте изменения аккуратно через feature flags, чтобы их можно было оценить с помощью экспериментов и откатить независимо от бинарных релизов.
Understand
Понимайте и готовьтесь к влиянию приложения на серверы. Предотвращайте известные проблемные паттерны (например, thundering herd). Устанавливайте практики разработки и релиза, избегающие проблемных feedback-паттернов между приложениями и сервисами.
Связанные материалы от Google
Site Reliability Engineering
Google SRE Book
Основы SRE-практик: SLO, error budgets, toil, on-call и postmortems.
The Site Reliability Workbook
Google SRE Workbook
Практическое продолжение с конкретными примерами и case studies.
Building Secure and Reliable Systems
Google, 2020
Как совместить security и reliability в production-системах.