SRE for Mobile Applications
summary
Google Search app SRE work focuses on client-side monitoring, progressive rollouts and remote feature flags to avoid rollbacks; real tactics include UI tests in emulators against production, Play Console metrics, and hashing stable user ID with flag seed to produce independent rollout buckets. Notable failures are specific: a bad doodle config causes tens of millions of crashes across millions of users, and a cached bad config causing endless crash loop leaves older app versions bricked until config reversion and server-side validation occur. Baseline SLOs sit near 85% success and ~50–100 flags run concurrently.
AI-written summary · about
chapters (21)
- 0:00Intro
- 1:49In general, an SRE team for mobile
- 3:55Disadvantages of client-side SRE
- 6:07Why mobile? - Key Points
- 7:11Caveats of realtime monitoring
- 8:28Continuous Integration
- 9:31System and app health
- 14:05Flag guarding
- 17:43The big advantage
- 18:48Release Process
- 20:47How to SRE a mobile app - Key Points
- 21:17Karl Landsteiner
- 23:25Jagadish Chandra Bose
- 23:36Doodle crashes (again)
- 24:06What did we learn?
- 25:59Cached config crashes
- 29:30Unresponsive app caused by fixes
- 31:12Other Outages
- 33:04Case Studies - Key Points
- 33:24Future of SRE for Mobile
- 35:21Unsolved problems
related talks
40mHow Google SRE and developers work together
14mWeb Apps, through the Lens of SRE (Site Reliability Engineering)
41mAn Introduction to SRE at Google (with DevOps Focus)
32mHow Google SRE and Developers Work Together
25mProduct Reliability for Google Maps
22mSRE for Enterprises
27mHow Google SRE and developers work together
21mSRE, what is it all about?!