NOC-Prozesse (Network Operation Center) sind seit Jahrzehnten in Stein gemeißelt. Doch es ist an der Zeit, einige dieser Prozesse weiterzuentwickeln. Die digitale Transformation und das Cloud-Zeitalter haben zum Aufstieg von DevOps und damit zur Service Ownership geführt. Diensteigentum Entwickler übernehmen Verantwortung für die Unterstützung der von ihnen bereitgestellten Software in jeder Phase des Lebenszyklus. Dadurch sind die Entwicklungsteams näher an ihren Kunden, dem Unternehmen und dem von ihnen geschaffenen Mehrwert.

Dies erfordert auch eine Abkehr von den traditionellen Methoden der NOC-Vorfallbearbeitung. Doch während Unternehmen auf Service Ownership umstellen, bleiben einige alte NOC-Prozesse bestehen. Hier sind drei häufige NOC-Prozessüberbleibsel und wie man sie ersetzt oder aktualisiert.

Prozess-Kater: L1-Responder können Probleme nicht lösen

NOCs waren früher die Kommandozentrale für technische Probleme. Sie funktionierten wie ein Gehirn und sendeten Signale an die entsprechenden Stellen. Netzwerkprobleme? Weiter zum Netzwerk. Sicherheitsprobleme? Weiter zur Sicherheit. Die zentrale Aufgabe des NOCs bestand darin, den richtigen SME zur Lösung eines Problems einzubeziehen. Das bedeutete, Tabellenkalkulationen (und manchmal auch physische Kontaktbücher!) zu durchforsten, um herauszufinden, wer wofür verantwortlich war.

Als alles vor Ort und persönlich erledigt war, war dies sinnvoll. Es gab weniger Dienste, und Vorfälle konnten sauber nach Abteilungen getrennt werden. Bei Problemen mit der Datenbank konnte man den Datenbank-Bereitschaftsdienst anrufen. Der Mitarbeiter (der wahrscheinlich im Büro oder in der Nähe war, um persönlich zu reagieren) konnte dann zum Rechenzentrum fahren und nachsehen.

Im Zeitalter der Remote-Arbeit und der Cloud, in dem Unternehmen Hunderte oder Tausende von Diensten von Dutzenden oder gar Hunderten von Teams weltweit verwalten, hat die Rolodex-Methode ausgedient. Es ist nahezu unmöglich, präzise Tabellen zu führen, um zu wissen, welche Teams für welche Dienste zuständig sind. Und mit dem Wandel in der Organisation veralten Datensätze schnell. Dienste können zwischen Teams wechseln. Teams verändern sich, wenn Mitarbeiter zwischen ihnen wechseln oder das Unternehmen verlassen bzw. neu betreten. Ein L1-Responder muss sich daher sehr anstrengen, um die richtige Person effizient und zeitnah zu identifizieren.

Unternehmen benötigen eine Möglichkeit, diese manuellen Schritte zu vermeiden, um die richtige Person zu finden und Vorfälle direkt an SMEs weiterzuleiten, die eingreifen und auf Probleme reagieren können. Dies kann auf verschiedene Weise geschehen. Für manche Unternehmen ist ein DevOps-Service-Ownership-Modell der richtige Weg. Diejenigen, die den Code schreiben, werden beauftragt, im Falle eines Vorfalls zu reagieren und den Service zu reparieren. Die Warnung wird direkt an die Bereitschaftsperson im Entwicklungsteam weitergeleitet, die den Service unterstützt, und das SME übernimmt von dort aus die weitere Bearbeitung.

Für andere Organisationen kann ein hybrider Ansatz sinnvoll sein, bei dem L1-Responder die erste Verteidigungslinie bilden, bevor sie an verteilte, einsatzbereite Teams weitergeleitet werden. L1-Responder sollten nicht als Routing-Center fungieren, das das Problem an ein anderes Team weiterleitet. Stattdessen sollten sie befugt sein, einen Vorfall selbst zu lösen. Sie können Ihre L1-Responder effektiver gestalten, indem Sie ihnen die Möglichkeit geben, sowohl Fehler zu beheben Und selektiv Beheben von Vorfällen. Der Zugriff auf Automatisierung und Ressourcen wie Runbooks ermöglicht es L1-Respondern, den Diagnose- und Behebungsprozess zu beschleunigen, oft ohne die für den X-Service zuständigen Fachexperten durch eine Eskalation zu stören. Durch die Automatisierung in den Händen von L1-Respondern können Unternehmen unnötige Eskalationen vermeiden und L1-Responder in die Lage versetzen, Probleme schneller zu lösen.

Prozess-Kater: Größere Störungen werden nicht oder zu spät gemeldet

Wir haben es schon oft gehört: Zeit ist Geld. Und da NOCs die primäre Methode zur Sicherstellung der Reaktion auf Vorfälle waren, trugen sie eine zusätzliche Verantwortung. Ein NOC musste sicherstellen, dass die Ressourcen gut verwaltet wurden. Das bedeutete, dass kein unnötiges Personal auf Probleme reagieren musste. NOCs wurden oft dafür verantwortlich gemacht, wenn sie zu früh einen größeren Vorfall meldeten und die Mitarbeiter wegen eines winzigen Problems unterbrachen. Diese Störungen hielten KMU von ihrer Innovationsarbeit ab. Daher war es für NOC-Responder entscheidend, nur dann einen größeren Vorfall zu melden, wenn klar war, dass ein viel größeres Problem im Spiel war.

Aber jetzt ist Zeit nicht Geld, sondern Betriebszeit. Die Kosten eines größeren Vorfalls Die unbemerkten Kosten übersteigen die Kosten für zusätzliche Hilfe. Stellen Sie sich vor, Sie sind ein Online-Händler und Ihr Warenkorb ist ausgefallen. Jede Minute, in der Ihre Kunden keine Artikel in den Warenkorb legen können, kostet Sie Hunderttausende von Dollar. Zudem sind die Kundenerwartungen in den letzten Jahren gestiegen. Sie erwarten, dass ihre App, ihr Tool, ihre Plattform, ihr Streaming-Dienst usw. reibungslos funktioniert. Und wenn das nicht der Fall ist, untergräbt das das Kundenvertrauen. Tatsächlich laut PWC , würde jeder dritte Kunde nach einer einzigen schlechten Erfahrung die Geschäftsbeziehung mit einer Marke, die er mochte, beenden.

Unternehmen müssen schwerwiegende Vorfälle früher melden, um die Auswirkungen auf ihre Kunden zu minimieren. Das kann zwar bedeuten, dass ab und zu jemand unnötig geweckt wird. Mit Service Ownership ist das jedoch deutlich unwahrscheinlicher. Serviceverantwortliche KMUs wissen besser, wann sie einen schwerwiegenden Vorfall melden müssen, als ein L1-Responder. Dadurch gibt es weniger Fehlalarme.

Prozess-Kater: Kommen-und-gehen-Kriegsräume

NOCs dienen oft als Kommunikationszentrum bei größeren Vorfällen. Dies hilft den Einsatzkräften, die an der Lösung eines Problems arbeiten, bei der Sache zu bleiben. Als viele Unternehmen noch alles (und jeden) vor Ort hatten, gab es eine Kriegsraum Die Mitarbeiter kamen dorthin, und der NOC-Koordinator hielt alle auf dem Laufenden. Mit verteilten Teams und Systemen gehören physische Krisenräume der Vergangenheit an. Viele Unternehmen verfügen stattdessen über virtuelle Krisenräume mit einer Videokonferenzbrücke oder einem Chat-Kanal, der während eines Vorfalls geöffnet bleibt.

Andere Stakeholder möchten diesen Krisenraum vielleicht wie einen physischen nutzen und jederzeit eingreifen. In der virtuellen Welt bedeutet dies jedoch, dass diese Stakeholder den Einsatzkräften Fragen stellen. Dies verzögert die Lösung. Unternehmen mit virtuellen Krisenräumen mit ständigem Kommen und Gehen können häufiger zu Missverständnissen und Frustration führen. Die Einsatzkräfte sind durch Unterbrechungen frustriert, und Stakeholder sind frustriert über mangelnde Kommunikation.

Eine Möglichkeit, dies zu mildern, besteht darin, den War Room für Nicht-Teilnehmer zu schließen. Wenn jemand nicht Teil des Incident-Response-Teams ist, benötigt er keinen Zugriff auf den virtuellen War Room des Response-Teams. Stattdessen benötigt er einen interne Verbindung . Dies ist ein benannter Kommunikator des Incident-Response-Teams.

Die interne Kommunikationsbeauftragte konsolidiert Informationen zu Vorfällen und leitet sie an relevante Stakeholder weiter. Um dies zu erleichtern, können Kommunikationsbeauftragte Folgendes verwenden: Vorlagen für Statusaktualisierungsbenachrichtigungen Diese Vorlagen geben vor, wie die Kommunikation für eine bestimmte Zielgruppe gestaltet werden soll. Sie stellen sicher, dass die Beteiligten alle notwendigen Informationen für ihre Entscheidungen erhalten. Und niemand muss die Arbeit am aktuellen Vorfall unterbrechen, um Updates zu teilen.

Kater sind nicht lustig, aber sie enden immer

NOCs sind für viele Unternehmen eine bewährte Methode zur Bewältigung von Vorfällen. Doch im Zeitalter der digitalen Transformation sind NOC-Methoden veraltet. Reibungslose Kommunikation und schnelle Reaktion sind entscheidend für das Vertrauen der Kunden. Künftig werden Teams die KMU umgehend einbeziehen und größere Vorfälle eher früher als später melden. Sie werden außerdem während eines Vorfalls mit den wichtigsten Beteiligten kommunizieren und gleichzeitig Grenzen setzen.

Und oft benötigen Teams eine digitale Betriebsplattform, um diesen Übergang zu unterstützen. PagerDuty ermöglicht es Teams, Best Practices für schwerwiegende Vorfälle in ihr Unternehmen zu integrieren, kritische Vorfälle schneller zu lösen und zukünftige Vorfälle zu verhindern. Testen Sie uns 14 Tage lang kostenlos.