Non fermatevi al primo guasto.
Il primo guasto che trovate non è quasi mai l'unico. Il nostro metodo per districare un collasso a più cause: ordinare le cause per contributo e non per rumore, leggere le fonti primarie a livello di kernel invece dei dashboard, sfogliare un guasto alla volta, e trattare ogni sintomo che ritorna come una diagnosi completamente nuova.
In questo articolo 6 sezioni
- In un collasso a più guasti, diversi guasti indossano lo stesso sintomo nello stesso momento. Sistemare il più rumoroso sembra un progresso e non cambia quasi nulla.
- Il metodo: ordinate le cause per contributo, non per rumore. Sistemate in quell'ordine. Misurate di nuovo al confine che ha ceduto dopo ogni singola modifica.
- Quando una correzione regge e il sintomo ritorna, non riapplicate la correzione. Rifate la diagnosi da zero. Stesso sintomo non significa stessa causa.
- Anche il recupero ha un ordine: fermate prima il fattore scatenante prossimo, dimostrate lo stato prima di qualsiasi mossa distruttiva, mantenete ogni passo reversibile.
Il vostro sito collassa. Qualcuno trova un guasto plausibile, lo sistema e dichiara vittoria. Il sito resta giù, oppure torna su e ricollassa al prossimo fattore scatenante. La correzione si è fermata al primo guasto, e nei giorni peggiori ce ne sono altri quattro dietro. Questa è la disciplina che non si ferma.
Regola uno: ordinate per contributo, non per rumore
Il sintomo più rumoroso è una pessima chiave di ordinamento. Esempio: il kernel grida contesa sull'I/O del disco, ma il motore della cascata è un resolver in stallo che tiene occupato ogni worker, e il maggiore fattore in corso è una tempesta di file di sessione che nessuna prima teoria includeva. Ordinate le cause in base a quanta parte del collasso possiedono, e sistemate in quell'ordine.
- Contesa sull'I/O del disco (il sintomo rumoroso)
- Il job che tutti sospettano
- Il resolver che nessuno sospetta
- Il resolver: il motore
- La tempesta di sessioni: il fattore maggiore
- Il job: reale, non il fattore
Regola due: leggete le fonti primarie, non i dashboard
I dashboard riassumono. I kernel testimoniano. Quando i livelli non sono d'accordo, vince il kernel. Il primo passaggio canonico su qualsiasi macchina Linux incastrata è la stessa breve lista ogni volta, e poi un'euristica che vale la pena incorniciare: margine presente e sito giù significano un guasto dell'applicazione o di una dipendenza, non di capacità. Un disco a frazioni di percento di utilizzo mentre i worker sono appesi è contesa sui lock, non I/O, qualunque cosa dica il grafico.
# 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?Dieci minuti di fonti primarie battono un pomeriggio di archeologia sui dashboard.
Regola tre: sfogliate un guasto alla volta
Una modifica, poi misurate di nuovo al confine che ha ceduto, prima di toccare il livello successivo. La disciplina sembra lenta ed è la cosa più veloce disponibile, perché due modifiche simultanee che interagiscono non vi dicono nulla di nessuna delle due. La verifica è per livello: sistemate il resolver, dimostrate la risoluzione dei nomi sulla macchina; smaltite la tempesta, dimostrate gli stati dei worker; poi salite.
Regola quattro: diffidate del momento «l'abbiamo sistemato»
Quando una correzione regge e il sintomo ritorna ore dopo, il riflesso è riapplicare la correzione più forte. Misurate di nuovo, invece. La domanda da porre è quella semplice: come sapete che sta facendo I/O? Pochi secondi di strace che catturano zero chiamate di sistema significano che i worker sono bloccati nel kernel su un lock, non stanno facendo I/O affatto, ed è così che il vero fattore viene trovato invece di essere coperto. Quando un sintomo ritorna dopo una correzione autentica, è un guasto diverso con gli stessi vestiti addosso.
Regole da cinque a sette: anche il recupero ha un ordine
Fermate il fattore scatenante prossimo prima di toccare la causa.
Se un polling di monitoraggio è ciò che manda in crash un cluster, fermate prima il polling, recuperate la posizione, rimuovete la causa, e solo allora applicate la modifica pianificata a un cluster sano.
Dimostrate lo stato prima di qualsiasi mossa distruttiva.
Un volume segnalato come corrotto riceve un controllo di integrità in sola lettura prima che qualcuno rimuova un flag o metta mano a un restore. Il recupero stesso ha delle trappole. Conoscetele prima di fare il passo.
Mantenete ogni passo reversibile.
Backup prima di toccare. Spostate da parte, non cancellate. Ricaricate, non riavviate, sotto carico. La mossa di panico che non può essere annullata non è mai la mossa.
Regola otto: chiudete la falla per tutti
Ogni nuovo schema di guasto diventa un controllo pre-volo con un nome nella configurazione di riferimento. Il metodo non è solo il modo in cui una brutta mattina viene districata. È il modo in cui si impedisce che la stessa mattina si ripeta altrove.
Risposte dirette
Perché il problema del mio server ritorna dopo ogni correzione?+
Perché l'incidente ha più di una causa e ogni correzione ne ha affrontata una. Quando una correzione regge e il sintomo ritorna, rifate la diagnosi dai principi primi. Stesso sintomo non significa stessa causa.
Come trovo la vera causa radice di un carico alto sul server?+
Fonti primarie prima di tutto: dmesg per OOM e task appesi, iostat per verificare se il disco è davvero occupato, lo stack di un processo o pochi secondi di tracing per vedere dove sono bloccati i worker. Ordinate ciò che trovate per contributo al collasso, non per quanto sembra rumoroso.
Cosa significa quando il carico è alto ma il disco è inattivo?+
Di solito contesa sui lock o una dipendenza in stallo, non capacità. Margine presente mentre il sito è giù indica un guasto dell'applicazione o di una dipendenza, e aggiungere risorse non cambia nulla.
Devo riavviare un servizio che va in crash per sistemarlo?+
Non finché il fattore scatenante è ancora attivo. Se qualcosa continua a ucciderlo, un riavvio rimanda in esecuzione il crash. Fermate prima il fattore scatenante prossimo, poi rimuovete la causa, poi riavviate in uno stato sano.
Qual è un buon metodo per il post-mortem di un incidente?+
Elencate ogni guasto che ha contribuito, non solo il primo. Ordinate per contributo. Registrate l'indizio che ha smascherato ciascuno. E trasformate ogni falla in un controllo pre-volo permanente, così che non possa allinearsi di nuovo. Se un post-mortem ha esattamente una causa per un collasso totale, leggetelo due volte.
Un secondo parere su un incidente ostinato?
Se continua a ritornare, ha più cause di quelle che l'ultimo report ha trovato. Portateci la storia dei sintomi; noi porteremo il metodo.
Parla con un ingegnereSiete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere