Injeção de Falhas Sensível à Configuração para Resiliência Distribuída

1. Institutional Framing

Sistemas distribuídos raramente colapsam porque a matemática de consenso está errada. O colapso tende a ocorrer na fronteira entre o modelo de falhas declarado e a superfície real de configuração em produção. O artigo selecionado é relevante porque explicita uma lacuna operacional: campanhas de fault injection normalmente medem cobertura de código, mas não cobertura de caminhos de tolerância a falhas condicionados por configuração. Em produção, essa diferença é crítica.

Para engenharia institucional, este artefato mapeia para Distributed Systems Architecture com alinhamento nas linhas de capacidade failure propagation control (primária), consistency and partition strategy design e replica recovery and convergence patterns. O ganho empresarial é direto: sem campanhas sensíveis à configuração, painéis de resiliência superestimam robustez enquanto estados adversarialmente alcançáveis permanecem sem teste.

Traceability Note

Paper: CAFault: Enhance Fault Injection Technique in Practical Distributed Systems via Abundant Fault-Dependent Configurations.

Authors: Yuanliang Chen, Fuchen Ma, Yuanhang Zhou, Zhen Yan, Yu Jiang.

Source: 2025 USENIX Annual Technical Conference (USENIX ATC 25). Link: https://www.usenix.org/conference/atc25/presentation/chen-yuanliang (PDF: https://www.usenix.org/system/files/atc25-chen-yuanliang.pdf).

Source Claim Baseline

O paper afirma que workflows existentes de fault injection em sistemas distribuídos são tipicamente executados com configurações padrão fixas e, por isso, deixam de exercitar caminhos dependentes de configuração em lógicas de tolerância a falhas. Ele propõe o CAFault com dois componentes centrais: FDModel para inferir dependências entre entradas de falha e entradas de configuração, e fuzzing guiado por lógica de tratamento de falhas para priorizar exploração relevante.

A avaliação reporta quatro sistemas amplamente utilizados: HDFS, ZooKeeper, MySQL-Cluster e IPFS. Em comparação com CrashFuzz, Mallory e Chronos, o paper reporta maior cobertura de lógica de tolerância a falhas e 16 bugs sérios previamente desconhecidos. Também reporta que ideias do FDModel melhoram desempenho e cobertura quando incorporadas em ferramentas existentes.

Internal Fit Matrix

selected_domain: Distributed Systems
selected_capability_lines: failure propagation control; consistency and partition strategy design; replica recovery and convergence patterns
why this paper supports enterprise engineering decisions: transforma validação de resiliência de testes em configuração default para exploração explícita de estados condicionados por configuração

2. Technical Deconstruction

CAFault deve ser modelado como sistema de redução de espaço de estados sob restrições adversariais, e não apenas como otimização de fuzzing. O objetivo é maximizar descoberta de falhas por unidade de tempo de campanha, podando dois espaços acoplados: vetores de configuração e vetores de falha. Seja $\mathcal{C}$ o espaço de configurações, $\mathcal{F}$ o espaço de agendamentos de falha, e $\mathcal{R}\subseteq \mathcal{C}\times\mathcal{F}$ a região útil de alcançabilidade de lógica de falha.

\text{Work}_{\text{naive}} = |\mathcal{C}|\cdot|\mathcal{F}|,\qquad \text{Work}_{\text{guided}} \approx |\widehat{\mathcal{R}}| \ll |\mathcal{C}|\cdot|\mathcal{F}| \tag{E2}

Decisão de engenharia associada a (E2): orçamento de campanha deve ser dirigido pelo tamanho da fronteira alcançável de lógica de falha, e não por meta bruta de quantidade de testes.

O FDModel opera como estimador online de dependências. A partir de deltas observados em cobertura de lógica de falha $\Delta H$ sob perturbações $\Delta c_i$ , o modelo estima relevância de cada parâmetro. Em termos operacionais, isso separa dimensões de baixo valor (por exemplo, verbosidade de log) de controles críticos (timeouts, fatores de replicação, thresholds de recuperação).

O fuzzing orientado por tratamento de falhas desloca o alvo de cobertura genérica para cobertura semanticamente ligada à resiliência: reeleição de líder, rejoin de réplica, transferências de estado e esgotamento de orçamento de retry.

3. Hidden Assumptions

Para uso institucional, alguns pressupostos precisam ser explicitados.

O primeiro é completude de observabilidade. Se a telemetria não captura transições causais de máquina de estados, a inferência de dependências fica enviesada. O segundo é estacionariedade ambiental durante a campanha. Em ambiente real, jitter de agendamento e contenção de recursos alteram caminhos sensíveis a tempo. O terceiro é supor correlação forte entre aumento de cobertura e descoberta de superfícies críticas; essa relação não é sempre verdadeira em protocolos quorum-based.

P(\text{detect bug}) = f\big(\text{coverage}_{fh},\ \text{observability},\ \text{timing fidelity},\ \text{oracle quality}\big) \tag{E3}

Decisão de engenharia associada a (E3): antes de escalar campanha, fortalecer oráculos de invariantes e rastreabilidade causal. Sem isso, expansão de fuzzing tem utilidade marginal baixa.

Há ainda pressuposto implícito de confiança no canal de configuração. Em contexto adversarial, mudanças de configuração precisam de proveniência criptograficamente verificável e resistência a replay.

4. Adversarial Stress Test

Sob adversário ativo, a questão não é apenas se o CAFault encontra bugs, mas se a incerteza explorável é reduzida mais rápido do que o atacante consegue operacionalizar drift de configuração e falhas temporizadas.

Considere estratégia adversária $A$ : induzir drift de configuração aparentemente benigno e, em seguida, acionar sequência de falhas para forçar recuperação não convergente. Seja $T_d$ tempo de descoberta do defensor e $T_a$ tempo de exploração do atacante. Margem de segurança existe somente se:

T_d + T_p < T_a \tag{E4}

onde $T_p$ é o tempo de correção e rollout. Decisão associada a (E4): descoberta sem pipeline de correção rápida não melhora risco real.

Vetores de estresse recomendados:

Replay e rollback de configuração em subconjuntos de nós.
Distorção temporal com perda seletiva de heartbeat.
Sobrecarga durante recuperação com rejoin simultâneo.
Acoplamento cross-layer com eventos de rotação de certificados.

Critérios de aceite devem ser invariantes formais: ausência de dual-leader além de janela limitada, monotonicidade de índice de commit observável e janela máxima de stale read durante failover.

5. Operationalization

A adoção prática requer pipeline determinístico de validação de resiliência.

\Gamma = (S,\ C_b,\ F_b,\ O,\ I,\ B) \tag{E5}

com $S$ versão do sistema, $C_b$ baseline de configurações, $F_b$ orçamento de falhas, $O$ esquema de observabilidade, $I$ conjunto de oráculos de invariantes e $B$ limite de blast radius. Decisão associada a (E5): não executar campanha sem $I$ e $B$ explicitamente versionados.

// Scheduler determinístico para testes de falha sensíveis à configuração.
type Campaign struct {
    Version      string
    ConfigSeeds  []Config
    FaultBudget  FaultBudget
    Invariants   []Invariant
    MaxBlast     BlastRadius
}

func RunCampaign(c Campaign) Report {
    deps := InferFaultConfigDependencies(c.ConfigSeeds)
    prioritizedConfigs := RankConfigsByFaultRelevance(deps)

    report := NewReport(c.Version)
    for _, cfg := range prioritizedConfigs {
        faults := GenerateFaultSchedules(cfg, c.FaultBudget)
        for _, fs := range faults {
            trace := ExecuteDeterministicScenario(cfg, fs)
            verdict := EvaluateInvariants(trace, c.Invariants)
            report.Record(cfg, fs, verdict, trace.CausalHash())
            if report.ExceedsBlast(c.MaxBlast) {
                return report.FailClosed("blast radius threshold exceeded")
            }
        }
    }
    return report
}

Controles operacionais mandatórios:

Artefatos de configuração assinados e versionados monotonicamente.
Hash causal reprodutível por cenário para triagem determinística.
Isolamento de domínio para impedir vazamento de falhas injetadas.
Condições de parada por orçamento de risco, não apenas por tempo.

6. Enterprise Impact

O principal efeito empresarial é elevar a qualidade de governança de resiliência. O valor não está apenas em achar mais bugs, mas em reduzir incerteza sobre regiões de configuração de alto impacto ainda não testadas.

R_a = w_1\cdot C_{fh} + w_2\cdot I_{pass} + w_3\cdot D_{repro} - w_4\cdot U_{untested} \tag{E6}

com $C_{fh}$ cobertura de lógica de falha, $I_{pass}$ taxa de invariantes aprovadas, $D_{repro}$ densidade de reprodutibilidade e $U_{untested}$ massa ponderada de configurações críticas não testadas. Decisão associada a (E6): relatórios executivos devem expor $U_{untested}$ explicitamente.

Ambientes regulados se beneficiam mais porque passam a produzir evidência auditável de due diligence sobre premissas de tolerância a falhas em configurações realistas.

7. What STIGNING Would Do Differently

Vincular FDModel a proveniência assinada. Dependências aprendidas sem assinatura e contexto de aprovação não devem entrar no modelo.
Priorizar risco de quebra de invariantes. Ordenar campanhas por probabilidade de violação de safety/liveness, não por novidade sintática.
Persistir suites de replay adversarial. Traços críticos devem ser incorporados ao CI/CD com relógio e rede determinísticos.
Simular comprometimento do plano de controle. Incluir respostas inconsistentes do serviço de configuração entre réplicas.
Aplicar SLO de convergência pós-falha. Cada release deve provar tempo máximo de reconvergência sob carga.
Atestar estado de configuração em log imutável. Exigir rastreabilidade criptográfica do estado efetivo em runtime.
Mensurar utilidade marginal de campanha. Encerrar ou redesenhar suites quando não houver redução de risco alto não testado.

\text{Ship} \iff \left(U_{untested}^{hi} \leq \theta_u\right) \land \left(P_{inv\_break} \leq \theta_p\right) \tag{E7}

Decisão associada a (E7): política de release deve falhar fechado quando $U_{untested}^{hi}$ exceder limiar, mesmo com alto pass rate agregado.

8. Strategic Outlook

Validação de resiliência sensível à configuração tende a se tornar baseline em sistemas distribuídos de alta garantia, mas isso exige integração com governança arquitetural e não apenas adoção de ferramenta.

Direções estratégicas:

Bibliotecas padronizadas de invariantes por família de protocolo.
Síntese de falhas cross-layer incluindo identidade, PKI e malha de serviços.
Evidência criptograficamente auditável de campanhas e decisões de release.

\Delta \text{Risk}_{12m} \approx -k_1\cdot \Delta U_{untested}^{hi} - k_2\cdot \Delta T_{detect} - k_3\cdot \Delta T_{repair} \tag{E8}

A implicação operacional é objetiva: investimento deve reduzir simultaneamente incerteza de alto impacto, latência de detecção e latência de correção.

References

Yuanliang Chen, Fuchen Ma, Yuanhang Zhou, Zhen Yan, Yu Jiang. CAFault: Enhance Fault Injection Technique in Practical Distributed Systems via Abundant Fault-Dependent Configurations. USENIX ATC 2025. https://www.usenix.org/conference/atc25/presentation/chen-yuanliang
PDF do artigo: https://www.usenix.org/system/files/atc25-chen-yuanliang.pdf
Ferramentas citadas no paper: CrashFuzz, Mallory, Chronos.

Conclusion

CAFault corrige uma limitação estrutural de práticas comuns de resiliência: sem sensibilidade à configuração, campanhas de fault injection deixam lacunas adversariais materialmente relevantes. Para contexto empresarial, o próximo nível de maturidade é integrar essa abordagem com governança criptograficamente verificável de configuração, oráculos de invariantes e replay determinístico, de forma que alegações de robustez permaneçam defensáveis sob auditoria e sob ataque.

STIGNING Academic Deconstruction Series Engineering Under Adversarial Conditions