Implementing Service Level Objectives (Alex Hidalgo)
Problem
Teams cannot manage reliability without shared facts about the service.
Action
Define the service, its users, and the results they expect.
Outcome
Reliability work starts from a clear view of user needs.
Chapter: SLO Development - The Reliability Stack - Service Truths
Problem
System metrics may not show whether users receive a good service.
Action
Choose indicators that measure successful user interactions.
Outcome
Service health reflects the experience that users receive.
Chapter: SLO Development - The Reliability Stack - The Reliability Stack - Service Level Indicators
Problem
Measurements alone do not define acceptable service performance.
Action
Set targets for the share of successful events over time.
Outcome
Teams gain a clear standard for reliability decisions.
Chapter: SLO Development - The Reliability Stack - The Reliability Stack - Service Level Objectives
Problem
Teams often argue about reliability without a shared risk limit.
Action
Calculate the acceptable failure amount from each SLO.
Outcome
Teams can balance service changes with reliability needs.
Chapter: SLO Development - The Reliability Stack - The Reliability Stack - Error Budgets
Problem
Technical boundaries do not always match how users experience a service.
Action
Describe each service by its users and supported interactions.
Outcome
Service definitions support meaningful reliability measurements.
Chapter: SLO Development - The Reliability Stack - What Is a Service? - Example Services
Problem
An SLO has little value when teams treat it as a promise alone.
Action
Use SLO results as evidence during planning and risk decisions.
Outcome
Reliability data guide practical choices rather than empty compliance.
Chapter: SLO Development - The Reliability Stack - Things to Keep in Mind - SLOs Are Just Data
Problem
A one-time SLO effort becomes outdated and loses value.
Action
Assign regular work to measure, review, and use SLOs.
Outcome
Reliability practices remain active after initial implementation.
Chapter: SLO Development - The Reliability Stack - Things to Keep in Mind - SLOs Are a Process, Not a Project
Problem
Initial measurements and targets rarely capture user needs perfectly.
Action
Review results and adjust indicators, targets, and policies.
Outcome
SLOs become more accurate and useful over time.
Chapter: SLO Development - The Reliability Stack - Things to Keep in Mind - Iterate Over Everything
Problem
Service use and user expectations change after targets are set.
Action
Reevaluate SLOs after important product, traffic, or dependency changes.
Outcome
Reliability targets continue to match current conditions.
Chapter: SLO Development - The Reliability Stack - Things to Keep in Mind - The World Will Change
Problem
Technical measurements can distract teams from the people they serve.
Action
Connect each reliability decision to its effect on users and staff.
Outcome
Reliability work supports real human needs.
Chapter: SLO Development - The Reliability Stack - Things to Keep in Mind - It's All About Humans
Problem
Disconnected measurements and targets do not support consistent decisions.
Action
Connect service truths, SLIs, SLOs, and error budgets.
Outcome
Teams gain a complete method for managing reliability.
Chapter: SLO Development - The Reliability Stack - Summary
Problem
Reliability does not result from isolated fixes or individual effort.
Action
Design processes and systems that produce dependable user outcomes.
Outcome
Reliability becomes repeatable instead of accidental.
Chapter: SLO Development - How to Think About Reliability - Reliability Engineering
Problem
Users form expectations even when no reliability target is published.
Action
Review past performance and user behavior to identify implied expectations.
Outcome
Formal targets begin from what the service users already know.
Chapter: SLO Development - How to Think About Reliability - Past Performance and Your Users - Implied Agreements
Problem
Unspoken expectations create conflict when service quality changes.
Action
Agree with stakeholders on measurable reliability targets.
Outcome
Teams and users share a clear standard for acceptable service.
Chapter: SLO Development - How to Think About Reliability - Past Performance and Your Users - Making Agreements
Problem
General claims about reliability hide how performance is measured.
Action
Count good events and total valid events over a defined period.
Outcome
Reliability becomes a concrete and verifiable ratio.
Chapter: SLO Development - How to Think About Reliability - A Worked Example of Reliability
Problem
A perfect target can block useful changes without improving user happiness.
Action
Choose the lowest reliability level that still meets user requirements.
Outcome
Teams preserve room for change while protecting user needs.
Chapter: SLO Development - How to Think About Reliability - How Reliable Should You Be? - 100% Isn't Necessary
Problem
Each additional reliability improvement requires more money and effort.
Action
Fund improvements only when their user value justifies their cost.
Outcome
Resources support the most valuable level of reliability.
Chapter: SLO Development - How to Think About Reliability - How Reliable Should You Be? - Reliability Is Expensive
Problem
Technical ambition alone cannot determine the right reliability level.
Action
Set targets from user needs, business value, and engineering cost.
Outcome
Reliability investments match the service context.
Chapter: SLO Development - How to Think About Reliability - How Reliable Should You Be? - How to Think About Reliability
Problem
Reliability work fails when expectations remain vague or absolute.
Action
Turn observed user needs into explicit and affordable targets.
Outcome
Teams can manage reliability with shared expectations.
Chapter: SLO Development - How to Think About Reliability - Summary
Problem
Users remain unhappy when measurements ignore failed experiences.
Action
Measure whether important user actions complete successfully and quickly.
Outcome
SLIs reveal changes that affect user satisfaction.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - What Meaningful SLIs Provide - Happier Users
Problem
Engineers waste effort when service health lacks a trusted measure.
Action
Provide SLIs that connect technical behavior to user impact.
Outcome
Engineers can focus work on meaningful reliability problems.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - What Meaningful SLIs Provide - Happier Engineers
Problem
Reliability work loses support when its business value is unclear.
Action
Choose SLIs for user journeys that support important business outcomes.
Outcome
Reliability decisions protect both users and the business.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - What Meaningful SLIs Provide - A Happier Business
Problem
Internal health metrics can hide slow or failed requests.
Action
Measure valid requests by success and response time.
Outcome
The SLI represents the quality users receive.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - Caring About Many Things - A Request and Response Service
Problem
Too many indicators make reliability difficult to understand and operate.
Action
Choose a small set of SLIs that represent several user concerns.
Outcome
Teams gain broad coverage without excessive measurement work.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - Caring About Many Things - Measuring Many Things by Measuring Only a Few
Problem
Vague SLI descriptions produce inconsistent calculations.
Action
Document the valid events, good events, data source, and time scope.
Outcome
Different teams can calculate the same result.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - Caring About Many Things - A Written Example
Problem
A complex service can succeed internally while its users still fail.
Action
Define SLIs around complete user journeys across service components.
Outcome
Reliability measurements capture the combined user experience.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - Something More Complex - Measuring Complex Service User Reliability
Problem
Complex service boundaries make indicator definitions easy to misunderstand.
Action
Write concrete examples of events that count as good or bad.
Outcome
Teams apply complex SLI definitions consistently.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - Something More Complex - Another Written Example
Problem
Technically sound indicators may ignore the service actions that create value.
Action
Prioritize SLIs for journeys that matter most to business results.
Outcome
Reliability work supports important business activity.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - Something More Complex - Business Alignment and SLIs
Problem
Poor indicators weaken every SLO built from them.
Action
Select precise user-centered measures for the most important journeys.
Outcome
SLOs rest on useful evidence about service quality.
Chapter: SLO Development - Developing Meaningful Service Level Indicators - Summary
Problem
An SLI cannot guide decisions without an acceptable target.
Action
Define the required success ratio and measurement window.
Outcome
Teams can distinguish acceptable performance from excessive failure.
Chapter: SLO Development - Choosing Good Service Level Objectives - Reliability Targets
Problem
Excess reliability can create expectations that limit future change.
Action
Set targets below historical perfection when users can tolerate failures.
Outcome
Teams can innovate without breaking user trust.
Chapter: SLO Development - Choosing Good Service Level Objectives - User Happiness - The Problem of Being Too Reliable
Problem
A familiar percentage may not match actual user needs.
Action
Choose targets from observed user tolerance instead of attractive numbers.
Outcome
The SLO reflects meaningful reliability rather than convention.
Chapter: SLO Development - Choosing Good Service Level Objectives - User Happiness - The Problem with the Number Nine
Problem
Too many SLOs divide attention and complicate decisions.
Action
Keep only targets that protect distinct and important user experiences.
Outcome
Teams can understand and act on their SLOs.
Chapter: SLO Development - Choosing Good Service Level Objectives - User Happiness - The Problem with Too Many SLOs
Problem
A service cannot meet targets that its critical dependencies make impossible.
Action
Measure dependency behavior and include its risk in target decisions.
Outcome
Service targets reflect real external limits.
Chapter: SLO Development - Choosing Good Service Level Objectives - Service Dependencies and Components - Service Dependencies
Problem
A component failure does not always create a user failure.
Action
Set service SLOs from user outcomes while monitoring components for diagnosis.
Outcome
Targets describe user reliability without losing technical visibility.
Chapter: SLO Development - Choosing Good Service Level Objectives - Service Dependencies and Components - Service Components
Problem
Provider claims do not show the reliability your users receive.
Action
Measure hosted and open-source dependencies from your own service boundary.
Outcome
Your SLO decisions use observed dependency performance.
Chapter: SLO Development - Choosing Good Service Level Objectives - Reliability for Things You Don't Own - Open Source or Hosted Services
Problem
Hardware specifications do not prove dependable user outcomes.
Action
Track hardware failures by their effect on valid service events.
Outcome
Hardware reliability connects to actual service quality.
Chapter: SLO Development - Choosing Good Service Level Objectives - Reliability for Things You Don't Own - Measuring Hardware
Problem
Targets chosen without evidence may be impossible or meaningless.
Action
Use historical SLI results as the first target baseline.
Outcome
Initial SLOs begin from demonstrated service behavior.
Chapter: SLO Development - Choosing Good Service Level Objectives - Choosing Targets - Past Performance
Problem
A single average can hide important variation in service quality.
Action
Examine distributions, ranges, and sample sizes before choosing targets.
Outcome
Targets reflect normal performance and meaningful variation.
Chapter: SLO Development - Choosing Good Service Level Objectives - Choosing Targets - Basic Statistics
Problem
Metric type and collection behavior can distort SLO calculations.
Action
Verify units, labels, sampling, aggregation, and handling of missing data.
Outcome
Targets rely on metrics that behave as expected.
Chapter: SLO Development - Choosing Good Service Level Objectives - Choosing Targets - Metric Attributes
Problem
Percentiles can hide how many individual events met user needs.
Action
Count events below a user-centered threshold over the SLO window.
Outcome
Latency objectives directly represent successful experiences.
Chapter: SLO Development - Choosing Good Service Level Objectives - Choosing Targets - Percentile Thresholds
Problem
New services lack data for evidence-based SLO targets.
Action
Set a reasonable temporary target and revise it after collecting data.
Outcome
Reliability management can begin before a long history exists.
Chapter: SLO Development - Choosing Good Service Level Objectives - Choosing Targets - What to Do Without a History
Problem
Poor targets create noise without guiding useful decisions.
Action
Base a small set of targets on users, evidence, and dependencies.
Outcome
SLOs become practical standards for service reliability.
Chapter: SLO Development - Choosing Good Service Level Objectives - Summary
Problem
Feature releases add risk when reliability is already below target.
Action
Slow, risky releases when the error budget is depleted.
Outcome
Release decisions balance product progress with user reliability.
Chapter: SLO Development - How to Use Error Budgets - Error Budgets in Practice - To Release New Features or Not?
Problem
Teams may keep building features while reliability debt continues to grow.
Action
Move effort toward reliability when budget consumption exceeds policy limits.
Outcome
Project priorities respond to measured service risk.
Chapter: SLO Development - How to Use Error Budgets - Error Budgets in Practice - Project Focus
Problem
Unexamined changes can consume more error budget than expected.
Action
Assess the size, reversibility, dependencies, and failure impact of the change.
Outcome
Teams spend their error budget with clearer risk awareness.
Chapter: SLO Development - How to Use Error Budgets - Error Budgets in Practice - Examining Risk Factors
Problem
Fear of failure can prevent teams from learning about system behavior.
Action
Run bounded failure experiments when enough error budget remains.
Outcome
Teams discover weaknesses without exceeding accepted user risk.
Chapter: SLO Development - How to Use Error Budgets - Error Budgets in Practice - Experimentation and Chaos Engineering
Problem
Unknown capacity limits can cause sudden service failure.
Action
Run load and stress tests within approved error budget limits.
Outcome
Teams learn safe capacity and failure behavior early.
Chapter: SLO Development - How to Use Error Budgets - Error Budgets in Practice - Load and Stress Tests
Problem
Failover plans may fail when traffic or dependencies disappear.
Action
Run controlled blackhole exercises against expected failure paths.
Outcome
Teams verify that systems handle lost traffic or dependencies.
Chapter: SLO Development - How to Use Error Budgets - Error Budgets in Practice - Blackhole Exercises
Problem
Unused error budget can hide untested assumptions and slow progress.
Action
Use the available budget for controlled changes that test service limits.
Outcome
Accepted risk produces evidence and improvement.
Chapter: SLO Development - How to Use Error Budgets - Error Budgets in Practice - Purposely Burning Budget
Problem
Constant pressure to maintain reliability can exhaust engineers and damage cooperation.
Action
Use error budget rules to set fair limits on urgent work.
Outcome
Teams make calmer decisions with less personal conflict.
Chapter: SLO Development - How to Use Error Budgets - Error Budgets in Practice - Error Budgets for Humans
Problem
Teams cannot use a budget when its amount is unclear.
Action
Derive allowed bad events from the SLO target and window.
Outcome
Everyone sees the same remaining reliability allowance.
Chapter: SLO Development - How to Use Error Budgets - Error Budget Measurement - Establishing Error Budgets
Problem
A measured error budget has no value without defined responses.
Action
Specify which actions follow healthy, threatened, and exhausted budgets.
Outcome
Reliability data leads to consistent operating choices.
Chapter: SLO Development - How to Use Error Budgets - Error Budget Measurement - Decision Making
Problem
Teams may interpret the same budget status differently.
Action
Document owners, thresholds, actions, exceptions, and review rules.
Outcome
Stakeholders know how reliability affects planned work.
Chapter: SLO Development - How to Use Error Budgets - Error Budget Measurement - Error Budget Policies
Problem
Error budgets cannot balance risk when teams ignore their status.
Action
Measure budget use and apply agreed responses to each condition.
Outcome
Reliability and change proceed within shared risk limits.
Chapter: SLO Development - How to Use Error Budgets - Summary
Problem
Code alone cannot create shared reliability decisions.
Action
Include communication, policy, ownership, and training in SLO implementation.
Outcome
The organization can use SLOs in daily work.
Chapter: SLO Implementation - Getting Buy-In - Engineering Is More than Code
Problem
Engineers may resist SLO work that appears to add measurement overhead.
Action
Show how SLOs improve priorities, alerts, and technical decisions.
Outcome
Engineering sees direct value in adopting SLOs.
Chapter: SLO Implementation - Getting Buy-In - Key Stakeholders - Engineering
Problem
Product teams may treat reliability as separate from user value.
Action
Show how error budgets guide feature timing and protect key journeys.
Outcome
Product decisions account for service reliability.
Chapter: SLO Implementation - Getting Buy-In - Key Stakeholders - Product
Problem
SLOs fail operationally when responders do not shape their use.
Action
Ask operations teams to define signals, alerts, and response policies.
Outcome
SLOs support practical incident response.
Chapter: SLO Implementation - Getting Buy-In - Key Stakeholders - Operations
Problem
Test coverage may not focus on the failures that matter to users.
Action
Use SLO journeys to prioritize reliability tests and release checks.
Outcome
QA effort protects important user outcomes.
Chapter: SLO Implementation - Getting Buy-In - Key Stakeholders - QA
Problem
Reliability language can create contractual or regulatory risk.
Action
Ask legal teams to review published targets and related commitments.
Outcome
SLO communication avoids unintended obligations.
Chapter: SLO Implementation - Getting Buy-In - Key Stakeholders - Legal
Problem
Executives may not support technical measures without clear business use.
Action
Explain how SLOs control risk, priorities, and investment.
Outcome
Leaders can support reliability work with informed decisions.
Chapter: SLO Implementation - Getting Buy-In - Key Stakeholders - Executive Leadership
Problem
Early broad rollout can fail before the method proves its value.
Action
Start with service owners, then involve affected decision-makers.
Outcome
Support grows from concrete evidence and clear ownership.
Chapter: SLO Implementation - Getting Buy-In - Making It So - Order of Operation
Problem
General promises rarely resolve stakeholder concerns about SLO adoption.
Action
Connect each objection to service data and a small practical response.
Outcome
Stakeholders can judge SLOs through relevant evidence.
Chapter: SLO Implementation - Getting Buy-In - Making It So - Common Objections and How to Overcome Them
Problem
Agreement on SLO ideas may disappear when decisions affect planned work.
Action
Create a simple error budget policy and apply it to a real case.
Outcome
The organization proves whether it will act on reliability data.
Chapter: SLO Implementation - Getting Buy-In - Making It So - Your First Error Budget Policy (and Your First Critical Test)
Problem
Large SLO programs often fail when they ignore local constraints.
Action
Pilot the process, learn from objections, and expand gradually.
Outcome
Adoption improves through evidence and adjustment.
Chapter: SLO Implementation - Getting Buy-In - Lessons Learned the Hard Way
Problem
SLO implementation stalls without support from affected groups.
Action
Align stakeholders on benefits, roles, and an initial policy.
Outcome
The first SLO has enough support to influence work.
Chapter: SLO Implementation - Getting Buy-In - Summary
Problem
Fixed measurement logic makes later SLO changes expensive.
Action
Separate event collection from target values and evaluation windows.
Outcome
Teams can revise targets without rebuilding instrumentation.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Design Goals - Flexible Targets
Problem
Calculation errors can silently produce false reliability results.
Action
Test SLO logic with known good, bad, and missing events.
Outcome
Teams can trust the reported SLO status.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Design Goals - Testable Targets
Problem
Delayed measurements prevent timely reliability decisions.
Action
Collect and evaluate SLI events within the required response time.
Outcome
SLO status reflects recent service behavior.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Design Goals - Freshness
Problem
A detailed SLI collection can consume excessive storage and processing.
Action
Choose the least costly data that still supports reliable decisions.
Outcome
SLO measurement remains affordable at the service scale.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Design Goals - Cost
Problem
Unreliable monitoring creates gaps and false SLO results.
Action
Design the SLI collection to survive failures in the measured service.
Outcome
Reliability decisions remain possible during incidents.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Design Goals - Reliability
Problem
Separate SLO systems increase cost and operational complexity.
Action
Build SLO calculations on trusted tools already used across the organization.
Outcome
Implementation becomes easier to operate and support.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Organizational Constraints - Common Machinery
Problem
High event volume can make detailed storage too expensive.
Action
Record counters and distributions with labels needed for SLO calculations.
Outcome
Teams can efficiently calculate SLOs from time-series data.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Organizational Constraints - Centralized Time Series Statistics (Metrics)
Problem
Aggregated metrics may hide the context needed for complex SLIs.
Action
Store consistent event fields that identify valid and successful outcomes.
Outcome
Teams can calculate and investigate detailed reliability results.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Organizational Constraints - Structured Event Databases (Logging)
Problem
Request success alone can hide experiences that are too slow.
Action
Count requests as good only when they succeed within the latency threshold.
Outcome
The SLI protects both correctness and response speed.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Common Cases - Latency-Sensitive Request Processing
Problem
Batch systems can process all work while delivering results too late.
Action
Track successful items that finish within the allowed processing lag.
Outcome
The SLI reflects useful batch delivery.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Common Cases - Low-Lag, High-Throughput Batch Processing
Problem
Server health cannot reveal all failures on mobile and web clients.
Action
Collect client signals for successful and timely user actions.
Outcome
SLOs include failures that occur outside the server.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Common Cases - Mobile and Web Clients
Problem
Unusual services may not fit standard request or batch patterns.
Action
Identify valid events and the conditions that make each event good.
Outcome
Any service can gain a clear reliability measure.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Common Cases - The General Case
Problem
Aggregate SLO data may show harm without revealing its cause.
Action
Attach trace identifiers or exemplars to failed SLI events.
Outcome
Engineers can move quickly from detection to diagnosis.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Other Considerations - Integration with Distributed Tracing
Problem
Hidden calculations prevent teams from understanding or trusting SLO results.
Action
Publish definitions, queries, owners, and dashboards in a known location.
Outcome
Teams can inspect and reuse reliability measurements.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Other Considerations - SLI and SLO Discoverability
Problem
SLOs fail when collection is rigid, costly, or unreliable.
Action
Design testable metrics that align with service patterns and existing tools.
Outcome
Teams receive dependable data for reliability decisions.
Chapter: SLO Implementation - Measuring SLIs and SLOs - Summary
Problem
Static metric thresholds create noise without measuring user impact.
Action
Alert on threats to the SLO rather than on isolated metric values.
Outcome
Responders focus on conditions that endanger reliability.
Chapter: SLO Implementation - SLO Monitoring and Alerting - Motivation: What Is SLO Alerting, and Why Should You Do It? - The Shortcomings of Simple Threshold Alerting
Problem
Teams need alerts that reflect both impact and urgency.
Action
Trigger alerts when failures consume error budget at a dangerous rate.
Outcome
Alerts connect response effort to user reliability risk.
Chapter: SLO Implementation - SLO Monitoring and Alerting - Motivation: What Is SLO Alerting, and Why Should You Do It? - A Better Way
Problem
Alert logic cannot be correct without a defined reliability objective.
Action
Select the SLO target and window before setting burn thresholds.
Outcome
Alert behavior follows the actual reliability commitment.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - Choosing a Target
Problem
A budget can disappear before responders have time to act.
Action
Set alert thresholds that leave enough budget for investigation and repair.
Outcome
Responders receive useful time to protect the SLO.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - Error Budgets and Response Time
Problem
Raw failure rates do not show how quickly the budget will run out.
Action
Compare the observed error rate with the error rate allowed by the SLO.
Outcome
Teams can judge the urgency of reliability loss.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - Error Budget Burn Rate
Problem
Fixed periods can delay or distort detection near their boundaries.
Action
Calculate burn continuously over recent short and long windows.
Outcome
Alerts respond consistently regardless of calendar boundaries.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - Rolling Windows
Problem
A single alert window cannot effectively detect both sudden and gradual failures.
Action
Use paired windows and burn thresholds for each response level.
Outcome
Alerting catches serious incidents without excessive noise.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - Putting It Together
Problem
An SLO alert identifies user harm but not its technical cause.
Action
Break failed events down by service dimensions and related telemetry.
Outcome
Responders can narrow the source of user impact.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - Troubleshooting with SLO Alerting
Problem
Low traffic and missing data can produce misleading burn calculations.
Action
Test alert behavior for sparse events, gaps, and sudden traffic changes.
Outcome
Alerts remain useful under unusual service conditions.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - Corner Cases
Problem
Replacing mature alerts at once can remove needed operational coverage.
Action
Run SLO alerts alongside current alerts and compare their usefulness.
Outcome
Teams can adopt better alerts without sudden coverage loss.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - SLO Alerting in a Brownfield Setup
Problem
Initial alert settings rarely match every service condition.
Action
Review alert performance after incidents and adjust the windows or thresholds as needed.
Outcome
SLO alerts become more timely and less noisy.
Chapter: SLO Implementation - SLO Monitoring and Alerting - How to Do SLO Alerting - Parting Recommendations
Problem
Metric noise can overwhelm responders without protecting users.
Action
Use tested burn rate alerts tied to error budget risk.
Outcome
Response effort focuses on meaningful SLO threats.
Chapter: SLO Implementation - SLO Monitoring and Alerting - Summary
Problem
Availability percentages can be misunderstood without a clear event model.
Action
Treat each valid request as a trial with success or failure.
Outcome
Availability becomes a measurable probability of user success.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - On Probability - SLI Example: Availability
Problem
A few events can make low-traffic reliability estimates unstable.
Action
Report sample size and uncertainty with the observed success ratio.
Outcome
Teams avoid strong conclusions from weak evidence.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - On Probability - SLI Example: Low QPS
Problem
Teams need a simple estimate of unknown reliability behavior.
Action
Choose the parameter value that makes the observed data most likely.
Outcome
The estimate follows the available evidence directly.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - On Statistics - Maximum Likelihood Estimation
Problem
Limited data may produce unstable estimates when used alone.
Action
Choose the most likely parameter after including a reasonable prior.
Outcome
Estimates remain useful when observations are sparse.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - On Statistics - Maximum a Posteriori
Problem
A single estimate hides uncertainty about service behavior.
Action
Use Bayesian inference to update a probability distribution with new data.
Outcome
Decisions reflect both uncertainty and accumulated evidence.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - On Statistics - Bayesian Inference
Problem
Queue delays vary and often have a long tail.
Action
Estimate the probability that queued work completes within its threshold.
Outcome
The SLI captures uncertainty in queueing performance.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - On Statistics - SLI Example: Queueing Latency
Problem
Batch averages can hide late items that affect users.
Action
Count items or jobs that finish before the required deadline.
Outcome
Batch reliability reflects timely completion.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - On Statistics - Batch Latency
Problem
Rare data loss is difficult to measure from ordinary observations.
Action
Model failure probabilities across storage copies and recovery paths.
Outcome
Durability estimates reflect the combined risk of permanent loss.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - On Statistics - SLI Example: Durability
Problem
Complex reliability estimates may exceed the scope of basic statistical methods.
Action
Study relevant probability methods before making high-impact assumptions.
Outcome
Advanced SLO decisions rest on stronger analysis.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - Further Reading
Problem
Reliability data varies in volume, shape, and uncertainty.
Action
Choose an estimation method that is appropriate for the service and sample size.
Outcome
SLI and SLO conclusions become more defensible.
Chapter: SLO Implementation - Probability and Statistics for SLIs and SLOs - Summary
Problem
A user request depends on several parts of an image service.
Action
Map the full image request path and its possible failures.
Outcome
Architecture work targets the parts that affect user success.
Chapter: SLO Implementation - Architecting for Reliability - Example System: Image-Serving Service
Problem
Hardware eventually fails or becomes unavailable.
Action
Provide enough redundant capacity to meet targets during expected failures.
Outcome
Normal hardware loss does not break the service SLO.
Chapter: SLO Implementation - Architecting for Reliability - Architectural Considerations: Hardware
Problem
Both monoliths and microservices create different failure and operating costs.
Action
Choose boundaries that match ownership, isolation, and dependency needs.
Outcome
Architecture supports reliability without needless complexity.
Chapter: SLO Implementation - Architecting for Reliability - Architectural Considerations: Monolith or Microservices
Problem
Unplanned failures expose architectural weaknesses during real incidents.
Action
Identify likely failures and design detection, isolation, and recovery paths.
Outcome
The system handles expected failures more safely.
Chapter: SLO Implementation - Architecting for Reliability - Architectural Considerations: Anticipating Failure Modes
Problem
Different request types may need different reliability and latency treatment.
Action
Classify requests by their work, urgency, and failure effect.
Outcome
Each request path receives suitable reliability controls.
Chapter: SLO Implementation - Architecting for Reliability - Architectural Considerations: Three Types of Requests
Problem
Weak foundational components limit the reliability of the whole system.
Action
Choose storage, queues, caches, and compute systems with known behavior.
Outcome
The architecture starts from understood reliability properties.
Chapter: SLO Implementation - Architecting for Reliability - Systems and Building Blocks
Problem
Component targets do not directly reveal end-user reliability.
Action
Model how serial, parallel, and redundant components combine.
Outcome
Architectural choices can be tested against the service SLO.
Chapter: SLO Implementation - Architecting for Reliability - Quantitative Analysis of Systems
Problem
A reliable design cannot be verified without observations.
Action
Add measurements for user outcomes, components, and dependencies.
Outcome
Teams can confirm reliability and diagnose failures.
Chapter: SLO Implementation - Architecting for Reliability - Instrumentation! The System Also Needs Instrumentation!
Problem
Later architectural choices can change hardware capacity and redundancy needs.
Action
Recalculate hardware requirements after defining traffic and failure paths.
Outcome
Infrastructure matches the completed reliability design.
Chapter: SLO Implementation - Architecting for Reliability - Architectural Considerations: Hardware, Revisited
Problem
A target may be impossible when component behavior cannot support it.
Action
Combine measured system SLIs to estimate achievable service reliability.
Outcome
The SLO reflects what the architecture can deliver.
Chapter: SLO Implementation - Architecting for Reliability - SLOs as a Result of System SLIs
Problem
Unknown dependencies create hidden paths to user failure.
Action
Record each dependency, its limits, owner, and failure behavior.
Outcome
Teams can manage external risks before incidents occur.
Chapter: SLO Implementation - Architecting for Reliability - The Importance of Identifying and Understanding Dependencies
Problem
Architecture cannot support reliability that it was not designed to deliver.
Action
Model failures, dependencies, capacity, and measurements against target outcomes.
Outcome
The system has a credible path to its SLO.
Chapter: SLO Implementation - Architecting for Reliability - Summary
Problem
Available infrastructure does not guarantee useful or correct data.
Action
Design data flows around the results that consumers need.
Outcome
Data systems support dependable application behavior.
Chapter: SLO Implementation - Data Reliability - Data Services - Designing Data Applications
Problem
Data systems often serve people, applications, and downstream pipelines differently.
Action
List each consumer and the data outcomes they require.
Outcome
Reliability measures cover distinct consumer needs.
Chapter: SLO Implementation - Data Reliability - Users of Data Services
Problem
Good data can still be delivered through an unreliable application.
Action
Set distinct objectives for data quality and application behavior.
Outcome
Teams can identify which layer failed its users.
Chapter: SLO Implementation - Data Reliability - Setting Measurable Data Objectives - Data and Data Application Reliability
Problem
Data availability alone does not ensure that data is useful.
Action
Measure accuracy, completeness, freshness, and consistency where users need them.
Outcome
Objectives protect the qualities that make data usable.
Chapter: SLO Implementation - Data Reliability - Setting Measurable Data Objectives - Data Properties
Problem
Reliable data does not prevent slow or failed data applications.
Action
Track application availability, latency, correctness, and throughput.
Outcome
Users receive dependable access to useful data.
Chapter: SLO Implementation - Data Reliability - Setting Measurable Data Objectives - Data Application Properties
Problem
Retries and partial processing can corrupt or duplicate data results.
Action
Design idempotency, validation, checkpoints, and recovery for failure paths.
Outcome
Applications recover without creating unreliable data.
Chapter: SLO Implementation - Data Reliability - System Design Concerns - Data Application Failures
Problem
A reliable system can still be insecure, costly, or hard to maintain.
Action
Review reliability decisions besides security, privacy, cost, and operability.
Outcome
Data systems remain useful beyond reliability alone.
Chapter: SLO Implementation - Data Reliability - System Design Concerns - Other Qualities
Problem
Teams cannot assess impact when the origins and transformations of the data are unknown.
Action
Record where data comes from and how each system changes it.
Outcome
Failures can be traced to affected data and consumers.
Chapter: SLO Implementation - Data Reliability - Data Lineage
Problem
Data users depend on both trustworthy data and dependable applications.
Action
Measure data properties, application behavior, and lineage together.
Outcome
Teams can manage complete data service reliability.
Chapter: SLO Implementation - Data Reliability - Summary
Problem
Growth changes traffic, users, dependencies, and the impact of failures.
Action
Review service boundaries and SLOs at each major growth stage.
Outcome
Reliability practices scale with the service.
Chapter: SLO Implementation - A Worked Example - Dogs Deserve Clothes - How a Service Grows
Problem
Component-based design can miss complete customer outcomes.
Action
Map service components to the journeys they must support.
Outcome
Architecture and reliability measures protect real service use.
Chapter: SLO Implementation - A Worked Example - Dogs Deserve Clothes - The Design of a Service
Problem
Customers cannot buy products they cannot reliably find or inspect.
Action
Measure successful searches, listings, and product page views.
Outcome
SLOs protect the browsing steps that lead to purchases.
Chapter: SLO Implementation - A Worked Example - SLIs and SLOs as User Journeys - Customers: Finding and Browsing Products
Problem
A purchase fails when internal service calls do not complete correctly.
Action
Define SLIs for the service interactions required to buy products.
Outcome
Reliability covers machine users within the purchase journey.
Chapter: SLO Implementation - A Worked Example - SLIs and SLOs as User Journeys - Other Services as Users: Buying Products
Problem
Employee tools can fail even when customer paths appear healthy.
Action
Define SLIs for important internal tasks and workflows.
Outcome
SLOs support the people who operate the business.
Chapter: SLO Implementation - A Worked Example - SLIs and SLOs as User Journeys - Internal Users
Problem
Shared platforms affect many services through common capabilities.
Action
Measure platform outcomes from the view of internal service consumers.
Outcome
Platform reliability reflects the needs of dependent teams.
Chapter: SLO Implementation - A Worked Example - SLIs and SLOs as User Journeys - Platforms as Services
Problem
A service can overlook customers, internal users, or dependent systems.
Action
Map each user journey to a small set of measurable outcomes.
Outcome
SLO coverage reflects the complete service ecosystem.
Chapter: SLO Implementation - A Worked Example - Summary
Problem
Without SLOs, reliability decisions depend on opinions and urgent events.
Action
Document cases where unclear targets caused waste or conflict.
Outcome
Teams see why shared reliability standards are needed.
Chapter: SLO Culture - Building an SLO Culture - A Culture of No SLOs
Problem
A large policy change can trigger resistance before value is visible.
Action
Use pilots, evidence, and local champions to expand SLO use.
Outcome
Reliability practices spread through demonstrated value.
Chapter: SLO Culture - Building an SLO Culture - Strategies for Shifting Culture
Problem
Abstract SLO proposals may not earn stakeholder attention.
Action
Connect the first SLO effort to a visible reliability pain.
Outcome
Stakeholders understand the immediate reason to participate.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - Getting Buy-in
Problem
SLO tasks disappear when feature work always takes priority.
Action
Place SLO implementation in normal planning with owners and deadlines.
Outcome
Reliability work receives sustained attention.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - Prioritizing SLO Work
Problem
Broad implementation can delay practical learning.
Action
Build measurement, reporting, and policy for one important journey.
Outcome
The team gains a working example to improve and expand.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - Implementing Your SLO
Problem
Available metrics may not represent what users need.
Action
Define good events for the service's most important journeys.
Outcome
SLIs measure meaningful service quality.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - What Will Your SLIs Be?
Problem
Targets lose trust when they are arbitrary or impossible.
Action
Use user needs and past performance to set initial objectives.
Outcome
SLOs provide credible standards for decisions.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - What Will Your SLOs Be?
Problem
An SLO has no value when teams only display it.
Action
Use error budget status during releases, planning, and incident reviews.
Outcome
Reliability data changes actual team behavior.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - Using Your SLO
Problem
Initial SLOs contain assumptions that real use may disprove.
Action
Review results and adjust definitions, targets, or policies.
Outcome
SLOs become better matched to service needs.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - Iterating on Your SLO
Problem
Teams can delay adoption while seeking perfect SLO definitions.
Action
Accept an SLO once it reliably supports useful decisions.
Outcome
The organization gains value without endless refinement.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - Determining When Your SLOs Are Good Enough
Problem
A single successful team cannot create an organization-wide culture of reliability.
Action
Share examples, tools, and direct support with interested teams.
Outcome
SLO practices spread through practical assistance.
Chapter: SLO Culture - Building an SLO Culture - Path to a Culture of SLOs - Advocating for Others to Use SLOs
Problem
Policies alone cannot make reliability data part of normal work.
Action
Build, use, improve, and share SLOs through real services.
Outcome
SLO-based decisions become an organizational habit.
Chapter: SLO Culture - Building an SLO Culture - Summary
Problem
Waiting for a perfect design prevents teams from learning.
Action
Set a reasonable first target with available user-centered data.
Outcome
The team gains a baseline for future improvement.
Chapter: SLO Culture - SLO Evolution - SLO Genesis - The First Pass
Problem
Service data may not reveal whether targets match user expectations.
Action
Gather user feedback about failures, delays, and important journeys.
Outcome
SLOs reflect observed user needs more closely.
Chapter: SLO Culture - SLO Evolution - SLO Genesis - Listening to Users
Problem
Targets can become stale without a planned review.
Action
Set regular dates to examine performance, use, and user expectations.
Outcome
SLOs evolve before they lose relevance.
Chapter: SLO Culture - SLO Evolution - SLO Genesis - Periodic Revisits
Problem
Higher usage can expose capacity limits and impact new users.
Action
Review indicators and targets when traffic or workload increases.
Outcome
SLOs account for the reliability effects of growth.
Chapter: SLO Culture - SLO Evolution - Usage Changes - Increased Utilization Changes
Problem
Lower use can change sample quality and business importance.
Action
Review measurement windows and targets when workload decreases.
Outcome
SLOs remain meaningful under reduced activity.
Chapter: SLO Culture - SLO Evolution - Usage Changes - Decreased Utilization Changes
Problem
New user behavior can make existing journeys and measures incomplete.
Action
Revise SLIs when users adopt different service functions.
Outcome
Reliability coverage follows actual service use.
Chapter: SLO Culture - SLO Evolution - Usage Changes - Functional Utilization Changes
Problem
A changed dependency can alter achievable service reliability.
Action
Measure its new behavior and recalculate service risk.
Outcome
SLOs reflect the current dependency chain.
Chapter: SLO Culture - SLO Evolution - Dependency Changes - Service Dependency Changes
Problem
Platform migrations can change performance and failure behavior.
Action
Compare SLI results before and after the platform change.
Outcome
Teams detect whether targets or architecture need adjustment.
Chapter: SLO Culture - SLO Evolution - Dependency Changes - Platform Changes
Problem
Adding or removing dependencies changes service failure paths.
Action
Revise journey maps, measurements, and reliability calculations.
Outcome
SLO design matches the current architecture.
Chapter: SLO Culture - SLO Evolution - Dependency Changes - Dependency Introduction or Retirement
Problem
Incidents can reveal incorrect assumptions in existing reliability targets.
Action
Use failure evidence to revise indicators, targets, or policies.
Outcome
Future SLO decisions account for learned failure behavior.
Chapter: SLO Culture - SLO Evolution - Failure-Induced Changes -
Problem
Users may expect better performance after service improvements.
Action
Monitor feedback and behavior for shifts in tolerated failure.
Outcome
SLOs stay aligned with current user expectations.
Chapter: SLO Culture - SLO Evolution - User Expectation and Requirement Changes - User Expectation Changes
Problem
Formal user needs can change the minimum acceptable service level.
Action
Revise objectives when contracts, policies, or critical workflows change.
Outcome
Reliability targets satisfy current user requirements.
Chapter: SLO Culture - SLO Evolution - User Expectation and Requirement Changes - User Requirement Changes
Problem
New tools or instrumentation can change reported SLI values.
Action
Compare old and new measurements before adopting the replacement.
Outcome
Tool changes do not create false reliability trends.
Chapter: SLO Culture - SLO Evolution - Tooling Changes - Measurement Changes
Problem
Calculation changes can alter results without any change to the service.
Action
Run old and new formulas on the same data.
Outcome
Teams understand and explain differences in reported reliability.
Chapter: SLO Culture - SLO Evolution - Tooling Changes - Calculation Changes
Problem
Experienced judgment can still misread user needs or service behavior.
Action
Treat intuition as a hypothesis and check it against evidence.
Outcome
SLO changes rely on verified observations.
Chapter: SLO Culture - SLO Evolution - Intuition-Based Changes
Problem
An ambitious target can create confusion when the service cannot meet it.
Action
Label aspirational SLOs clearly and pair them with improvement plans.
Outcome
Teams can improve reliability without making false commitments.
Chapter: SLO Culture - SLO Evolution - Setting Aspirational SLOs
Problem
A passing SLO can coexist with unhappy users.
Action
Compare SLO status with complaints, surveys, and observed behavior.
Outcome
Teams find targets that misrepresent user experience.
Chapter: SLO Culture - SLO Evolution - Identifying Incorrect SLOs - Listening to Users (Redux)
Problem
Serious incidents may not consume budget when an SLO is poorly defined.
Action
Check whether each meaningful failure appears in SLI results.
Outcome
SLOs become more sensitive to real user harm.
Chapter: SLO Culture - SLO Evolution - Identifying Incorrect SLOs - Paying Attention to Failures
Problem
Unplanned reviews happen only after targets become harmful.
Action
Set review frequency according to service change and risk.
Outcome
SLO updates occur predictably and with clear evidence.
Chapter: SLO Culture - SLO Evolution - How to Change SLOs - Revisit Schedules
Problem
Static SLOs become inaccurate as services and users change.
Action
Review targets after scheduled intervals and meaningful events.
Outcome
SLOs remain useful throughout the service lifecycle.
Chapter: SLO Culture - SLO Evolution - Summary
Problem
A target is hard to trust without its full meaning and source.
Action
Document the service, users, SLI, target, window, owner, and policy.
Outcome
Readers can understand and verify the SLO.
Chapter: SLO Culture - Discoverable and Understandable SLOs - Understandability - SLO Definition Documents
Problem
Vague or inconsistent terms cause different SLO interpretations.
Action
Describe valid events, good events, and targets in plain language.
Outcome
Stakeholders share the same understanding of reliability.
Chapter: SLO Culture - Discoverable and Understandable SLOs - Understandability - Phraseology
Problem
Scattered definitions make SLOs difficult to find and maintain.
Action
Place SLO documents in a known searchable repository.
Outcome
Teams can quickly locate current reliability definitions.
Chapter: SLO Culture - Discoverable and Understandable SLOs - Discoverability - Document Repositories
Problem
A document repository may not clearly expose ownership or service relationships.
Action
Provide searchable indexes for SLOs, services, owners, and dependencies.
Outcome
People can find relevant SLO information more easily.
Chapter: SLO Culture - Discoverable and Understandable SLOs - Discoverability - Discoverability Tooling
Problem
Stakeholders cannot act on reliability trends they never see.
Action
Report target status, budget use, incidents, and planned responses.
Outcome
Reliability performance informs shared decisions.
Chapter: SLO Culture - Discoverable and Understandable SLOs - Discoverability - SLO Reports
Problem
Crowded dashboards hide the signals needed for reliability decisions.
Action
Display SLI performance, target, error budget, and recent burn.
Outcome
Teams can quickly understand current SLO health.
Chapter: SLO Culture - Discoverable and Understandable SLOs - Discoverability - Dashboards
Problem
Hidden or confusing SLOs cannot guide organization-wide behavior.
Action
Publish plain definitions, reports, and dashboards in shared locations.
Outcome
Stakeholders can understand and use reliability information.
Chapter: SLO Culture - Discoverable and Understandable SLOs - Summary
Problem
A generic SLO program may ignore local needs and obstacles.
Action
Study current reliability problems, tools, teams, and decision processes.
Outcome
Advocacy begins with relevant evidence.
Chapter: SLO Culture - SLO Advocacy - Crawl - Do Your Research
Problem
Stakeholders may not support SLOs without a clear local benefit.
Action
Explain the problem, proposed pilot, expected value, and required effort.
Outcome
Decision makers can evaluate a concrete proposal.
Chapter: SLO Culture - SLO Advocacy - Crawl - Prepare Your Sales Pitch
Problem
People need reusable guidance after an advocacy conversation ends.
Action
Prepare examples, templates, diagrams, and frequently asked questions.
Outcome
Teams can more easily understand and begin SLO work.
Chapter: SLO Culture - SLO Advocacy - Crawl - Create Your Supporting Artifacts
Problem
Presentations alone do not build practical SLO skills.
Action
Guide participants through defining an SLI, an SLO, and an error budget.
Outcome
Participants leave with direct implementation experience.
Chapter: SLO Culture - SLO Advocacy - Crawl - Run Your First Training and Workshop
Problem
A broad launch creates risk before the process is proven.
Action
Implement a complete SLO workflow for one suitable service.
Outcome
The organization gains evidence and lessons from real use.
Chapter: SLO Culture - SLO Advocacy - Crawl - Implement an SLO Pilot with a Single Service
Problem
One announcement cannot reach every team or change habits.
Action
Use several communication channels to repeat practical SLO benefits.
Outcome
More people learn when and why to use SLOs.
Chapter: SLO Culture - SLO Advocacy - Crawl - Spread Your Message
Problem
Objections and implementation problems can stop early SLO efforts.
Action
Collect common challenges and prepare evidence-based responses.
Outcome
Advocates can keep pilots moving through resistance.
Chapter: SLO Culture - SLO Advocacy - Crawl - Learn How to Handle Challenges
Problem
Central advocates cannot implement SLOs for every service alone.
Action
Support willing teams in building SLOs for additional services.
Outcome
Adoption grows through local ownership and practical examples.
Chapter: SLO Culture - SLO Advocacy - Walk - Work with Early Adopters to Implement SLOs for More Services
Problem
Teams may lose interest when early reliability work goes unnoticed.
Action
Share specific examples where SLOs improved a decision or outcome.
Outcome
Visible success builds confidence in the practice.
Chapter: SLO Culture - SLO Advocacy - Walk - Celebrate Achievements and Build Confidence
Problem
Future teams need proof that SLOs work in similar situations.
Action
Document each service problem, implementation, decision, and result.
Outcome
Advocates gain reusable evidence for new adopters.
Chapter: SLO Culture - SLO Advocacy - Walk - Create a Library of Case Studies
Problem
One trainer limits how quickly SLO knowledge can spread.
Action
Teach experienced adopters to run the standard training program.
Outcome
More teams can receive practical SLO instruction.
Chapter: SLO Culture - SLO Advocacy - Walk - Scale Your Training Program by Adding More Trainers
Problem
Informal messages cannot support a growing adoption program.
Action
Create regular channels for updates, guidance, and questions.
Outcome
Reliable information reaches a wider organization.
Chapter: SLO Culture - SLO Advocacy - Walk - Scale Your Communications
Problem
Local SLO successes provide little value when other teams cannot find them.
Action
Publish and promote case studies through shared organizational channels.
Outcome
Teams can learn from proven SLO applications.
Chapter: SLO Culture - SLO Advocacy - Run - Share Your Library of SLO Case Studies
Problem
Distributed adopters need ongoing help beyond central training.
Action
Connect experienced practitioners for advice, review, and shared learning.
Outcome
SLO knowledge becomes available across the organization.
Chapter: SLO Culture - SLO Advocacy - Run - Create a Community of SLO Experts
Problem
Training and guidance become stale as adoption and needs change.
Action
Collect feedback and update materials, tools, and support methods.
Outcome
The program stays useful as SLO practice grows.
Chapter: SLO Culture - SLO Advocacy - Run - Continuously Improve
Problem
SLO adoption cannot scale through isolated promotion.
Action
Prove value, support adopters, train advocates, and share results.
Outcome
The organization develops lasting SLO capability.
Chapter: SLO Culture - SLO Advocacy - Summary
Problem
Incident totals are misleading when teams use different definitions.
Action
Define an incident clearly and count it using a single process.
Outcome
Reports show a comparable record of service disruption.
Chapter: SLO Culture - Reliability Reporting - Basic Reporting - Counting Incidents
Problem
Incident counts treat minor problems and major harm as equal.
Action
Assign severity based on user impact, scope, and duration.
Outcome
Reports distinguish events by their real importance.
Chapter: SLO Culture - Reliability Reporting - Basic Reporting - Severity Levels
Problem
Averages hide variation and encourage misleading comparisons.
Action
Report distributions and user impact besides time-based incident measures.
Outcome
Reliability reports describe incidents more accurately.
Chapter: SLO Culture - Reliability Reporting - Basic Reporting - The Problem with Mean Time to X
Problem
Incident statistics do not show whether service targets were met.
Action
Report incident data with SLI performance and SLO compliance.
Outcome
Basic reporting connects events to reliability objectives.
Chapter: SLO Culture - Reliability Reporting - Basic Reporting - SLOs for Basic Reporting
Problem
Stakeholders need a simple view of target performance.
Action
Show whether each SLO meets its target within its window.
Outcome
Readers can identify services with reliability problems.
Chapter: SLO Culture - Reliability Reporting - Advanced Reporting - SLO Status
Problem
SLO status alone does not show how much risk remains.
Action
Show budget consumed, budget remaining, and current burn rate.
Outcome
Stakeholders can adjust plans before the budget is exhausted.
Chapter: SLO Culture - Reliability Reporting - Advanced Reporting - Error Budget Status
Problem
Isolated operational metrics cannot support complete reliability decisions.
Action
Combine incidents, severity, SLO status, and error budget status.
Outcome
Reports give stakeholders a practical view of reliability risk.
Chapter: SLO Culture - Reliability Reporting - Summary