Stripe automatiza recuperação de banco de dados com busca em grafos e máquinas de estado

A equipe de engenharia da Stripe descreveu recentemente como automatizou a recuperação de incidentes de banco de dados modelando sua infraestrutura global como um grafo. Combinando algoritmos de busca em grafos com máquinas de estado, o sistema calcula e executa planos de remediação de forma automática.

Segundo os autores, o sistema agora se adapta dinamicamente a diferentes layouts de shards do MongoDB, reduzindo em cerca de 30% os alertas de pager relacionados a banco de dados. Na prática, são 200 pages a menos por ano e a eliminação de cerca de 12 dias anuais de shards em estado não saudável.

O problema do sistema hard-coded

A Stripe conta que seu sistema original de remediação, baseado em plugins e com sequências fixas (hard-coded), não escalava bem. Dependências frágeis, cenários de múltiplas falhas, lógica específica de layout e estados intermediários não tratados exigiam intervenção manual com frequência.

Os números ajudam a dimensionar o incômodo: em uma janela de seis meses, o control plane acionou operadores 124 vezes por shards mal configurados e 32 vezes por cenários de nó único fora do ar complicados por outros problemas de saúde. Operações críticas como builds de índice e manutenções planejadas ficaram bloqueadas por, em média, uma hora por incidente.

Como funciona o modelo em grafo

A solução foi modelar a infraestrutura MongoDB como um grafo, no qual:

• Nós representam componentes de infraestrutura;
• Arestas capturam as relações entre eles;
• Atributos dos nós descrevem o estado atual de cada componente.

Em vez das sequências fixas de remediação, a Stripe passou a usar traversal de grafo para identificar caminhos de recuperação válidos. Isso permite que a mesma lógica se adapte automaticamente a diferentes layouts de banco e a uma infraestrutura em constante evolução.

Inicialmente o time usou busca em largura (BFS) para encontrar caminhos válidos, mas depois adotou o algoritmo de Dijkstra para priorizar planos de recuperação de menor custo, reduzindo operações desnecessárias sem abrir mão da correção. Um ganho colateral, segundo o texto: como o Dijkstra explora caminhos para todos os estados alcançáveis, e não só o estado-alvo, o sistema oferece remediação parcial. Quando não existe caminho completo, o algoritmo retorna o caminho até o estado "menos mal configurado".

Em vez de embutir a lógica de recuperação em workflows fixos, a Stripe modela a remediação como regras componíveis com transições de estado explícitas, deixando o planejador combinar operações dinamicamente conforme a infraestrutura muda. O time planeja estender o framework para além da recuperação de falhas: automação de mudanças de topologia, deploys blue-green e orquestração de manutenções planejadas junto do healing reativo.

A conclusão dos engenheiros resume o princípio de projeto: "Para times que gerenciam infraestrutura distribuída complexa, esse padrão de modelagem em máquina de estado, planejamento baseado em simulação e pathfinding em tempo de execução oferece uma alternativa convincente a acumular runbooks cada vez mais específicos. Runbooks codificam procedimentos de recuperação conhecidos; uma máquina de estado descobre procedimentos novos."

O que isso muda para quem opera infra no Brasil

O padrão descrito pela Stripe é reaproveitável por qualquer equipe brasileira que mantém frotas de banco de dados em escala e sofre com plantões (on-call) sobrecarregados. Scott MacVicar, head de developer infrastructure da Stripe, escreveu no LinkedIn que operar uma frota global de bancos significa aceitar que degradação de hardware e shards não saudáveis são ocorrências diárias, e que o desafio, em escala, "não é só corrigir problemas. É fazer isso sem esgotar seus engenheiros de plantão."

A Stripe não está sozinha nesse movimento: a InfoQ lembra que a Uber descreveu recentemente sua plataforma declarativa e self-healing Odin, enquanto a Meta detalhou ferramentas assistidas por IA para acelerar a resposta a incidentes.

Para times menores, a lição central independe da escala da Stripe: quando runbooks começam a se multiplicar e a ganhar exceções, vale considerar modelar estados e transições explicitamente e deixar um algoritmo de busca calcular o caminho de recuperação, em vez de codificar cada cenário à mão.

Fonte: InfoQ