Site Reliability Engineering interview question · Most asked
How would you take a service from 99.9% to 99.99% availability?
Summary
First confirm the business needs it, because it cuts allowed downtime from about 43 minutes to about 4 minutes a month. Then analyse where the current budget goes, and attack the largest causes: remove single points of failure (multi-zone, redundancy), make changes safer (canaries, automated rollback), speed up detection and mitigation (burn-rate alerts, automated failover), and degrade gracefully when dependencies fail.
Longer Answer
At four nines, humans are too slow to be the recovery mechanism: an engineer being paged, waking up and logging in already uses the monthly budget. So recovery must be automatic (health-check-based failover, automated rollback, load shedding), and changes must be staged so a bad one only affects a small slice. Check critical dependencies: you cannot exceed their availability without redundancy or fallbacks. Measure progress against the SLO, and price the cost (extra regions, engineering time) explicitly.
Key Points
- Confirm the need; 4 minutes/month.
- Spend analysis: fix the biggest budget consumers.
- Automated recovery; humans are too slow.
- Dependencies cap you.
Explanation
What interviewers look for
Budget-driven prioritisation and the insight that manual response cannot meet four nines.
More most-asked Site Reliability Engineering questions
- What is Site Reliability Engineering, and how does it relate to DevOps?
- What makes a good alert? Explain symptom-based alerting and alert fatigue.
- What is an error budget, and how should it be used?
- Define SLI, SLO and SLA, and explain how they relate.
- What is burn-rate alerting, and why is it better than alerting on raw error rates?
- How do you choose good SLIs for a service?
- What are the four golden signals?
- What is the difference between monitoring and observability? Explain metrics, logs and traces.