Früher oder später, in jedem Projekt, ist es Zeit, an der Stabilität / Verfügbarkeit Ihres Dienstes zu arbeiten. Bei einigen Diensten ist in der Anfangsphase die Geschwindigkeit der Entwicklung von Funktionen wichtiger, da das Team derzeit nicht vollständig gebildet ist und die Technologien nicht sehr sorgfältig ausgewählt werden. Bei anderen Diensten (häufig technologische b2b) besteht bei der ersten Veröffentlichung die Notwendigkeit einer hohen Verfügbarkeit, um das Vertrauen der Kunden zu gewinnen. Nehmen wir jedoch an, dass der Moment X dennoch gekommen ist und Sie sich darum kümmern, wie viel Zeit Ihr Service im Berichtszeitraum "liegt". Im Rahmen der Kürzung schlage ich vor, zu prüfen, worum es bei den Ausfallzeiten geht und wie am besten daran gearbeitet werden kann, sie zu reduzieren.
Indikatoren
Bevor Sie etwas verbessern, müssen Sie natürlich den aktuellen Status verstehen. Wenn wir also anfingen, Ausfallzeiten zu reduzieren, ist dies zunächst einmal und es ist notwendig, mit der Messung zu beginnen.
Wir werden hier nicht im Detail darüber sprechen, wie dies spezifisch zu tun ist, die Vor- und Nachteile verschiedener Ansätze, aber der Prozess der These sieht ungefähr so aus:
- Wir stützen uns auf geschäftsnahe Kennzahlen (Fehler im Service, Antwortzeit des Service, $ / Sekunde, Anmeldungen / Sekunde usw.).
- Bestimmen Sie, was gut und was schlecht ist
- Übergang gut-> schlecht ist der Beginn eines Vorfalls
- Übergang schlecht-> gut - Ende des Vorfalls
- Zeit von Anfang bis Ende - die Dauer des Vorfalls (Kappe mit uns)
- die Summe der Dauer von Vorfällen für den Zeitraum (Monat / Quartal / Jahr) - Ausfallzeit
- (100 - <Ausfallzeit> / <Periodendauer> * 100) = Prozentsatz der Verfügbarkeit für den Zeitraum
Wenn es um Betriebs- / Ausfallzeiten geht, erwähnen sie oft einen anderen Indikator:
MTTR (mittlere Reparaturzeit) - Die durchschnittliche Zeit vom Beginn des Vorfalls bis zu seinem Ende.
Probleme mit ihm beginnen gleich beim ersten Wort in der Abkürzung. Da alle Vorfälle unterschiedlich sind, kann die Mittelung der Dauer nichts über das System aussagen.
Dieses Mal werden wir nichts mitteln, sondern nur sehen, was während des Vorfalls passiert.
Anatomie eines Vorfalls
Mal sehen, welche wichtigen Schritte während des Vorfalls unterschieden werden können:
- Erkennung - das Intervall zwischen dem ersten Fehler, den wir dem Benutzer gegeben haben, bevor die Telefonzentrale eine SMS erhalten hat
- Reaktion - vom Erhalt einer Benachrichtigung über ein Problem bis zu dem Moment, als eine Person mit der Lösung dieses Problems begann (normalerweise wird das Überwachungsereignis in diesem Moment in den Status Bestätigt versetzt).
- Untersuchung - vom Beginn der Arbeit an einem Problem bis zu dem Moment, an dem die Ursache des Vorfalls verstanden wird und wir wissen, was getan werden muss, um die Arbeit wiederherzustellen.
- Eliminierung - Wiederherstellungszeit, zum Beispiel Rollback-Release, förderte eine neue
Meister primärer Datenbankserver
Vielleicht ist unser Modell unvollständig und es gibt einige andere Phasen, aber ich schlage vor, sie erst einzuführen, nachdem wir erkannt haben, wie dies uns in der Praxis helfen wird. Betrachten Sie in der Zwischenzeit jede Phase genauer.
Erkennung
Warum verbringen wir Zeit damit, einen Notfall zu finden? Warum nicht eine Benachrichtigung über den ersten Fehler senden, den ein Benutzer erhält? Tatsächlich kenne ich viele Unternehmen, die dies versucht haben, aber sie haben diese Idee nur wenige Stunden später aufgegeben, für die sie mehrere zehn SMS erhalten haben. Ich denke, dass es keinen einzigen mehr oder weniger großen Dienst gibt, der keinen konstanten "Hintergrund" -Fehlerstrom aufweist. Nicht alle von ihnen sind ein Zeichen dafür, dass etwas kaputt gegangen ist, es gibt auch Fehler in der Software, ungültige Daten aus dem Formular und unzureichende Validierung usw.
Infolgedessen wird die Fehlerquote (oder andere Metriken), die die täglichen Schwankungen überschreitet, als Kriterium für das Öffnen eines Vorfalls verwendet. Genau dies führt dazu, dass die Benachrichtigung der verantwortlichen Mitarbeiter später erfolgt als der tatsächliche Beginn des Problems.
Aber zurück zu unserer ursprünglichen Aufgabe - die Dauer von Vorfällen zu reduzieren. Wie können wir die Erkennungszeit verkürzen? Schneller zu benachrichtigen? Eine Superlogik zur Erkennung von Anomalien entwickeln?
Ich schlage vor, noch nichts zu tun, sondern die nächsten Phasen zu betrachten, da sie in Wirklichkeit miteinander verbunden sind.
Reaktion
Hier haben wir einen rein menschlichen Faktor. Wir gehen davon aus, dass die Überwachung das Problem erkannt hat und wir den diensthabenden Ingenieur erfolgreich geweckt haben (die gesamte Eskalation hat auch in der vorherigen Phase funktioniert).
Betrachten Sie den "schlimmsten" Fall, wir haben keinen dedizierten Dienst, und die Warnung hat den friedlich schlafenden Administrator erwischt. Seine Handlungen:
- Auf SMS antworten: Hier hilft eine Frau mit einem empfindlichen Ohr sehr, verschiedene Anwendungen für das Telefon, wodurch die Wirkung des SMS-Empfangs verbessert wird (1-5 Minuten).
- Treffen Sie eine Entscheidung, dass er trotzdem aus dem Bett kriecht: Wenn die Warnungen nicht richtig eingestellt sind, kann eine Person 2 Minuten warten. "Was ist, wenn eine Lösung kommt?" und einschlafen (1-15 Minuten)
- Gehen Sie zum Laptop, öffnen Sie die Augen, wachen Sie auf, gehen Sie zur Überwachung, drücken Sie Ack: (1-15 Minuten)
Als Ergebnis erhalten wir im schlimmsten Fall eine Reaktionszeit von 35 Minuten. Nach meinen Beobachtungen scheint eine solche Reaktionszeit wahr zu sein.
Da wir in dieser Phase mit Menschen zu tun haben, müssen wir äußerst sorgfältig und nachdenklich handeln. In keinem Fall müssen Sie eine Vorschrift schreiben, nach der sich eine Person, die gerade aufgewacht ist, bewegen sollte! Lassen Sie uns einfach die Bedingungen erstellen.
Lassen Sie uns die Zweifel des Ingenieurs loswerden, dass das Problem von selbst enden wird. Dies geschieht ganz einfach: Machen Sie das Warnkriterium unempfindlich gegenüber geringfügigen Problemen und benachrichtigen Sie, wenn der Vorfall eine längere Zeit dauert . Ja, wir haben gerade die Dauer der "Erkennungs" -Stufe verlängert, aber schauen wir uns ein Beispiel an:
- Erhöhen Sie die Erkennungszeit um 5 Minuten
- Die Anzahl der Vorfälle wird reduziert: Alle kurzen Fehlerausbrüche fallen normalerweise innerhalb von 1 Minute. Diese kurzen Vorfälle müssen aufgezeichnet werden, ohne jedoch Personen zu benachrichtigen. Oft verursachen sie insgesamt sehr große Ausfallzeiten, aber Sie können sie während der Geschäftszeiten bearbeiten. Für diese Aufgabe benötigen Sie eine hohe Granularität bei der Überwachung, da das Problem bereits behoben ist und Diagnosetools den Verlauf größtenteils nicht speichern.
- Wenn eine Person gezwungen ist, einmal im Monat oder seltener und nicht jeden zweiten Tag auf Warnungen zu reagieren, wird sie angemessener darauf reagieren und dies nicht als Routine behandeln
- Eine verspätete Benachrichtigung lässt eine Person nicht denken: Wenn eine SMS eintrifft, ist alles ernst und wird nicht selbst korrigiert
Möglicherweise reduziert dieser Ansatz die Gesamtreaktionszeit um mehr als 15 Minuten. Wenn eine solche Reaktionszeit nicht zu Ihnen passt, sollten Sie über den Dienst nachdenken.
Untersuchung
Vielleicht ist dies die schwierigste Phase eines Unfalls, wenn Sie verstehen müssen, was passiert und was zu tun ist. In der Realität wird diese Phase sehr oft mit der Phase des Ergreifens von Maßnahmen kombiniert, da der Prozess normalerweise folgendermaßen abläuft:
- Wir betrachten die Überwachung, Protokolle (wenn die Überwachung nicht ausreicht) und starten einige andere Diagnosetools
- Hypothesen aufstellen
- Wir testen Hypothesen entweder anhand von Metriken oder durch Ausführen einer Aktion (alles neu starten :)
- bewerten die Ergebnisse von Änderungen
- Kommunizieren Sie mit Kollegen, wenn Ihr Wissen über ein bestimmtes Subsystem nicht ausreicht
und so weiter bis zur Erleuchtung oder dem Ende des Vorfalls.
Diese Phase ist normalerweise die bedeutendste in der Gesamtdauer des Vorfalls. Wie kann man es reduzieren?
Hier ist nicht alles klar, es gibt mehrere Vektoren:
- Vereinfachen Sie Ihre Infrastruktur : Stellen Sie sich vor, wie schnell Menschen mit einer Datenbank und einem Dienst abstürzen
- Wissensverbreitung in einem Team : Ideal, wenn die Kommunikation der Menschen nicht während des Vorfalls, sondern während der täglichen Arbeit erfolgt (die Kommunikation der Menschen ist im Allgemeinen ein sehr langer Prozess).
- Überwachung : Viele Leute denken, dass die Überwachung nur in der Phase "Erkennung" funktioniert, aber tatsächlich als Optimierung des Hypothesentestprozesses ("Funktioniert die Datenbank ordnungsgemäß?", "Stößt mein Dienst auf Ressourcen?") und auch als Transportmittel dienen kann Wissensverbreitung in einem Team. "Serge, überprüfe, ob es Fehler im X-Protokoll bezüglich Deadlocks gibt?" kann in einen Auslöser verwandelt werden, dessen Beschreibung ein Link zum Wiki mit Anweisungen ist .
Beseitigung
Wie ich oben sagte, verschmilzt diese Phase oft mit der vorherigen. Aber es kommt vor, dass der Grund sofort klar ist, aber die Erholung wird sehr lange dauern. Zum Beispiel ist ein Server tot Meister primär (ich werde mich lange nicht daran gewöhnen können :) mit einer Datenbank, und Sie haben noch nie ein Replikat beworben, dh Sie werden die Dokumentation lesen, eine neue Anwendungskonfiguration einführen usw.
Natürlich müssen Sie nach jedem wichtigen Vorfall herausfinden, wie Sie verhindern können, dass dies erneut geschieht, oder die Wiederherstellung erheblich beschleunigen. Aber mal sehen, in welche Richtungen wir versuchen können, proaktiv zu arbeiten:
- Tools für das Infrastrukturmanagement : Wenn Sie alles reparieren müssen, um eine neue Konfiguration einzuführen, dies jedoch in mindestens 20 Minuten erledigt ist, ist dies Ihre Einschränkung. Versuchen Sie, Szenarien zu entwickeln, wie etwas passieren könnte, und einige Prozesse dringend zu beschleunigen. In ansible haben Sie beispielsweise serial (parallele Ausführung von Aufgaben) = 3 festgelegt. Wenn Sie jedoch immer noch lügen, können Sie mit serial = 30 würfeln. Sie müssen jedem beibringen, dies neu zu definieren (ähnlich wie bei der fortlaufenden Aktualisierungsstrategie in Kubernetes).
- Übungen : Wenn Sie wissen, dass die wahrscheinlichen Szenarien für Fehler und Wiederherstellung nicht automatisiert sind, sollten Sie Anweisungen haben, die getestet werden müssen . Planen Sie Ausfallzeiten (falls erforderlich) und führen Sie Übungen durch. In dieser Phase werden solche Fälle häufig automatisiert, da die meisten Fallstricke selbst der kompliziertesten Verfahren auf den ersten Blick während der Übungen geklärt werden.
- Interaktion mit Auftragnehmern : Sie sollten im Voraus wissen, was Sie tun werden, wenn Ihr Hosting-Anbieter krank wird. Oft führt das Bewusstsein für die Wahrscheinlichkeit eines Problems und die Kosten des Risikoabschlusses zu der Schlussfolgerung: "Wir werden nur auf die Wiederherstellung warten." Auf der anderen Seite werden Ingenieure und Unternehmen auf ein solches Szenario vorbereitet sein. Sie können beispielsweise das Problem des Umschaltens Ihres Datenverkehrs auf einen vorbereiteten Stub lösen, Benutzer mit einem vorbereiteten Brief benachrichtigen usw. Oder umgekehrt, Sie geben eine Anweisung, nach der wir dem Hoster 30 Minuten Zeit geben, um sich zu erholen, und dann wechseln wir zu einem anderen Domänencontroller, in dem bereits eine Replik der Datenbank vorhanden ist. Sie müssen jedoch alles andere erweitern. Und auch hier, in den Lehren, notieren wir die Zeit für den Umzug usw.
MTBF (Mittlere Zeit zwischen Ausfällen)
Eine weitere häufig verwendete Metrik, die in der Verfügbarkeitsdiskussion erwähnt wird. Auch hier schlage ich vor, nichts zu mitteln, sondern nur über die Anzahl der Vorfälle zu sprechen, die über einen bestimmten Zeitraum auftreten.
Hier steht die Frage im Vordergrund, wie sehr Sie sich um die Fehlertoleranz Ihres Dienstes gekümmert haben:
- Gibt es einen Single Point of Failure (SPOF) in der Infrastruktur? Wie hoch ist die Ausfallwahrscheinlichkeit?
- Wie sicher sind Sie, dass es keine SPOFs gibt, von denen Sie nichts wissen? (Dies ist genau das Problem, das Chaos Affe löst)
- Funktionieren Load Balancer gut? ( mein Bericht über das Balancieren )
- Wie belastbar ist das Netzwerk?
- Wie zuverlässig ist das Rechenzentrum?
Um all dies zu berechnen / vorherzusagen, erstellen sie manchmal eine „Risikokarte“, in der jedes Szenario (von dem natürlich angenommen werden kann, dass es immer solche gibt, die wir noch nicht kennen) eine Wahrscheinlichkeit + Auswirkung (kurze / lange Ausfallzeiten, Datenverlust, Reputationsverlust) hat , usw). Dann arbeiten sie systematisch an einer solchen Karte und schließen vor allem höchst wahrscheinliche und schwerwiegende Szenarien in Bezug auf die Auswirkungen.
Eine andere Technik, die verwendet werden kann, ist die Klassifizierung vergangener Vorfälle. Es wird viel darüber geredet, dass es sehr nützlich ist, Post-Mortem-Vorfälle zu schreiben, in denen die Ursachen des Problems, die Handlungen von Menschen und mögliche zukünftige Handlungen analysiert werden. Um jedoch schnell die Ursachen aller Unfälle in der letzten Zeit zu ermitteln, ist es zweckmäßig, ihre Dauer mit einer Gruppierung nach „Problemklassen“ zusammenzufassen und zu ermitteln, wo die meisten Ausfallzeiten darin bestehen, Maßnahmen zu ergreifen:
- menschliche Fehler : Reduzieren Sie die Anzahl der manuellen Aktionen in der Produktion, verschiedene Schutzmaßnahmen gegen Bedienerfehler
- erfolglose Releases : Es lohnt sich, die Tests zu verbessern (einschließlich Lasttests).
- Anwendungsfehler : Leckagen, Abstürze und andere Einfrierungen reparieren
- Netzwerk : Ausrüstung kaufen, einrichten, Netzwerker einstellen, Auftragnehmer wechseln
- Datenbanken : Mieten Sie einen DBA, achten Sie auf Fehlertoleranz, kaufen Sie bessere Hardware
- DC : Denken Sie an Backup oder Umzug
- Externe Einflüsse (ddos, Blockierung, Zertifikatsüberprüfungen, Domains): Antiddos kaufen, Proxys auffüllen, die Gültigkeit von Domains / Zertifikaten überwachen, mehrere Zertifikate von verschiedenen CAs haben.
Das heißt, wenn Sie nicht einmal versuchen, mögliche Szenarien von Problemen vorherzusagen, lohnt es sich auf jeden Fall, mit bereits aufgetretenen Vorfällen zu arbeiten.
Insgesamt
Alle Vorfälle sind unterschiedlich:
Der Algorithmus zur Erhöhung der Betriebszeit ist jeder anderen Optimierung sehr ähnlich:
-> -> ->
Aus eigener Erfahrung kann ich sagen, dass es für eine signifikante Verbesserung der Betriebszeit ausreicht, nur damit zu beginnen und die Ursachen von Vorfällen zu analysieren. Es kommt normalerweise vor, dass die einfachsten Änderungen den größten Effekt haben.
Unser Überwachungsservice hilft nicht nur bei der "Erkennung", sondern reduziert auch die "Untersuchung" erheblich (Kunden werden dies bestätigen).