Revision · Observability & Operations

This part was about the moment after you ship, when the system is live and something is slow or wrong and your only window in is the signals it emits. Every page serves one loop: emit signals, detect a problem, diagnose it, fix or roll back, and watch the signals confirm the fix.

What this part covered

• Observability vs monitoring — monitoring answers the known questions you predicted; observability lets you investigate the unknown ones without redeploying, which is what you reach for at 3 a.m. when every dashboard is green and the system is still broken.
• Logging — structured, centralized, level-controlled events tied together with correlation IDs are the highest-fidelity signal, and also the most expensive to store, so volume and noise are the real cost.
• Metrics — cheap aggregated counters, gauges, and histograms drive dashboards and alerts via the RED and USE methods, but throw away detail and fall into the cardinality trap that blows up the bill.
• Distributed tracing — spans and context propagation follow one request across service hops so you can find where the time went when the whole thing is slow but no single service looks slow.
• Alerting & on-call — the cardinal rule is alert on symptoms users feel, not causes engineers fear; tie alerts to error budgets and SLOs, fight alert fatigue, and make each page actionable with a runbook.
• Deployment strategies — change a running system safely with rolling, blue-green, and canary releases, decouple deploy from release with feature flags, and treat fast rollback as the thing that saves you.
• The recurring trade question — every signal you emit buys future insight and costs storage, network, and engineer attention, so the art is emitting the right signals rather than drowning tomorrow’s answer in noise.

The takeaway

Seeing is only half of operations; the other half is what you do with what you see. Logs, metrics, and traces feed the loop, alerting triggers it, and deployment strategies make the “fix or roll back” step safe and fast — turning a checklist of techniques into a single feedback system. Next we turn from watching the system to guarding it: Security and the design of trust boundaries.