30. Observability
The picture to keep in your head
Every question below is answered twice: first in the car, so you can picture it, then in the system, so you know exactly how it works. Each answer ends with a memory code to lock it in.
The picture to keep in your head
You're driving on the highway. The dashboard shows your speed, fuel and engine temperature at a glance. The car keeps a trip log: every hard brake, every warning, with the time. Your phone's maps can replay the route, showing exactly where you lost twenty minutes (a toll queue, not the traffic). The service book makes a promise: "service every 10,000 km". And the warning lights stay dark unless something actually needs you: no light for "the radio is slightly loud", but a red one for "oil pressure low, stop now".
When the car starts making a strange noise, you don't guess. You look at the gauges, check the log, replay the route, and narrow it down.
That's observability: being able to tell, from the outside, what's happening inside your system, and why.
Our running example: the bookstore's checkout during the Big Book Sale. Customers say "checkout is slow". Is it? For whom? Since when? Why? And should anyone have been woken up? Traffic and latency numbers are assumptions for practice.
| In the car | In the system |
|---|---|
| Knowing what's wrong without opening the bonnet | Why observability |
| The trip log | Logs |
| The gauges | Metrics |
| The route replay | Traces |
| Speed, fuel, temperature: the few that matter | Golden signals, RED and USE |
| "Service every 10,000 km" | SLI, SLO, SLA |
| How many km of slack before the next service | Error budgets |
| Warning lights that only light for real problems | Alerting without noise |
| The dashboard layout | Dashboards |
| Strange noise → gauges → log → replay → fix | Debugging an incident |
Figure: you can't fix what you can't see; watch what the driver feels, and keep the logbook.