Arquitetura de sistemas críticos: quanto custa 1 hora fora do ar e o paradoxo dos 99,99%

Em reuniões entre diretores de negócios e equipes de tecnologia, é muito comum ouvir uma frase dita com naturalidade: “nosso sistema novo precisa ficar 100% do tempo no ar”. Do ponto de vista da engenharia física e computacional, porém, 100% de disponibilidade perpétua não existe. Cabos submarinos são rompidos por âncoras de navios, tabelas de roteamento BGP sofrem erros humanos, certificados TLS expiram e deploys de sexta-feira encontram casos de borda que nenhum ambiente de homologação previu.

Por isso, a verdadeira conversa estratégica entre liderança técnica e liderança de negócios não é sobre prometer o impossível, mas sobre precificar o risco da indisponibilidade e escolher conscientemente em qual degrau da escada dos “noves” cada parte da sua empresa precisa operar.

1. A matemática fria da tabela dos “Noves”

Na linguagem de Site Reliability Engineering (SRE), medimos a confiabilidade de uma plataforma pela porcentagem de tempo em que ela responde corretamente às requisições dentro de uma janela anual. À primeira vista, a diferença entre 99% e 99,99% parece um detalhe estatístico de apenas 0,99 ponto percentual. Quando convertemos essa porcentagem para horas e minutos reais de operação parada ao longo de um ano, o choque de realidade aparece:

Pense no significado prático de 99,99%: se a sua operação sofrer um único incidente no mês de janeiro que leve 55 minutos para ser diagnosticado e revertido, você já estourou toda a sua cota de indisponibilidade do ano inteiro até dezembro!

2. A armadilha da probabilidade em sistemas distribuídos

Muitas equipes acreditam que, se contratarem um banco de dados gerenciado na nuvem que promete 99,9% de SLA e hospedarem suas aplicações em containers que também têm 99,9%, o sistema final terá 99,9% de disponibilidade. A matemática das probabilidades diz exatamente o oposto.

Quando você desenha uma arquitetura síncrona em série, onde o sucesso da compra do cliente depende simultaneamente do Serviço A (autenticação), do Serviço B (catálogo), do Serviço C (cálculo de frete), do Serviço D (motor antifraude) e do Serviço E (gateway de pagamento), a disponibilidade real do fluxo completo é a multiplicação das probabilidades individuais:

$$0,999 \times 0,999 \times 0,999 \times 0,999 \times 0,999 = (0,999)^5 \approx 99,5%$$

Ou seja: cinco microsserviços excelentes de “três noves” (8 horas de queda por ano cada), quando acoplados de forma síncrona sem tolerância a falhas, entregam juntos um sistema de apenas 99,5% (quase 44 horas fora do ar por ano). É por isso que arquiteturas de microsserviços mal desenhadas frequentemente caem mais do que o antigo monólito que elas substituíram.

3. Como ganhar resiliência sem multiplicar a conta de nuvem por dez

Subir de 99,9% para 99,99% apenas comprando mais servidores redundantes em múltiplas regiões geográficas (multi-region active-active) pode multiplicar a sua fatura de infraestrutura em nuvem por três ou quatro vezes. Na maioria das empresas, existe um caminho de engenharia muito mais inteligente e econômico antes de gastar milhões em hardware duplicado:

1. Desacoplamento assíncrono e Degradação Graciosa (Graceful Degradation): pergunte-se sempre: o que é estritamente indispensável para capturar o pedido ou atender o cliente agora, e o que pode ser processado 30 segundos depois? Se o serviço externo de programa de fidelidade, de recomendação ou de nota fiscal estiver lento, o sistema principal deve fechar a venda normalmente, salvar o evento em uma fila durável e processar o restante em segundo plano (Circuit Breaker). Nunca deixe um serviço secundário derrubar o caixa da empresa.
2. Controle o maior vilão real: as suas próprias mudanças: relatórios globais do Uptime Institute e do grupo DORA mostram que entre 70% e 80% das quedas severas não são causadas por meteoros caindo no data center da AWS ou do Google, mas por deploys de código novo, alterações de variáveis de configuração, certificados vencidos ou migrations de banco de dados que trancam tabelas. Implementar canary deploys (liberar a versão nova para 1% do tráfego antes de liberar para 100%), feature flags (botões de desligamento instantâneo sem precisar recompilar código) e testes automatizados de contrato reduz 80% das quedas quase de graça.
3. Classifique seus sistemas em Tiers (Camadas de Criticidade): nem todo software da empresa merece o custo financeiro e a complexidade de engenharia dos “quatro noves”. Separe sua arquitetura em Tier 0 / Tier 1 (o fluxo que recebe dinheiro, atende o cliente na loja ou mantém a fábrica rodando, onde cada minuto parado custa dezenas de milhares de reais) e Tier 2 / Tier 3 (painéis internos de RH, relatórios gerenciais do dia anterior, cadastros administrativos).

Concentrar o rigor do SRE, os simulados de falha (Game Days) e o investimento de redundância nos 20% da arquitetura que protegem 99% da receita da empresa é a marca registrada de uma liderança técnica madura, que fala a língua da engenharia sem esquecer a língua do balanço financeiro.