Não pare na primeira falha.
A primeira falha que encontra quase nunca é a única. O nosso método para desembaraçar um colapso com várias causas: classifique as causas por contribuição e não por intensidade, leia fontes primárias ao nível do kernel em vez de dashboards, descasque uma falha de cada vez, e trate qualquer sintoma que regressa como um diagnóstico totalmente novo.
Neste artigo 6 secções
- Num colapso com várias falhas, várias falhas vestem o mesmo sintoma ao mesmo tempo. Corrigir a mais ruidosa parece progresso e quase nada muda.
- O método: classifique as causas por contribuição, não por intensidade. Corrija por essa ordem. Volte a medir na fronteira que falhou depois de cada alteração.
- Quando uma correção se mantém e o sintoma regressa, não reaplique a correção. Volte a diagnosticar do zero. O mesmo sintoma não significa a mesma causa.
- A recuperação também tem uma ordem: pare primeiro o gatilho imediato, prove o estado antes de qualquer ação destrutiva, mantenha cada passo reversível.
O seu website colapsa. Alguém encontra uma falha plausível, corrige-a e declara vitória. O website continua em baixo, ou volta e colapsa de novo ao gatilho seguinte. A correção parou na primeira falha, e nos piores dias há mais quatro atrás dela. Esta é a disciplina que não para.
Regra um: classifique por contribuição, não por intensidade
O sintoma mais ruidoso é uma péssima chave de ordenação. Exemplo: o kernel grita disk I/O contention, mas o motor da cascata é um resolver bloqueado que segura todos os workers, e o maior fator em curso é uma tempestade de ficheiros de sessão que nenhuma primeira teoria incluía. Classifique as causas pela fatia do colapso que lhes pertence, e corrija por essa ordem.
- Disk I/O contention (o sintoma ruidoso)
- O job de que todos suspeitam
- O resolver de que ninguém suspeita
- O resolver: o motor
- A tempestade de sessões: o maior fator
- O job: real, mas não o fator
Regra dois: leia fontes primárias, não dashboards
Os dashboards resumem. Os kernels testemunham. Quando as camadas discordam, ganha o kernel. A primeira passagem canónica em qualquer máquina Linux encravada é a mesma lista curta de todas as vezes, e depois uma heurística que merece moldura: margem presente e website em baixo significa falha de aplicação ou de dependência, não de capacidade. Um disco a frações de um por cento de utilização enquanto os workers ficam pendurados é lock contention, não I/O, diga o gráfico o que disser.
# the canonical first pass on a wedged Linux box
dmesg -T | tail -50 # OOM kills, hung tasks, hardware complaints
journalctl --list-boots # did this box reboot when you think it did?
last -x reboot | head # corroborate the reboot story
cat /etc/resolv.conf # who does this box think answers DNS?
iostat -x 5 3 # is the disk actually busy, or just blamed?
cat /proc/<pid>/stack # where exactly is that worker stuck?
strace -p <pid> -c -f # a few seconds: is it even making syscalls?Dez minutos de fontes primárias valem mais do que uma tarde de arqueologia em dashboards.
Regra três: descasque uma falha de cada vez
Uma alteração, e depois nova medição na fronteira que falhou, antes de tocar na camada seguinte. A disciplina parece lenta e é a coisa mais rápida que existe, porque duas alterações simultâneas que interagem não dizem nada sobre nenhuma delas. A verificação é por camada: corrija o resolver, prove a resolução de nomes na máquina; limpe a tempestade, prove os estados dos workers; depois suba.
Regra quatro: desconfie do momento «já está corrigido»
Quando uma correção se mantém e o sintoma regressa horas depois, o reflexo é reaplicar a correção com mais força. Volte a medir em vez disso. A pergunta a fazer é a mais simples: como sabe que está a fazer I/O? Alguns segundos de strace que apanham zero system calls significam que os workers estão bloqueados no kernel à espera de um lock, sem fazer I/O nenhum, e é assim que o verdadeiro fator é encontrado em vez de tapado. Quando um sintoma regressa depois de uma correção genuína, é uma falha diferente com a mesma roupa.
Regras cinco a sete: a recuperação também tem uma ordem
Pare o gatilho imediato antes de tocar na causa.
Se é um poll de monitorização que está a derrubar um cluster, pare primeiro o poll, recupere a posição, remova a causa, e só então aplique a alteração planeada a um cluster saudável.
Prove o estado antes de qualquer ação destrutiva.
Um volume marcado como corrompido recebe uma verificação de integridade só de leitura antes de alguém limpar uma flag ou recorrer a um restore. A própria recuperação tem armadilhas. Conheça-as antes de dar o passo.
Mantenha cada passo reversível.
Backup antes de tocar. Ponha de lado, não apague. Reload, não restart, sob carga. A ação de pânico que não se pode desfazer nunca é a ação certa.
Regra oito: feche o buraco para todos
Cada novo padrão de falha torna-se uma verificação prévia com nome na configuração de referência. O método não é só a forma como uma manhã má se desembaraça. É a forma como essa mesma manhã é impedida de se repetir em qualquer outro lado.
Respostas diretas
Porque é que o problema do meu servidor volta depois de cada correção?+
Porque o incidente tem mais do que uma causa e cada correção tratou de uma. Quando uma correção se mantém e o sintoma regressa, volte a diagnosticar a partir dos princípios básicos. O mesmo sintoma não significa a mesma causa.
Como encontro a verdadeira causa raiz de um load elevado no servidor?+
Fontes primárias primeiro: dmesg para OOM e hung tasks, iostat para testar se o disco está realmente ocupado, uma process stack ou alguns segundos de tracing para ver onde os workers estão presos. Classifique o que encontrar pela contribuição para o colapso, não pelo ruído que faz.
O que significa quando o load está alto mas o disco está parado?+
Normalmente lock contention ou uma dependência bloqueada, não capacidade. Margem presente enquanto o website está em baixo aponta para uma falha de aplicação ou de dependência, e acrescentar recursos não muda nada.
Devo reiniciar um serviço que está a falhar para o corrigir?+
Não enquanto o gatilho continuar vivo. Se algo o está a matar repetidamente, um restart repete o crash. Pare primeiro o gatilho imediato, depois remova a causa, depois reinicie para um estado saudável.
Qual é um bom método de post-mortem de incidente?+
Liste todas as falhas que contribuíram, não só a primeira. Classifique por contribuição. Registe o sinal que expôs cada uma. E transforme cada buraco numa verificação prévia permanente para que não se volte a alinhar. Se um post-mortem tem exatamente uma causa para um colapso total, leia-o duas vezes.
Uma segunda opinião sobre um incidente teimoso?
Se continua a voltar, tem mais causas do que as que o último relatório encontrou. Traga-nos o histórico dos sintomas, nós trazemos o método.
Fale com um engenheiroChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro