# O que é SLO? Orçamentos de Erro Explicados, Mais um Template URL: https://formula.dog/pt/journal/o-que-e-slo Type: blog Locale: pt Published: 2026-10-03 Updated: 2026-10-03 --- > O que é um SLO, como funciona um orçamento de erro, e como rastreá-lo em Excel ou Google Sheets? Fórmulas prontas para copiar e colar. ## O que é SLO? Um guia prático com fórmulas para sua planilha Então, o que é SLO? Um Service Level Objective (Objetivo de Nível de Serviço) é a meta de confiabilidade que você define para um serviço, expressa como um número dentro de um período de tempo. "99,9% dos pedidos são bem-sucedidos em 30 dias" é um SLO. Ele diz ao seu time quanto tempo inativo é aceitável antes de parar de lançar recursos e começar a corrigir problemas. A matemática por trás disso é divisão pura, é por isso que uma planilha dá conta. Biscuit já foi buscar as fórmulas. Você traz os números. ## Os três acrônimos que você vê em todo lugar, explicados SLI, SLO, SLA. As pessoas confundem muito em reuniões, então aqui está a versão resumida. - **SLI (Service Level Indicator)**: aquilo que você mede. A porcentagem de requisições que retornam sem erro, a porcentagem de páginas que carregam em menos de 300 ms, a porcentagem de jobs que terminam no prazo. - **SLO (Service Level Objective)**: a meta para essa medição. "O SLI deve ser de pelo menos 99,9% em 30 dias." - **SLA (Service Level Agreement)**: um contrato com consequências, geralmente dinheiro de volta, ligado a uma meta. O teste mais simples vem do livro SRE do Google: pergunte o que acontece se você não atingir a meta. Se nada contratual acontecer, você está olhando para um SLO, não para um SLA. Seu SLO deve ser mais rigoroso do que qualquer SLA que você tenha assinado, para receber um aviso antes do cliente receber um reembolso. Em termos de planilha: o SLI é uma coluna de medições, o SLO é uma célula com a meta, e o SLA é um PDF que alguém na área jurídica guarda. ## Por que 99,9% e 99,99% são promessas muito diferentes Cada novecentos a mais corta seu tempo permitido de inatividade por um fator de dez. Ao longo de um mês de 30 dias (43.200 minutos), é isto que cada meta deixa para você: - **99%**: 1% de orçamento, 432 minutos (7,2 horas) de inatividade permitida por 30 dias - **99,5%**: 0,5% de orçamento, 216 minutos (3,6 horas) - **99,9%**: 0,1% de orçamento, 43,2 minutos - **99,95%**: 0,05% de orçamento, 21,6 minutos - **99,99%**: 0,01% de orçamento, 4,32 minutos Essa última linha é a armadilha. Quatro minutos por mês significa que uma pessoa não consegue nem terminar de ler o alerta antes do orçamento acabar. A maioria das ferramentas internas, dashboards e pequenos produtos SaaS não precisam disso, e perseguir isso custa dinheiro real em redundância e horas de prontidão. Pule 99,99% a menos que um cliente esteja pagando especificamente por isso. O conselho do Google é direto também: comece com uma meta que você pode apertar depois, porque uma meta rigorosa que você tem que afrouxar ensina todo mundo a ignorar o número. ![Close-up of a fuel gauge needle, a picture of an error budget being spent](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/3bd194-i1.webp) ## O orçamento de erro: o número que seu time realmente discute O orçamento de erro é aquilo que o SLO deixa sobre a mesa. Meta de 99,9%, então o orçamento é 0,1%. Em 30 dias, são 43,2 minutos de tempo "ruim" que você pode gastar. Pense nisso como um medidor de combustível. Deploys arriscados queimam combustível. Uma migração ruim de banco de dados queima combustível. Um apagão às 3 da manhã queima muito combustível. Quando o tanque está cheio, lance mais rápido. Quando está vazio, pare de adicionar recursos e comece a consertar a confiabilidade. A política de amostra do próprio Google é concreta sobre isso: se um serviço estoura seu orçamento em uma janela de quatro semanas, todas as mudanças param, exceto correções P0 e patches de segurança, até que o serviço volte dentro de seu SLO. O orçamento é uma ferramenta de negociação, não um castigo. Permite que um gerente de produto e um engenheiro discutam da mesma célula em vez de do feeling. Vale a pena se você tem mais de um time trabalhando o mesmo serviço. Exagerado se você é um fundador solo com uma landing page e um formulário de contato. ## Escolhendo um SLI que seus usuários reconheceriam Os melhores SLIs descrevem um momento que uma pessoa notaria. Três cobrem a maioria dos serviços: - **Disponibilidade**: a porcentagem de requisições que têm sucesso. Fácil de medir, fácil de explicar. - **Latência**: a porcentagem de requisições mais rápidas que um limite. "95% das buscas retornam em menos de 300 ms" é melhor que uma média, porque médias ocultam a cauda lenta que irrita as pessoas. - **Atualização**: para data pipelines e relatórios, a porcentagem de execuções que terminam antes do prazo. Essa se encaixa bem em pessoal de planilha: "a planilha de vendas da manhã é atualizada até as 8 da manhã em 99% dos dias úteis." Escreva o SLI como uma fração: eventos bons dividido por eventos válidos. Esse único hábito torna todo SLO calculável em uma célula, e força você a decidir o que conta como "bom" antes do incidente, não durante. Para a janela, um período móvel de 30 dias é o mais comum. Um mês de calendário é mais simples de relatar, mas redefine o orçamento no dia 1º, o que tenta times a empurrar deploys arriscados no final do mês. Em uma planilha, uma janela móvel significa apenas filtrar a aba Incidents para os últimos 30 dias com `SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30)`. ## Monte um rastreador de SLO em Google Sheets ou Excel em 10 minutos Você não precisa de uma plataforma de monitoramento para começar. Você precisa de duas abas: **Incidents** e **SLO**. Na aba **Incidents**, registre cada apagão com a hora de início na coluna A, hora de fim na coluna B, e a duração na coluna C: `=(B2-A2)*24*60` - `B2` e `A2`: os datas e horas do final e início do incidente. - `*24*60`: converte a diferença em dias para minutos. Funciona tanto no Excel quanto no Sheets, em todas as versões. Agora a aba **SLO**. Coloque esses rótulos na coluna A e as fórmulas na coluna B: `B1: 0.999 (sua meta de SLO) B2: 30 (janela em dias) B3: =B2*24*60 (total de minutos na janela) B4: =B3*(1-B1) (orçamento de erro em minutos) B5: =SUM(Incidents!C2:C) (tempo inativo até agora) B6: =1-B5/B3 (disponibilidade real) B7: =B4-B5 (orçamento restante, em minutos) B8: =B5/B4 (porcentagem do orçamento gasta)`Com uma meta de 99,9%, `B3` retorna 43200 e `B4` retorna 43,2. Registre um apagão de 12 minutos e `B8` mostra 27,8%. Voilà o que isso dá em uma célula de verdade. Uma observação sobre `C2:C` em `B5`: o intervalo aberto é sintaxe de Sheets. No Excel, use um intervalo fixo como `Incidents!C2:C500` ou referência de tabela. Adicione uma célula de status para ninguém ter que ler o número: `=IF(B8>=1,"Congele launches",IF(B8>=0.5,"Cuidado","Pode lançar"))` - `B8>=1`: orçamento totalmente gasto ou extrapolado. - `B8>=0.5`: metade gasto, então revise mudanças arriscadas. - Qualquer outra coisa: luz verde. Escolha seus próprios limites. Cinquenta por cento é um palpite de partida, não uma lei da física. Preso na sintaxe para sua própria versão dessa planilha? Descreva em português simples e deixe a ferramenta escrever para você. ### Contando requisições em vez de minutos Rastreamento baseado em tempo é fácil de explicar mas grosseiro. Se seu serviço fica "offline" por 5 minutos às 4 da manhã quando ninguém está online, dói menos do que 5 minutos ao meio-dia. A maioria dos times sérios define o SLI por requisições. Cole um export do seu log de requisições em uma aba, com o código de status HTTP na coluna B. Então: `=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)` - `COUNTIF(B2:B,">=500")`: conta requisições que retornaram um erro de servidor. - `COUNTA(B2:B)`: conta todas as requisições. Um menos a porcentagem de erro lhe dá a porcentagem de sucesso. O resultado é seu SLI de disponibilidade como uma fração. Compare-o com a célula de meta e você tem o SLO inteiro em uma linha. Excel 2016 e 365 aceitam `COUNTIF`; basta trocar `B2:B` por um intervalo delimitado. Dois avisos honestos. Planilhas engasgam em milhões de linhas, então exporte totais diários em vez de logs brutos. E uma resposta 4xx é geralmente erro do usuário, não apagão do seu lado, então decida essa regra uma vez e escreva. ![Notebook, pencil, coffee and a stopwatch laid out for tracking uptime by hand](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/ebd9a7-i2.webp) ## Taxa de queimada: a fórmula que avisa você antes de ser tarde demais Saber que queimou 27,8% do orçamento é bom. Saber que está queimando mais rápido que o calendário é útil. Essa proporção é a taxa de queimada. `=B8/(B9/B2)` - `B8`: porcentagem do orçamento gasta até agora. - `B9`: dias decorridos na janela (insira manualmente ou use `=TODAY()-B10`, com a data de início da janela em `B10`). - `B2`: total da janela em dias. Uma taxa de queimada de 1 significa que você vai terminar a janela com exatamente orçamento zerado. Acima de 1, você está indo para um congelamento. Abaixo de 1, tem espaço. Se está 10 dias em uma janela de 30 dias e já queimou 60%, a taxa de queimada é 1,8. Esse é o número para colocar em um display. Essa é a mesma ideia que as grandes ferramentas de monitoramento usam para alertas de taxa de queimada. Uma planilha não vai te chamar às 3 da manhã, porém, então trate-a como uma camada de relatório, não como um alarme. Aqui está um exemplo trabalhado com números reais. Seu SLO é 99,9% em 30 dias, então o orçamento é 43,2 minutos. Dia 1 a 8: um deploy ruim derruba a página de checkout por 14 minutos. Isso é 32,4% do orçamento gasto em um quarto da janela, uma taxa de queimada de cerca de 1,2. Nada está em fogo, mas a planilha agora diz "Cuidado", e a próxima migração arriscada recebe uma segunda olhada. Dia 15: um apagão do provedor adiciona 30 minutos. Total 44 minutos, 101,9% queimados. A célula de status vira "Congele launches", e a conversa sobre prioridades acontece com um número na mesa em vez de um feeling. Esse é o valor inteiro do exercício. Não os novecentos, mas a célula compartilhada que todo mundo consegue apontar. ## Quando a planilha não é mais suficiente Um rastreador assim funciona para um ou dois serviços e uma revisão semanal. Quebra quando você tem dezenas de serviços, precisa de coleta automática de dados, ou quer alertas que disparem em minutos em vez de na próxima reunião de segunda. Hora de olhar uma ferramenta de observabilidade adequada. Datadog e Grafana têm recursos SLO nativos que puxam o SLI reto de suas métricas e desenham o orçamento para você. Escolha Grafana se quiser open source e já roda Prometheus. Escolha Datadog se prefere pagar para não rodar nada você mesmo. De qualquer forma, mantenha a planilha ao redor para a revisão mensal, porque todo mundo na sala consegue abrir e ninguém precisa de login em um vendor. Se quer ajuda rascunhando um primeiro conjunto de SLIs para um serviço, um assistente geral é um parceiro decente para brainstorming. Verifique cada número que ele dá, porque vai feliz inventar uma meta plausível. ## Erros que tornam um SLO inútil, e o que fazer na segunda Alguns padrões que Biscuit viu terminar mal: - **Copiar seu desempenho atual como a meta.** Se rodou em 99,97% no trimestre passado, um SLO de 99,97% congela um ritmo que você pode não conseguir sustentar. - **Muitos SLOs.** Dois ou três por serviço. Além disso, ninguém lembra qual importa. - **Medir o que é fácil, não o que usuários sentem.** Uso de CPU não é um SLI. Checkouts falhados são. - **Sem consequência.** Um SLO sem uma política de orçamento de erro é um desejo. Decida com antecedência o que acontece em 50%, 100% e 150% gasta. - **Nunca revisitar a meta.** Revise a cada trimestre. Se nunca chega perto de gastar o orçamento, a meta é muito solta. ![Golden retriever asleep in a quiet home office at night while the dashboard stays green](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/560fcb-i3.webp) Agora a parte de segunda. Escolha um serviço. Escreva um SLI em uma frase que um não-engenheiro conseguiria seguir. Defina uma meta solta, 99,5% ou 99,9%. Monte as duas abas acima, registre os incidentes do mês passado, e veja o que o orçamento diz. Se a resposta é "queimamos 300% dele", você descobriu por que todo mundo se sente exausto. Se a resposta é "queimamos 4%", aperte a meta ou lance mais rápido. De qualquer forma, você agora tem um número para discutir em vez de um feeling. Bom garoto. Agora vá registrar esses incidentes. ## FAQ ### O que é um SLO em termos simples? Um SLO (service level objective) é uma meta de confiabilidade para um serviço, tal como '99,9% dos pedidos são bem-sucedidos em 30 dias'. Transforma um objetivo vago como 'ser confiável' em um número que seu time consegue medir e rastrear. ### Qual é a diferença entre um SLO e um SLA? Um SLO é uma meta interna. Um SLA é um contrato com consequências, geralmente reembolsos ou créditos, se a meta não for atingida. Se perder o número não tem pena contratual, é um SLO. Defina seu SLO mais rigoroso que seu SLA. ### O que é um orçamento de erro? O orçamento de erro é o quanto de falha seu SLO permite. Um SLO de 99,9% deixa um orçamento de 0,1%, que é 43,2 minutos de inatividade em 30 dias. Os times gastam em incidentes e deploys arriscados, e desaceleram quando acaba. ### Como você calcula um SLO em Excel ou Google Sheets? Calcule minutos totais na janela (dias*24*60), multiplique por (1 - meta) para obter o orçamento, depois subtraia o tempo de inatividade registrado. Para SLIs baseados em requisições, divida requisições boas por requisições totais, por exemplo com COUNTIFS e COUNTA. ### Qual é uma boa meta de SLO? Comece solto, depois aperte. 99,5% ou 99,9% serve para a maioria das ferramentas internas e produtos pequenos. 99,99% deixa cerca de 4 minutos de inatividade por mês e raramente vale o custo a menos que um cliente pague por isso. ### Quantos SLOs um serviço deve ter? Dois ou três que correspondam ao que usuários realmente sentem, como disponibilidade e latência. Mais do que isso e ninguém lembra qual direciona decisões.