Hören Sie nicht beim ersten Fehler auf.

Ihre Site bricht zusammen. Jemand findet einen plausiblen Fehler, behebt ihn und erklärt den Sieg. Die Site bleibt unten, oder sie kommt zurück und bricht beim nächsten Auslöser erneut zusammen. Die Korrektur hat beim ersten Fehler aufgehört, und an den schlimmsten Tagen stecken dahinter vier weitere. Das hier ist die Disziplin, die nicht aufhört.

Regel eins: nach Beitrag ordnen, nicht nach Lautstärke

Das lauteste Symptom ist ein schrecklicher Sortierschlüssel. Beispiel: Der Kernel schreit nach Disk-I/O-Contention, aber der Motor der Kaskade ist ein hängender Resolver, der jeden Worker festhält, und der größte fortlaufende Treiber ist ein Sturm von Session-Dateien, den keine erste Theorie enthielt. Ordnen Sie die Ursachen danach, wie viel des Zusammenbruchs ihnen gehört, und beheben Sie sie in dieser Reihenfolge.

Regel zwei: Primärquellen lesen, nicht Dashboards

Dashboards fassen zusammen. Kernel sagen aus. Wenn die Ebenen sich widersprechen, gewinnt der Kernel. Der kanonische erste Durchgang auf jeder festgefahrenen Linux-Maschine ist jedes Mal dieselbe kurze Liste, und dann eine Faustregel, die es wert ist, eingerahmt zu werden: Reserve vorhanden und Site unten bedeutet einen Fehler in der Anwendung oder einer Abhängigkeit, nicht in der Kapazität. Eine Festplatte bei Bruchteilen eines Prozents Auslastung, während Worker hängen, ist Lock-Contention, nicht I/O, egal was der Graph sagt.

# 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?

Zehn Minuten Primärquellen schlagen einen Nachmittag Dashboard-Archäologie.

Regel drei: einen Fehler nach dem anderen abschälen

Eine Änderung, dann an der Grenze neu messen, die ausgefallen ist, bevor Sie die nächste Ebene anfassen. Die Disziplin fühlt sich langsam an und ist das Schnellste, was es gibt, denn zwei gleichzeitige Änderungen, die sich gegenseitig beeinflussen, sagen Ihnen über keine von beiden etwas. Die Verifikation erfolgt pro Ebene: Resolver reparieren, Namensauflösung auf der Maschine beweisen; Sturm beseitigen, Worker-Zustände beweisen; dann nach oben gehen.

Regel vier: dem «Wir haben es behoben»-Moment misstrauen

Wenn eine Korrektur hält und das Symptom Stunden später zurückkehrt, ist der Reflex, die Korrektur noch härter erneut anzuwenden. Messen Sie stattdessen neu. Die Frage, die zu stellen ist, ist die einfache: Woher wissen Sie, dass es I/O macht? Ein paar Sekunden strace, die null Systemaufrufe einfangen, bedeuten, dass die Worker im Kernel auf einem Lock blockiert sind und gar kein I/O machen, und so wird der eigentliche Treiber gefunden, statt übertüncht zu werden. Wenn ein Symptom nach einer echten Korrektur zurückkehrt, ist es ein anderer Fehler in denselben Kleidern.

Regeln fünf bis sieben: auch die Wiederherstellung hat eine Reihenfolge

Regel acht: das Loch für alle schließen

Jedes neue Fehlermuster wird zu einer benannten Vorabprüfung in der Referenzkonfiguration. Die Methode ist nicht nur die Art, wie ein schlechter Morgen entwirrt wird. Sie ist die Art, wie derselbe Morgen daran gehindert wird, sich irgendwo anders zu wiederholen.