Wie misst man die Kosten eines Vorfalls?

Viele in der Technologiebranche betrachten die Kosten eines Vorfalls ausschließlich unter dem Gesichtspunkt von Ausfallzeiten oder der Anzahl betroffener Kunden und Mitarbeiter. Auf den ersten Blick mag das oft ein nachvollziehbarer Ansatz sein. Es sorgt für Schlagzeilen, und Kundenreputation und -vertrauen sind – ganz klar – entscheidend für den Erfolg eines jeden Unternehmens.

Ein weiterer direkter Kostenfaktor von Vorfällen, der selten Beachtung findet, ist die Anzahl der Personen, die während eines Vorfalls involviert werden müssen; sei es, um bei der Untersuchung der Ursache, der Fehlerbehebung und der Lösung des Vorfalls zu helfen oder um ihr Team von der Verantwortung zu entbinden – unabhängig davon, ob der Vorfall schwerwiegend genug ist, um Ihre Kunden zu beeinträchtigen.

Laut PagerDuty -Daten 50% von Die Einsatzkräfte verbringen ihre Zeit damit, zu ermitteln, wer am besten zur zusätzlichen Unterstützung hinzugezogen werden sollte. ( und der Versuch herauszufinden, ob tatsächlich ein Problem vorliegt ) in der Umgebung x oder mit dem Dienst y. Angesichts dieser Statistik bedeutet dies, dass 50 % der Lebensdauer eines Vorfalls in den Anfangsphasen (Diagnose- und Triagephase) und nicht in den eigentlichen Abhilfemaßnahmen verbracht werden.

Das Fazit? Die Kosten für Arbeitsstunden und die Anzahl der manuellen Maßnahmen pro Vorfall können schnell beträchtlich werden.

Automatisierung Ihrer Reaktion auf Vorfälle

Die Anwendung von Automatisierung in den frühen, wiederkehrenden Phasen des Vorfalls, einschließlich der Diagnose des Schweregrades des Vorfalls und des Verständnisses der genetischen Zusammensetzung dessen, was schiefgelaufen ist (und wie), ist entscheidend für den Erfolg der letztendlichen Behebung des Vorfalls.

Automatisierung ist auch aus personeller Sicht wichtig, um zu verhindern, dass Ihre Teams durch immer wiederkehrende Aufgaben bei jedem Vorfall überlastet werden. Die Verfügbarkeit der Diagnosedaten für die Einsatzkräfte ist entscheidend für die Effizienz der Einsatzplanung und den gesamten Arbeitsablauf der Vorfallsbewältigung.

Bevor wir fortfahren, sollten wir zunächst den Begriff „Diagnostikdaten“ definieren. Diagnosedaten Ist Die von Incident-Respondern erhobenen Daten sind in der Regel spezifischer als die von Überwachungstools bereitgestellten Informationen. Während Überwachungstools beispielsweise bei einem plötzlichen Anstieg der CPU- oder Speicherauslastung Alarm schlagen, untersuchen Incident-Responder die Prozesse mit dem höchsten CPU- und Speicherverbrauch. In diesem Fall stellen die Prozessnamen bzw. -IDs und deren zugehöriger Ressourcenverbrauch die „Diagnosedaten“ dar.

Nachdem wir nun die automatisierte Diagnose definiert haben, Warum sollte dich das interessieren? Denn die Einführung einer automatisierten Diagnosepraxis kann die Kosten von Vorfällen senken, indem sowohl die Vorfallsdauer verkürzt als auch weniger Einsatzkräfte alarmiert werden.

Das Problem mit MTTR

Vielleicht ist „Problem“ hier das falsche Wort, aber hören Sie mir zu: Die Kennzahl MTTR ist zu allgemein, um detaillierte, umsetzbare Erkenntnisse zu liefern. Die mittlere Reparaturzeit (MTTR) ist seit Jahrzehnten eine Standardkennzahl für die Wartbarkeit in der IT-Welt. Obwohl sie viele Anwendungsbereiche hat und die allgemeine Wiederherstellungsrate gut beschreibt, liegt ihre Achillesferse genau darin – in ihrer Allgemeingültigkeit. Und da wir nun mit Sicherheit davon ausgehen können, dass 50 % von Da die Einsatzkräfte viel Zeit damit verbringen, zu entscheiden, wer am besten zur zusätzlichen Unterstützung hinzugezogen werden sollte, haben wir begonnen, uns andere Kennzahlen innerhalb der MTTR-Zeitleiste anzusehen, wie z. B. MTTT (mittlere Zeit bis zur Triage) oder MTTI (mittlere Zeit bis zur Untersuchung).

MTTI/MTTT Die durchschnittliche Zeitspanne zwischen der Erkennung eines IT-Vorfalls und dem Beginn der Ursachen- und Lösungsuntersuchung durch das Unternehmen. Dies bezeichnet die Zeitspanne zwischen der mittleren Erkennungszeit (MTTD) und dem Beginn der mittleren Reparaturzeit (MTTR).

Bei PagerDuty messen wir dies als die Zeitspanne zwischen der Bestätigung des Ersthelfers und der Bestätigung des Problembehebungsteams. Diese Kennzahl hilft uns, die tatsächlichen Vorgänge im Hintergrund während eines Vorfalls zu verstehen. Aus unseren eigenen Daten konnten wir schließen, dass die mittlere Zeit bis zur Fehlerbehebung (MTTI) einer der zeitintensivsten Faktoren der mittleren Reparaturzeit (MTTR) ist. Und im modernen Geschäftsleben bedeutet jede Aufgabe, die Zeit und Aufmerksamkeit von Technikern erfordert, einen hohen Kostenaufwand. Wirklich teuer.

Nutzung automatisierter Diagnoseverfahren

Kommen wir nun zurück zum Thema MTTI und automatisierter Diagnostik. Die mittlere Zeit bis zur Fehlerbehebung (MTTI) verlängert sich nicht nur durch die technischen Aufgaben der Einsatzkräfte, die Diagnosedaten manuell abrufen und anhand des jeweiligen Dienstes und Vorfalls entscheiden müssen, an welches Team eskaliert werden soll. Es geht auch um die beteiligten Personen und ihre jeweiligen Grenzen, abhängig von dem spezifischen Fachwissen, das für den Beginn der Problemlösung erforderlich ist. Beispielsweise wissen die Ersthelfer in vielen Fällen nicht, wie sie das Problem aus der Datenbank- oder Netzwerkperspektive untersuchen sollen. Dies kann an fehlenden Kenntnissen (Datenbank- oder Netzwerkkenntnisse), fehlendem Zugriff oder an implizitem Wissen liegen (z. B. dass eine bestimmte Anwendungskomponente von einer komplexen Integration mit einem Drittanbieterdienst abhängt).

Durch die Automatisierung dieser Untersuchungs- und Fehlerbehebungsaufgaben sowie die Möglichkeit, diese Aktionen an verschiedene Teams und Einsatzkräfte zu delegieren, werden Sie einen positiven Kaskadeneffekt auf die mittlere Zeit bis zur Fehlerbehebung (MTTI) und schließlich auch auf die mittlere Zeit bis zur Reparatur (MTTR) erleben.

Warum sollten Sie sich also für automatisierte Diagnosen interessieren?

Mit automatisierter Diagnose können Sie:

• Reduzieren Eskalationen bei knappen Experten durch die Entwicklung von Wegen, um den Ersthelfern Informationen bereitzustellen, die normalerweise manuell gesammelt würden.
• Verteilen Fachkompetenz in allen Einsatzteams
• Aufrufen sichere Automatisierung hinter Firewalls und VPCs
• Fehlerbehebung und schneller lösen, ohne dass menschliches Eingreifen erforderlich ist
• Verbessern die Geschwindigkeit der Einarbeitung neuer Ingenieure und die Gewährleistung optimaler Effizienz auf allen Ebenen der Incident-Response-Organisation

Erste Schritte

Sie haben Ihre Entscheidung getroffen. Jetzt ist es an der Zeit, neue Wege zu beschreiten, aber wo fängt man an?

Um es mit einem Marketing-Slang auszudrücken: Man sollte nicht versuchen, das Unmögliche möglich zu machen. Testen Sie stattdessen Maßnahmen, die sowohl unkompliziert als auch risikoarm sind. Das könnte beispielsweise bedeuten, Ihre ressourcenintensivsten Dienste genauer unter die Lupe zu nehmen oder einfache Datenabfragen von verschiedenen Überwachungsanwendungen, Festplattennutzung usw. durchzuführen. Wichtig ist jedoch eine Strategie für die langfristige Einführung und eine klare Vision dieser Funktionalität. Natürlich können Sie ein Skript schreiben, das Daten aus zahlreichen Quellen abruft und einem Vorfall hinzufügt. Das ist aber alles andere als skalierbar.

Es ist wichtig, Überlegen Sie, welche verschiedenen Infrastrukturkomponenten und Tools Sie zur Erfassung von Diagnosedaten benötigen. Sie benötigen einen standardisierten Ansatz für die Schnittstelle zu Ihren heterogenen und dynamischen Umgebungen.

Um mehr über automatisierte Diagnosen zu erfahren, schauen Sie sich einige unserer Anleitungsartikel , die wir das ganze Jahr über weiterhin veröffentlichen werden. Außerdem sollten Sie sich auf einen Vortrag von Jake Cohen zum Thema automatisierte Diagnostik freuen. PagerDuty Gipfel nächste Woche !

Weitere Informationen zum Prozessautomatisierungsportfolio von PagerDuty finden Sie hier: Besuchen Sie diese Seite Und Nehmen Sie Kontakt mit Ihrem Kundenbetreuer auf Heute.

Noch Fragen? Stellen Sie sie gerne auf Twitter @sordnam