Practice this topic in a realistic system design interview
Suppose you are on call, and an alert wakes you up at 3 a.m. It says the payment service error rate is high.
You open the team dashboard. It has 60 panels. Several graphs look a little unusual, but you cannot tell which ones matter. There are no notes on what to check first, and the engineer who built the payment service is asleep in another time zone.
So you start guessing. Twenty minutes later, you find out that a deployment an hour ago caused the problem, and rolling it back fixes it.
The fix itself took 2 minutes, but finding it took 20.
Dashboards and runbooks exist to shorten that gap. Dashboards help you see what is wrong, and runbooks tell you what to do about it.
In this chapter, we will learn how to design dashboards that help you understand a system quickly, how to write runbooks that guide engineers through incidents, and how alerts, dashboards, and runbooks fit together into one response workflow.