Confiabilidade em Sistemas Distribuídos: o Guia de SRE

Um único nó que cai não deveria derrubar o sistema inteiro. Na prática, porém, é exatamente isso que acontece quando a confiabilidade não foi tratada como disciplina de engenharia. Em sistemas distribuídos, falhas parciais são a regra e não a exceção.

Confiabilidade em sistemas distribuídos é a capacidade de continuar entregando o resultado correto, dentro do tempo esperado, mesmo quando partes do sistema falham. Não é sorte nem heroísmo de plantão. É engenharia mensurável, com métricas, padrões e práticas próprias.

Neste guia você vai entender a definição formal do conceito e por que esses sistemas falham. Em seguida, vemos como medir o serviço com SLI e SLO, a matemática da redundância e os padrões que sustentam o uptime.

O que é confiabilidade em sistemas distribuídos

Confiabilidade descreve a probabilidade de um sistema executar a função esperada, sem erros, durante um intervalo definido. Em termos de SRE, ela é o atributo mais importante de qualquer serviço. Afinal, um sistema rápido mas instável não entrega valor ao usuário.

Vale destacar uma distinção que confunde muita gente. Confiabilidade, disponibilidade, resiliência e tolerância a falhas não são sinônimos. Cada conceito responde a uma pergunta diferente e exige métricas próprias.

O Google consolidou essa visão na obra de referência sobre SRE, ao colocar a confiabilidade no centro da engenharia de serviços.

Confiabilidade não é o mesmo que disponibilidade

Disponibilidade mede a fração de tempo em que o serviço responde. Confiabilidade mede se ele responde corretamente ao longo do tempo. Ou seja, um serviço pode estar disponível e ainda assim não ser confiável, porque responde com erro ou dado incorreto.

Por isso a diferença importa tanto ao definir metas. A tabela a seguir resume como cada conceito se posiciona. Use-a como referência ao desenhar objetivos de serviço com o time.

No dia a dia, muita gente trata alta disponibilidade e confiabilidade como a mesma coisa. Entretanto, elevar o uptime sem reduzir a taxa de erro apenas mascara o problema. A engenharia de tolerância a falhas ataca a causa, não o sintoma.

Por que sistemas distribuídos falham

Sistemas distribuídos falham de formas que sistemas monolíticos não conhecem. A causa raiz é a falha parcial: um componente para enquanto os demais seguem rodando, deixando o conjunto em um estado inconsistente e difícil de prever.

Além disso, a rede entre os componentes é não confiável por natureza. Pacotes se perdem, a latência varia e parceiros ficam indisponíveis sem aviso. Ignorar essas premissas é a origem da maioria dos incidentes graves em produção.

As oito falácias da computação distribuída

Em 1994, engenheiros da Sun formalizaram oito suposições falsas que derrubam sistemas distribuídos. São elas: a rede é confiável, a latência é zero, a banda é infinita e a rede é segura. A topologia não muda, há um único administrador, o custo de transporte é zero e a rede é homogênea.

Cada falácia vira um incidente quando a equipe assume que ela é verdadeira. Por isso, projetar para a falha sai mais barato que reagir a ela depois. Entender por que sistemas complexos falham é o primeiro passo para projetá-los melhor.

O teorema CAP e o custo da consistência

O teorema CAP afirma que, diante de uma partição de rede, um sistema distribuído precisa escolher entre consistência e disponibilidade. Não dá para ter as duas em forma plena durante a partição. Essa escolha define o comportamento do sistema sob estresse.

Sistemas financeiros costumam priorizar consistência, pois um saldo errado é inaceitável. Já um feed social prioriza disponibilidade, porque servir um dado levemente desatualizado é tolerável. Em síntese, confiabilidade depende de escolher o trade-off certo para cada domínio.

Como medir confiabilidade: SLI, SLO e error budget

Você não melhora o que não mede. A engenharia de confiabilidade moderna mede o serviço com três instrumentos encadeados: o SLI, o SLO e o error budget. Juntos, eles transformam uma intenção vaga em uma meta operável.

Do SLI ao error budget

O SLI (Service Level Indicator) é a métrica crua da qualidade percebida, como a fração de requisições respondidas com sucesso. O SLO (Service Level Objective) é a meta sobre esse indicador, por exemplo 99,9% de sucesso em 30 dias.

O error budget é o complemento do SLO. Se a meta é 99,9%, o orçamento de erro vale 0,1% das requisições. Enquanto há saldo, o time lança novidades. Quando o orçamento estoura, a prioridade vira estabilizar. Dessa forma, confiabilidade e velocidade param de competir.

Defina o SLI a partir das jornadas críticas do usuário, não da infraestrutura. Os sinais RED e USE ajudam a escolher indicadores que refletem dor real do cliente. A consulta abaixo calcula a fração de erro em PromQL.

# Fração de requisições com erro nos últimos 30 dias
sum(rate(http_requests_total{status="5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

Compare o resultado com o error budget definido. Para fundamentar metas sólidas, vale consultar o guia prático de implementação mantido pelo Google, que detalha a queima do orçamento.

A matemática da confiabilidade: redundância em série e em paralelo

A confiabilidade de um sistema é o produto da confiabilidade dos componentes em série. Se três serviços de 99,9% dependem um do outro em cadeia, o resultado não é 99,9%. É 0,999 elevado a 3, ou seja, cerca de 99,7%.

Cada dependência em série derruba o número. A redundância inverte essa lógica: dois componentes de 99% em paralelo entregam 99,99%, porque ambos precisam falhar ao mesmo tempo. Portanto, redundância é a alavanca matemática da confiabilidade.

O custo cresce rápido conforme você adiciona noves. A tabela mostra o downtime anual tolerado em cada nível de SLA. Use-a para calibrar metas realistas junto ao negócio.

Cada nove adicional multiplica o custo de engenharia e de infraestrutura. Em contrapartida, nem todo serviço precisa de cinco noves. Definir o nível certo evita gastar onde o usuário sequer percebe o ganho.

Padrões de engenharia de confiabilidade

Medir é metade do trabalho. A outra metade está em projetar o sistema para absorver falhas sem propagá-las. Com o tempo, alguns padrões viraram o vocabulário comum dessa engenharia.

A tabela reúne os padrões mais usados, o problema que cada um resolve e quando aplicá-lo. Vale combiná-los, porque raramente um padrão isolado sustenta um serviço crítico sozinho.

Esses padrões aparecem em frameworks de arquitetura consolidados. O framework Well-Architected da AWS dedica um pilar inteiro ao tema, com checklists acionáveis para cada padrão.

Como validar confiabilidade: chaos engineering e observabilidade

Um sistema só é confiável quando você prova que ele resiste. O chaos engineering injeta falhas controladas em produção (latência, queda de nó, perda de pacote) para validar se os padrões funcionam de verdade. A hipótese é simples: o serviço deve se manter dentro do SLO.

Sem visibilidade, porém, um experimento de caos vira apenas um apagão. A observabilidade fecha o ciclo, pois mostra o que aconteceu, onde e por quê. Logs, métricas e traces correlacionados transformam um incidente em aprendizado.

Aprofunde a base lendo sobre os pilares da observabilidade e estruture metas com o guia de Site Reliability Engineering. As duas práticas trabalham juntas: uma define a meta, a outra revela o caminho até ela.

Da operação reativa à engenharia de confiabilidade

Muitas equipes ainda descobrem o incidente pelo cliente. Esse modelo reativo custa caro: o MTTR explode, a fadiga de alertas cresce e a confiança do negócio despenca. A virada começa quando a confiabilidade entra no fluxo diário de engenharia.

Na prática, isso significa SLOs revisados a cada ciclo, error budget guiando o roadmap e postmortems sem culpado. Assim, o monitoramento deixa de ser vigilância e passa a ser insumo de decisão de engenharia.

Estruturar essa cultura raramente acontece sozinho. Times que aceleram o caminho costumam contar com uma operação assistida de SRE para implantar indicadores, objetivos e ritos de confiabilidade já nos primeiros meses.

Conclusão

Confiabilidade em sistemas distribuídos não é um recurso que se compra pronto. É uma disciplina que combina definição clara, medição honesta e padrões de engenharia aplicados com método.

Percorremos a distinção entre disponibilidade e confiabilidade. Vimos por que as falhas parciais e o teorema CAP impõem trade-offs inevitáveis. Também detalhamos como SLI, SLO e error budget transformam intenção em meta operável.

A matemática da redundância e padrões como circuit breaker e degradação graciosa sustentam o uptime. Por fim, chaos engineering e observabilidade provam que tudo realmente funciona.

O fio condutor é simples: confiabilidade se projeta, se mede e se valida, nunca se improvisa. Quanto antes ela entrar no fluxo de engenharia, menor o custo de cada incidente evitado. Se a sua operação ainda descobre falhas pelo cliente e quer transformar reação em previsibilidade, fale com um especialista da OpServices. Juntos, estruturamos a sua jornada de confiabilidade.