Os Tres Conceitos de Falha que Devem Ser Conhecidos
Bem-vindo
Os sistemas distribuídos falham em padrões. Assim que você aprende os padrões, todo postmortem se torna um exercício de reconhecimento em vez de um mistério.
Três conceitos cobrem a maioria do que importa na análise de falhas em produção:
Ponto único de falha (SPOF): um componente cuja falha traz baixa em um sistema maior. Muitas vezes escondido: o servidor DNS que todos dependem; o certificado que tudo renova contra; o banco de dados mestre único.
Falha em cadeia: a falha de um componente dispara outra, que dispara outra. Um banco de dados lento causa timeouts na camada de API, que causa tentativas, que carrega o banco de dados ainda mais, que causa mais timeouts. A explosão se espalha.
Raio de explosão: quanto da rede vai abaixo quando uma peça falha. Escolhas arquiteturais either limitam ou não limitam o raio. Uma SPOF tem raio de explosão ilimitado. Um serviço bulkhead tem raio limitado.
Ao final desta lição você será:
- Capaz de identificar SPOFs em uma arquitetura por inspeção
- Reconhecer padrões de falha em cadeia: tropa de furia, tempestade de tentativas, fila da morte
- Ler um verdadeiro cronograma & separar o gatilho da defeito latente que o gatilho revelou
- Escrever itens de ação sem culpas que alvejem os sistemas em vez das pessoas, cobrindo prevenção / detecção / recuperação
- Razão sobre bulkheads & interruptores de corrente como ferramentas para limitar o raio de explosão
Spot the Single Point of Failure
Inspeção da Arquitetura Camadas
Considere uma pequena arquitetura web:
- DNS: api.example.com -> único IP do servidor de nomes 203.0.113.10 hospedado por um único provedor de DNS
- CDN: único fornecedor de CDN na frente de api.example.com
- Ingresso: duas máquinas de proxy reverso atrás de um balanceador de carga
- Backend: seis réplicas de API nas duas zonas de disponibilidade (três por zona)
- Banco de dados: um primário + um secundário, na mesma zona de disponibilidade
- Cache: cluster Redis, três nós espalhados pelas mesmas duas zonas de disponibilidade
Pergunta: quais componentes são SPOFs? Ponto de atenção: SPOFs não são sempre a 'única máquina' óbvia. Um cluster de três máquinas todas em uma única zona de disponibilidade é um SPOF para a falha da zona.
Tres 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 de nível superior, em vez de falhar, tentam novamente. As tentativas se multiplicam pelo carregamento original. O serviço lentifica ainda mais, disparando mais tentativas. Eventualmente, o carregamento 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 consumidor exaure memória; crasha; reinicia; encontra uma fila ainda maior; crasha 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 Sombreamento. Clientes que recalam esperam mais cada vez, com desvio aleatório. Evita ondas sincronizadas de tentativas.
Fechadura de Circuito. Um chamador rastreia a taxa de falha downstream. Acima de um limiar, o chamador para de 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. Pool de conexões A para banco de dados, pool de conexões B para cache. Um banco de dados lento não pode privar todas as conexões; chamadas para cache continuam.
Descarte de Carga. Quando sobrecarregado, rejeita 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. Lentificar produtores quando consumidores não conseguem acompanhar. Filtros se tornam limitadas; emissores bloqueiam; a fonte original de trabalho sente a fricção.
Diagnose a Cascade
Equipes de API derretem durante uma failover de banco de dados padrão. Cronologia:
- 14:00:00 — operador promove banco de dados reserva. Inesperada indisponibilidade: ~ 10 segundos.
- 14:00:08 — primário indisponível. Perguntas 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 — pool de conexões do novo primário exausto; 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 de tráfego gradual completa. Total de interrupção: ~ 10 minutos (contra o esperado ~ 10 segundos).
SERVFAIL DNS: Dois Defeitos Compensadores
Um Postmortem de Verdadeira-Forma
O que se 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 permitidos allow-axfr-ips do primário.
2. A zona example.com tinha um conflito de CNAME de anos de idade (RFC-violating) (demo.example.com tinha tanto CNAME quanto MX/TXT no mesmo rótulo) que causou o fornecedor A a rejeitar a zona em AXFR recém.
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 expirada; 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 CNAME)
- 20:07 — check-zone revela 1 erro: conflito 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 AXFR afetou todas as zonas. Mas apenas example.com tinha o conflito CNAME e apenas 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 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 antes da violação foi introduzida. 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 uma nova IP de sincronização. A lista de permitidos da primária não a incluiu. AXFR negado. Três horas depois (SOA expirada), 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 isto antes do lançamento' é inocente.
As boas ações de ação inocente se agrupam em três dimensões:
- Prevenção: tornar a coisa rua 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 fechadas para água: paredes verticais que dividem a quilha 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 e a mesma ideia.
Padrão de bulkhead: isolar recursos por dependência. Um serviço que chama três APIs downstream utiliza 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 ficam bloqueadas esperando 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 estadoful em torno de uma dependência downstream que rastreia a taxa de falha. Três estados:
- Fechado (normal): as chamadas passam direto. Falhas contadas.
- Aberto (trancado): após um limiar de falha (digamos, 50% de 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 uma pequena fração de chamadas. Se elas forem bem-sucedidas, ele volta ao normal. Se falharem, ele reabre para outro período de arrefecimento.
A chave: o interruptor de circuito evita esforço desperdiçado durante períodos de desconhecimento, e dá à dependência 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.
Limite 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 continue saudável.
Hoje, o serviço utiliza uma única pool de 200 threads compartilhados e uma única pool de conexões HTTP compartilhados. Todos os quatro downstreams competem por essas recursos. Não há circuit breakers.
Projete uma Revisão de Modo de Falha
Síntese
Aprendeu a identificar SPOFs por inspeção, reconhecer padrões de falha em cascata, separar defeito de desvio quando lê uma postmortem, escrever ações culpadas sem culpa em prevenção / detecção / recuperação e limitar o raio de explosão com bulkheads + circuit breakers + degradação graciosa.
Aplique todos os cinco.
Seu time 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 uma postmortem de forma produtiva, escrever ações culpadas sem culpa 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. Checagem de saúde, pontos de extremidade de versão, as quatro sinais dourados 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 entreza centralidade (qual nó de gráfico é a garganta) e corte mínimo (a limitação do raio de explosão).
Bem feito. Adiante.