Vor etwa einem Jahr technische Schwierigkeiten Bei Citi wurden zeitweise mehrere Hunderttausend Karten und eine Reihe von Geldautomaten gleichzeitig abgeschaltet. Das Ergebnis: Citis neu eingeführte Costco Anywhere-Karten erhielten eine „ Flut von Beschwerden .”

Der Internetausdruck für etwas in diesem Ausmaß lautet „Reifenbrand“.

Vorfälle, die sich zu einem echten Brand entwickeln, betreffen normalerweise jeden in der Organisation, von der Unternehmensleitung über die Benutzer bis hin zum Supportdesk. Die PR- oder Marketingabteilung schlägt Alarm und kümmert sich um die externe Kommunikation, und das technische Team muss sich darum kümmern.

Das bedeutet, dass Sie eine interne Obduktion und ein SLA-gesteuertes meine Schuld nach außen. Diese werden oft als „Root-Cause“-Analysen verfasst und konzentrieren sich auf die Schuldzuweisung und Korrektur der an dem Vorfall beteiligten Personen, Prozesse und Technologien.

Technische Leiter können und sollten in solchen Situationen mehr tun, als nur Schuld zuzuweisen. Ja, die Teams sollten so schnell wie möglich handeln, um die Triage zu bewältigen und den Service wieder in den Normalzustand zu versetzen. Aber bei der Messung der Ursachen des Vorfalls, der Wirksamkeit der Reaktion und der Auswirkungen sollte das Ziel nicht darin bestehen, sich ausschließlich auf die „Grundursachen“ zu konzentrieren.

Der Point-and-Shoot-Ansatz schiebt die Schuld auf andere und verlangt ein Budget. Ein Portfolio-Ansatz zeigt, wie die aktuellen Investitionen bestimmte Ergebnisse gebracht haben und wie eine Umverteilung diese Ergebnisse verändern könnte. Er hilft dem Rest der Organisation zu erkennen, wie in DevOps , Support- und Serviceteams.

Sprechen Sie mit mir übers Geschäft!

Beispielsweise interne Tools wie Service jetzt , PagerDuty , Und Locker sind Investitionen in Geschwindigkeit und Breite – sie helfen den Leuten, Probleme in Ihrem gesamten Infrastruktur-Stack viel schneller zu lösen. Um sie weiter auszubauen, sind möglicherweise engere Integrationen mit entwicklungsspezifischen Tools, mehr Bereitschaftspersonal oder ein System zur Benachrichtigung der Benutzer auf Mobilgeräten oder in Apps erforderlich. Diese Investitionen sollten nicht ad hoc nach einem Vorfall präsentiert werden. Vielmehr sollten die Metriken für Vorfallmanagement und Vorfalllösung eine Möglichkeit sein, zu zeigen, wie sie derzeit konfiguriert sind und wo Personen, Prozesse und Tools hinzugefügt werden könnten, um die Ergebnisse der Vorfalllösung zu verbessern.

Darüber hinaus sollte die Kommunikation in einer klaren, geschäftsgerechten Sprache erfolgen, da DevOps, TechOps, der Support und die Serviceorganisation bei Vorfällen zwangsläufig mit der Geschäftsseite kommunizieren müssen.

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

Priorität 2

Interne Vorfallbenachrichtigungen (z. B. Ticket zur Änderungsverwaltung) werden sofort an das Bereitschaftspersonal gesendet (über PagerDuty und Slack). Das SLA erfordert eine Managementkommunikation mit dem Kontoinhaber am selben Tag.

• (Historischer Prozentsatz) % der Vorfälle mit Priorität 3, die innerhalb des im SLA vereinbarten Ziels gelöst wurden
• (Prozentsatz) % der Vorfälle mit Priorität 3 innerhalb des relevanten Zeitrahmens.

Priorität 1

Interne Vorfallbenachrichtigungen (z. B. Ausfall der Warenkorb-App) werden sofort an das Bereitschaftspersonal, das Managementteam und den Support gesendet. Das SLA erfordert eine Kommunikation des Managements mit dem Einsatzleiter innerhalb einer Stunde nach dieser Benachrichtigung.

• (Historischer Prozentsatz) % der Vorfälle mit Priorität 1, die innerhalb des im SLA vereinbarten Ziels gelöst wurden
• (Prozentsatz) % der Vorfälle mit Priorität 1 innerhalb des relevanten Zeitrahmens.

Diese Vorlage kann intern verwendet werden für Einsatzkräfte und Geschäftsinteressenten sowie extern für Kunden und Interessenten. Auch ohne technische Kenntnisse kann die Geschäftsseite den Vorfallverlauf und die Lösungszeit verstehen. Diese Daten sind ein Vermögenswert, den das technische Team pflegen kann, und binden direkt Vorfalllösung und DevOps-Prozesse zum Endergebnis.

Während die oben genannten Punkte Ihnen dabei helfen, die richtigen Gespräche auf Unternehmensebene zu führen, Obduktion ist für DevOps- und Serviceteams eher introspektiv. Fragen Sie: Sind diese Prozesse richtig? Ist unsere Infrastruktur robust genug? Wenn nicht, wie messen wir das, damit wir es wissen und was würden wir ändern?

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

• Wir priorisieren Vorfälle entsprechend ihrer Auswirkung und Dringlichkeit:
  • Anzahl der Tickets, bei denen die Priorität nach der Anmeldung geändert wurde
  • Anzahl zusätzlich erstellter Tickets aufgrund von Beschwerden oder Eskalationen
  • Anzahl und Stufe des Personals, das den einzelnen Ticketprioritäten zugewiesen ist
• Wir kommunizieren eng, damit Kunden und Benutzer wissen, was passiert und wann sie mit der Lösung ihrer Vorfälle rechnen können:
  • Prozentsatz der Vorfälle, bei denen der Kunde den Service Desk kontaktierte, um ein Update anzufordern
• Kunden und Nutzer sind mit unserem Vorfallmanagement zufrieden:
  • Prozentsatz der Benutzer, die bei der Zufriedenheitsumfrage nach einem Vorfall eine Bewertung von 4 oder 5 abgeben
  • Höhere Zufriedenheit mit der Vorfalllösung bei der jährlichen Kundenzufriedenheitsumfrage
• Wir erkennen wiederkehrende Vorfälle und erläutern die Probleme im öffentlichen Forum, um dazu beizutragen, zukünftige negative Auswirkungen zu verringern:
  • Anzahl der vom Service Desk protokollierten und im Forum aufgedeckten Probleme
  • Anzahl der zum Forum weitergeleiteten Tickets
  • Anzahl der vom Forum generierten Tickets
• Wir nutzen unsere Investitionen und Werkzeuge zur Vorfallbehebung effizient:
  • Prozentsatz der per E-Mail/Forum/Anwendung protokollierten Vorfälle
  • Prozentsatz der mit Self-Service-Tools erkannten und gelösten Vorfälle
  • Durchschnittliche Kosten zur Lösung des Vorfalls (nach Priorität)
  • Durchschnittliche Zeit zur Lösung von Vorfällen seit der Investition in Tools
  • Prozentuale Reduzierung der Anzahl von Vorfällen seit der Investition in Tools

Es gibt noch viel mehr Kennzahlen, die darauf basieren, was für Ihr spezifisches Team am sinnvollsten zu analysieren ist, aber diese Kennzahlen können Ihnen einen Vorsprung bei der Beantwortung dieser unvermeidlichen Fragen verschaffen, und sie erfordern keine große Prozessneuerfindung, um loszulegen. Verwenden Sie einfach modernes Ticketing, Überwachung , Vorfallbehebung, Zusammenarbeit , und Tools zur Kundenzufriedenheit, von denen viele über integrierte Analysefunktionen verfügen.

Die oben erwähnten PagerDuty und Slack sind Standardtools für die Vorfallbehebung und Zusammenarbeit. ServiceNow und die Atlassian Suite eignen sich hervorragend für die Verbindung von Vorfall- und Asset-Management. Wichtig ist vor allem, dass die effektive Lösung und Vorbeugung von Vorfällen nicht nur von Werkzeugen abhängt, sondern auch von einem klar definierter Prozess das den Menschen dabei hilft, die Tools auf effektive, integrierte und selbstbediente Weise zu nutzen.

Niemals „Sonstiges“, „Verschiedenes“ oder andere allgemeine Kategorien in die Bewertung der Effektivität Ihrer Tools, Prozesse und Mitarbeiter einbeziehen – das ist, als würden Sie eine Falltür in alle Ihre Kennzahlen einbauen. Eine Vorlage kann zwar ein guter Ausgangspunkt sein, das Team wird jedoch viel mehr aus Ihrem Reporting herausholen, wenn Sie mehr tun, als nur aus einer Vorlage zu kopieren. Beginnen Sie stattdessen mit der Intuition Ihres Teams:

• Liegt bei Ihrem Service ein Fehler im Abrechnungsmodul der Kategorie P1 oder P2 vor?
• Für welche Kunden wäre P1 das Richtige?
• Gibt es Kunden, für die alles P1 ist?

Kochen Sie nicht das Meer. Denken Sie daran, Sie sind im selben Team und es ist kein Ablage.

Konzentrieren Sie sich bei diesen Fragen darauf, wie Ihr Team mit diesen Vorfällen umgeht (Zeitplan, Personal, Einsatz von Tools usw.) und legen Sie auf dieser Grundlage Prioritäten fest. Wenn Sie die grundlegenden Kategorien an Werkzeugen und Prozessen zur Vorfallbehebung abgedeckt haben und über Kennzahlen verfügen, die nachverfolgen, wie das Unternehmen weiterhin in Verbesserungen investieren kann, sind Sie bestens aufgestellt – selbst im Fall von Reifenbränden.

^{Foto in Springfield Reifenhandel auf Simpsons Wiki}