Dies ist das zweite in eine Reihe von Beiträgen zur Steigerung der allgemeinen Verfügbarkeit Ihres Dienstes oder Systems.

Im erster Beitrag In dieser Reihe haben wir einige Konzepte der Systemverfügbarkeit definiert und eingeführt, darunter die mittlere Zeit zwischen Ausfällen (MTBF) und die mittlere Wiederherstellungszeit (MTTR). zunehmend MTBF und Reduzierung Die mittlere Reparaturzeit (MTTR) ist wichtig, aber ihre Reduzierung ist wohl einfacher. Es bedarf keiner monatelangen Entwicklungsarbeit und hoher Investitionen, um Ergebnisse zu erzielen, sondern oft lassen sich diese schrittweise mit zusätzlichen Werkzeugen, Verfahren und Prozessen erreichen.

In diesem Beitrag geht es um Dinge, die Sie heute tun können, um die mittlere Reparaturzeit (MTTR) zu verkürzen und Ihre Verfügbarkeit effektiv zu erhöhen.

Tun Sie es einfach!

Bei jedem Ausfall zählt jede Minute. Je nach Branche kann jede zusätzliche Minute Ausfallzeit zu Umsatzeinbußen, Kundenverlust oder Schlimmerem führen. Um diese wertvollen Minuten optimal zu nutzen und die mittlere Reparaturzeit (MTTR) effektiv zu verkürzen, sollte in Ihrem Team eine proaktive Herangehensweise gefördert werden.

Was „Handlungsorientierung“ in einer operativen Situation bedeutet: Wenn Sie zu irgendeinem Zeitpunkt eine Hypothese zur Ursache Ihres Ausfalls haben und Ihnen oder jemand anderem eine Lösungsidee einfällt, die das Problem beheben könnte, setzen Sie sie einfach um. Probieren Sie es einfach aus.

Diese Haltung hilft Ihnen, nicht in Entscheidungsstarre zu verfallen, wenn Sie vor einem wirklich gravierenden Betriebsproblem stehen und nicht genügend Informationen und Daten vorliegen, um eine fundierte und durchdachte Entscheidung über das weitere Vorgehen zu treffen. Die perfekte Lösung nach zwei Stunden Ausfallzeit ist fast immer weniger zielführend als eine zwar unvollkommene, aber hilfreiche Maßnahme nach 15 Minuten. Und wer weiß: Vielleicht behebt einer der ersten Versuche das Problem sogar vollständig. Es gibt nur einen Weg, das sicher herauszufinden: Probieren Sie es einfach aus. Ein Ausfall ist nicht der richtige Zeitpunkt für Risikoscheu.

Ein wichtiger Faktor für die Entwicklung dieser operativen Denkweise in Ihrem Unternehmen ist Folgendes: nicht Mitarbeiter für Fehler oder Risiken bei der Behebung eines größeren Betriebsproblems zu bestrafen, ist keine gute Idee. Dass das Neustarten aller Frontends das Problem kurzzeitig verschlimmert hat? Nun ja, einen Versuch war es wert. Diese Lösung werden wir beim nächsten Mal nicht so schnell anwenden.

Natürlich sollte man Risiken eingehen und Dinge ausprobieren, aber leichtsinnig vorgehen ist sinnlos. Bevor Sie eine Datenbanktabelle leeren, erstellen Sie unbedingt ein Backup. Bevor Sie eine Aktualisierungsanweisung für 12.000 Zeilen ausführen, lassen Sie den SQL-Code von jemandem überprüfen und teilen Sie ihn nach Möglichkeit in mehrere Transaktionen auf. Wägen Sie außerdem das Ausmaß des Problems gegen die angestrebte Lösung ab: Systemausfälle sind eine Sache, aber wenn Ihre Systeme stattdessen nur noch teilweise funktionieren, ist das ein großes Problem. reduziert Wenn es um Kapazität oder Funktionalität geht, sollten Sie von radikalen Verbesserungen absehen, bei denen das Risiko eines Fehlers sehr groß oder gar katastrophal wäre.

Kenne deine Feinde und dich selbst.

Man sagt also, wenn man seine Feinde und sich selbst kennt, kann man hundert Schlachten gewinnen, ohne eine einzige Niederlage zu erleiden. Sun Tzu

Feinde

Sie und Ihr Team sollten mit den häufigsten Problemen sehr vertraut sein – Feinde – denen Ihr Dienst oder System tagtäglich ausgesetzt ist. Ich meine damit nicht die katastrophalsten und exotischsten potenziellen Probleme, die Sie haben. könnte Es geht um die Realität und die alltäglichen Fehlerquellen, denen Ihr System in der Vergangenheit begegnet ist und mit ziemlicher Sicherheit auch in Zukunft begegnen wird.

Sie wissen, welche Probleme ich meine: das Skalierungsproblem, das noch immer nicht gelöst ist, der störanfällige Legacy-Dienst, der gelegentlich ausfällt, die Datenbank, die sich ständig aufhängt, oder jene spezifischen Umstände, die eine Flut von Meldungen auslösen. Ganz gleich, um welche Fehlerursache es sich handelt, wenn sie in Ihrem System häufig auftritt, alle Ein Mitglied Ihres Teams sollte wissen (oder darin geschult sein), wie damit umzugehen ist.

Ja, Sie arbeiten wahrscheinlich bereits an der Behebung der Ursache des Problems (und falls nicht, sollten Sie es unbedingt tun) und hoffen, dass es bald der Vergangenheit angehört. Viele Ihrer chronischen Probleme lassen sich jedoch nicht einfach und vollständig lösen – sonst hätten Sie es längst getan – und manche Altsysteme sind schwer zu ändern. Daher sollten Sie weiterhin dokumentierte und detaillierte Verfahren für den Umgang mit solchen Problemen bereithalten, und diese Dokumentation sollte Ihrem Team bei zukünftigen Vorfällen leicht zugänglich sein. Ein internes Wiki eignet sich hervorragend für diesen Leitfaden für Notfallmaßnahmen.

Selbst

Sie und Ihr Team sollten sich außerdem sehr gut mit den Ihnen zur Verfügung stehenden Werkzeugen auskennen, um den Zustand Ihrer Systeme verstehen zu können.

Zunächst beginne ich mit dem Offensichtlichsten: Man muss wissen, dass es ein Problem gibt, um es beheben zu können. Sie benötigen also Überwachung. Und zwar in großem Umfang.

Überwachung auf Hostebene: CPU, freier Speicher, Swap-Nutzung, Festplattenspeicher, Festplatten-IOPS, Netzwerk-I/O oder sonstige Attribute auf Hostebene, die für das betreffende System wichtig sind. Tonne S    O F    großartig T    M Onitorin G    S Lösungen Es gibt dafür entsprechende Angebote.

Überwachung auf Anwendungsebene: Richten Sie Überwachungsmodule ein, um verschiedene Systemzustandsmetriken Ihres Systems zu überprüfen und darüber zu berichten, wie zum Beispiel: Anfragelatenz, Durchsatz Verarbeitungsverzögerungen, Warteschlangenlängen, Fehlerraten, Datenbankleistung , von Anfang bis Ende    Leistung usw. Einrichtung logscans das kontinuierlich Überwachen Sie Ihre Serviceprotokolle. Achten Sie auf Warnsignale. Wenn Sie ein nach außen gerichtetes System haben, richten Sie ein externer Monitor um zu überprüfen, ob Ihr System/Ihre Website erreichbar ist, Anfragen annimmt und einwandfrei funktioniert.

Machen Sie sich mit der Nutzung Ihrer Überwachungstools vertraut. Diese Tools sind in Krisensituationen eine wertvolle Hilfe, um schnell und visuell die Fehlerursache zu ermitteln. Wenn Ihr Team jedoch nicht weiß, wie man sie oder deren Benutzeroberfläche bedient (oder sich überhaupt anmeldet), sind sie wenig nützlich. Fügen Sie in Ihrem oben erwähnten Notfallleitfaden Links zu interessanten/nützlichen Überwachungsgrafiken und -diagrammen hinzu, um einen schnellen Zugriff zu ermöglichen.

Diese Überwachungssysteme nützen aber wenig, wenn sie niemand abhört. Sie sollten – und hier kommt die Eigenwerbung ins Spiel! – ein System wie dieses verwenden. PagerDuty Um die Lücke zwischen den Überwachungssystemen und Ihrem Bereitschaftspersonal (denjenigen, die das Problem tatsächlich beheben) zu schließen sowie Bereitschaftspläne und Eskalationsrichtlinien zu organisieren. Eine andere – teurere – Option wäre beispielsweise … NOC Ich will diesen Punkt nicht weiter ausführen, aber es gibt keinerlei Grund für eine Verzögerung zwischen dem Erkennen eines Problems durch Ihre Überwachungssysteme und Du die Erkenntnis, dass es ein Problem gibt.

Ich werde demnächst einen weiteren Beitrag veröffentlichen, in dem ich einige meiner Lieblingstipps detailliert vorstelle.