Resiliência

Visão Geral

Tolerância a falhas trata das falhas previstas: você identificou o modo de falha e construiu a resposta.

Resiliência é a capacidade de absorver o inesperado — o que ninguém previu, a combinação improvável, a falha em modo desconhecido — e se adaptar.

A distinção não é acadêmica. Ela muda onde se investe: tolerância é engenharia de mecanismos; resiliência inclui pessoas, procedimentos, margem e capacidade de aprender.

Problema

Todo mecanismo de tolerância cobre um cenário antecipado. Os incidentes graves quase sempre vêm de cenários que ninguém antecipou — não porque a equipe foi negligente, mas porque o espaço de combinações possíveis é grande demais para ser enumerado.

Um sistema com dez mecanismos de tolerância bem construídos ainda vai enfrentar a situação para a qual nenhum deles foi projetado.

O que determina o resultado, nesse momento, não é a lista de mecanismos. É a capacidade de perceber, entender, decidir e agir sob incerteza — que é a definição prática de resiliência.

Conceitos Centrais

As quatro capacidades

antecipar   reconhecer o que pode dar errado antes de acontecer
monitorar   perceber o que está acontecendo agora
responder   agir sob incerteza, com informação incompleta
aprender    transformar o ocorrido em capacidade

Tolerância a falhas cobre principalmente a primeira, transformada em mecanismo. As outras três dependem de pessoas, ferramentas e processo — e são o que decide o resultado no cenário não previsto.

Margem de manobra

Um sistema operando no limite não tem para onde ir quando algo inesperado acontece.

sem margem   utilização a 85%, sem folga, sem alternativa
com margem   folga de capacidade, caminho alternativo, funcionalidade que pode ser
             desligada, tempo antes do impacto

Margem é o que dá opções durante o incidente. Ela custa — capacidade ociosa, caminhos alternativos a manter — e é o que separa um sistema que degrada de um que colapsa.

Ver planejamento de capacidade e degradação graciosa.

Reversibilidade vale mais que acerto

Num cenário desconhecido, a capacidade de desfazer rapidamente vale mais que a de decidir corretamente na primeira tentativa.

reversão em 2 minutos    permite tentar, observar, tentar de novo
reversão em 2 horas      cada decisão é definitiva sob pressão

Isso orienta investimento: implantação reversível, interruptores por funcionalidade, mudanças de configuração sem implantação, migrações com caminho de volta.

É a propriedade que mais reduz a gravidade de incidentes, e ela não aparece em nenhum diagrama de arquitetura.

As pessoas fazem parte do sistema

Num incidente não previsto, o trabalho é humano: entender o que está acontecendo, formular hipóteses, decidir.

O que sustenta isso:

observabilidade      permite responder perguntas não antecipadas
conhecimento distribuído  não depende de uma pessoa específica
sobreaviso sustentável    quem está exausto decide pior
procedimentos ensaiados   reduzem a carga cognitiva no momento errado
autoridade clara          quem decide o quê, sem escalada

Ver observabilidade. A diferença entre monitoramento e observabilidade é exatamente essa: o primeiro responde perguntas previstas, a segunda permite formular perguntas novas — que é o que o cenário desconhecido exige.

Aprender é a capacidade que compõe

Um incidente que não gera aprendizado será repetido.

O que transforma incidente em capacidade:

Análise sem busca de culpado. Se as pessoas temem consequência, a informação não aparece — e sem informação honesta não há aprendizado.

Foco em condições, não em erro individual. "Por que essa ação pareceu razoável no momento?" ensina mais que "quem errou".

Ações com dono e prazo. Análises que terminam em observações não mudam nada.

Quase-incidentes também. O que quase deu errado carrega a mesma informação, sem o custo.

Resiliência não é ausência de falha

Um sistema resiliente falha — e absorve, degrada, se recupera e melhora.

Perseguir ausência de falha leva a fragilidade: sistemas otimizados para o caso esperado, sem margem, sem alternativas, que funcionam perfeitamente até encontrarem o inesperado.

Ver SLO — o orçamento de erro é a expressão formal dessa ideia: falha é esperada e orçada.

Modelo Mental

Tolerância cobre o que você previu; resiliência cobre o que você não previu. A segunda depende de margem, reversibilidade e pessoas.

Quando Usar

Investir em resiliência se justifica quando:

• O sistema é complexo o suficiente para produzir cenários não antecipados.
• O custo de incidentes graves é alto.
• Há dependências e interações difíceis de enumerar.
• A operação envolve pessoas de sobreaviso.

Quando Não Usar

Como substituto de tolerância. Os cenários previstos devem ser tratados por mecanismo, não por improviso.

Sem observabilidade. Não se responde ao que não se enxerga.

Sem margem. Um sistema no limite não tem opções.

Análise de incidente buscando culpado. Destrói a informação.

Investindo só em mecanismo, ignorando procedimento e pessoas.

Alternativas

Não há alternativa a resiliência — há ênfases diferentes:

• Mais mecanismos de tolerância — cobre mais cenários previstos, e não o imprevisto.
• Simplificar — menos interações, menos combinações inesperadas. Frequentemente a intervenção mais eficaz.
• Reduzir o alcance — sistemas menores e isolados falham menos junto.
• Reversibilidade — a de melhor retorno isolado.

Trade-offs

Com margem	No limite
Opções durante o incidente	Nenhuma
Capacidade ociosa	Utilização alta
Custo permanente	Menor

Reversível	Irreversível
Permite tentar	Cada decisão é definitiva
Exige desenho	Mais simples

Modos de Falha

Sem margem. O primeiro imprevisto vira colapso.

Reversão lenta. Decisões sob pressão sem possibilidade de correção.

Conhecimento concentrado. A pessoa que sabe está de férias.

Observabilidade insuficiente. Ninguém consegue entender o que acontece.

Análise que busca culpado. O aprendizado não acontece.

Ações sem dono. O mesmo incidente se repete.

Sobreaviso exausto. Decisões piores no momento em que importam mais.

Erros Comuns

Confundir com tolerância a falhas. Tolerância cobre falhas previstas; resiliência é sobre o que não foi previsto. Um sistema pode tolerar toda falha prevista e ruir na primeira que ninguém imaginou.

Investir só em mecanismos. Disjuntor e retentativa são úteis e insuficientes: a capacidade de responder bem depende também de quem opera, do que se enxerga e de quanto tempo se tem para reagir.

Operar sem folga. Sistema e time no limite não têm capacidade de absorver surpresa. A folga é o que transforma imprevisto em incidente controlado.

Não priorizar reversibilidade. Poder desfazer rápido vale mais que acertar sempre, porque o erro é certo e a velocidade de recuperação é o que se controla.

Análises de incidente sem ações rastreadas. Análise que não vira tarefa priorizada é ritual: o mesmo incidente volta, e a segunda análise chega às mesmas conclusões.

Ignorar quase-incidentes. O que quase deu errado carrega a mesma informação que o incidente, sem o custo. Descartá-lo é abrir mão do aprendizado mais barato que existe.

Exemplo Real

Uma plataforma de pagamentos tinha investimento sério em tolerância: circuit breakers, bulkheads, redundância em três zonas, failover exercitado.

Um incidente de 4 horas veio de uma combinação que nenhum mecanismo cobria.

A sequência: uma mudança de configuração aumentou o tamanho de um pool de conexões; isso aumentou o consumo de memória por instância; o escalonamento automático, ao adicionar instâncias durante um pico, esgotou a cota de endereços da sub-rede; as instâncias novas subiam e falhavam; o balanceador as removia e adicionava outras, num ciclo.

Nenhum mecanismo de tolerância se aplicava — não havia componente falhando, havia uma interação entre três decisões razoáveis.

O que prolongou o incidente:

Sem margem. As instâncias operavam a 80%. Não havia folga para absorver enquanto o problema era investigado.

Reversão lenta. A mudança de configuração estava embutida na imagem. Reverter exigia nova construção e implantação: 35 minutos.

Conhecimento concentrado. A pessoa que entendia a configuração de rede estava indisponível. Levou 2 horas até alguém suspeitar da cota de endereços.

Observabilidade insuficiente. Não havia métrica de endereços disponíveis na sub-rede. O sintoma — instâncias falhando ao iniciar — não apontava para a causa.

As correções foram de resiliência, não de tolerância:

Margem. Utilização alvo reduzida para 60%, dando espaço de absorção.

Configuração fora da imagem, alterável em segundos, com reversão imediata.

Interruptores por funcionalidade, permitindo reduzir carga sem implantar.

Métricas de recursos de infraestrutura — endereços, cotas, limites — que antes não existiam.

Exercícios de mesa mensais, discutindo cenários combinados. O terceiro exercício encontrou dois outros acoplamentos que ninguém tinha percebido.

Rotação de conhecimento, com a documentação de rede revisada por quem não a escreveu.

O que a equipe registra: os mecanismos de tolerância continuam corretos e não teriam ajudado. O que teria reduzido as 4 horas para minutos era a reversão rápida da configuração — que custou dois dias para implementar.

Conceitos Relacionados

• Tolerância a Falhas — o previsto.
• Engenharia do Caos — como descobrir o imprevisto.
• Degradação Graciosa — a margem em forma de funcionalidade.
• Observabilidade.

Exercício Prático

Meça quanto tempo leva para reverter a última mudança implantada no seu sistema — de verdade, cronometrado.

Esse número é o limite inferior da duração de qualquer incidente causado por uma mudança.

Perguntas de Entrevista

• Qual a diferença entre tolerância a falhas e resiliência?
• Por que reversibilidade vale mais que acerto no cenário desconhecido?
• Por que análise de incidente sem busca de culpado é requisito, não gentileza?

Para Aprofundar

• Hollnagel, Erik. Resilience Engineering in Practice. Ashgate, 2011.
• Woods, David. Four Concepts for Resilience. Reliability Engineering, 2015.
• Allspaw, John. Blameless PostMortems and a Just Culture, 2012.