Subcapability 03 de 05 · Platform Engineering

SRE & Reliability

SLOs e error budgets que traduzem confiabilidade de conversa técnica em contrato quantitativo e dão ao board o modelo de decisão que faltava para investir em disponibilidade com critério.

O que está em jogo

O sistema caiu. O time acorda de madrugada. Resolve o problema às pressas. Ninguém documenta o que aconteceu. Na semana seguinte, o mesmo padrão. Sem SLO que defina o que é aceitável, sem error budget que meça o quanto de instabilidade o negócio suporta, cada incidente começa do zero e a empresa paga o mesmo custo de downtime indefinidamente.

O que é, na prática

Confiabilidade é uma decisão econômica. Ir de 99,9% para 99,99% de disponibilidade custa exponencialmente mais. Sem SRE, o board nunca sabe se paga demais ou de menos por reliability, e o trade-off vira briga entre dev e ops sem linguagem comum. Downtime tem preço direto. Uma hora de indisponibilidade em operação de médio porte representa dezenas de milhares em receita não capturada e custo de recuperação de confiança do cliente que não aparece em nenhum relatório de incidente. Organizações que gerenciam error budgets de forma ativa conseguem reduzir custos relacionados a downtime em até 40%, segundo análises de práticas de engenharia de confiabilidade.

Como atuamos

Ganhos mensuráveis

O que muda no resultado quando essa subcapacidade amadurece.

Perguntas frequentes

Como definir o SLO certo para um serviço?

Começando pelo impacto de negócio, não pela capacidade técnica. A pergunta certa é: qual percentual de indisponibilidade ou degradação o usuário percebe e o negócio considera inaceitável? 99,9% significa pouco menos de 9 horas de downtime por ano. 99,99% significa menos de uma hora. A diferença de custo entre os dois é exponencial. O SLO certo é o que equilibra o custo de indisponibilidade com o custo de confiabilidade adicional.

O que é error budget e como ele muda a dinâmica entre dev e ops?

Error budget é o quanto de instabilidade o SLO permite em um período. Se o SLO é 99,9% de disponibilidade em 30 dias, o error budget é 43 minutos de downtime. Enquanto o budget está disponível, o time pode fazer deploys com confiança. Quando o budget está esgotado, a prioridade muda para estabilidade. Essa mecânica elimina a briga de "dev quer velocidade, ops quer estabilidade" porque ambos trabalham com o mesmo orçamento explícito.

Blameless postmortem funciona em cultura onde a primeira reação é buscar culpado?

A mudança começa pela estrutura do documento, não pela cultura. Um template de postmortem que pede causas raiz sistêmicas, linha do tempo de eventos e ações de prevenção, sem campo para nome de responsável, já direciona a conversa para o sistema. A cultura acompanha quando o processo produz resultado melhor: o mesmo incidente para de se repetir.

Como calcular o custo de downtime para justificar investimento em SRE?

Uma aproximação defensável começa com o volume de transações por hora no serviço e a taxa de conversão ou o valor médio por transação. Multiplica pelo percentual de usuários afetados durante o downtime. Adiciona o custo de suporte gerado pelo incidente. Para serviços B2B, o custo de breach de SLA contratual entra no cálculo. Esse número, apresentado ao board com frequência histórica de incidentes, justifica o investimento em SRE com critério que orçamento de TI raramente tem.

Quanto tempo leva para SRE gerar resultado visível?

As primeiras melhorias em tempo de restauração aparecem em semanas, com runbooks estruturados e on-call rotation com responsabilidade clara. SLOs conectados ao board e error budgets que mudam comportamento de deploy levam um trimestre para se estabelecer. A redução sustentada de incidentes recorrentes via postmortem estruturado é visível em três a seis meses.

Quer clareza sobre onde investir primeiro?

Diagnóstico completo de capacidades de tecnologia com roadmap de evolução conectado ao resultado financeiro.