Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Reduzieren MTTR

Nachdem ein Fehler entdeckt wurde, dient der Rest der MTTR Zeit der eigentlichen Reparatur oder Minderung der Auswirkungen. Um einen Fehler zu reparieren oder zu mindern, müssen Sie wissen, was falsch ist. Es gibt zwei Hauptgruppen von Kennzahlen, die in dieser Phase Aufschluss geben: 1/ Kennzahlen zur Folgenabschätzung und 2/ Kennzahlen zur betrieblichen Health. Die erste Gruppe gibt Aufschluss über das Ausmaß der Auswirkungen bei einem Ausfall. Dabei wird die Anzahl oder der Prozentsatz der betroffenen Kunden, Ressourcen oder Workloads gemessen. Die zweite Gruppe hilft bei der Identifizierung der Gründe für die Auswirkungen. Sobald das Warum erkannt wurde, können Bediener und die Automatisierung auf den Fehler reagieren und ihn beheben. Weitere Informationen zu diesen Kennzahlen finden Sie in Anhang 1 — MTTD und in MTTR wichtigen Kennzahlen.

Umgehung von Ausfällen

Der schnellste Ansatz zur Minderung der Auswirkungen sind ausfallschnelle Subsysteme, die Ausfälle umgehen. Bei diesem Ansatz wird Redundanz verwendet, um das Problem zu reduzieren, MTTR indem die Arbeit eines ausgefallenen Subsystems schnell auf ein Ersatzsystem verlagert wird. Die Redundanz kann von Softwareprozessen über EC2 Instanzen bis hin zu mehreren Regionen AZs reichen.

Durch Ersatzsubsysteme kann die Geschwindigkeit auf nahezu MTTR Null reduziert werden. Die Wiederherstellungszeit ist nur das, was benötigt wird, um die Arbeit auf das Ersatzgerät umzuleiten. Dies geschieht häufig mit minimaler Latenz und ermöglicht es, die Arbeit innerhalb des definierten Zeitraums abzuschließenSLA, wobei die Verfügbarkeit des Systems erhalten bleibt. Dies führt MTTRs eher zu geringfügigen, vielleicht sogar unmerklichen Verzögerungen als zu längeren Zeiten der Nichtverfügbarkeit.

Wenn Ihr Service beispielsweise EC2 Instances hinter einem Application Load Balancer (ALB) verwendet, können Sie Integritätsprüfungen in einem Intervall von nur fünf Sekunden konfigurieren und nur zwei fehlgeschlagene Zustandsprüfungen benötigen, bevor ein Ziel als fehlerhaft markiert wird. Das bedeutet, dass Sie innerhalb von 10 Sekunden einen Fehler erkennen und das Senden von Datenverkehr an den fehlerhaften Host beenden können. In diesem Fall MTTR ist das praktisch dasselbe wie beim, MTTD da der Fehler, sobald er erkannt wird, auch behoben wird.

Genau das versuchen Workloads mit hoher Verfügbarkeit oder kontinuierlicher Verfügbarkeit zu erreichen. Wir möchten Ausfälle in der Arbeitslast schnell umgehen, indem wir ausgefallene Subsysteme schnell erkennen, sie als ausgefallen markieren, das Senden von Datenverkehr an sie beenden und stattdessen Datenverkehr an ein redundantes Subsystem weiterleiten.

Beachten Sie, dass Ihr Workload durch die Verwendung eines solchen Fail-Fast-Mechanismus sehr empfindlich auf vorübergehende Fehler reagiert. Stellen Sie im angegebenen Beispiel sicher, dass Ihre Load Balancer-Integritätsprüfungen nur oberflächliche Zustandsprüfungen oder Verfügbarkeitsprüfungen und lokale Integritätsprüfungen nur für die Instanz durchführen und keine Abhängigkeiten oder Workflows testen (oft als tiefgreifende Integritätsprüfungen bezeichnet). Dadurch wird verhindert, dass Instanzen bei vorübergehenden Fehlern, die sich auf die Arbeitslast auswirken, unnötig ausgetauscht werden.

Beobachtbarkeit und die Fähigkeit, Fehler in Subsystemen zu erkennen, sind entscheidend für die erfolgreiche Umgehung von Ausfällen. Sie müssen den Umfang der Auswirkungen kennen, damit die betroffenen Ressourcen als fehlerhaft oder ausgefallen markiert und außer Betrieb genommen werden können, sodass sie umgeleitet werden können. Wenn beispielsweise eine einzelne AZ teilweise beeinträchtigt wird, muss Ihre Instrumentierung in der Lage sein, zu erkennen, dass ein AZ-lokales Problem vorliegt, damit alle Ressourcen in dieser AZ umgeleitet werden können, bis sie wiederhergestellt sind.

Für die Umgehung von Ausfällen durch Routing sind je nach Umgebung möglicherweise auch zusätzliche Tools erforderlich. Stellen Sie sich anhand des vorherigen Beispiels mit EC2 Instances hinter einem vorALB, dass Instanzen in einer AZ möglicherweise die lokalen Zustandsprüfungen bestehen, aber eine isolierte Beeinträchtigung der AZ dazu führt, dass sie keine Verbindung zu ihrer Datenbank in einer anderen AZ herstellen können. In diesem Fall werden diese Instanzen durch die Integritätsprüfungen des Lastenausgleichs nicht außer Betrieb genommen. Ein anderer automatisierter Mechanismus wäre erforderlich, um die AZ aus dem Load Balancer zu entfernen oder die Instances dazu zu zwingen, ihre Integritätsprüfungen nicht zu bestehen. Dies hängt davon ab, ob es sich bei dem Umfang der Auswirkungen um eine AZ handelt. Für Workloads, die keinen Load Balancer verwenden, wäre eine ähnliche Methode erforderlich, um zu verhindern, dass Ressourcen in einer bestimmten AZ Arbeitseinheiten akzeptieren oder Kapazität aus der AZ ganz entfernen.

In einigen Fällen kann die Verlagerung von Arbeit auf ein redundantes Subsystem nicht automatisiert werden, z. B. der Failover von einer primären auf eine sekundäre Datenbank, bei der die Technologie keine eigene Wahl zum Marktführer vorsieht. Dies ist ein übliches Szenario für Architekturen mit AWS mehreren Regionen. Da diese Arten von Failovers eine gewisse Ausfallzeit erfordern, nicht sofort rückgängig gemacht werden können und die Arbeitslast für einen gewissen Zeitraum ohne Redundanz bleibt, ist es wichtig, dass ein Mensch in den Entscheidungsprozess einbezogen wird.

Workloads, für die ein weniger striktes Konsistenzmodell verwendet werden kann, können kürzere Ergebnisse erzielen, MTTRs indem Failover-Automatisierung für mehrere Regionen verwendet wird, um Ausfälle zu umgehen. Funktionen wie die regionsübergreifende Amazon S3 S3-Replikation oder globale Amazon DynamoDB-Tabellen bieten Funktionen für mehrere Regionen durch letztlich konsistente Replikation. Darüber hinaus ist die Verwendung eines lockeren Konsistenzmodells von Vorteil, wenn wir das Theorem berücksichtigen. CAP Wenn der Workload bei Netzwerkausfällen, die sich auf die Konnektivität zu statusbehafteten Subsystemen auswirken, Verfügbarkeit der Konsistenz vorzieht, kann er dennoch fehlerfreie Antworten liefern — eine weitere Möglichkeit, Fehler zu umgehen.

Das Routing zur Umgehung von Ausfällen kann mit zwei verschiedenen Strategien implementiert werden. Die erste Strategie besteht in der Implementierung statischer Stabilität, indem im Voraus genügend Ressourcen bereitgestellt werden, um die gesamte Last des ausgefallenen Subsystems zu bewältigen. Dabei kann es sich um eine einzelne EC2 Instanz oder um eine gesamte Kapazität von AZ handeln. Der Versuch, während eines Fehlers neue Ressourcen bereitzustellen, erhöht die Abhängigkeit von einer Kontrollebene in Ihrem Wiederherstellungspfad MTTR und fügt eine Abhängigkeit von dieser hinzu. Dies ist jedoch mit zusätzlichen Kosten verbunden.

Die zweite Strategie besteht darin, einen Teil des Datenverkehrs vom ausgefallenen Teilsystem auf andere umzuleiten und den überschüssigen Verkehr, der von der verbleibenden Kapazität nicht bewältigt werden kann, abzuleiten. Während dieser Phase der Verschlechterung können Sie neue Ressourcen aufstocken, um die ausgefallene Kapazität zu ersetzen. Dieser Ansatz dauert länger MTTR und führt zu einer Abhängigkeit von einer Steuerungsebene, kostet aber weniger, wenn Reservekapazitäten im Standby-Modus vorhanden sind.

Kehren Sie zu einem zweifelsfrei funktionierenden Zustand zurück

Ein weiterer gängiger Ansatz zur Risikominderung während einer Reparatur besteht darin, die Arbeitslast wieder in einen als funktionierend bekannten Zustand zu versetzen. Wenn eine kürzlich durchgeführte Änderung den Fehler verursacht haben könnte, ist das Zurücksetzen dieser Änderung eine Möglichkeit, zum vorherigen Zustand zurückzukehren.

In anderen Fällen könnten vorübergehende Bedingungen den Fehler verursacht haben. In diesem Fall könnte ein Neustart der Arbeitslast die Auswirkungen abschwächen. Lassen Sie uns diese beiden Szenarien untersuchen.

Während einer Bereitstellung MTTR hängt die Minimierung von MTTD und von Beobachtbarkeit und Automatisierung ab. Ihr Bereitstellungsprozess muss die Arbeitslast kontinuierlich auf erhöhte Fehlerraten, erhöhte Latenz oder Anomalien hin beobachten. Sobald diese erkannt wurden, sollte der Bereitstellungsprozess gestoppt werden.

Es gibt verschiedene Bereitstellungsstrategien, z. B. direkte Bereitstellungen, blaue/grüne Bereitstellungen und fortlaufende Bereitstellungen. Jede dieser Methoden verwendet möglicherweise einen anderen Mechanismus, um zu einem zweifelsfrei funktionierenden Zustand zurückzukehren. Es kann automatisch zum vorherigen Status zurückkehren, den Verkehr wieder in die blaue Umgebung verlagern oder ein manuelles Eingreifen erfordern.

CloudFormation bietet die Möglichkeit, im Rahmen seiner Stack-Erstellungs- und Aktualisierungsvorgänge ein automatisches Rollback durchzuführen, was AWS CodeDeployauch der Fall ist. CodeDeploy unterstützt auch Blau/Grün- und fortlaufende Bereitstellungen.

Um diese Funktionen zu nutzen und Ihren Energieverbrauch zu minimieren, sollten Sie erwägenMTTR, Ihre gesamte Infrastruktur- und Codebereitstellung mithilfe dieser Services zu automatisieren. In Szenarien, in denen Sie diese Dienste nicht nutzen können, sollten Sie erwägen, das Saga-Muster zu implementieren, um fehlgeschlagene AWS Step Functions Bereitstellungen rückgängig zu machen.

Wenn Sie einen Neustart in Betracht ziehen, gibt es verschiedene Ansätze. Diese reichen vom Neustart eines Servers, der längsten Aufgabe, bis zum Neustart eines Threads, der kürzesten Aufgabe. In der folgenden Tabelle sind einige der Methoden zum Neustarten und die ungefähren Zeiten bis zum Abschluss aufgeführt (repräsentativ für Größenunterschiede, diese sind nicht exakt).

Wenn man sich die Tabelle ansieht, gibt es einige klare Vorteile MTTR bei der Verwendung von Containern und serverlosen Funktionen (wie AWS Lambda). Sie MTTR sind um Größenordnungen schneller als der Neustart einer virtuellen Maschine oder der Start einer neuen. Die Verwendung von Fehlerisolierung durch Softwaremodularität ist jedoch ebenfalls von Vorteil. Wenn Sie den Ausfall eines einzelnen Prozesses oder Threads eindämmen können, ist die Wiederherstellung nach diesem Fehler viel schneller als der Neustart eines Containers oder Servers.

Als allgemeine Methode zur Wiederherstellung können Sie von unten nach oben vorgehen: 1/Restart, 2/Reboot, 3/Reimage/ReDeploy, 4/Replace. Sobald Sie jedoch mit dem Neustartschritt begonnen haben, ist das Routing zur Umgehung von Fehlern in der Regel schneller (in der Regel dauert es höchstens 3-4 Minuten). Um die Auswirkungen nach einem Neustartversuch so schnell wie möglich abzumildern, umgehen Sie den Ausfall und setzen Sie dann im Hintergrund den Wiederherstellungsprozess fort, um die Kapazität Ihres Workloads wiederherzustellen.

Diagnose eines Fehlers

Ein Teil des Reparaturprozesses nach der Erkennung ist der Diagnosezeitraum. In diesem Zeitraum versuchen die Bediener herauszufinden, was falsch ist. Dieser Prozess kann das Abfragen von Protokollen, das Überprüfen von Operational Health-Metriken oder das Anmelden bei Hosts zur Fehlerbehebung beinhalten. All diese Aktionen benötigen Zeit. Daher kann die Erstellung von Tools und Runbooks zur Beschleunigung dieser Aktionen auch dazu beitragen, diesen Aufwand zu reduzieren. MTTR

Runbooks und Automatisierung

In ähnlicher Weise müssen Bediener, nachdem Sie festgestellt haben, was falsch ist und welche Maßnahmen zur Behebung der Arbeitslast ergriffen werden können, in der Regel einige Schritte ausführen, um das Problem zu lösen. Nach einem Ausfall kann die Arbeitslast beispielsweise am schnellsten repariert werden, indem sie neu gestartet wird, was mehrere, geordnete Schritte umfassen kann. Die Verwendung eines Runbooks, das diese Schritte entweder automatisiert oder einem Bediener spezifische Anweisungen gibt, beschleunigt den Vorgang und trägt dazu bei, das Risiko unbeabsichtigter Aktionen zu verringern.