Sammeln kritischer Beweise für eine schnellere Ursachenanalyse

Wahrscheinlich kommt Ihnen das bekannt vor: Sie stellen ein Problem mit der Endbenutzererfahrung fest (vielleicht eine Leistungsverschlechterung oder einen Ausfall). Sobald Sie die Ursache des Problems entdeckt haben, ist es nicht schwer, es zu beheben. Der wahre Schmerzpunkt ist jedoch die Zeit zwischen diesen beiden Ereignissen. Oftmals wird es dem Benutzer überlassen, die Ursache zu finden, indem er Teams, Prozesse und Tools zusammenstellt und isolierte Datenfragmente zusammensetzt.  Jede Minute, die Sie mit der Suche nach der Ursache verbringen, ist für Ihr Unternehmen verlorenes Geld und, was noch schlimmer ist, rufschädigend. In diesem Beitrag erfahren Sie, welche Beweise Sie sammeln müssen, um Ihren Prozess der Ursachenanalyse zu beschleunigen.  

• Analysieren Sie die kritischsten möglichen Probleme und entwickeln Sie eine Strategie, um die notwendigen Metriken zu sammeln (Was-wäre-wenn-Analyse)
• Erfassen Sie die richtigen Metriken, Ereignisse usw. in den Tools; diejenigen, die die Probleme erklären können
• Sammeln Sie alle zusätzlichen Informationen aus allen Tools, einschließlich der Protokolle auf Anwendungsebene, um sie zu korrelieren und Ursache-Wirkungs-Beziehungen zu finden.
• Erstellen Sie automatische Verfahren, die dabei helfen, Beweise und Abweichungen von der Norm in Beziehung zu setzen und Problemkaskaden zu erkennen.

Die Verantwortung für den ersten Aufzählungspunkt liegt bei der IT-Abteilung. Die letzten drei Punkte sollten vorzugsweise über eine einzige Plattform abgewickelt werden. Diese "zentrale Erfassungs- und Verarbeitungsplattform" würde alle Daten integrieren und verarbeiten. Andernfalls verlieren wir zu viel Zeit damit, in verschiedenen Tools zu suchen und verschiedene Teams einzubeziehen.

"Wir verlieren zu viel Zeit damit, in verschiedenen Tools zu suchen und verschiedene Teams einzubeziehen....." 

Das Sammeln der Beweise 

Alle Probleme zu erkennen, ist aus pragmatischer Sicht nicht möglich. Die kritischsten Probleme lassen sich jedoch mit den offensichtlichsten Metriken oder Ereignissen aufspüren, wie z.B.:

• kundenorientierte Service-Reaktionszeit
• Netzverlust
• verfügbarer Festplattenplatz
• Fehlerzahl
• Fehler in den Protokollen
• Aufbau von Nachrichten in Warteschlangen
• Änderungen der Umgebung, wie Upgrades oder Implementierungen

Viele Kunden verwenden Agenten, die jede VM überwachen und Betriebssystemmetriken (wie CPU, Speicher, Festplatten-I/O, Netzwerk-I/O) an ein Tool zur Protokollaggregation (wie Splunk oder Elasticsearch) senden. Diese Metriken sind ein guter Beweis für die Infrastruktur auf niedriger Ebene, aber sie beantworten nicht sofort die Frage: "Gibt es ein Problem aus der Sicht des Unternehmens oder des Endbenutzers?" Diese Metriken dienen hauptsächlich dazu, die Theorien darüber, was schief gelaufen ist, zu bestätigen oder zu verwerfen.  

Um die Ursache zu finden und Probleme zu erkennen, die sich über mehrere Teams, Hosts usw. erstrecken, müssen Sie benutzerbezogene/aufgabenkritische Überwachungsdaten mit den Daten auf niedriger Infrastruktur- und Anwendungsebene korrelieren. Die Fähigkeit, die gesamte Geschäftskette zu visualisieren, von vor Ort bis zur Cloud und von Legacy- bis zu Microservices, ist für die Bewältigung dieser Aufgabe entscheidend.  Nur so können Sie verstehen, welche Komponenten sich auf den Business Service auswirken könnten und diejenigen ausschließen, die dies nicht tun.

Ein konkreter Anwendungsfall

Stellen Sie sich vor, es gibt eine Antwortverzögerung für die Komponente 'Business X'. Als Operator würde ich gerne sehen, welche anderen Komponenten, die von der Komponente 'Business X' aufgerufen werden, ebenfalls von der Verzögerung betroffen sind. Mit anderen Worten: Ich möchte sehen, wie sich diese Verzögerung ausbreitet.  Das Verständnis der Komponenten und ihrer Beziehungen ist entscheidend, da sonst wertvolle Zeit mit der Suche nach Dingen verschwendet wird, die mit dem aktuellen Problem nichts zu tun haben. Diese Verbindungen ermöglichen es uns, verwandte Dienste mit einem Klick zu sehen, anstatt E-Mails an andere Teams zu senden oder in Splunk zu suchen, um herauszufinden, was miteinander in Beziehung steht.

Sobald eine Gruppe von Komponenten mit kaskadierenden Verzögerungen gefunden ist, betrachte ich jede einzelne und schließe diejenigen aus, die nicht korreliert sind. Dazu schaue ich mir alle gesammelten Metriken und Ereignisse an, um Abweichungen zu entdecken, die die Verzögerung erklären können.

Zusammenfassung

Die Integration mehrerer Informationsquellen und das Hinzufügen von Beziehungen erhöht die Wahrscheinlichkeit, die Ursache zu finden oder eine realistische Theorie auf der Grundlage von Beweisen und Daten zu entwickeln. Das Verständnis der Beziehungen zwischen den Komponenten, sowohl logisch als auch physisch, ist entscheidend. Wenn Sie diese Erkenntnisse mit allen verfügbaren Telemetriedaten (aus verschiedenen Datenquellen) kombinieren, erhalten Sie eine einheitliche Sichtweise, mit der Sie die mittlere Reparaturzeit (MTTR) drastisch reduzieren können. Wenn Sie mehr über die Ursachenanalyse erfahren möchten, empfehlen wir Ihnen, unseren Beitrag zu lesen  Ist die Ursachenanalyse tot oder fangen wir gerade erst an?". 

Möchten Sie mehr darüber erfahren, wie StackState Ihnen dabei hilft, Ihre Einblicke und Ursachenanalysen zu automatisieren? Fordern Sie noch heute eine kostenlose Anleitung an , um ein besseres Verständnis unserer Lösung zu erhalten.