What's changed: Deepened AZ-400 Chapter 5 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
5.3Feedback and SRE Practices
Understand continuous feedback—SLI/SLO/error budgets, blast radius control, postmortems, continuous improvement, and user feedback. Improve reliability through learning.
DevOps is completed by a learning loop. Quantify reliability with SLI/SLO, learn from failures via postmortems, and improve continuously.
5.3.1SRE and feedback
- SLI/SLO: SLI = measured reliability indicators, SLO = targets; quantify the service promise.
- Error budget: headroom against the SLO; risky changes are acceptable while budget remains.
- Blast radius control: limit failure impact via canary/feature flags/staged rollout.
- Postmortems: blameless retros to learn root cause/prevention and improve continuously.
Common on AZ-400: measured = SLI, target = SLO, headroom = error budget, limit impact = blast radius control (canary/flags), blameless retro = postmortem. Use error budgets to decide: move fast while budget remains, prioritize stability when exhausted.
User feedback (in-app surveys/telemetry/support) is part of instrumentation. Combine with hypothesis testing (A/B) to invest in what delivers value.
AZ-400 SRE/feedback probes "connecting measurement to learning and decisions to continuously raise reliability." An SLI (Service Level Indicator) is a measured reliability metric (success rate, p99 latency, availability), an SLO (Objective) is its target (e.g., 99.9% monthly), and an SLA is the external contract (breaching it triggers compensation). The error budget = (1 − SLO) is the "allowable amount of failure," used for objective decisions: while budget remains, ship risky changes fast; when exhausted, prioritize stabilization (change freeze, reliability investment)—resolving the "speed vs stability" tension. During incidents, limit the blast radius (canary/feature flags/staged rollout/circuit breakers) to localize impact. Afterward, run blameless postmortems to learn systemic root cause (process/design, not people) and prevention, turning action items into work items for continuous improvement. Reduce toil (repetitive manual work) via automation to redirect engineers to value creation. Validate hypotheses with user feedback (in-app surveys, telemetry, support) and A/B testing to invest in what delivers value. The key is to quantify reliability with SLI/SLO/error budgets and run a learning loop via blast-radius control and postmortems.
| Term | Meaning | How used |
|---|---|---|
| SLI | Measured reliability indicator | Measure success rate/latency/availability |
| SLO | Reliability target | E.g., 99.9% monthly |
| Error budget | Headroom vs SLO (1−SLO) | Remaining → move fast; exhausted → stabilize |
| Postmortem | Blameless retro | Learn root cause and prevention |
Scenario: The dev team wants to ship features fast while ops worries about stability—they conflict and need an objective criterion. → Define an SLO (e.g., 99.9% success) for the service and operate by error budget. While budget remains, allow feature deploys (favor speed); if it runs out mid-month, freeze changes and invest in reliability (favor stability). This arbitrates "speed vs stability" with data, and incidents are learned from via blameless postmortems for prevention.
FAQ: SLI vs SLO vs SLA? SLI is the metric you actually measure (e.g., fraction of successful requests). SLO is the internal target (e.g., 99.9%). SLA is the customer contract, where a breach triggers compensation like refunds. SLOs are usually set stricter than SLAs so you can act before an SLA breach. The error budget is computed from the SLO and sets risk tolerance for changes.
Exam trap: Don’t confuse SLI/SLO/SLA—measured = SLI, internal target = SLO, external contract = SLA. Also, making postmortems about blaming individuals is wrong (it chills reporting)—keep them blameless, focused on systemic causes. The error budget’s goal is not "never spend it" but to inform speed-vs-stability decisions by remaining amount (being overly conservative while budget remains is also inefficient).
5.3.2Section summary
- Reliability = SLI/SLO/error budget
- Learning = blast radius control + postmortems + continuous improvement
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What is the defined reliability "target" (e.g., 99.9% success monthly) called?
Q2. What is the "headroom" against the SLO that informs how aggressively to ship changes?
Q3. What is the blameless retro after an incident to learn root cause and prevention called?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.