Umgang mit Störungen #

Diese Seite richtet sich an Ingenieure in Rufbereitschaft für eine Exponential-Website. Sie gibt eine Abfolge für jede Störung und verweist auf die Runbooks für die häufigen. Sie ersetzt nicht den Störungsprozess Ihrer Organisation; sie ergänzt die Schritte, die für Exponential spezifisch sind.

Inhalt #

1. Die ersten zehn Minuten
2. Symptome und die Werkzeuge dafür
3. Den Schaden stoppen
4. Beheben: vorwärts korrigieren
5. Sicherheitsvorfälle
6. Nach der Störung

Die ersten zehn Minuten #

1. Bestätigen und eingrenzen. Rufen Sie die Startseite und die Anmeldung der Administration von außen auf. Die Startseite kann aus einem Cache ausgeliefert werden, während die Datenbank ausgefallen ist; die Anmeldeseite sagt Ihnen also mehr (Zustandsprüfungen und Verfügbarkeit).
2. Prüfen Sie die Server. ./console exp:velocity status für Velocity; sonst den PHP-FPM-Dienst und den Datenbankserver.
3. Lesen Sie die neuesten Fehler. Setup > Logdateien oder ./console exp:logs; die Fehlerreferenz eines Besuchers führt zu den Zeilen seiner Anfrage (Einen Fehler anhand seiner Referenz finden).
4. Fragen Sie, was sich geändert hat. Der Audit-Trail hält Bereitstellungen, Schreibvorgänge an Einstellungen und das Leeren von Caches mit Wer und Wann fest: ./console exp:audit tail --allow-root-user.
5. Entscheiden Sie: zuerst den Schaden stoppen oder direkt beheben?

Symptome und die Werkzeuge dafür #

Den Schaden stoppen #

• Der Wartungsmodus nimmt die öffentliche Website mit 503 und Retry-After vom Netz und bringt sie mit einem Befehl zurück:

  php bin/php/maintenance.php on --message="Back at 06:00" --until=2h --allow-root-user
  php bin/php/maintenance.php off --allow-root-user

  (Wartungsmodus).

• Schalten Sie die Erweiterung oder Einstellung ab, die die Änderung eingeführt hat, über settings/override/ und ein Leeren des INI-Cache (und einen Neustart von Velocity).

• Stellen Sie aus der Sicherung wieder her, wenn Daten beschädigt sind (Aus der Sicherung wiederherstellen).

Beheben: vorwärts korrigieren #

Korrigieren Sie vorwärts mit einem neuen Commit und, bei einem Release, einer neuen Version. Ein veröffentlichter Tag oder ein Release wird nie verschoben, ersetzt oder neu erstellt, selbst wenn es die Ursache ist; die Notes der nächsten Version sagen, was an der vorherigen falsch war (Versionsnummern und unveränderliche Tags). Bei einer Installation aus Git-Klonen können Sie eine Korrektur nutzen, bevor sie veröffentlicht ist (Mit Git entwickeln).

Sicherheitsvorfälle #

• Eine Schwachstelle in Exponential selbst wird vertraulich an die Adresse in SECURITY.md gemeldet, nicht im öffentlichen Issue-Tracker. Geben Sie Version, Engine und Datenbank an, was ein Angreifer tun kann, und die Schritte zum Reproduzieren, und lassen Sie Passwörter, Geheimnisse und personenbezogene Daten weg.
• Prüfen Sie die Integrität des Audit-Trails (./console exp:audit verify --allow-root-user, Exit-Status 1 bei gebrochener Kette), bevor Sie sich auf ihn als Beweis verlassen.
• Wechseln Sie die Geheimnisse, die ein Angreifer gesehen haben könnte, in settings/override/.

Nach der Störung #

• Schreiben Sie den zeitlichen Ablauf, die Ursache, was sie entdeckt hat und was sie früher entdeckt hätte, auf.
• Fügen Sie den Test hinzu, der sie gefunden hätte (Teststrategie).
• War die Ursache eine Verhaltensänderung, prüfen Sie, ob ihre Upgrade-Hinweise in doc/eng-us/bc/6.0/ sagten, was zu tun ist; wenn nicht, korrigieren Sie sie (Changelogs und Upgrade-Hinweise).
• Melden Sie einen Fehler der Software öffentlich, mit der Diagnose, die die Seite Einen Fehler melden der Hilfe vorbereitet (Wenn etwas schiefgeht).

Verwandte Seiten #

• Beobachtbarkeit: Logs, Debug-Leiste und Audit-Trail
• Runbooks für Hoster
• Fehlersuche
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.