Dies ist das zweite eine Reihe von Beiträgen auf die Steigerung der Gesamtverfügbarkeit Ihres Dienstes oder Systems.

Im erster Beitrag dieser Serie haben wir einige Konzepte der Systemverfügbarkeit definiert und eingeführt, darunter die mittlere Zeit zwischen Ausfällen (MTBF) und die mittlere Zeit bis zur Wiederherstellung (MTTR). Beide zunehmend MTBF und Reduzierung MTTR sind wichtig, aber die Reduzierung von MTTR ist wohl einfacher. Es sind keine Monate an Entwicklungsarbeit und Kapitalaufwand nötig, um Ergebnisse zu sehen, sondern sie können oft schrittweise mit einigen zusätzlichen Tools, Verfahren und Prozessen erreicht werden.

In diesem Beitrag sprechen wir über Dinge, die Sie heute tun können, um die MTTR zu verkürzen und Ihre Verfügbarkeit effektiv zu erhöhen.

Tun Sie es einfach!

Bei jedem Ausfallszenario kommt es auf jede Minute an. Je nach Unternehmen kann jede zusätzliche Minute Ausfallzeit zu Umsatzeinbußen, verlorenem Kundenvertrauen oder Schlimmerem führen. Um zu verhindern, dass diese wertvollen Minuten verschwendet werden – und die MTTR effektiv direkt erhöht wird – sollte in Ihrem Team eine „Handlungsbereitschaft“ gepflegt werden.

Was „Handlungsbereitschaft“ in einer betrieblichen Situation bedeutet: Wenn Sie zu irgendeinem Zeitpunkt eine Hypothese über die Ursache Ihres Ausfalls haben und Sie oder jemand anderes eine Idee für eine Lösung hat, die zur Behebung des Problems beitragen könnte, dann setzen Sie diese einfach um. Probieren Sie es einfach aus.

Diese Einstellung hilft Ihnen, zu verhindern, dass Sie in Unentschlossenheit verfallen, wenn Sie mit einem wirklich schlimmen Betriebsproblem konfrontiert sind und nicht genügend Recherche und Daten haben, um eine vollständig informierte und wohlüberlegte Entscheidung darüber zu treffen, welchen Ansatz Sie ausprobieren möchten. Zwei Stunden nach einem Ausfall die perfekte Lösung zu finden, ist fast immer weniger erfolgreich, als nach 15 Minuten eine nicht perfekte, aber hilfreiche Lösung zu finden. Und wer weiß: Eines der ersten Dinge, die Sie versuchen, könnte das Problem tatsächlich vollständig beheben. Es gibt nur einen Weg, dies herauszufinden: Probieren Sie es einfach aus. Ein Ausfall ist nicht der richtige Zeitpunkt, um risikoscheu zu sein.

Ein wichtiger Faktor bei der Entwicklung dieser operativen Haltung in Ihrer Organisation ist nicht Leute dafür bestrafen, dass sie Fehler machen oder Risiken eingehen, während sie versuchen, ein großes Betriebsproblem zu beheben. Das Aufgeben der gesamten Frontend-Flotte hat das Problem für kurze Zeit verschlimmert? Na ja, einen Versuch war es wert. Das nächste Mal werden wir diese Lösung nicht so schnell ausprobieren.

Natürlich sollten Sie Risiken eingehen und Dinge ausprobieren, aber es hat keinen Sinn, dabei dumm zu sein. Bevor Sie die Datenbanktabelle kürzen, stellen Sie sicher, dass Sie ein Backup haben. Bevor Sie die Update-Anweisung über 12.000 Zeilen ausführen, lassen Sie das SQL von jemandem noch einmal überprüfen und teilen Sie es, wenn möglich, in mehrere Transaktionen auf. Und wägen Sie das Ausmaß des Problems gegen die Lösung ab, die Sie versuchen: Ausfälle sind eine Sache, aber wenn Ihre Systeme stattdessen nur mit reduziert Wenn Sie Probleme mit der Kapazität oder Funktionalität haben, sollten Sie vielleicht mit den radikalen Korrekturen warten, wenn die potenziellen negativen Folgen eines Fehlers sehr groß oder katastrophal sind.

Kenne deine Feinde und dich selbst

Es heißt also: Wenn du deine Feinde und dich selbst kennst, kannst du hundert Schlachten gewinnen, ohne eine einzige zu verlieren. – Sun Tzu

Feinde

Sie und Ihr Team sollten mit den häufigsten Problemen bestens vertraut sein – Feinde – mit denen Ihr Service oder System tagtäglich konfrontiert ist. Ich meine damit nicht die katastrophalsten und exotischsten potenziellen Probleme, die Sie könnte sondern die realen und alltäglichen Fehlerarten, denen Ihr System in der Vergangenheit ausgesetzt war und mit ziemlicher Sicherheit auch in der Zukunft ausgesetzt sein wird.

Sie wissen, welche Art von Problemen ich meine: das Skalierungsproblem, das noch nicht gelöst wurde, der pingelige Legacy-Dienst, der gelegentlich ausfällt, die Datenbank, die die unangenehme Angewohnheit hat, einfach zu blockieren, oder diese speziellen Umstände, die einen Nachrichtensturm auslösen. Was auch immer der Fehlermodus ist, wenn es etwas ist, das in Ihrem System häufig auftritt, alle Die Mitglieder Ihres Teams sollten wissen (oder darin geschult sein), wie damit umzugehen ist.

Ja, Sie arbeiten wahrscheinlich daran, die Grundursache des Problems zu beheben (und wenn nicht, sollten Sie das tun) und hoffen, dass es bald eine ferne, traurige Erinnerung sein wird. Viele Ihrer chronischsten Probleme lassen sich jedoch nicht einfach und vollständig beseitigen – sonst hätten Sie es schon vor langer Zeit getan – und einige Altsysteme lassen sich nur schwer ändern. Sie sollten also weiterhin dokumentierte und detaillierte Verfahren zur Lösung dieser Probleme haben und diese Dokumentation sollte Ihrem Team bei zukünftigen Vorfällen leicht zugänglich sein. Ein internes Wiki ist ein großartiger Ort für diesen Leitfaden für Notfalleinsätze.

Selbst

Sie und Ihr Team sollten außerdem mit den Ihnen zur Verfügung stehenden Tools sehr vertraut sein, um den Zustand Ihrer Systeme zu verstehen.

Ich beginne mit dem Offensichtlichsten: Sie müssen wissen, dass ein Problem vorliegt, um es beheben zu können. Sie benötigen also Überwachung. Und zwar eine Menge.

Überwachen Sie auf Hostebene: CPU, freier Speicher, Swap-Nutzung, Festplattenspeicher, Festplatten-IOPS, Netzwerk-E/A oder welche Hostebenenattribute auch immer für das betreffende System wichtig sind. Es gibt Tonne S    Ö F    toll T    M autorin G    S Lösungen da draußen verfügbar für diese.

Überwachung auf Anwendungsebene: Richten Sie Monitore ein, um verschiedene Integritätsmetriken Ihres Systems auf Systemebene zu überprüfen und darüber zu berichten, wie Anforderungslatenz, Durchsatz , Verarbeitungsverzögerungen, Warteschlangengrößen, Fehlerraten, Datenbankleistung , Ende zu Ende    Leistung , usw. Setup Protokollscans das kontinuierlich Überwachen Sie Ihre Serviceprotokolle Suchen Sie nach schlechten Zeichen. Wenn Sie ein nach außen gerichtetes System haben, richten Sie ein externer Monitor um zu überprüfen, ob Ihr System/Ihre Website aktiv ist, Anfragen akzeptiert und fehlerfrei ist.

Machen Sie sich mit der Verwendung Ihrer Überwachungstools vertraut. Diese Tools sind in einer Fehlersituation großartige Ressourcen, um schnell und visuell herauszufinden, was schief läuft. Wenn Ihr Team jedoch nicht weiß, wie sie oder ihre Benutzeroberfläche verwendet werden (oder sich nicht einmal anmelden), sind sie nicht sehr nützlich. Fügen Sie in Ihrem oben erwähnten Notfallhandbuch Links zu interessanten/nützlichen Überwachungsdiagrammen und -tabellen hinzu, um schnell darauf zugreifen zu können.

Aber diese Überwachungssysteme sind nicht sehr nützlich, wenn niemand ihnen zuhört. Sie sollten – unverschämte Werbung! – ein System wie PagerDuty um die Lücke zwischen den Überwachungssystemen und Ihrem Bereitschaftspersonal (den Leuten, die das Problem tatsächlich beheben werden) zu überbrücken sowie Bereitschaftspläne und Eskalationsrichtlinien zu organisieren. Eine andere – teurere – Option wäre so etwas wie ein NOC . Ich werde nicht zu sehr auf diesem Punkt herumreiten, aber es gibt keinen Grund dafür, dass es irgendeine Verzögerung zwischen der Erkennung eines Problems durch Ihre Überwachungssysteme und Du erkennen, dass es ein Problem gibt.

Ich werde in Kürze einen weiteren Beitrag mit weiteren Einzelheiten zu meinen Lieblingstipps veröffentlichen.