[Stabilität] Untersuchung zur Verkürzung der MTTR | Technisches Team von JD Logistics

1. Was ist MTTR?

Wenn im System ein Systemfehler auftritt, müssen wir einige Indikatoren verwenden, um die Schwere und das Ausmaß des Fehlers zu messen. Unter diesen ist MTTR (Mean Time To Repair ) ein sehr wichtiger Indikator, der uns helfen kann, die durchschnittliche Zeit zu verstehen, die für die Reparatur des Systems erforderlich ist. Es ist nicht ratsam, die Reparatur des Systems zu lange in Anspruch zu nehmen, insbesondere für ein Unternehmen wie JD.com. Wenn die MTTR zu lang ist, kann dies schwerwiegende Folgen haben, wie z. B. die Begleichung von Kartenrechnungen durch den Benutzer und Umsatzeinbußen für das Unternehmen. Um die Stabilität und Zuverlässigkeit des Systems sicherzustellen, müssen wir daher die MTTR so weit wie möglich verkürzen.



Um die MTTR zu berechnen, dividieren Sie die Gesamtwartungszeit durch die Gesamtzahl der Wartungsvorgänge in einem bestimmten Zeitraum. Die MTTR-Berechnungsformel lautet:



2. So verkürzen Sie die MTTR

Das Verständnis von MTTR ist ein sehr wichtiges Werkzeug für jedes Unternehmen, da es uns hilft, besser auf Probleme in der Produktion zu reagieren und diese zu beheben. In den meisten Fällen hoffen Unternehmen, die MTTR durch interne Wartungsteams zu reduzieren, was die erforderlichen Ressourcen, Tools und Softwareunterstützung erfordert.

Welche Schritte können Sie also unternehmen, um die MTTR Ihres Unternehmens zu verkürzen? Der beste Ausgangspunkt besteht darin, jede Phase der MTTR zu verstehen und Maßnahmen zu ergreifen, um den Zeitaufwand für jede Phase zu reduzieren. Konkret können wir folgende Aspekte berücksichtigen:

1. Problemerkennungszeit: Überwachung und Alarmierung zur Fehlererkennung

Damit Techniker nach Auftreten eines Fehlers das Problem identifizieren können, können wir die MTTR-Erkennungszeit durch die Einrichtung eines Alarmsystems verkürzen. Indem wir den Betrieb des Systems in Echtzeit überwachen und den Alarmmechanismus rechtzeitig erkennen und auslösen, können wir das Problem in kürzester Zeit lokalisieren und geeignete Maßnahmen zur Behebung ergreifen.

Wir können unnötige Alarminformationen herausfiltern, indem wir vernünftige Schwellenwerte und Regeln festlegen. Dadurch wird verhindert, dass Alarmgeräusche das Entwicklungs- und Betriebsteam beeinträchtigen und es ihnen ermöglicht, sich mehr auf echte Probleme zu konzentrieren.

1.1. UMP-Überwachung

  • Realisieren Sie 3 goldene Überwachungsindikatoren (Verfügbarkeitsrate, Anrufvolumen, TP99) durch UMP.

Bei der Konfiguration des Alarmmechanismus können wir Faktoren wie Verfügbarkeit, TP99 und Anrufvolumen umfassend zur Auswertung berücksichtigen. Eine umfassende Auswertung dieser Indikatoren kann uns helfen, ein umfassenderes Verständnis des Systembetriebs zu erlangen, sodass potenzielle Probleme rechtzeitig erkannt und entsprechende Maßnahmen ergriffen werden können.

Es wird empfohlen, bei der Konfiguration von Alarmen zunächst eine strengere Strategie anzuwenden, d. h. zuerst festzuziehen und dann zu lockern und sich schrittweise an den besten Zustand anzupassen . Dadurch wird sichergestellt, dass Probleme frühzeitig erkannt und größere Ausfälle vermieden werden. Wenn sich das System jedoch allmählich stabilisiert, können wir die Alarmschwelle entsprechend der tatsächlichen Situation auch entsprechend lockern, um die Verfügbarkeit und Effizienz des Systems zu verbessern.

Es ist zu beachten, dass wir bei der Konfiguration von Alarmen Anpassungen und Optimierungen basierend auf spezifischen Geschäftsszenarien und Systemeigenschaften vornehmen müssen. Unterschiedliche Systeme können unterschiedliche Risikopunkte und Engpässe aufweisen. Daher müssen wir entsprechende Alarmstrategien basierend auf der tatsächlichen Situation formulieren, um die Stabilität und Zuverlässigkeit des Systems sicherzustellen.

critical告警方式:咚咚、邮件、即时消息(京ME)、语音
可用率:(分钟级)可用率 < 99.9% 连续 3 次超过阈值则报警,且在 3 分钟内报一次警。
性能:(分钟级)TP99 >= 200.0ms 连续 3 次超过阈值则报警,且在 3 分钟内只报一次警。
调用次数:当方法调用次数在 1 分钟的总和,连续 3 次大于 5000000 则报警,且在 3分钟内只报一次警

warning告警方式:咚咚、邮件、即时消息
可用率:(分钟级)可用率 < 99.95% 连续 3 次超过阈值则报警,且在 30 分钟内报一次警。
性能:(分钟级)TP99 >= 100.ms 连续 3 次超过阈值则报警,且在 30 分钟内只报一次警。
调用次数:当方法调用次数在 1 分钟的总和,连续 3 次大于 2000000 则报警,且在 3 分钟内只报一次警
  • Wenn es sich bei UMP um eine geplante Aufgabe handelt, ist der wichtigste Punkt die Bestimmung des Überwachungszeitraums . Nur durch die korrekte Konfiguration des Überwachungszeitraums können wir sicherstellen, dass die UMP innerhalb des erwarteten Zeitraums normal ausgeführt wird. Auf diese Weise wird der Alarmmechanismus automatisch ausgelöst, sobald der UMP nicht innerhalb des erwarteten Zeitraums ausgeführt wird, um ihn zu erkennen und zu lösen das Problem rechtzeitig lösen.

1.2. Alarmrufe sollten schnell, genau und selten erfolgen.

Bei der Verarbeitung von Alarminformationen kommt es für uns nicht auf die Menge, sondern auf die Richtigkeit und Vollständigkeit der Informationen an . Unser Team erhält täglich Hunderte von Alarmmeldungen. Haben Sie genug Energie und Zeit, um jede einzelne zu überprüfen? Können Sie sicherstellen, dass jeder einzelne Aufmerksamkeit erregt?

Daher müssen wir die geschäftlichen Auswirkungen bewerten und je nach Situation eine angemessene Alarmhäufigkeit festlegen. Insbesondere bei Alarmmeldungen, die als „Schlüsselstimmen“ gelten, sollten wir sie so schnell wie möglich entdecken und bearbeiten . Nur so können wir sicherstellen, dass wir in Notfällen schnell und präzise reagieren und mögliche Auswirkungen minimieren können.

1.3. Details entscheiden über Erfolg oder Misserfolg.

1. Wenn die Reaktionszeit auf die Alarminformationen lang ist, müssen wir prüfen, ob der Reaktionsmechanismus des Teams im Dienst normal ist. Wir müssen sicherstellen, dass die Alarminformationen effektiv an die richtigen Personen weitergeleitet werden können, damit das Problem rechtzeitig gelöst werden kann.
2. Bezüglich der täglichen Abwicklung von Alarminformationen sollten wir einen entsprechenden Verarbeitungsmechanismus einrichten, um sicherzustellen, dass jede Alarminformation ordnungsgemäß verarbeitet werden kann. Wenn wir kein tägliches Clearing und keinen täglichen Abschluss erreichen können, müssen wir die Gründe gründlich analysieren und entsprechende Maßnahmen ergreifen, um sie zu verbessern.
3. Bei der Verarbeitung von Alarminformationen müssen wir deren Ursachen eingehend analysieren. Nur wenn die Ursache des Problems gefunden wird, kann das Problem grundsätzlich gelöst werden.
4. Wenn der Alarm häufig auftritt, aber nicht behandelt wurde, müssen wir ernsthaft darüber nachdenken, ob der Alarm notwendig ist. Manchmal können einige Alarme durch Fehlalarme oder irrelevante Probleme verursacht werden. Zu diesem Zeitpunkt müssen wir diese Alarme überprüfen und beseitigen.
5. Wenn ein Problem auftritt und die entsprechenden Alarminformationen von UMP oder anderen Links nicht hinzugefügt werden, müssen wir sorgfältig prüfen, ob auch andere Kernlinks übersehen wurden. Wenn ein Zusatz fehlt, können wir ihn mithilfe des Tool-Scannings finden.
6. Für die zuvor angezeigten Alarminformationen können wir aufgrund unserer Erfahrung nicht auf eine bestimmte Ursache schließen. Historische Erfahrungen sind nicht unbedingt genau und zuverlässig, und echte Schlussfolgerungen können nur durch Untersuchung und Analyse relevanter Protokolle gezogen werden.
7. Bei der Konfiguration von Alarminformationen müssen wir deren Rationalität sorgfältig abwägen. Es wird empfohlen, sich schrittweise an den besten Zustand anzupassen, indem man zuerst anzieht und dann lockert. Dadurch können zu viele oder zu wenige Alarmmeldungen von Anfang an vermieden werden, wodurch die Arbeitseffizienz und -genauigkeit verbessert wird.

2. Zeit zur Linderung von Systemproblemen: Fehlerreaktionsmechanismus, schnelle Blutstillung

Warum müssen wir Systemprobleme entschärfen, anstatt sie nur zu lokalisieren? Denn bei Systemproblemen ist die bloße Lokalisierung des Problems nur ein Teil der Lösung. Noch wichtiger ist, dass wir Systemprobleme so schnell wie möglich beheben müssen, um weitere Auswirkungen auf das Geschäft zu vermeiden.

Um die Effizienz der Problembehandlung zu verbessern, müssen wir von den folgenden drei Aspekten ausgehen:

1. Verbessern Sie das Befehlssystem und die Rollenverteilung : Ein vollständiges Befehlssystem und eine klare Rollenverteilung können die Effizienz der Fehlerbehandlung effektiv verbessern. Bei der Bearbeitung von Problemen muss jede Rolle ihre Verantwortlichkeiten und Aufgaben klären und gemeinsam an der Lösung des Problems arbeiten.
2. Vollständige technische Fehlerisolierung bedeutet : Auf technischer Ebene müssen wir einige Fehlerisolierungsmittel einführen, beispielsweise durch DUCC-Switches, um übermäßiges Code-Rollback zu vermeiden. Dadurch kann die Blutung schneller gestoppt werden (DUCC schaltet in Sekunden um, wenn die Maschine mehrmals zurückrollt, dauert es 5-10 Minuten)
3. Ausreichend gebohrte Garantie für Fehlerbehandlungsmechanismen : Schließlich müssen wir eine ausreichend gebohrte Garantie für Fehlerbehandlungsmechanismen einrichten, einschließlich UAT-Umgebungstests, Fehlerbehebungsübungen, Notfallplan-SOP usw. Dies ermöglicht eine schnelle Reaktion und effektive Problemlösung, wenn Probleme auftreten.

Kurz gesagt: Um die Effizienz der Problembehandlung zu verbessern, müssen wir eine Reihe von Maßnahmen ergreifen, um die Systemproblemzeit zu verkürzen, und nicht nur, um das Problem zu lokalisieren. Nur so kann die Stabilität und Zuverlässigkeit des Systems wirklich gewährleistet werden.

2.1. Implementieren Sie einen Fehler-Notfallreaktionsmechanismus

Unabhängig von der Größe einer Organisation ist ihre Fähigkeit, auf Notfälle zu reagieren, eines ihrer wichtigsten Merkmale. Bei Notfällen ist ein vollständiger Notfallplan und ein praktischer Schulungsmechanismus erforderlich, um sicherzustellen, dass auf verschiedene Notfälle schnell und effektiv reagiert werden kann. Um dieses Ziel zu erreichen, müssen wir von folgenden Aspekten ausgehen:

1. Etablieren Sie einen vollständigen Trainings- und Übungsprozess: Es ist sehr wichtig, einen vollständigen Trainings- und Übungsprozess einzurichten und aufrechtzuerhalten. Dies erfordert eine Gruppe von Personen, die mit dem Geschäft vertraut sind und sich engagiert für die Formulierung und Umsetzung relevanter Pläne einsetzen. Gleichzeitig müssen regelmäßige Übungen und Simulationstests unter realen Bedingungen durchgeführt werden, um die Wirksamkeit und Durchführbarkeit von Notfallplänen sicherzustellen.
2. Melden Sie das Problem zuerst der Gruppe und nutzen Sie die Stärke des Teams: Bei der Bewältigung eines Notfalls sollten Sie das Problem zuerst der Gruppe melden und die Stärke des Teams voll ausnutzen. Durch Brainstorming kann die Ursache des Problems schneller gefunden und entsprechende Maßnahmen zur Lösung ergriffen werden.
3. Bestimmen Sie die Schwere des Problems angemessen: Bei der Bestimmung der Schwere des Problems müssen Sie über ein gutes technisches Urteilsvermögen verfügen und ein gewisses Maß an Ruhe bewahren.

Kurz gesagt, um die Fähigkeit der Organisation, auf Notfälle zu reagieren, zu verbessern, müssen wir einen vollständigen Schulungs- und Übungsprozess einrichten, die Stärke des Teams voll ausschöpfen und die Schwere des Problems angemessen bestimmen . Nur so kann die Stabilität und Zuverlässigkeit der Organisation wirklich gewährleistet werden.

Aufteilung der Schlüsselrollen

1. Fault Commander . Diese Rolle stellt den Kern des gesamten Befehlssystems dar. Seine wichtigste Verantwortung ist die Organisation und Koordination, nicht die Ausführung, wie z. B. die verantwortliche Person, der Teamleiter und der Architekt.
2. Kommunikation und Anleitung . Verantwortlich für die Sammlung und Berichterstattung interner und externer Informationen, erfordert jedoch gute Kommunikations- und Ausdrucksfähigkeiten, wie z. B. die eines Produktmanagers.
3. Testamentsvollstrecker . Alle Arten von Mitarbeitern, die an der Fehlerbehandlung beteiligt sind, sind für die tatsächliche Fehlerlokalisierung und die Wiederherstellung des Geschäftsbetriebs verantwortlich, z. B. die Kernkollegen für Forschung und Entwicklung sowie Betrieb und Wartung des Teams.

Prozessmechanismus

1. Nach Entdeckung eines Fehlers haben Bereitschaftskollegen oder Teamleiter das Recht, entsprechende Geschäftsentwicklungs- oder andere notwendige Ressourcen hinzuzuziehen, um schnell ein Treffen zu organisieren.
2. Wenn das Problem schwierig ist und große Auswirkungen hat, können Sie um Intervention auf höherer Ebene bitten, beispielsweise den Abteilungsleiter usw.

Feedback-Mechanismus

Rückmeldung über den aktuellen Bearbeitungsfortschritt und die nächste Aktion. Wenn es Vorgänge gibt, die sofort durchgeführt werden müssen, melden Sie diese im Voraus. Zu den zu meldenden Inhalten gehören auch die Auswirkungen auf das Geschäft und das System. Abschließend wird der Fehlerkommandant vorgenommen Treffen Sie eine Entscheidung, bevor Sie sie ausführen, um zu vermeiden, dass Sie beschäftigt sind. Etwas ist schief gelaufen. Kein Fortschritt ist immer noch Fortschritt und zeitnahes Feedback ist erforderlich. Feedback von nicht-technischem Personal, z. B. vom Kundendienst usw. Es darf nicht in technischen Begriffen, sondern in einer möglichst sachlichen Sprache beschrieben werden, und der Gegenpartei muss eine grobe Erwartung mitgeteilt werden, z. B. was wir tun, wie lange die Wiederherstellung dauern wird und ob dies nicht möglich ist Wie lange dauert es, bis ich einen Rückruf erhalte? Feedback und mehr.

2.2. Notfallplan zur schnellen Blutstillung

Grundprinzipien: Bei allen während des Fehlerbehandlungsprozesses ergriffenen Mitteln und Maßnahmen hat die Wiederherstellung des Geschäftsbetriebs höchste Priorität, und die Wiederherstellung von Hämostaselösungen vor Ort hat Vorrang vor der Suche nach der Fehlerursache.

1. Wenn Sie auf ein Problem stoßen, besteht Ihre erste Reaktion möglicherweise darin, sofort mit der Fehlerbehebung zu beginnen und zu versuchen, die Ursache des Problems so schnell wie möglich zu finden. Das ist falsch! Mach das nicht. Der richtige Ansatz ist: Die Behebung von Systemproblemen hat oberste Priorität und alles wird getan, um das System wieder betriebsbereit zu machen.
2. Blutungen schnell stoppen, statt die Ursache zu untersuchen. Zunächst ist es nur erforderlich, das Problem grob zu lokalisieren und dann die Situation durch einige Notfallplanmaßnahmen (Herabstufung des DUCC-Schalters, Strombegrenzung, Rollback usw.) wiederherzustellen.
3. Überlegen Sie bei Online-Problemen zunächst, ob diese durch Änderungen wie Online-Gehen, Ändern von Geschäftskonfigurationen usw. und Angleichen von Informationen verursacht werden.
4. Während der Veröffentlichung traten Fehler auf, aber vor der Veröffentlichung war alles normal? Machen Sie sich um nichts Sorgen, setzen Sie es zuerst zurück und untersuchen Sie es dann langsam, nachdem es wieder normal ist.
5. Die Anwendung läuft seit langem stabil, aber plötzlich beginnt der Prozess abzubrechen? Da es sich höchstwahrscheinlich um einen Speicherverlust handelt, starten Sie die Methode daher stillschweigend neu.
6. Wie kann festgestellt werden, ob es sich um ein online eingeführtes Problem handelt? Besteht das gleiche Problem jedes Jahr vor der Online-Schaltung (z. B. gestern oder letzte Woche) ? Wenn es auch existiert, bedeutet das, dass es nichts mit dem Online-Gehen zu tun hat. Schauen Sie sich das Protokoll von gestern an. Das Protokoll ist das zuverlässigste. Die Verfügbarkeitsrate wird jeden täuschen (weil Sie die Verfügbarkeitsrate heute möglicherweise verwaltet haben und die Verfügbarkeitsrate zuvor 100 % betrug, aber nicht unbedingt 100 % beträgt).
7. Geschäft, Produkte und Forschung und Entwicklung werden parallel betrieben
8. Um das Problem schnell zu lokalisieren, sollte die Problemszene rechtzeitig gespeichert werden. Entfernen Sie beispielsweise zuerst den JSF-Dienst, behalten Sie jedoch einen Computer bei (starten Sie ihn nicht neu) und behalten Sie die JVM-Stack-Informationen für die anschließende Ursachenanalyse bei.

2.3. Nutzen Sie die vorhandenen Tools voll aus, um Positionierungsprobleme intelligent zu analysieren

2.2.1. Für TP99, das hoch und schwer zu positionieren ist:

Die Aufrufbeziehung ist komplex, was es schwierig macht, Leistungsengpässe schnell zu lokalisieren. Mithilfe von Tools können die komplexen Abhängigkeiten zwischen Diensten im Vorfeld geklärt werden und sich auf die Kernprobleme von Engpassdiensten konzentrieren, anstatt Verknüpfungen erst dann zu klären, wenn Probleme auftreten.

Wie Taishan-Failover usw.: Informieren Sie intelligent darüber, mit welchem ​​Faktor dieser Alarm am meisten zusammenhängt. Die Funktion befindet sich in der Testphase.
Global Signage, das UMP-Sammelstellen integriert, kann schnell erkennen, welcher Link einen hohen TP99 aufweist
Long-Link-Anwendung, Taishan-Radarkarte konfigurieren.
Pfinder-Distributed-Calling-Link als Grundlage für die Analyse

2.2.2. Als Reaktion auf das plötzlich hohe Anrufaufkommen

Sie können JSF>Verkehrsschutz>Anwendungen und Schnittstellen>Alias ​​und Methodenname verwenden, um das Anrufvolumen von Upstream-Anwendungen zu ermitteln und dann entsprechende Maßnahmen zu ergreifen, z. B. Upstream-Kommunikation, Strategien zur Strombegrenzung usw.

2.2.3. Thread-Analyse, JVM, Flame-Graph-CPU-Sampling usw.

Taishan-Plattform》Fehlerdiagnose》Online-Diagnose

2.2.4. Geschäftsthemen

Laut Fahrtenbuchrecherche gibt es dazu nichts zu sagen.

Indem Sie Techniker durch standardisierte Verfahren anleiten und schulen, können Sie die Zeit verkürzen, die zur Lösung von Problemen benötigt wird. Im Falle desselben Fehlers können Sie mithilfe einer geeigneten Dokumentation und Notfallplänen (SOPs) schnell alle ursächlichen Faktoren untersuchen, die möglicherweise zu dem Fehler geführt haben.

3. Zusammenfassung

Nachdem das Online-Problem behoben ist, ist das Verfassen eines COE-Überprüfungsberichts (Center of Excellence) ein sehr wichtiger Schritt. In diesem Bericht können wir den gesamten Problembehandlungsprozess überprüfen und darüber nachdenken, was wir hätten tun können, um die MTTR (Mean Time To Repair) schneller zu verkürzen, wenn wir dies zu diesem Zeitpunkt getan hätten.

Konkret können wir von folgenden Aspekten ausgehen:

1. Analysieren Sie die Ursache des Problems: Zunächst müssen Sie eine eingehende Analyse des Problems durchführen, um die Grundursache des Problems herauszufinden . Nur wenn wir die Grundursache des Problems finden, können wir gezielte Maßnahmen zur Lösung des Problems ergreifen und die MTTR verkürzen.
2. Erfahrungen und Erkenntnisse zusammenfassen: Im Prozess der Problemanalyse müssen wir Erfahrungen und Erkenntnisse zusammenfassen und Verbesserungsvorschläge machen. Zu diesen Vorschlägen können die Optimierung von Prozessen, die Verbesserung der Effizienz, die Stärkung des Trainings usw. gehören. Es ist jedoch nicht erforderlich, eine Reihe von Maßnahmen aufzulisten. Konzentrieren Sie sich einfach auf die wichtigsten Punkte gemäß der 2/8-Regel .
3. Ziehen Sie Schlussfolgerungen aus einem Beispiel, um zu verhindern, dass beim nächsten Mal ähnliche Probleme auftreten : Wir müssen die Erfahrungen und Lehren aus diesem Problem auf andere ähnliche Probleme anwenden, um zu verhindern, dass ähnliche Probleme erneut auftreten.

Kurz gesagt: Durch eine eingehende Analyse von Problemen, die Identifizierung von Grundursachen, die Zusammenfassung von Erfahrungen und Lehren sowie das Ziehen von Schlussfolgerungen aus einem Beispiel können wir die MTTR effektiv verkürzen und die Stabilität und Zuverlässigkeit des Systems sicherstellen .

Referenz:

SRE Google Betriebs- und Wartungsentschlüsselung

Kontinuierliche Lieferung 2.0

Autor: JD Logistics Feng Zhiwen

Quelle: JD Cloud Developer Community Ziyuanqishuo Tech Bitte geben Sie beim Nachdruck die Quelle an

200 Yuan Geldstrafe und mehr als 1 Million Yuan beschlagnahmt You Yuxi: Die Bedeutung hochwertiger chinesischer Dokumente Musks Hardcore-Migrationsserver Solon für JDK 21, virtuelle Threads sind unglaublich! ! ! TCP-Überlastungskontrolle rettet das Internet- Flutter für OpenHarmony ist da. Die LTS-Periode des Linux-Kernels wird von 6 auf 2 Jahre wiederhergestellt. Go 1.22 behebt den Variablenfehler der For-Schleife. Svelte hat ein „neues Rad“ gebaut – Runen. Google feiert sein 25-jähriges Jubiläum
{{o.name}}
{{m.name}}

Ich denke du magst

Origin my.oschina.net/u/4090830/blog/10114513
Empfohlen
Rangfolge