Aprenda sobre orçamentos de erro para equipes enxutas: defina SLOs realistas para produtos iniciais, decida quais incidentes importam e realize um ritual semanal simples de confiabilidade.
Equipes enxutas lançam rápido porque precisam. O risco normalmente não é um grande apagão dramático. É a mesma falha pequena se repetindo: um cadastro instável, um checkout que às vezes falha, um deploy que ocasionalmente quebra uma tela. Cada um rouba horas, corrói a confiança e transforma releases em cara ou coroa.
Orçamentos de erro dão a equipes enxutas uma forma simples de seguir rápido sem fingir que a confiabilidade "vai acontecer sozinha".
Um SLO (objetivo de nível de serviço) é uma promessa clara sobre a experiência do usuário, expressa como um número em uma janela de tempo. Exemplo: “Checkouts bem-sucedidos são pelo menos 99,5% nos últimos 7 dias.” O orçamento de erro é a quantidade permitida de “ruim” dentro dessa promessa. Se seu SLO é 99,5%, seu orçamento semanal é 0,5% de checkouts falhos.
Não se trata de perfeição ou de mostrar uptime por exibição. Não é processo pesado, reuniões intermináveis ou uma planilha que ninguém atualiza. É uma forma de concordar sobre o que significa “bom o suficiente”, notar quando vocês estão derivando e tomar uma decisão calma sobre o que fazer a seguir.
Comece pequeno: escolha 1 a 3 SLOs voltados ao usuário ligados às jornadas mais importantes, meça usando sinais que você já tem (erros, latência, pagamentos falhos) e faça uma rápida revisão semanal onde você observa a queima do orçamento e escolhe uma ação de acompanhamento. O hábito importa mais que a ferramenta.
Pense em confiabilidade como um plano de dieta. Você não precisa de dias perfeitos. Você precisa de uma meta, de uma maneira de medi-la e de uma margem para a vida real.
Um SLI (indicador de nível de serviço) é o número que você observa, como “% de requisições que conseguem” ou “p95 de carregamento de página abaixo de 2 segundos”. Um SLO é a meta para esse número, como “99,9% das requisições bem-sucedidas”. O orçamento de erro é quanto você pode deixar de atingir o SLO e ainda estar dentro do esperado.
Exemplo: se seu SLO é 99,9% de disponibilidade, seu orçamento é 0,1% de downtime. Em uma semana (10.080 minutos), 0,1% são cerca de 10 minutos. Isso não significa que você deve tentar “usar” 10 minutos. Significa que quando você os gasta, está conscientemente trocando confiabilidade por velocidade, experimentos ou trabalho de recursos.
Esse é o valor: transforma confiabilidade em ferramenta de decisão, não em um exercício de relatório. Se você queimou a maior parte do orçamento na quarta-feira, pausa mudanças arriscadas e corrige o que está quebrando. Se você está quase sem gasto, pode lançar com mais confiança.
Nem tudo precisa do mesmo SLO. Um app público voltado ao cliente pode precisar de 99,9%. Uma ferramenta administrativa interna muitas vezes pode ser mais frouxa porque menos pessoas notam e o impacto é menor.
Não comece medindo tudo. Comece protegendo os momentos onde o usuário decide se seu produto funciona ou não.
Escolha 1 a 3 jornadas de usuário que carregam mais confiança. Se essas estiverem sólidas, a maioria dos outros problemas parecerá menor. Bons candidatos são o primeiro contato (cadastro ou login), o momento do dinheiro (checkout ou upgrade) e a ação central (publicar, criar, enviar, carregar ou uma chamada de API crítica).
Escreva o que significa “sucesso” em termos simples. Evite linguagem técnica como “200 OK” a não ser que seus usuários sejam desenvolvedores.
Alguns exemplos que você pode adaptar:
Escolha uma janela de medição que corresponda à velocidade com que você muda as coisas. Uma janela de 7 dias funciona quando você lança diariamente e quer feedback rápido. Uma janela de 28 dias é mais calma se os releases forem menos frequentes ou seus dados forem ruidosos.
Produtos iniciais têm restrições: o tráfego pode ser baixo (um deploy ruim distorce seus números), os fluxos mudam rápido e a telemetria costuma ser escassa. Tudo bem. Comece com contagens simples (tentativas vs. sucessos). Aperfeiçoe as definições depois que a própria jornada parar de mudar.
Comece com o que você entrega hoje, não com o que você gostaria de ter. Por uma ou duas semanas, capture uma linha de base para cada jornada chave: com que frequência ela tem sucesso e com que frequência falha. Use tráfego real se tiver. Se não tiver, use seus próprios testes mais tickets de suporte e logs. Você está construindo uma imagem aproximada do “normal”.
Seu primeiro SLO deve ser algo que você consiga atingir na maioria das semanas enquanto ainda entrega. Se sua taxa de sucesso hoje é 98,5%, não coloque 99,9% e espere. Defina 98% ou 98,5% e aperfeiçoe depois.
Latência é tentadora, mas pode distrair cedo. Muitas equipes extraem mais valor de um SLO de taxa de sucesso primeiro (requisições concluem sem erros). Adicione latência quando os usuários realmente a sentirem e você tiver dados estáveis o suficiente para tornar os números significativos.
Um formato útil é uma linha por jornada: quem, o quê, meta e janela de tempo.
Mantenha a janela mais longa para momentos de dinheiro e confiança (billing, auth). Mantenha-a mais curta para fluxos do dia a dia. Quando você conseguir atingir o SLO facilmente, aumente um pouco e continue.
Equipes enxutas perdem muito tempo de confiabilidade quando cada soluço vira um alarme vermelho. O objetivo é simples: dor visível ao usuário gasta o orçamento; todo o resto é tratado como trabalho normal.
Um pequeno conjunto de tipos de incidentes basta: outage total, outage parcial (uma jornada chave quebra), desempenho degradado (funciona mas está lento), deploy ruim (um release causa falhas) e problemas de dados (errados, faltando, duplicados).
Mantenha a escala pequena e use-a sempre.
Decida o que conta contra o orçamento. Trate falhas visíveis ao usuário como gasto: cadastro ou checkout quebrados, timeouts que o usuário sente, picos de 5xx que impedem jornadas. Manutenção planejada não deve contar se você comunicou e o app se comportou como esperado no período.
Uma regra encerra a maioria dos debates: se um usuário externo real perceberia e não conseguiria completar uma jornada protegida, conta. Caso contrário, não conta.
Essa regra também cobre áreas cinzentas comuns: uma falha de terceiro conta só se ela quebrar sua jornada, horas de baixo tráfego ainda contam se usuários forem impactados, e testadores internos não contam a não ser que dogfooding seja seu uso principal.
O objetivo não é medição perfeita. É um sinal compartilhado e repetível que indica quando a confiabilidade está ficando cara.
Para cada SLO, escolha uma fonte de verdade e mantenha-a: um painel de monitoramento, logs do app, uma verificação sintética que bate em um endpoint, ou uma métrica única como checkouts bem-sucedidos por minuto. Se você mudar o método de medição depois, registre a data e trate como um reset para não comparar maçãs com laranjas.
Alertas devem refletir a queima do orçamento, não cada soluço. Um pico breve pode ser irritante, mas não deve acordar ninguém se mal toca o orçamento mensal. Um padrão simples funciona bem: alertar em “queima rápida” (você está no ritmo de queimar o orçamento do mês em um dia) e um alerta mais suave em “queima lenta” (no ritmo de queimar em uma semana).
Mantenha um registro mínimo de confiabilidade para não depender da memória. Uma linha por incidente basta: data e duração, impacto ao usuário, causa provável, o que você mudou e um responsável pelo follow-up com data limite.
Exemplo: uma equipe de duas pessoas lança uma nova API para um app mobile. O SLO deles é “99,5% de requisições bem-sucedidas”, medido por um contador. Um deploy ruim derruba para 97% por 20 minutos. Um alerta de queima rápida dispara, eles fazem rollback e o follow-up é “adicionar um canary antes do deploy”.
Você não precisa de um processo grande. Você precisa de um hábito pequeno que mantenha a confiabilidade visível sem roubar tempo de construção. Uma checagem de 20 minutos funciona porque transforma tudo em uma pergunta: estamos gastando confiabilidade mais rápido que o planejado?
Use o mesmo horário na agenda toda semana. Mantenha uma nota compartilhada que você apenas acrescente (não reescreva). Consistência vence detalhes.
Uma agenda simples que cabe:
Entre follow-ups e compromissos, decida sua regra de release para a semana e mantenha simples:
Se seu fluxo de cadastro teve duas pequenas quedas e queimou a maior parte do orçamento, você pode congelar apenas mudanças relacionadas ao cadastro enquanto ainda entrega trabalho não relacionado.
Um orçamento de erro só importa se ele muda o que você fará na semana seguinte. O ponto não é uptime perfeito. É uma forma clara de decidir: emitimos funcionalidades ou pagamos a dívida de confiabilidade?
Uma política que você pode dizer em voz alta:
Isso não é punição. É uma troca pública para que os usuários não paguem por isso depois.
Quando você desacelera, evite tarefas vagas como “melhorar estabilidade”. Escolha mudanças que alterem o próximo resultado: adicione um guardrail (timeouts, validação de entrada, limites de taxa), melhore um teste que teria pegado o bug, facilite rollback, corrija a maior fonte de erro ou adicione um alerta atrelado a uma jornada do usuário.
Separe relatório de culpa. Recompense relatórios rápidos de incidente, mesmo quando os detalhes estiverem bagunçados. O único relatório ruim é o que aparece tarde demais, quando ninguém lembra o que mudou.
Uma armadilha frequente é definir um SLO ouro no dia um (99,99% soa ótimo) e depois ignorá-lo quando a realidade chega. Seu SLO inicial precisa ser alcançável com as pessoas e ferramentas atuais, senão vira ruído de fundo.
Outro erro é medir a coisa errada. Equipes observam cinco serviços e um gráfico de banco, mas perdem a jornada que o usuário realmente sente: cadastro, checkout ou “salvar alterações”. Se você não consegue explicar o SLO em uma frase do ponto de vista do usuário, provavelmente é muito interno.
Fadiga de alertas queima a única pessoa que pode consertar produção. Se todo pico pequeno pagina alguém, paginar vira “normal” e incêndios reais são perdidos. Page por impacto ao usuário. Direcione todo o resto para checagem diária.
Um assassino mais silencioso é contagem inconsistente. Uma semana você conta uma lentidão de dois minutos como incidente, na semana seguinte não. Então o orçamento vira debate em vez de sinal. Escreva as regras uma vez e aplique consistentemente.
Salvaguardas que ajudam:
Se um deploy quebra o login por 3 minutos, conte isso todas as vezes, mesmo que seja consertado rápido. Consistência é o que torna o orçamento útil.
Acione um cronômetro de 10 minutos, abra um documento compartilhado e responda estas cinco perguntas:
Se não conseguem medir algo ainda, comece com um proxy visível rápido: pagamentos falhos, erros 500 ou tickets de suporte marcados “checkout”. Substituam proxies depois quando o rastreamento melhorar.
Exemplo: uma equipe de duas pessoas vê três mensagens “não consigo resetar senha” na semana. Se reset de senha é uma jornada protegida, isso é um incidente. Eles escrevem uma nota curta (o que aconteceu, quantos usuários, o que foi feito) e escolhem um follow-up: adicionar um alerta em falhas de reset ou adicionar uma tentativa de retry.
Maya e Jon comandam uma startup de duas pessoas e lançam toda sexta. Eles se movem rápido, mas seus primeiros usuários pagantes se importam com uma coisa: conseguem criar um projeto e convidar um colega sem que quebre?
Na semana passada tiveram um outage real: “Criar projeto” falhou por 22 minutos após uma migração ruim. Também tiveram três períodos “lentos mas não mortos” onde a tela ficou girando por 8 a 12 segundos. Usuários reclamaram, mas a equipe discutiu se lentidão conta como “fora do ar”.
Eles escolhem uma jornada e a tornam mensurável:
Na segunda eles fazem o ritual de 20 minutos. Mesmo horário, mesmo documento. Respondem quatro perguntas: o que aconteceu, quanto do orçamento foi consumido, o que se repetiu e qual única mudança evitaria a repetição.
A troca fica óbvia: o outage mais os períodos lentos consumiram a maior parte do orçamento semanal. Então a “grande feature” da próxima semana vira “adicionar um índice no DB, tornar migrações mais seguras e alertar em falhas de criar-projeto”.
O resultado não é confiabilidade perfeita. São menos problemas repetidos, decisões mais claras e menos noites em claro porque concordaram antecipadamente sobre o que é “ruim o suficiente”.
Escolha uma jornada de usuário e faça uma promessa simples de confiabilidade sobre ela. Orçamentos de erro funcionam melhor quando são chatos e repetíveis, não perfeitos.
Comece com um SLO e um ritual semanal. Se ainda parecer fácil depois de um mês, adicione um segundo SLO. Se estiver pesado, reduza.
Mantenha a matemática simples (semanal ou mensal). Mantenha a meta realista para onde vocês estão hoje. Escrevam uma nota de confiabilidade de uma página que responda: o SLO e como é medido, o que conta como incidente, quem está responsável esta semana, quando é a checagem e o que fazer por padrão quando o orçamento queima rápido.
Se você está construindo em uma plataforma como Koder.ai (koder.ai), ela pode ajudar a combinar iteração rápida com hábitos de segurança, especialmente snapshots e rollback, para que “reverter ao último estado bom” continue sendo uma ação normal e praticada.
Mantenha o ciclo curto: um SLO, uma nota, uma checagem semanal curta. O objetivo não é eliminar incidentes. É notar cedo, decidir com calma e proteger as poucas coisas que os usuários realmente sentem.
Um SLO é uma promessa de confiabilidade sobre a experiência do usuário, medida em uma janela de tempo (como 7 ou 30 dias).
Exemplo: “99,5% dos checkouts são bem-sucedidos nos últimos 7 dias.”
Um orçamento de erro é a quantidade permitida de “ruim” dentro do seu SLO.
Se seu SLO é 99,5% de sucesso, seu orçamento é 0,5% de falhas nesse período. Quando você gasta o orçamento rápido demais, desacelera mudanças arriscadas e corrige as causas.
Comece com 1–3 jornadas que os usuários percebem imediatamente:
Se essas estiverem confiáveis, a maior parte dos outros problemas parecerá menor e será mais fácil priorizar depois.
Escolha um baseline que você realmente consiga atingir na maioria das semanas.
Se hoje você está em 98,5%, começar em 98–98,5% é mais útil que declarar 99,9% e ignorar o SLO.
Use contagem simples: tentativas vs. sucessos.
Boas fontes iniciais:
Não espere observabilidade perfeita; comece com um proxy confiável e mantenha consistência.
Conte como incidente se um usuário externo notaria e não conseguiria completar uma jornada protegida.
Exemplos que contam contra o orçamento:
Não conte inconveniências internas a menos que o uso interno seja o principal do produto.
Regra simples: paginar por gasto do orçamento, não por cada oscilação.
Dois tipos úteis de alerta:
Isso reduz a fadiga de alertas e foca a atenção no que realmente altera o que você vai entregar.
Mantenha em 20 minutos, mesmo horário, mesmo documento:
Encerre com um modo de release para a semana: Normal, ou .
Use uma política padrão simples:
O objetivo é uma troca calma, não punição.
Algumas salvaguardas práticas:
Se você usa uma plataforma como Koder.ai, torne “reverter para o último estado bom” um movimento rotineiro e trate rollbacks repetidos como sinal para investir em testes ou verificações mais seguras.
