Três Padrões Clássicos de Cascata

Falhas Viajam Pelos Dependências

Padrão 1: Turba de Trovão. Um recurso compartilhado (cache, trava, banco de dados) falha ou reinicia. Cada cliente que dependia dele tenta novamente simultaneamente. A onda de tentativas supera o que volta; as tentativas se amontoam mais rápido do que a recuperação pode absorvê-las; a recuperação nunca é concluída.

Padrão 2: Tempestade de Recursos. Um serviço downstream lentifica. Chamadores upstream, em vez de falhar, tentam novamente. As tentativas multiplicam a carga original. O serviço downstream lentifica ainda mais, disparando mais tentativas. Eventualmente, a carga excede até uma versão saudável do serviço.

Padrão 3: Filas de Morte. Uma fila de processamento sem pressão de back recebe mais rápido do que processa. A fila cresce ilimitadamente. O memória se exaure; o consumidor cai; reinicia; encontra uma fila ainda maior; cai novamente.

Fio comum: uma pequena perturbação inicial dispara um loop de feedback positivo. A resposta do sistema amplifica a falha em vez de amortecê-la.

Mecanismos de Amortecimento

Atraso Exponencial com Trote. Clientes que reciclaram esperam mais cada vez, com desvio aleatório. Evita ondas sincronizadas de tentativas.

Fechador de Circuito. Um chamador rastreia a taxa de falha downstream. Passando um limiar, o chamador para chamar por um período de resfriamento e falha imediatamente em suas próprias solicitações. Evita trabalho desperdiçado e permite que o downstream recupere.

Bulkhead. Isolar recursos por dependência. Piscina de conexões A para banco de dados, piscina de conexões B para cache. Um banco de dados lento não pode privar todas as conexões; chamadas de cache continuam.

Descarte de Carga. Quando sobrecarregado, descarta solicitações na borda em vez de aceitá-las e falhar lentamente. Um 429 em 1 ms é melhor do que um 500 em 30 segundos.

Pressão de Back. Lenta produção quando consumidores não conseguem acompanhar. Filtros se tornam limitados; emissores bloqueiam; a fonte original de trabalho sente a fricção.

Diagnostique uma Cascata

Um time de camada de API derrete durante uma failover de banco de dados rotineira. Cronologia:

- 14:00:00 — operador promove banco de dados reserva. Inesperada indisponibilidade: ~10 segundos.

- 14:00:08 — primário indisponível. Peticionamentos de API tier começam a falhar com erros de conexão de banco de dados.

- 14:00:08 — API tier tenta novamente (configuração padrão: 5 tentativas, sem atraso, 100ms de intervalo).

- 14:00:11 — reserva promovida, aceitando novas conexões.

- 14:00:11 — API tier abre milhares de novas conexões de banco de dados simultaneamente (cada réplica × cada solicitação concorrente × cada tentativa).

- 14:00:13 — nova conexão do pool de conexões do primário exaurida; novas conexões rejeitadas.

- 14:00:13-14:05:00 — réplicas do API tier exaurem pools de conexões, lançam exceções, param, reiniciam, repetem.

- 14:05:00 — operador para o tráfego do API tier; banco de dados se estabiliza.

- 14:10:00 — restauração gradual de tráfego completa. Total de interrupção: ~10 minutos (contra o esperado de ~10 segundos).

SERVFAIL DNS: Dois Defeitos Compensadores

Um Postmortem de Verdadeira Forma

O que segue é uma versão desinfectada de um incidente real. Nomes de fornecedores alterados, IPs anonimizadas; a forma, a cronologia e as lições são reais.

Resumo

O site example.com retornou SERVFAIL de todos os resolvers de DNS públicos por aproximadamente 3-4 horas. Todas as outras 46 zonas no mesmo mestre de DNS foram afetadas. Causa raiz: dois defeitos compensadores.

1. O fornecedor A (um provedor secundário de DNS) adicionou uma nova IP de sincronização interna que não estava na lista de allowlist allow-axfr-ips primária.

2. A zona example.com tinha um conflito de CNAME de anos de idade que violava o RFC (demo.example.com tinha tanto CNAME quanto MX/TXT na mesma etiqueta) que fez o fornecedor A rejeitar a zona em AXFR fresca.

Cronologia (UTC)

- ~15:00 — O fornecedor A adiciona nova IP de sincronização 198.51.100.42 à sua infraestrutura

- 15:02 — primeira AXFR-out negada para 198.51.100.42 aparece nos logs DNS primários (nenhuma alerta neste sinal)

- ~18:00 — janela SOA expirou; O Vendedor A lança a zona example.com do cache

- ~18:30 — SERVFAIL detectado externamente

- ~19:45 — causa raiz identificada

- 20:00 — 198.51.100.42 adicionado à allow-axfr-ips; primário reiniciado

- 20:05 — NOTIFY enviado; AXFR iniciado; zona AINDA SERVFAIL (conflito de CNAME)

- 20:07 — check-zone revela 1 erro: conflito de CNAME em demo.example.com

- 20:09 — CNAME substituído por A; verificação da zona limpa (0 erros)

- 20:10 — NOTIFY enviado; AXFR completa; O Vendedor A começa a servir a zona

- 20:11 — dig @8.8.8.8 example.com A retorna a correta IP — RESOLVIDO

Por que apenas example.com?

As 47 zonas compartilham o mesmo DNS primário. A bloco de IPs AXFR afetou todas as zonas. Mas apenas o example.com teve o conflito de CNAME e apenas o example.com precisava de um AXFR fresco no momento em que a negação foi aplicada. As outras zonas já haviam atualizado antes da negação ou ainda não precisavam.

Defeito latente

O conflito de CNAME em demo.example.com existia há anos. Funcionava porque o primário servia a zona do seu banco de dados (generoso em relação às violações de RFC) e o Vendedor A servia de dados cache velhos desde antes da introdução da violação. Quando o Vendedor A lançou sua cache e precisou de dados frescos, a violação surgiu.

Desencadeador

O Vendedor A adicionou em silêncio um novo IP de sincronização. A lista de permitidos do primário não o incluiu. AXFR negado. Três horas depois (SOA expirou), o Vendedor A lançou a zona. O defeito latente surgiu quando o sistema tentou recuperar.

Escreva Ações de Ação Inocente

Inocente: Alvos Sistemas, Não Pessoas

Uma ação de ação inocente nomeia algo que o sistema deve fazer diferente, não algo que uma pessoa deve fazer diferente. 'Treine o operador' é culpável. 'Adicione uma verificação automática que capture isso antes do lançamento' é inocente.

As boas ações de ação inocente se agrupam em três dimensões:

- Prevenção: tornar a má coisa mais difícil ou impossível

- Detecção: perceber mais cedo se acontece

- Recuperação: limitar os danos quando acontece

Cada item deve nomear (1) a mudança específica no sistema, (2) uma equipe de propriedade e (3) a dimensão que atende.

Compartimentos Que Afundam Sem O Navio

Empréstimo da Engenharia Naval

Navios carregam bulkheads d'água-tight: paredes verticais que dividem o casco em compartimentos. Um compartimento pode ser inundado sem afundar o navio; outro pode falhar sem afetar o resto.

Sistemas distribuídos emprestam a mesma palavra & a mesma ideia.

Padrão de bulkhead: isolar recursos por dependência. Um serviço que chama três APIs downstream usa três pools de conexões separados, três orçamentos de threads separados, três orçamentos de repetição separados. Uma API downstream lenta ou falhando não pode consumir os recursos alocados para as outras duas.

Sem bulkheads: uma dependência lenta exaure a pool de threads compartilhada; chamadas para outras dependências bloqueiam esperando por threads; o serviço inteiro se torna inoperante.

Com bulkheads: uma dependência lenta exaure sua própria pool; chamadas para ela falham rapidamente; chamadas para outras dependências continuam normalmente; o raio de explosão fica limitado à dependência falhando.

Interruptores de Circuito

Padrão de interruptor de circuito: um wrapper estatal em torno de uma dependência downstream que rastreia a taxa de falha. Três estados:

- Fechado (normal): chamadas passam por dentro. Falhas contadas.

- Aberto (trancado): após um limiar de falha (digamos, 50% falhas nas últimas 30 segundos), o interruptor abre. As chamadas falham imediatamente sem tentar a dependência. Salva o chamador de desperdício de trabalho; salva a dependência de receber carga enquanto está doente.

- Meio-aberto (testando): após um período de arrefecimento, o interruptor permite que uma pequena fração de chamadas passe por dentro. Se elas tiverem sucesso, ele volta ao normal. Se falharem, ele volta a abrir por outro período de arrefecimento.

A chave: o interruptor de circuito evita esforço desperdiçado durante períodos de conhecumente-in Saudável, & dá para a downstream uma chance de se recuperar sem carga contínua.

Bulkheads limitam o raio de explosão. Interruptores de circuito evitam a explosão se sustentar.

Limita o Raio de Explosão

Seu serviço de API faz quatro chamadas para serviços downstream: Serviço de Usuário, Serviço de Recomendação, Serviço de Notificação e uma API de Pagamento de terceiros. A equipe já ouviu dizer que 'o Serviço de Recomendação tem sido um pouco instável' e quer garantir que, quando falha, o resto do sistema fique saudável.

Hoje, o serviço usa uma única fila de threads compartilhada com 200 threads e uma única pool de conexões HTTP compartilhada. Todos os quatro downstreams competem por essas recursos. Não há circuit breakers.

Projete uma Revisão de Modo de Falha

Síntese

Aprenderam a identificar SPOFs por inspeção, reconhecer padrões de falha cascata, separar defeito de gatilho ao ler um postmortem, escrever ações culpadas transcorridas pela prevenção / detecção / recuperação, e limitar o raio de explosão com bulkheads + interrupters + degradação graciosa.

Aplicar todos os cinco.

Sua equipe está lançando um novo serviço, search.example.com, que depende de três serviços downstream: um índice de pesquisa primário (index.example.com), um serviço de análise (analytics.example.com) e um serviço de recomendações (recs.example.com). A equipe quer que você liderie uma 'revisão de modo de falha' antes do lançamento.

Onde Este Curso Vai Seguir

Onde Este Curso Vai Seguir

Agora você pode identificar um SPOF, reconhecer uma cascata, ler um postmortem de forma produtiva, escrever ações culpadas e limitar o raio de explosão por design.

A última aula neste curso (cs_distsys_observability_and_capacity) ensina o que medir para descobrir quando um problema está acontecendo antes que os usuários percebam. Controles de saúde, pontos de extremidade de versão, as quatro luzes douradas na camada de proxy e como as decisões de capacidade de surto estão relacionadas aos dados observados.

Aula companheira: geometry_of_failure_modes_and_blast_radius deriva a centralidade de betweenness (qual nó do gráfico é a garganta) e a corte mínima (o limite para o raio de explosão).

Bem feito. Em frente.