A Practical Framework for Flaky Failure Triage in Distributed Database Continuous Integration

1. Problema e Contexto

Em sistemas de Integração Contínua (CI) para bancos de dados distribuídos, as falhas são frequentemente causadas por estados transitórios de runtime (como contenção de locks, atrasos de replicação ou gargalos de I/O) em vez de defeitos persistentes no código. Quando uma falha ocorre, os operadores precisam tomar uma decisão rápida e crítica:

1. Reexecutar automaticamente (Rerun): Se a falha for "flaky" (intermitente/não reproduzível).
2. Escalar para depuração (Escalate): Se a falha for persistente.

Desafios de Implantação:
Esta decisão deve ser tomada sob restrições rigorosas de latência (milissegundos) e recursos (apenas CPU), sem acesso a logs pós-falha ou informações futuras. Abordagens existentes falham neste cenário devido a:

• Vazamento de Dados (Leakage): Uso de logs pós-falha ou strings de erro que não estariam disponíveis no momento da decisão online.
• Má Calibração: Modelos que funcionam bem em ranking, mas cujas probabilidades não são calibradas para decisões de limiar fixo sob mudanças de carga ou versões (shift).
• Viés de Rótulo: Os rótulos de "falha flaky" são gerados por políticas de reexecução com orçamento finito. Se o orçamento de reexecução for pequeno, falhas flaky podem ser erroneamente rotuladas como persistentes (censura unilateral).

2. Metodologia: O Framework SCOUT

O artigo apresenta o SCOUT (State-aware Causal Online Uncertainty-calibrated Triage), um framework projetado especificamente para este cenário de decisão online estrita. A arquitetura divide-se em dois caminhos:

A. Caminho Online (Decisão Imediata)

O objetivo é classificar uma falha em milissegundos usando apenas dados disponíveis antes ou no momento da falha.

1. Extração de Recursos Causais Estritos (Strict-Causal Feature Extraction):
   • Utiliza apenas telemetria pré-falha (janela de -120s a 0s), metadados pré-execução e histórico de execuções anteriores.
   • Bloqueia explicitamente qualquer artefato pós-falha (logs, strings de erro).
   • Agrega métricas de telemetria (CPU, I/O, latência Raft, filas, etc.) em estatísticas de janela (média, max, std, p95).
2. Pontuação Leve Consciente do Estado (Lightweight State-Aware Scoring):
   • Utiliza modelos logísticos leves (Regressão Logística) em vez de modelos pesados de sequência ou multimodais.
   • Oferece três variantes:
     • State LR: Apenas telemetria densa.
     • Text LR: Apenas metadados esparsos (TF-IDF).
     • SDJ-LR: Fusão de ambos.
   • O foco é baixa latência e interpretabilidade, não apenas precisão de ranking.

B. Caminho Offline (Adaptação e Correção)

Melhora o modelo online usando dados históricos de reexecução.

1. Calibração Portável a Decisão (Decision-Portable Calibration):
   • Resolve o problema de shift (mudança de distribuição) entre domínios (ex: versões diferentes do banco de dados ou cargas de trabalho).
   • Utiliza um método chamado OA-Cal (Overlap-Aware Calibration).
   • Seleciona o melhor calibrador (ex: Isotonic, Sigmoid) baseado apenas no conjunto de calibração de origem e na sobreposição com o alvo, sem usar rótulos do alvo.
   • Garante que um único limiar de custo ($\tau^*$) funcione em diferentes cenários.
2. Correção de Orçamento de Reexecução (Rerun-Budget Correction):
   • Resolve o viés de censura onde falhas flaky não são detectadas devido a orçamentos de reexecução limitados.
   • Utiliza uma correção suave posterior (Posterior-Soft Correction). Em vez de usar o rótulo binário duro (passou/não passou), estima a probabilidade posterior de que a falha teria passado se houvesse um orçamento de reexecução maior (oracle), assumindo uma distribuição Beta. Isso cria um alvo de treinamento mais suave e menos enviesado.

3. Principais Contribuições

1. Formulação do Problema: Define a triagem de falhas flaky como um problema de decisão online estritamente causal, onde a latência e a ausência de dados futuros são restrições primárias.
2. Framework SCOUT: Propõe uma solução prática que combina extração de recursos causais, pontuação leve e técnicas de calibração/correção específicas para implantação.
3. Técnicas de Implantação:
   • Desenvolve a OA-Cal para garantir que decisões baseadas em limiar fixo sejam portáveis entre domínios e ao longo do tempo.
   • Introduz a correção suave posterior para mitigar o viés inerente a políticas de reexecução com orçamento finito.
4. Validação Abrangente: Avaliação em benchmarks sintéticos, traços reais do TiDB (v7/v8) e metadados do GitHub Actions, demonstrando viabilidade em produção.

4. Resultados Experimentais

O SCOUT foi avaliado em um conjunto de dados de 3.680 execuções falhas e traços reais:

• Eficácia de Recursos (RQ1): A telemetria de runtime densa (pré-falha) é a fonte dominante de sinal. Modelos leves (State LR) com agregação de janela superam ou igualam modelos mais complexos (como LightGBM ou redes neurais sequenciais) em termos de custo de decisão, mantendo a latência ultrabaixa.
• Portabilidade sob Mudança (RQ2): A calibração é mais importante que a complexidade do modelo.
  • Modelos não calibrados têm custos de decisão altos (ex: 765.4) e falham sob shift.
  • Com calibração (Isotonic/OA-Cal), o custo cai drasticamente (para ~496.9) e mantém-se estável entre versões e cargas de trabalho.
• Correção de Orçamento (RQ3): A correção suave posterior reduz significativamente o erro de calibração (ECE) de 0.320 para 0.027 e melhora o Brier Score, superando abordagens ingênuas e métodos de aprendizado positivo-não-rotulado (PU) genéricos.
• Viabilidade de Implantação (RQ4):
  • Latência: O SCOUT atinge uma latência P95 de 1.17 ms em CPU (Apple M4), atendendo aos requisitos de tempo real.
  • Interpretabilidade: Os recursos aprendidos (ex: razão de espera por lock, latência de aplicação Raft) são intuitivos e operacionais.
• Generalização (RQ5): O framework demonstrou eficácia em traços reais do TiDB e em metadados do GitHub Actions, mesmo com censura severa e falta de telemetria detalhada (apenas metadados).

5. Significado e Impacto

O trabalho é significativo porque preenche uma lacuna crítica entre a pesquisa acadêmica sobre testes flaky e as necessidades operacionais reais de bancos de dados distribuídos.

• Operacionalidade: Ao focar em restrições de CPU e latência de milissegundos, o SCOUT é diretamente aplicável em ambientes de produção onde modelos pesados de IA não são viáveis.
• Robustez: As técnicas de calibração e correção de viés garantem que o sistema não degrade sua performance quando o ambiente de teste muda (novas versões, novas cargas), evitando falsos positivos (reexecuções desnecessárias) e falsos negativos (falhas persistentes ignoradas).
• Eficiência de Recursos: Ao reduzir a necessidade de depuração manual e otimizar o uso de recursos de CI, o framework economiza tempo e custos computacionais significativos para equipes de engenharia de software em grande escala.

Em resumo, o SCOUT transforma a triagem de falhas flaky de um problema de classificação genérico em um sistema de decisão causal, calibrado e eficiente, pronto para implantação em infraestruturas críticas de CI.