SLOs, SLIs e métricas de confiabilidade

Nível: B2

Objetivo

Discutir SLOs, SLIs e métricas de confiabilidade em inglês com linguagem operacional clara: distinguir SLO, SLI e SLA; definir availability targets e latency percentiles (p50, p95, p99); gerenciar o error budget e o burn rate; e combater alert fatigue definindo alertas úteis em vez de alertas barulhentos.

Explicação

Em conversas maduras de SRE e plataforma, três siglas aparecem o tempo todo: SLI, SLO e SLA. Confundi-las é um sinal clássico de quem ainda não participou de uma reliability review, e o custo de confundir é alto — porque cada uma implica um compromisso diferente.

1. SLI, SLO e SLA

• SLI (Service Level Indicator) é a métrica bruta que observamos. Não é um objetivo, é o número. Exemplos: `availability`, `error rate`, `p95 latency`.
• *The SLI for availability is the ratio of successful requests to total requests.*
• *We picked three SLIs: availability, latency, and error rate.*

• SLO (Service Level Objective) é o alvo numérico que a equipe se compromete a manter. É a parte que entra em alerta e em postmortem.
• *Our SLO is 99.9% successful requests per month.*
• *If the SLO is 99.9%, the error budget is 0.1%, which is roughly 43 minutes of downtime per month.*

• SLA (Service Level Agreement) é o compromisso contratual com o cliente, normalmente com crédito ou penalidade. O SLO costuma ser mais rígido que o SLA, porque a equipe quer folga antes de chegar no ponto em que paga caro.
• *The SLA is 99.5%, but our internal SLO is 99.9%, so we have a buffer.*
• *We never let the SLO slip below the SLA, or we start paying credits.*

A frase-modelo B2 para apresentar os três juntos é: *We measure X as the SLI, we target Y as the SLO, and we promise Z in the SLA.*

2. Availability target

Availability é a fração do tempo em que o sistema responde corretamente. O target é o número que a equipe promete manter: 99.9% (three nines), 99.95%, 99.99% (four nines), e assim por diante. Cada nove adicional corta o error budget em dez vezes:

Não defina availability como `the system is up`. Defina como `the ratio of successful responses to total responses over a rolling window` — porque up não é o mesmo que correto, e o SLO mede correção, não processo.

• *We define availability as the share of 2xx and 3xx responses, not as uptime of the pod.*
• *Our availability target is 99.9% over a rolling 30-day window.*

3. Latency percentile

Latência é traiçoeira com a média: um p99 de 4s com média de 200ms significa que 1% dos usuários está esperando 4 segundos, e esses são, geralmente, os usuários que mais precisam de velocidade (compra, checkout, login). Por isso SLOs de latência são quase sempre definidos em percentis:

• p50 (mediana): experiência do usuário típico. *p50 latency is 80ms, which feels fast.*
• p95: usuário lento, mas ainda dentro do tolerável. *p95 latency is 250ms, which is acceptable for the search page.*
• p99: pior caso realista, usado para SLOs rígidos. *p99 latency is 800ms, which is our hard SLO.*
• p99.9 (tail): o caso extremo, usado em serviços de pagamento. *p99.9 is 2 seconds, which only happens on cold starts.*

A frase B2 para definir um SLO de latência cita percentil + threshold + janela: *Our SLO is that 95% of requests complete in under 300ms over a rolling 30-day window.* Sem percentil, sem janela, o SLO não é comparável.

4. Error budget e burn rate

O error budget é a margem de falha permitida dentro do SLO: `1 - SLO`. Se o SLO é 99.9%, o error budget é 0.1% das requisições, ou ~43 minutos de requests falhando por mês.

O burn rate é a velocidade com que estamos consumindo esse budget. Se o SLO é 99.9% e estamos a 99% em uma hora, estamos queimando o budget dez vezes mais rápido do que o sustentável — é o sinal clássico de que algo precisa ser feito agora, não no postmortem.

• *We burned the error budget in the first week, so we froze deploys for the rest of the month.*
• *The current burn rate is 14x, which means at this pace the budget is gone in two days.*
• *A high burn rate is a signal to act, not a signal to wait for the monthly report.*

A frase B2 para discutir budget cita causa + consequência + ação: *We burned 30% of the budget in one hour because of the new deploy, so we rolled it back and paused releases until the SLO recovers.*

5. Alert fatigue

Alert fatigue é o que acontece quando a equipe recebe tantos alertas de baixa qualidade que começa a ignorar todos, inclusive os importantes. É o equivalente operacional de `the boy who cried wolf`.

Os culpados típicos:

• Alertas que disparam em qualquer anomalia, sem threshold útil. *We used to alert on every CPU blip, which fired 200 times a day.*
• Alertas que não têm ação clara ligada a eles. *If the alert doesn't say what to do, the team will mute it.*
• Alertas de latência média em vez de percentile. *Average latency hides the problem; p99 is what pages.*
• Alertas em série que todos acordam a mesma pessoa. *Four alerts for the same incident should be one alert.*

A frase B2 para defender uma mudança de política de alertas cita sintoma + impacto + ação concreta: *We had 47 paging alerts last month, and 90% were noise, so the on-call stopped trusting the page, which means we need to alert only on SLO burn rate above 2x for ten minutes.*

6. Discutindo operação com linguagem clara

Em uma reliability review, frases B2 evitam jargão solto e sempre ligam métrica → target → ação:

• Em vez de `we are unhealthy`, prefira `we are at 99.7% against a 99.9% SLO, with a burn rate of 6x`.
• Em vez de `latency is bad`, prefira `p99 latency is 1.2s against a 500ms SLO, mostly on the checkout path`.
• Em vez de `we are alerting too much`, prefira `we are firing 30 paging alerts a day, and only two required action last month`.
• Em vez de `we have headroom`, prefira `we are 0.05% above SLO with 12 days left in the window, which is comfortable`.

A qualidade da discussão em B2 é medida por quão pouco se precisa explicar depois: o número, o threshold, a janela e a ação esperada devem estar todos na mesma frase.

Exemplos

Erros comuns

• Confundir SLI com SLO: SLI é a métrica, SLO é o alvo. Dizer *our SLI is 99.9%* está errado; diga *our SLO is 99.9%, measured by the availability SLI*.
• Definir SLO sem janela de tempo: *we want 99.9%* não é comparável. Sempre cite a janela (rolling 30-day, monthly, weekly) ao lado do número.
• Usar média em vez de percentile para latência: a média esconde os piores casos. Em SLO de latência, use p95 ou p99, e nomeie o percentil na frase.
• Definir availability como uptime do pod: uptime não é correção. Um pod pode estar up e retornando 500; o SLO mede correção, não processo.
• Tratar o error budget como abstração: *we have an error budget* sem citar quanto já foi queimado e em quanto tempo. Em revisão B2, o número e a janela são obrigatórios.
• Alertar em qualquer anomalia: se o alerta não tem threshold numérico e ação clara, ele é ruído. Paging alert só dispara em violação de SLO com consequência definida.
• Não diferenciar burn rate de erro total: estar abaixo do SLO por pouco agora pode ser menos urgente do que estar no target mas queimando rápido. Em reliability review, cite sempre os dois.
• Acumular alertas no mesmo incidente: dez alertas para o mesmo problema são um problema. Combine em uma página ou um dashboard antes de acordar a equipe.
• Esquecer o SLA: o SLO pode ser mais rígido que o SLA, mas se o SLO está abaixo do SLA, a empresa está pagando créditos. Em review de operação, cite os dois para alinhar prioridades.

Prática guiada

Reescreva cada bloco seguindo o padrão B2 para reliability review: métrica → target → burn rate → ação.

1. Métrica + target

`We want the service to be reliable.` → `We are targeting 99.9% availability over a rolling 30-day window, measured by the ratio of successful responses.`

1. Percentil em vez de média

`Latency is around 300ms.` → `p95 latency is 280ms and p99 latency is 850ms, against a 500ms p99 SLO.`

1. Burn rate + janela

`We are below SLO.` → `We are at 99.7% against a 99.9% SLO, with a burn rate of 6x and 12 days left in the window.`

1. Causa + impacto + ação no budget

`We used a lot of the error budget.` → `We burned 30% of the error budget in one hour because of the new deploy, so we rolled it back and froze releases until the SLO recovers.`

1. Política de alertas

`We are getting too many alerts.` → `We had 47 paging alerts last month, 90% were noise, so we now alert only on burn rate above 2x for ten minutes, which cut paging volume by 80%.`

Repare que cada frase cita um número, um threshold e uma consequência. É isso que transforma opinião em reliability review.

Resumo

SLI é a métrica observada (availability, error rate, latency); SLO é o alvo numérico (ex: 99.9% de requisições com sucesso); SLA é o compromisso contratual com o cliente, normalmente mais frouxo que o SLO. Availability target se calcula em uma janela de tempo (rolling 30-day) e o error budget é `1 - SLO`. Latency SLOs quase sempre usam percentis (p50, p95, p99, p99.9) — média esconde os piores casos. O burn rate mede a velocidade de consumo do budget; burn rate alto é sinal de ação imediata. Alert fatigue aparece quando a equipe recebe muitos alertas inúteis e começa a ignorar todos; a cura é alertar apenas em violação de SLO com threshold numérico e ação clara, combinando alertas do mesmo incidente. Em reliability review B2, prefira frases que citam métrica + target + burn rate + ação em vez de adjetivos vagos como `bad` ou `unhealthy`.

História: SLOs, SLIs e métricas de confiabilidade

Nível: B2

História em inglês

The Monday SLO review

On Monday morning, the platform team opened the monthly SLO review for the checkout service. The SLO was 99.9% successful requests over a rolling 30-day window, and the team needed to know if they were still inside the budget. Lena, the SRE lead, started by pulling the availability SLI, which had landed at 99.82% for the previous 30 days. That number was below the 99.9% target, and the team could already see that the error budget was almost gone. But Lena wanted to look beyond the monthly number, because the monthly number hides what really happened.

Reading the burn rate

She opened the burn rate dashboard, which shows how fast the team is consuming the error budget, not just how much is left. The first week of the month had been quiet, with a burn rate close to 1x, which is sustainable. But on the eighth, a deploy had pushed the burn rate to 14x for about three hours, which alone had consumed almost a third of the budget. By the end of week two, the team had burned 60% of the error budget, and they were only halfway through the window. "This is the part the leadership does not see," Lena said, "because the monthly report only shows we are below SLO, not how fast we got there."

The latency percentile

Then the team turned to latency, where the average looked fine, around 180ms, but the percentiles told a different story. p50 was 160ms, which felt fast to most users, and p95 was 320ms, which was still inside the SLO. But p99 was 1.4 seconds, well above the 500ms SLO, and almost all of that tail was on the payment confirmation path. "Average latency hides the problem," said Marco, the backend lead. "The user who waits 1.4 seconds is the user who is paying us." Lena agreed that the team needed an SLO on p99, not just on p95, because the worst 1% was the part the business actually felt.

The alert fatigue problem

After the metrics, the team reviewed the on-call experience, which had been rough for weeks. The paging system was firing 30 alerts a day, and the on-call engineer admitted that she had started muting notifications by reflex. Most of those alerts were for things that did not actually violate the SLO, like small CPU blips and short queue spikes. "When everything is an alert, nothing is an alert," Marco said, and Lena nodded. The team agreed that the next step was to alert only on SLO burn rate above 2x for ten minutes, which would cut paging volume by 80%.

Closing the review

At the end of the meeting, Lena summarized the situation in three numbers, which is how she always closes a review. Number one: availability was 99.82% against a 99.9% SLO, with 14 days left in the window and 40% of the error budget remaining. Number two: p99 latency was 1.4s against a 500ms SLO, and the fix for the payment confirmation path was the top priority for the next sprint. Number three: the on-call was receiving 30 paging alerts a day, and the team would cut that to 6 by switching to burn rate alerts above 2x for ten minutes. Approved by the EM, the action items went into the shared doc, and Lena left the room knowing exactly what would happen, when, and why.

Tradução linha por linha

Notas de vocabulário

• the monthly SLO review for the checkout service = SLO review = reunião recorrente para auditar aderência ao SLO; geralmente mensal.
• the error budget was almost gone = error budget = margem de falha permitida dentro do SLO; quase gone = risco de SLO violation.
• a burn rate close to 1x, which is sustainable = burn rate 1x = consumir o orçamento exatamente no fim da janela; sustentável.
• pushed the burn rate to 14x for about three hours = burn rate 14x = consumir o orçamento 14 vezes mais rápido; situação de incidente.
• the monthly report only shows we are below SLO, not how fast we got there = report mensal mostra estado final; burn rate mostra a velocidade — o segundo é o que importa para ação.
• p99 was 1.4 seconds, well above the 500ms SLO = p99 = percentil 99; cite contra o SLO para tornar a violação comparável.
• The user who waits 1.4 seconds is the user who is paying us = cauda longa do percentil = usuários de alto valor; business stake em SLO de p99.
• small CPU blips and short queue spikes = blip = pico curto de métrica; spike = subida mais longa; ambos comuns como ruído em alertas.
• When everything is an alert, nothing is an alert = princípio central do alert fatigue: muitos alertas inúteis apagam o sinal.
• burn rate above 2x for ten minutes = política B2: threshold numérico (2x) + duração (10 min) + ação (paging).
• with 14 days left in the window and 40% of the error budget remaining = report B2: número + target + janela restante + budget restante, todos na mesma frase.
• the fix for the payment confirmation path was the top priority = path = caminho de código; "top priority for the next sprint" amarra a métrica ao roadmap.

Perguntas de compreensão

1. What SLO was the team reviewing for the checkout service?
2. What was the availability SLI for the previous 30 days, and how did it compare to the SLO?
3. Why was Lena interested in the burn rate, not just the monthly availability number?
4. What event pushed the burn rate to 14x, and how long did it last?
5. What did the latency percentiles reveal that the average hid?
6. Why did Marco argue the team needed an SLO on p99, not just on p95?
7. What was the alert fatigue problem on the team?
8. What policy did the team agree to in order to fix alert fatigue?
9. What were the three numbers Lena used to close the review?
10. Why was fixing the payment confirmation path the top priority for the next sprint?

Prática com a história

1. Reescreva com a estrutura SLI + SLO + SLA: We measure availability. We aim for 99.9%. We promise 99.5% to the customer.
2. Reescreva citando burn rate e janela: We are below SLO. We still have time.
3. Reescreva com p99 em vez de média: Latency is 1.4 seconds, which is too slow.
4. Reescreva como política de alerta B2: We get too many alerts. We want fewer.
5. Reescreva com a estrutura MTTR + automação: It used to take 45 minutes to recover. We automated the rollback.