Um sistema passa o trimestre inteiro sem incidentes graves e a conclusão mais repetida costuma ser a mesma: teve sorte. A conclusão erra o alvo. A confiabilidade do sistema não nasce de sorte, nasce de um número definido antes de qualquer coisa acontecer: o quanto de falha o serviço pode acumular sem quebrar o que foi prometido a quem usa.
Jean Pierre Lessa e Santos Ferreira, especialista em tecnologia, software e inteligência artificial, observa que a confusão entre sorte e engenharia carrega um custo duplo: mascara falhas reais de processo atrás de uma explicação confortável e empurra a conversa sobre risco para depois do incidente, quando já é tarde para decidir com calma.
De onde vem a ideia de que sistema estável é sorte?
Por muito tempo, manter um sistema no ar foi tratado como trabalho de bombeiro: alguém detectava a falha, geralmente pelo cliente reclamando, e corria para resolver. Sem meta formal de disponibilidade, cada incidente virava uma negociação improvisada sobre o que era aceitável, decidida no calor do momento por quem estava de plantão naquele dia.
O modelo funcionava enquanto os sistemas eram simples e o volume de usuários, pequeno. Com a multiplicação de serviços interligados, a ausência de meta objetiva passou a gerar dois problemas opostos: times que travavam qualquer lançamento por medo de quebrar algo, e times que lançavam sem qualquer margem de segurança, torcendo para que nada desse errado. Sem um número de referência, a mesma falha podia ser tratada como tragédia num mês e como detalhe irrelevante no seguinte, dependendo de quem estava resolvendo o problema naquele momento.
O que SLOs e error budgets medem de fato?
Um objetivo de nível de serviço, conhecido como SLO, define um número concreto de disponibilidade ou desempenho aceitável para um serviço, por exemplo, 99,9% de tempo no ar em um trimestre. A partir desse número nasce o error budget, a margem de falha que ainda cabe dentro da meta sem quebrar o compromisso assumido com o negócio.
Jean Pierre Lessa e Santos Ferreira revela que a força desse modelo está em transformar uma decisão antes subjetiva, quanto risco vale a pena assumir, em um cálculo objetivo: enquanto o orçamento de erro não se esgota, o time pode lançar novidades; quando se esgota, o foco muda para estabilização, sem depender da opinião de quem está mais vocal na reunião.
Diferença entre monitorar e medir confiabilidade
Monitorar um sistema significa observar métricas técnicas, como uso de CPU, tempo de resposta ou taxa de erro, geralmente por meio de painéis e alertas. A vigilância constante é necessária, mas não substitui a definição de um objetivo. Um painel cheio de gráficos pode mostrar que tudo está normal e, ainda assim, não responder à pergunta que realmente importa: o serviço está cumprindo o que foi prometido ao usuário?
Medir confiabilidade exige conectar essas métricas a uma meta de negócio definida com antecedência. Jean Pierre Lessa e Santos Ferreira apresenta essa diferença como o ponto que separa operações reativas de operações orientadas a objetivo: a primeira reage ao alerta, a segunda sabe, a qualquer momento, quanto de margem ainda resta antes de um problema virar crise.
Por que decisão de negócio também depende dessas métricas
Um error budget bem definido não fica restrito à engenharia. Ele orienta conversas entre tecnologia e negócio sobre até onde vale a pena acelerar lançamentos e quando é hora de conter o ritmo, com um número compartilhado no lugar de opiniões divergentes sobre o que é razoável arriscar. A mesma lógica evita que uma decisão de lançamento dependa de quem grita mais alto numa reunião de alinhamento.
Jean Pierre Lessa e Santos Ferreira mostra que essa disciplina reduz o desgaste entre áreas justamente porque retira a discussão do terreno pessoal: ninguém precisa convencer ninguém sobre quem está certo, porque a métrica já definiu, antes da pressão do lançamento, qual risco a empresa aceita correr.