Monitoring? Not OPS problem
summary
Systems change from monthly releases to about 10 deployments per service per day producing roughly 10,000 possible states daily, so monitoring shifts from host CPU checks to service symptoms and user impact. Developers must own observability: track response time, error counts, and how many users are affected; design fallbacks (show top-sellers when recommendations fail) and expect failures. The goal is resilience, built with data-driven alerts and everyone on call responsibility.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 0:38Monitoring used to be
- 1:22Development process
- 2:41Tech landscape
- 4:35Monitoring
- 5:48System Resilience
- 6:43Developer Responsibility
- 7:10Professional Software Engineer
related talks
22mService Monitoring Manual—2018 Edition
58mObserving Applications in Production
38mEffective App Monitoring in Production
28mProduction Testing Through Monitoring
05mContinuous Performance
40mSurvivability of Observability: Taking your DIY system to success
43mMonitoring at one of the largest retail groups in the world
23mMastering Monitoring & Alerting: Key to Seamless Performance