The Abstention Protocol: RCA for Clos Fabrics
Este artigo apresenta o CoreSec, um sistema de análise de causa raiz em produção para tecidos Clos de larga escala que substitui a instável fusão baseada em pontuação por uma álgebra de abstenção determinística do tipo PAM para alcançar uma atribuição de falhas estável, explicável e monotônica em ambientes de telemetria ruidosos.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Na vasta e pulsante arquitetura da computação em nuvem moderna, os dados não fluem por um único cano, mas através de uma rede de conexões espalhada e multicamadas. Imagine uma cidade onde cada edifício está conectado a um switch de bairro local, que, por sua vez, se conecta a um hub de distrito, que finalmente se liga a uma espinha dorsal central. Essa estrutura, conhecida como tecido Clos (Clos fabric), permite que milhões de servidores conversem entre si com incrível velocidade e redundância. Se um caminho é bloqueado, o tráfego simplesmente encontra outro. Devido a esse design, o sistema é incrivelmente resiliente; ele pode absorver milhares de pequenas falhas aleatórias todos os dias — como um cabo solto, uma luz piscando ou um breve soluço de software — sem que o usuário médio sequer perceba. No entanto, esse ruído constante de fundo cria um problema profundo para os engenheiros que mantêm o sistema funcionando. Quando um serviço específico falha para um cliente, o sistema acende com centenas de avisos. O desafio não é encontrar as partes quebradas, mas descobrir qual dessas muitas partes quebradas realmente causou a interrupção específica.
Durante anos, a maneira padrão de resolver esse quebra-cabeça era atribuir uma pontuação a cada sinal de aviso. Se um cabo tinha uma contagem alta de erros, recebia uma pontuação alta. Se um switch reiniciava, recebia uma pontuação. O sistema somava essas pontuações e a entidade com o total mais alto era culpada pelo problema. Essa abordagem funcionava razoavelmente bem quando a rede estava silenciosa, mas em um ambiente de hiperescala, frequentemente falhava. Como sempre há algum ruído de fundo, o sistema frequentemente encontrava um "culpado" mesmo quando nada estava realmente errado, ou culpava o dispositivo errado porque as pontuações eram muito próximas para decidir. Os engenheiros descobriram que tentar ajustar essas pontuações para corrigir um tipo de erro acabava quebrando acidentalmente a capacidade do sistema de detectar outro. O resultado era um ciclo de incerteza, onde correções automatizadas eram às vezes disparadas por alarmes falsos, tornando a situação pior em vez de melhor.
Para resolver isso, uma equipe da Microsoft desenvolveu um novo sistema chamado CoreSec, que muda a lógica fundamental de como essas decisões são tomadas. Em vez de somar pontuações, o novo sistema trata a investigação como uma série de verificações estritas e independentes, semelhante a como um sistema de segurança pode verificar a identidade de uma pessoa. Em um edifício de alta segurança, um guarda pode exigir uma senha, uma impressão digital e um cartão de acesso. Se a senha estiver faltando, o guarda não adivinha; ele simplesmente nega a entrada e interrompe o processo. O CoreSec aplica essa mesma lógica de "abstenção" às falhas de rede. Ele atribui papéis específicos a diferentes tipos de dados. Alguns sinais são obrigatórios: se uma peça crítica de evidência estiver faltando ou desatualizada, o sistema se recusa a tomar uma decisão. Outros sinais são suficientes por si só: se um erro específico e inegável for encontrado, o sistema para de procurar e nomeia a causa imediatamente.
O sistema executa cinco investigações diferentes em paralelo, cada uma olhando para uma camada diferente da rede, desde os cabos individuais que conectam os servidores até os enormes switches de espinha dorsal que sustentam todo o tecido. Cada investigação usa seu próprio conjunto de regras para decidir se tem provas suficientes para votar em uma causa específica. Se a evidência for clara, ela vota. Se a evidência estiver faltando ou for contraditória, ela se abstém. Esta é uma mudança crucial. No sistema antigo, o computador era forçado a escolher um vencedor mesmo quando não sabia a resposta. No novo sistema, admitir a ignorância é um resultado válido e útil. Quando o sistema se abstém, ele diz aos engenheiros humanos: "Ainda não posso ter certeza", e entrega o caso a eles com um resumo claro do que faltou de dados. Isso evita que o sistema faça suposições confiantes, mas erradas, que poderiam disparar reparos automatizados desnecessários e potencialmente prejudiciais.
Assim que as cinco investigações paralelas terminam, uma segunda camada de lógica entra em cena para combinar seus resultados. Essa lógica entende a forma física da rede. Ela sabe que, se um único switch falhar, pode afetar alguns servidores, mas se um hub de nível superior falhar, causará um efeito cascata que fará com que muitos switches pareçam doentes ao mesmo tempo. O sistema usa regras simples e pré-definidas para decidir qual camada é verdadeiramente responsável. Por exemplo, se um switch de alto nível é suspeito, o sistema verifica se pelo menos dois terços dos switches menores conectados a ele também estão apresentando problemas. Se estiverem, o sistema conclui que o switch de alto nível é a causa raiz e ignora os switches individuais abaixo dele. Isso evita que o sistema se distraia pelos sintomas e culpe o nível errado da rede.
Os resultados da implementação deste sistema em mais de sessenta regiões da nuvem Azure têm sido impressionantes. Ao longo de três anos, o sistema processou mais de 700.000 incidentes. A taxa de alarmes falsos, onde o sistema culpava um dispositivo saudável, caiu de quase vinte por cento para menos de um por cento. Ao mesmo tempo, o número de vezes que o sistema identificou corretamente o problema sem precisar de ajuda humana aumentou significativamente. Talvez o mais importante seja que o sistema eliminou a necessidade de três engenheiros em tempo integral para revisar e reconciliar manualmente dados conflitantes para cada incidente. Os engenheiros que costumavam passar horas desembaraçando esses nós agora recebem um relatório claro e estruturado que diz exatamente o que o sistema encontrou, o que ele não conseguiu decidir e onde devem procurar a seguir.
O sucesso do CoreSec reside em sua recusa em adivinhar. Ao tratar a fusão de diferentes fontes de dados como um problema de composição, em vez de um jogo de pontuação, o sistema alcança um nível de estabilidade que era anteriormente impossível. Ele não depende de modelos complexos de aprendizado de máquina que podem mudar seu comportamento conforme a rede evolui. Em vez disso, utiliza um conjunto fixo de regras lógicas que provaram funcionar em diferentes hardwares, diferentes padrões de tráfego e diferentes designs de datacenter sem precisar de novo ajuste. O sistema mostrou que, em um mundo de informações ruidosas e incompletas, a ferramenta mais poderosa é frequentemente a capacidade de dizer: "Eu não sei", e esperar por evidências melhores. Essa abordagem transformou a análise de causa raiz de um jogo de probabilidade em um processo confiável e explicável, permitindo que a nuvem permaneça estável mesmo enquanto continua a crescer em tamanho e complexidade.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.