SLI, SLO, SLA: making reliability measurable on Azure
Tom, a platform engineer, is in a meeting when the business puts its demand on the table: the data platform should be 99.9% available. Rather than challenge the number with technical terms, Tom asks: "What do you rely on the platform to deliver, and when do you need it?"
"The finance report needs to be ready by 07:00 so the team can make its daily decisions," the business explains. Tom follows up: "And what happens if it's late, or the numbers aren't up to date?" The answer makes the real need clear: a running cluster is not enough. The report must be available on time, with data fresh enough to trust.
When a data platform becomes business critical, "it somehow runs" stops being enough. The business wants to know: when is the data there, how reliable are the pipelines, can I trust the numbers, and how fast are the reports? This is where service level indicators (SLIs), service level objectives (SLOs) and service level agreements (SLAs) come in, ideally combined with error budgets and good visualization in Azure.
An SLI is what you measure, an SLO is your internal target, and an SLA is what you promise. Keep the SLO stricter than the SLA, and use the error budget to decide when to focus more on reliability.