APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma arquitetura com duas instâncias pode parecer resiliente, mas ambas podem depender do mesmo componente indisponível. O analista técnico procura mecanismos de falha, condições que os ativam e consequências para o serviço. Num projeto fictício, um batch deve recuperar após interrupção sem perder nem duplicar instruções. O risco não fica descrito apenas por servidor em baixo: inclui estado parcialmente gravado, confirmação perdida e repetição de uma operação. Desenha a investigação com quem conhece aplicação, infraestrutura e operação. Distingue risco de produto, como duplicação de resultados, de risco de projeto, como não dispor do ambiente a tempo. A segunda situação pode impedir obter evidência sobre a primeira e deve aparecer no plano.
Aplicação guiada
Define para cada investigação o comportamento esperado, ambiente, dados, observação e limites. Um requisito como rápido não permite escolher um oráculo; percentil, carga, duração e taxa de erro precisam de contexto. Para recuperação, acorda o que significa serviço restaurado e como verificar integridade dos dados. Usa ambientes autorizados e dados artificiais nos exercícios. Antes de um ensaio de falha, identifica quem pode interrompê-lo, como repor condições e que dependências devem permanecer protegidas. A decisão final deve considerar evidência, representatividade e risco residual. Uma experiência bem-sucedida numa configuração reduzida não demonstra automaticamente o mesmo resultado na produção, sobretudo quando concorrência, volumes e dependências são diferentes.
Duas instâncias com a mesma dependência podem partilhar o mesmo modo de falha.
Armadilhas comuns
Redundância como prova; requisito sem medida; ambiente reduzido como equivalente.
Tópicos relacionados: Cobertura lógica white-box · Análise estática e dinâmica · Desempenho e perfil de carga
Liga risco, experiência e decisão operacional.
Referência: Google SRE testing for reliability · CTAL-TTA v4.0 (2021)