Availability: como medir e melhorar a disponibilidade da aplicação

O que é availability e os famosos "nines"

Entendendo o que cada nível de disponibilidade representa na prática

Availability é a fração de tempo em que um sistema está operacional e acessível para seus usuários, geralmente expressa como percentual. Os "nines" são a forma popular de descrever esses percentuais: 99% (dois nines) significa 87 horas de downtime por ano; 99,9% (três nines) significa 8,7 horas; 99,99% (quatro nines) permite apenas 52 minutos de downtime anual; e 99,999% (cinco nines) limita o downtime a pouco mais de 5 minutos por ano. A diferença prática entre três e quatro nines é enorme: sistemas financeiros, de saúde e e-commerce de grande escala raramente toleram mais de algumas horas de downtime por ano sem impacto severo na receita e reputação. Entender qual nível de availability é adequado para cada sistema é o primeiro passo para definir arquitetura e investimento corretos.

Como calcular availability em produção

A fórmula e os dados necessários para medir com precisão

A fórmula básica de availability é: Availability = MTBF / (MTBF + MTTR), onde MTBF é o Mean Time Between Failures (tempo médio entre falhas) e MTTR é o Mean Time To Recover (tempo médio para recuperar). Sistemas com MTBF alto têm falhas raras; sistemas com MTTR baixo se recuperam rapidamente quando falham — ambas as métricas importam. Na prática, calcular availability requer monitoramento contínuo com ferramentas de uptime como Pingdom, Datadog ou UptimeRobot, que verificam endpoints em intervalos de 30 a 60 segundos e registram cada período de indisponibilidade. Disponibilidade composta de múltiplos componentes em série é calculada multiplicando as disponibilidades individuais: dois serviços com 99,9% cada resultam em 99,8% de availability composta, não 99,9%.

Single points of failure — o maior inimigo da disponibilidade

Identificando e eliminando componentes que derrubam tudo sozinhos

Um single point of failure (SPOF) é qualquer componente cuja falha derruba o sistema inteiro — e a maioria dos sistemas tem mais SPOFs do que seus arquitetos percebem. Um servidor de banco de dados único, um load balancer sem réplica, um serviço de autenticação centralizado sem fallback, um certificado SSL gerenciado manualmente — cada um desses é um SPOF em potencial. A identificação de SPOFs requer um exercício de fault tree analysis: para cada componente do sistema, perguntar "se este componente falhar, o que acontece com o sistema?" Se a resposta for "o sistema para", é um SPOF e precisa de redundância. A regra prática é que qualquer sistema com SLA acima de 99,9% não pode ter nenhum SPOF em seu caminho crítico.

Redundância horizontal — múltiplas instâncias

Como distribuir carga e eliminar pontos únicos de falha

Redundância horizontal significa rodar múltiplas instâncias do mesmo componente em paralelo, atrás de um load balancer, de forma que a falha de qualquer instância individual não afete o sistema. Com duas instâncias, cada uma com 99% de availability, a probabilidade de ambas falharem ao mesmo tempo é de apenas 0,01% — elevando a availability composta para 99,99%. A distribuição entre zonas de disponibilidade (Availability Zones) da AWS, Azure ou GCP adiciona resiliência contra falhas de data center inteiro — um evento raro mas catastrófico para sistemas rodando em uma única AZ. O princípio do N+1 garante que sempre há pelo menos uma instância a mais do que o necessário para absorver a carga, de modo que a perda de uma instância não cause degradação de performance.

Failover automático — trocar de instância sem intervenção manual

Sistemas que se curam sozinhos sem esperar alguém acordar às 3h

Failover automático é a capacidade do sistema de detectar a falha de um componente e redirecionar tráfego para uma instância saudável sem intervenção humana. Load balancers como o AWS ALB e o NGINX verificam a saúde de backends em intervalos configuráveis e removem automaticamente instâncias que falham no health check. Em banco de dados, soluções como RDS Multi-AZ, MongoDB Atlas com replica sets e PostgreSQL com Patroni implementam failover automático em 30 a 60 segundos — tempo suficiente para ser imperceptível em sistemas com retry automático no cliente. O MTTR de sistemas com failover automático cai de minutos ou horas (tempo para um engenheiro acordar e intervir) para dezenas de segundos, impactando diretamente a availability calculada.

Health checks e readiness probes

Como o sistema sabe que uma instância está pronta para receber tráfego

Health checks são verificações periódicas que determinam se uma instância está viva e saudável. Liveness probes verificam se o processo está rodando e não travou — uma resposta 200 em /health é suficiente. Readiness probes são mais criteriosas: verificam se a instância está pronta para receber tráfego de produção, incluindo conectividade com o banco de dados, cache aquecido, e dependências externas disponíveis. Em Kubernetes, a separação entre liveness e readiness é fundamental: uma instância pode estar viva (o processo não crashou) mas não estar pronta (o banco está indisponível), e o Kubernetes deve remover essa instância do balanceamento de carga sem reiniciá-la desnecessariamente. Health checks que verificam dependências downstream devem ter timeouts agressivos para não ficarem presos aguardando um serviço lento.

Availability em banco de dados com réplicas

Read replicas, multi-AZ e quorum para diferentes cenários

Banco de dados é frequentemente o componente com menor availability em uma arquitetura, porque operações de escrita exigem consistência e não podem ser simplesmente distribuídas entre instâncias. Replica sets do MongoDB e read replicas do PostgreSQL permitem que leituras sejam distribuídas entre múltiplos nós, aumentando o throughput de leitura e mantendo disponibilidade para queries mesmo quando o primário está sob manutenção. Em configurações multi-AZ do RDS, uma réplica síncrona em outra AZ garante que o failover preserve todos os dados escritos até o momento da falha. Sistemas distribuídos que utilizam quorum (maioria dos nós deve confirmar uma escrita) como Cassandra e etcd trocam latência de escrita por maior disponibilidade e tolerância a partições de rede.

Chaos Engineering — testar falhas antes que aconteçam

Injetando falhas de propósito para descobrir fraquezas antes do usuário

Chaos Engineering é a prática de injetar falhas controladas em produção (ou em ambientes que espelham produção) para descobrir como o sistema se comporta sob condições adversas. A Netflix desenvolveu o Chaos Monkey para derrubar instâncias aleatórias em produção e forçar a equipe a construir sistemas que sobrevivem a isso. Ferramentas como Chaos Mesh (Kubernetes), AWS Fault Injection Simulator e Gremlin permitem simular falhas de rede, latência alta, uso excessivo de CPU, falha de banco de dados e reinicialização de pods de forma controlada e reversível. O objetivo não é causar incidentes, mas descobrir SPOFs, fluxos sem retry, timeouts inadequados e dependências ocultas antes que uma falha real exponha essas fragilidades para os usuários.

SLA vs SLO vs SLI em disponibilidade

A cadeia de compromissos que conecta métricas técnicas a contratos comerciais

SLI (Service Level Indicator) é a métrica técnica bruta — a porcentagem de requisições com resposta bem-sucedida nos últimos 30 dias. SLO (Service Level Objective) é a meta interna da equipe de engenharia — manter o SLI de availability acima de 99,9%. SLA (Service Level Agreement) é o contrato formal com o cliente — geralmente mais conservador que o SLO para deixar margem de segurança. Quando o SLI cai abaixo do SLO, o erro budget (orçamento de erros) é consumido, sinalizando que a equipe deve priorizar confiabilidade acima de novas features. Sistemas maduros monitoram o error budget restante continuamente e congelam deploys de novas features quando o budget está quase esgotado, protegendo o SLA contratual.

Conclusão — disponibilidade é uma propriedade arquitetural, não um ajuste final

Construir para falhar graciosamente desde o início

Availability não se adiciona a um sistema depois que ele está pronto — ela é resultado de decisões arquiteturais tomadas desde o início: eliminação de SPOFs, redundância em cada camada, failover automático, health checks precisos e prática de Chaos Engineering. Sistemas que atingem quatro ou cinco nines não são sistemas onde nada falha, são sistemas projetados para que as falhas inevitáveis não cheguem ao usuário. O caminho para alta disponibilidade começa pela medição honesta do estado atual — MTBF, MTTR, SPOFs mapeados — e pelo investimento sistemático em remover cada ponto de fragilidade. Continue em: Fundamentos obrigatórios antes de produção.