Wie dein Team schnelle Vorfallslösungen fördert und Kundenvertrauen stärkt

Benjamin Franklin soll einst gesagt haben:

„Nur zwei Dinge auf Erden sind uns ganz sicher: der Tod und die Steuern.“

Manche Mitglieder in Service-Management-Teams würden allerdings ein drittes hinzufügen: IT-Vorfälle.

Im vergangenen Jahrzehnt hat sich der Ansatz, Software zu entwickeln und zu betreiben, dramatisch verändert. Moderne Systeme bestehen aus einer komplexen Microservices-Architektur mit zahllosen Komponenten, in der viele Räder ineinandergreifen.

Das hat erwiesene Vorteile; die Fähigkeit, Code-Änderungen jederzeit ohne Verzögerungen einzuspielen und neue Features in hoher Frequenz auszuliefern, ist nur einer davon. Doch der moderne Ansatz hat gleichzeitig die Anfälligkeit für Störungen des Systems erhöht.

Dem kannst du unter anderem mit Software-Lösungen wie Atlassian Compass zwar teilweise entgegenwirken, indem deine Teams alle Komponenten und „Rädchen im Getriebe“ mit ihren Kontextinformationen sichtbar machen. Dennoch ist in der modernen IT-Welt die Gefahr von Vorfällen immer präsent – von Performance-Störungen bis hin zu großflächigen Ausfällen. Die Ursachen dafür sind vielfältig: defekte Hardware, fehlerhafter Code, falsche Konfigurationen, Angriffe und vieles mehr.

Die Frage ist also nicht ob, sondern wann. Und dann kommt es darauf an, einen Prozess an der Hand zu haben, der dein Team dabei unterstützt, den Vorfall effektiv zu erkennen, einzugrenzen und – natürlich – schnellstmöglich zu beheben. Es geht also um ein strukturiertes, wirksames Incident-Management.

Warum Incident-Management so wichtig ist

Der Incident-Management-Prozess ist einer der kritischsten, den es in einem Unternehmen gibt, das IT-Systeme braucht, um Wertschöpfung zu betreiben – also quasi jedes!

Interne Störungen an Produktivsystemen sind brisant genug und können eine Organisation im Zweifel an den Rand der Handlungsfähigkeit bringen. Bei Vorfällen an extern zugänglichen Systemen sind die Auswirkungen oft noch gravierender – mit langfristig wirkenden Folgen. Sie äußern sich in Vertrauens- und Reputationsverlusten, schlechter Presse, gegebenenfalls Strafzahlungen aufgrund verletzter SLAs oder verärgerten, abziehenden Kunden.

Reagiert dein Team unsystematisch und ineffizient, kann sich ein kleiner Vorfall im schlimmsten Fall kaskadenartig fortpflanzen und zu einem Flächenbrand anwachsen. Wenn eine Störung lange dauert, wenn sich ähnlich gelagerte Probleme gar wiederholen, weil man aus früheren Incidents nicht die richtigen Lehren gezogen hat, wenn die Kunden im Unklaren darüber gelassen werden, was vor sich geht, hat dein Unternehmen ein großes Problem.

Im Rahmen des Incident-Managements kann dein Team vieles falsch machen und immense Schäden fördern – oder aber schnelle Lösungen generieren, Vertrauen bewahren und ein zufriedenstellendes Nutzererlebnis schaffen.

Obwohl es im eigentlichen Incident-Management-Prozess gemäß IT Infrastructure Library (ITIL) zunächst allein darum geht, den Service (notfalls mithilfe von Workarounds) wieder vollumfänglich herzustellen, hat sich in erfahrenen, vorausschauenden Service-Management-Teams ein weiter gefasster, zyklischer Prozess etabliert, der fünf Stadien umfasst.

Die Vorbereitung ernstnehmen

Viele Service-Management-Teams behandeln die Vorbereitung im Rahmen des Incident-Managements eher stiefmütterlich: Incident-Management spielt genau dann eine Rolle, wenn ein Incident vorliegt. Dabei kann eine gute, strukturierte Vorbereitung im Ernstfall Gold wert sein und unnötiges Chaos vermeiden. Aber wie kann sich dein Team effektiv wappnen?

Das Durchspielen von Was-wäre-wenn-Szenarien hilft, wirksame Prozesse quasi einzuüben und bestehende Abläufe immer wieder auf Lücken, Flaschenhälse oder Hürden abzuklopfen. Außerdem hat es sich bewährt, die nötige Zeit zu investieren, um wichtige Materialien für den Ernstfall zentral zusammenzutragen.

Sie können quasi einen ständig griffbereiten Notfallkoffer mit wichtigen Informationen bilden, die bei einem Incident sofort verfügbar sein müssen, beispielsweise Incident-Response-Pläne, Kontaktlisten, Bereitschaftsübersichten, Eskalationsrichtlinien, Links zu wichtigen Tools und Abstimmungskanälen, Zugangsdaten, Compliance-Richtlinien, Dokus und ein Kommunikationsplan.

Effiziente, zentralisierte Alarmierungen

Im Idealfall identifiziert dein Team einen Incident, bevor die User es tun und in Scharen den Support kontaktieren. Doch auf welchem Weg wird das Team informiert und alarmiert?

Heute existieren zahlreiche ausgereifte Monitoring-Tools für IT-Systeme. Sie benachrichtigen dein Team automatisch über unnormales Verhalten und Probleme. Allerdings birgt ein umfangreiches Toolset aus separaten Werkzeugen wiederum die Gefahr redundanter oder falscher Alarme, was sich im Zweifel negativ auf die Geschwindigkeit deines Teams auswirken kann.

Um solche Fehlerpotenziale zu minimieren, lohnt es sich, eine Ebene zur Zentralisierung von Warnmeldungen einzuziehen, etwa mit einer Lösung wie Atlassian Opsgenie. Mit ihr hat dein Team die Möglichkeit, automatisierte Alarmierungsprozesse auf Basis von Alarmtypen, Bereitschaftsplänen und Eskalationsroutinen zu implementieren. Dadurch entschlackt dein Team die Warnmeldungs-Workflows, vermeidet Verzögerungen und senkt das Risiko menschlicher Fehler.

Eindämmung und Kommunikation des Vorfalls

Im dritten Schritt geht es darum, die Dimension und Ausdehnung des Incidents festzustellen, ihn nach Möglichkeit einzugrenzen und sein Ausmaß einzudämmen, damit sich die Lage nicht noch verschlimmert. Sofortmaßnahmen wie das Zurückfahren einer Code-Änderung, die Trennung eines Netzwerks vom Rest des Systems oder ein Server-Neustart können helfen, die Ausweitung des Incidents zu verhindern (und in manchen Fällen ist damit sogar schon das Problem gelöst). Alle weiteren Aktivitäten zur vollumfänglichen Service-Wiederherstellung sind nachgelagert.

Zur selben Zeit sollte dein Team Transparenz gegenüber den Usern herstellen. Zugegeben: Wenn ein Team im Auge des Sturms steht, erscheint diese Priorität nicht besonders intuitiv. Allerdings sind die offene Kommunikation und die Schaffung von Transparenz extrem wichtig, um das Vertrauen der User zu rechtfertigen und nicht zu verlieren.

Wenn du als User auf eine Software zugreifst, tust du das, weil du in diesem Moment ein Problem hast und es nun lösen willst. Du hast dir die Zeit dafür reserviert, du zahlst Geld. Da ist ein Ausfall ärgerlich und frustrierend genug. Noch ärgerlicher ist es, wenn du absolut im Dunkeln tappst, was eigentlich los ist.

Dank des Kommunikationsplans aus dem Notfallkoffer ist dein Team in der Lage, die erforderlichen Aktionen via Atlassian Statuspage, Social Media und andere direkte Kanäle zeitnah anzufahren und über die folgenden Incident-Management-Stadien hinweg aufrechtzuerhalten.

Vollständige Service-Wiederherstellung

Die vierte Phase dreht sich darum, eine dauerhafte Lösung zu schaffen, die den Service vollumfänglich und nachhaltig restauriert. In diesem Stadium gehen das Incident-Management und die ITIL-Praxis des Problem-Managements Hand in Hand: Das Team muss die Problemursachen ermitteln und (darauf aufbauend) geeignete Maßnahmen implementieren, die das Auftreten ähnlicher Incidents künftig effektiv verhindern.

In der Quintessenz strebt das Team danach, das betroffene System besser und sicherer zu machen als zuvor. Das ist gelungen, wenn der Service alle gewohnten Fähigkeiten und Features aufweist und darüber hinaus gegen weitere Vorfälle des spezifischen Typs geschützt ist.

Die Phase des Lernens

Wenn das Gewitter durchgezogen ist, kommt für das Incident-Management-Team die Zeit der Aufarbeitung und des Lernens. In Form von Postmortem-Analysen beschreibt das Team die Problemquellen, Ursachen und Auslöser der Störung und unterzieht die vorangegangen Workflow-Schritte einer kritischen Würdigung. Diese Bewertung hat vor allem das Ziel, Optimierungspotenziale an den Systemen und den Abläufen zu identifizieren. Das eröffnet Chancen, die Prozesse gegebenenfalls anzupassen und die Robustheit der betroffenen Systeme zu erhöhen.

Wer, was, warum, wie? Das sind die zentralen Fragen, die ein Postmortem aufwerfen und (ohne Schuldzuweisungen) beantworten sollte, damit das Team strukturiert aus dem Incident lernen kann. Diese Learnings gehören wiederum als Referenzinformationen in den Notfallkoffer – womit sich der Kreis des modernen Incident-Managements schließt.

Incident-Management – strukturiert und wirksam

Die IT-Welt unserer Tage ist komplexer denn je. Unablässig stellen Veränderungsfaktoren die Resilienz der IT-Umgebungen auf die Probe. Wie gesagt: Vorfälle werden zwangsläufig irgendwann eintreten; die entscheidende Frage lautet, wie schwerwiegend sie sind und wie schnell dein Team sie behebt.

Moderne Service-Management-Teams sind auf diese Herausforderung eingestellt. Sie trainieren ihre Prozesse regelmäßig anhand von What-if-Szenarien, bereiten sich gründlich auf den Ernstfall vor, nehmen sich Zeit zum Lernen und stellen sicher, dass sie zu jedem Zeitpunkt auf alle relevanten Informationen und Werkzeuge zugreifen können. Das sind gute Voraussetzungen, um Störungen rasch und wirksam zu identifizieren, einzuhegen, zu lösen und professionell zu kommunizieren.

Hast du Fragen? Möchtest du mehr darüber wissen, wie die bewährten Service-Management-Lösungen von Atlassian deine Teams bei der Incident-Bearbeitung und anderen ITIL-Praktiken unterstützen? Dann melde dich bei uns: Unsere erfahrenen Fachleute freuen sich darauf, mit dir über Service-Management ins Gespräch zu kommen!

Weiterführende Informationen

SOS, IT! Was ist eigentlich Incident Management?
Finde die richtige Service-Management-Software
Modernes ITSM als Inspiration für ein organisationsweites Enterprise Service Management (ESM)