Vor etwa einem Jahr, einige technische Schwierigkeiten Bei Citi wurden vorübergehend mehrere hunderttausend Karten und zahlreiche Geldautomaten gleichzeitig abgeschaltet. Die Folge: Die neu eingeführten Costco Anywhere-Karten von Citi erhielten eine „ Flut von Beschwerden „

Im Internet nennt man so etwas „Reifenbrand“.

Vorfälle, die sich zu einem Großbrand ausweiten, betreffen in der Regel alle Bereiche des Unternehmens – von der Führungsebene über die Nutzer bis hin zum Support. PR oder Marketing schlagen Alarm und kümmern sich um die externe Kommunikation, während das technische Team mit der Lösung des Problems allein gelassen wird.

Dies bedeutet, einen internen post mortem und eine SLA-gesteuerte mea culpa für die Außenwelt. Diese werden oft als „Ursachenanalysen“ verfasst, die sich auf die Schuldzuweisung und Korrektur der an dem Vorfall beteiligten Personen, Prozesse und Technologien konzentrieren.

Technische Führungskräfte können und sollten in solchen Situationen mehr tun, als nur Schuldzuweisungen vorzunehmen. Natürlich sollten die Teams so schnell wie möglich die Störung beheben und den Normalbetrieb wiederherstellen. Doch bei der Analyse der Ursachen des Vorfalls, der Effektivität der Reaktion und der Auswirkungen sollte der Fokus nicht allein auf den „Grundursachen“ liegen.

Der punktuelle Ansatz sucht nach Schuldigen und fordert ein Budget. Ein Portfolioansatz zeigt hingegen, welche konkreten Ergebnisse die aktuellen Investitionen erzielt haben und wie eine Umschichtung diese Ergebnisse verändern könnte. Er hilft dem Rest des Unternehmens zu erkennen, wie Investitionen sinnvoll sind. DevOps , Support- und Serviceteams.

Sprechen Sie mit mir über Geschäfte!

Zum Beispiel interne Tools wie ServiceNow , PagerDuty , Und Locker Investitionen in Geschwindigkeit und Reichweite helfen dabei, Probleme in Ihrer gesamten Infrastruktur deutlich schneller zu beheben. Ein weiterer Ausbau kann engere Integrationen mit entwicklungsspezifischen Tools, mehr Bereitschaftspersonal oder ein System zur Benachrichtigung von Nutzern auf Mobilgeräten oder in Apps erfordern. Diese Investitionen sollten nicht ad hoc nach einem Vorfall präsentiert werden. Vielmehr sollten die Kennzahlen für Vorfallmanagement und -behebung aufzeigen, wie diese aktuell konfiguriert sind und wo Personal, Prozesse und Tools hinzugefügt werden können, um die Ergebnisse der Vorfallbehebung zu verbessern.

Außerdem sollte die Kommunikation in einer klaren, „geschäftstauglichen“ Sprache erfolgen, da Vorfälle die DevOps-, TechOps-, Support- und Serviceorganisationen zwangsläufig dazu zwingen, mit der Geschäftsseite zu sprechen.

Hier ist ein sehr einfaches Beispiel für die Kommunikation bei Vorfällen:

Priorität 2

Interne Störungsmeldungen (z. B. Änderungsmanagement-Tickets) werden umgehend an die diensthabenden Mitarbeiter (via PagerDuty und Slack) gesendet. Die Service-Level-Vereinbarung (SLA) erfordert die Kommunikation mit dem Account-Inhaber am selben Tag.

• (Historischer Prozentsatz)% der Vorfälle der Priorität 3, die innerhalb der vereinbarten SLA-Zielvorgabe gelöst wurden
• (Prozent)% der Vorfälle der Priorität 3 innerhalb des relevanten Zeitraums.

Priorität 1

Interne Störungsmeldungen (z. B. Ausfall der Warenkorb-App) werden umgehend an den Bereitschaftsdienst, das Management und den Support gesendet. Die Service-Level-Vereinbarung (SLA) sieht vor, dass das Management innerhalb einer Stunde nach dieser Meldung den Einsatzleiter kontaktiert.

• (Historischer Prozentsatz)% der Vorfälle der Priorität 1, die innerhalb der vereinbarten SLA-Zielvorgabe gelöst wurden
• (Prozent)% der Vorfälle der Priorität 1 innerhalb des relevanten Zeitraums.

Diese Vorlage kann intern verwendet werden für Einsatzkräfte und für Geschäftspartner sowie extern für Kunden und Interessenten. Auch ohne technisches Vorwissen können die Geschäftsbereiche den Vorfallverlauf und die Lösungszeit nachvollziehen. Diese Daten sind ein wertvolles Gut, das das technische Team pflegen und direkt mit den Geschäftsprozessen verknüpfen kann. Vorfallbehebung und DevOps-Prozesse bis hin zum Endergebnis.

Das oben Genannte hilft Ihnen zwar dabei, die richtigen Gespräche auf Geschäftsebene zu führen, aber ein internes post mortem Für DevOps- und Serviceteams ist es eher eine Frage der Selbstreflexion. Fragen Sie sich: Sind diese Prozesse korrekt? Ist unsere Infrastruktur ausreichend ausfallsicher? Wenn nicht, wie können wir das messen und was würden wir ändern?

Hier sind einige Beispielkennzahlen, die Sie bei der Beurteilung der Leistung Ihres Teams berücksichtigen sollten:

• Wir priorisieren Vorfälle angemessen, basierend auf ihren Auswirkungen und ihrer Dringlichkeit:
  • Anzahl der Tickets, deren Priorität nach der Protokollierung geändert wurde
  • Anzahl der aufgrund von Beschwerden oder Eskalationen zusätzlich erstellten Tickets
  • Anzahl und Dienstgrad des Personals, das jeder Prioritätsstufe des Tickets zugeordnet ist.
• Wir kommunizieren gut, damit Kunden und Nutzer verstehen, was passiert und wann sie mit der Behebung ihrer Probleme rechnen können:
  • Prozentsatz der Vorfälle, bei denen der Kunde den Kundendienst kontaktierte, um ein Update zu erhalten
• Kunden und Nutzer sind mit unserem Umgang mit Vorfällen zufrieden:
  • Prozentsatz der Nutzer, die in der Zufriedenheitsumfrage nach dem Vorfall eine Bewertung von 4 oder 5 abgegeben haben.
  • Erhöhte Zufriedenheit mit der Vorfallbearbeitung laut jährlicher Kundenzufriedenheitsumfrage
• Wir erkennen wiederkehrende Vorfälle und erläutern Probleme im öffentlichen Forum, um zukünftige negative Auswirkungen zu verringern:
  • Anzahl der vom Service Desk gemeldeten Probleme, die im Forum aufgedeckt wurden
  • Anzahl der an das Forum weitergeleiteten Tickets
  • Anzahl der vom Forum generierten Tickets
• Wir nutzen unsere Investitionen und Tools zur Störungsbehebung effizient:
  • Prozentsatz der per E-Mail/Forum/Anwendung gemeldeten Vorfälle
  • Prozentsatz der Vorfälle, die mithilfe von Selbstbedienungstools erkannt und behoben wurden
  • Durchschnittliche Kosten zur Behebung des Vorfalls (nach Priorität)
  • Durchschnittliche Zeit zur Behebung von Vorfällen seit der Investition in die Tools
  • Prozentuale Reduzierung der Vorfallszahlen seit der Investition in die Tools

Es gibt weitaus mehr Kennzahlen, je nachdem, was für Ihr spezifisches Team am sinnvollsten zu analysieren ist. Diese Kennzahlen können Ihnen jedoch einen Vorsprung verschaffen, um die unvermeidlichen Fragen zu beantworten, und erfordern keine großen Prozessänderungen für den Einstieg. Nutzen Sie einfach ein modernes Ticketsystem. Überwachung , Störungsbehebung, Zusammenarbeit und Instrumente zur Kundenzufriedenheitssteigerung, von denen viele über integrierte Analysefunktionen verfügen.

Die oben genannten PagerDuty und Slack sind Standardwerkzeuge für die Störungsbehebung und Zusammenarbeit. ServiceNow und die Atlassian Die Suite eignet sich hervorragend zur Verknüpfung von Incident- und Asset-Management. Wichtig ist dabei vor allem, dass die effektive Behebung und Prävention von Incidents nicht nur von den Tools abhängt, sondern auch von einem umfassenden System. wohldefinierter Prozess das Menschen dabei hilft, Werkzeuge effektiv, integriert und im Selbstbedienungsverfahren zu nutzen.

Niemals Wenn Sie bei der Bewertung der Effektivität Ihrer Tools, Prozesse und Mitarbeiter Kategorien wie „Sonstiges“, „Verschiedenes“ oder ähnliches verwenden, schaffen Sie sich quasi eine Hintertür in Ihren Kennzahlen. Auch wenn eine Vorlage ein guter Ausgangspunkt sein kann, profitiert Ihr Team deutlich mehr von Ihren Berichten, wenn Sie nicht einfach nur eine Vorlage kopieren. Setzen Sie stattdessen auf die Intuition Ihres Teams.

• Wird ein Fehler im Abrechnungsmodul für Ihren Dienst als P1 oder P2 kategorisiert?
• Für welche Kunden wäre es P1?
• Gibt es Kunden, für die alles P1 ist?

Bringt das Meer nicht zum Kochen. Denkt daran, ihr sitzt im selben Team und es ist kein ... Ablagerung.

Konzentrieren Sie sich bei diesen Fragen darauf, wie Ihr Team mit solchen Vorfällen umgeht (Zeitablauf, Personal, Verwendung von Tools usw.) und skizzieren Sie darauf basierend Prioritäten. Wenn Sie die grundlegenden Kategorien von Werkzeugen und Prozessen zur Störungsbehebung abgedeckt haben und Kennzahlen erfassen, die nachverfolgen, wie das Unternehmen weiterhin in Verbesserungen investieren kann, dann sind Sie bestens gerüstet – selbst im Falle eines Reifenbrands.

^{Foto in Springfield Reifenhof auf Simpsons Wiki}