ilert führt dediziertes Incident Management ein

Nicht alle Alarmierungen sind gleich. Einige können schnell von der Dienstbereitschaft gelöst werden. Andere weisen auf ein Problem hin, das schwerwiegend genug ist, um das gesamte Unternehmen zu beeinträchtigen. Sie erfordern die Koordination des gesamten Teams. Deshalb haben wir Incidents als dedizierten Workspace für die Koordination von Alarmierungen mit dem größten Business Impact neu konzipiert.

‍

Bisher wurden Incidents in ilert genutzt, um Status-Updates an Kunden und Stakeholder zu kommunizieren. Einen Incident zu erstellen bedeutete gleichzeitig, ihn auf der Statusseite zu veröffentlichen. Wir haben jetzt beides voneinander getrennt: Incidents bleiben intern – Status-Updates dienen weiterhin der externen Kommunikation. Sie werden nur veröffentlicht, wenn Sie sich aktiv dafür entscheiden.

‍

Innerhalb eines Incidents kann Ihr Team einen Incident Channel erstellen, parallele Eskalationen auslösen, die Timeline nachverfolgen, den Status verwalten und Postmortems erstellen. Kunden erhalten keine Informationen, bis ein Status-Update veröffentlicht wird.

‍

Hier ist ein Überblick darüber, was sich geändert hat und was neu ist.

Incidents als interner Workspace für die Koordination

Bisher bedeutete das Erstellen eines Incidents in ilert, dass direkt ein Update auf der Statusseite veröffentlicht wurde. Die Koordination des Incidents fand innerhalb der Alarmierungen statt, und Informationen wurden in dem Moment öffentlich, in dem ein Incident erstellt wurde.

‍

Das ist jetzt nicht mehr der Fall: Incidents bleiben intern. Nichts wird öffentlich, bis Sie ein Status-Update veröffentlichen. Beim Erstellen eines Incidents öffnet sich ein interner Workspace für das Response Team. Nichts gelangt auf die Statusseite, bevor Sie sich für die Veröffentlichung eines Status-Updates entscheiden. Beides ist jetzt vollständig entkoppelt.

Alarmierungen, Incidents und Status-Updates

Mit dieser Änderung gibt es in ilert jetzt drei klar voneinander getrennte Objekte, die jeweils einen eigenen Zweck erfüllen:

• • Alarmierungen haben sich nicht geändert. Sie weisen auf Probleme hin und benachrichtigen Ihr Team.
  • Incidents sind jetzt ein dedizierter interner Workspace für die Koordination der Incident Response. Sie sind nicht mehr mit der Statusseite verknüpft.
  • Status-Updates sind jetzt von Incidents getrennt. Über sie kommunizieren Sie mit Kunden und Stakeholdern, sobald Sie dazu bereit sind.

Bestehende Incidents werden automatisch zu Status-Updates migriert. Es werden keine Daten gelöscht.

Incidents mit Schweregrad und eigenem Channel deklarieren

Beim Deklarieren eines Incidents erscheinen zwei neue Felder: Schweregrad und Incident Channel.

Schweregrad

Mit dem Schweregrad lässt sich der Business Impact bereits beim Deklarieren eines Incidents klassifizieren. Das ist hilfreich für Routing, Reporting und klare Erwartungen im Team. Beim Deklarieren eines Incidents ist der Schweregrad standardmäßig auf SEV3 gesetzt und kann je nach Kontext geändert werden.

Incident-Kanal

Beim Deklarieren eines Incidents kann ein dedizierter KanalChannel erstellt werden. Bisher erfolgte dies über Alarmierungen. Jetzt ist der KanalChannel direkt im Incident verankert, wo der gesamte Kontext für die Incident Response an einem Ort gebündelt ist.

Ein vollständiger Incident-Response-Workspace: parallele Eskalationen, Incident Commander, Status, Timeline und Postmortems

Nach der Deklaration wird der Incident zum zentralen Ort, an dem das Team die Incident Response koordiniert.

Parallele Eskalationen

Mit parallelen Eskalationen lassen sich beim Deklarieren eines Incidents mehrere Teams und einzelne Personen gleichzeitig benachrichtigen. Ihr Team muss nicht warten, bis eine Eskalationskette Schritt für Schritt durchlaufen wurde, bevor die nächste ausgelöst wird.

‍
Folgendes kann gleichzeitig ausgelöst werden:

• eine Eskalationskette
• ein Dienstplan
• ein komplettes Team, bei dem alle Mitglieder gleichzeitig benachrichtigt werden
• ein bestimmter Nutzer direkt

Wird ein Team direkt benachrichtigt, stoppt das erste Teammitglied, das dem Incident beitritt, die Benachrichtigung für alle anderen. Diese erhalten eine „Page resolved“-Benachrichtigung.

Incident commander

Mit dem Incident Commander lässt sich ein bestimmtes Teammitglied zuweisen, das die Verantwortung für die Incident Response übernimmt. So hat das Team vom Deklarieren bis zur Lösung des Incidents eine zentral verantwortliche Person.

Incident-Status

Der Incident-Status kann während der Bearbeitung nachverfolgt und aktualisiert werden. So bleiben alle intern darüber informiert, wo die Incident Response gerade steht.

Incident-Timeline

Die Incident-Timeline zeichnet jede Aktion, jede Benachrichtigung und jede Änderung automatisch in Echtzeit auf. Das ist hilfreich, während der Incident läuft und unerlässlich beim Erstellen des Postmortems.

Postmortems

Postmortems wurden von Status-Updates zu Incidents verschoben – dorthin, wo der vollständige Verlauf tatsächlich erfasst wird. Wenn ein Incident gelöst wird, kann ein Postmortem erstellt werden, wobei Informationen aus der Timeline, Nachrichten aus dem Incident-Kanal und verknüpfte Alarmierungen mit einfließen.

Status-Updates: Kommunikation mit Stakeholdern

Was bisher auf der Statusseite als Incident bezeichnet wurde, heißt jetzt Status-Update. Die Funktionalität bleibt ansonsten unverändert. Status-Updates haben jetzt eine eigene dedizierte Seite in ilert.

Es gibt zwei Möglichkeiten, ein Status-Update zu erstellen:

Status-Update über die Status-Updates-Seite veröffentlichen

Die Status-Updates-Seite bietet eine dedizierte Ansicht aller veröffentlichten Updates. Sie können nach Service, Statusseite und Erstellungsdatum filtern und neue Updates direkt von dort aus veröffentlichen.

Status-Update über einen Incident veröffentlichen (empfohlen)

Bearbeiten Sie den Incident intern und veröffentlichen Sie ein Status-Update, sobald Sie bereit sind, extern zu kommunizieren. Das Status-Update wird mit dem Incident verknüpft, sodass interne Koordination und externe Kommunikation miteinander verbunden bleiben.

Kurz gesagt: Incidents dienen jetzt als interne Koordinationsebene mit dedizierten Tools, die Ihr Team während der Incident Response unterstützen. Status-Updates bleiben unverändert und dienen weiterhin als Kommunikationsebene, um Kunden und Stakeholder zu informieren.

‍

Bei Fragen oder wenn Sie Unterstützung bei dem neuen Set-up benötigen, wenden Sie sich gerne an Ihren Customer Success Manager oder kontaktieren Sie unser Support-Team.

‍

Die Änderungen werden ab Montag, dem 20. Juli, schrittweise ausgerollt. Wenn Sie schneller von den Aktualisierungen profitieren möchten, kontaktieren Sie uns unter support@ilert.com.

‍

Neu bei ilert? Incident-Management ist in allen Tarifen verfügbar. Probieren Sie es kostenlos aus und sehen Sie selbst, wie Ihr Team schneller koordiniert, wenn es darauf ankommt.