NOC- oder Network Operation Center-Prozesse sind seit Jahrzehnten in Stein gemeißelt. Doch es ist an der Zeit, dass sich einige dieser Prozesse weiterentwickeln. Die digitale Transformation und das Cloud-Zeitalter haben zum Aufstieg von DevOps und damit zum Service Ownership geführt. Diensteigentum bedeutet, dass Entwickler die Verantwortung für die Unterstützung der von ihnen bereitgestellten Software in jeder Phase des Lebenszyklus übernehmen. Dadurch kommen Entwicklungsteams näher an ihre Kunden, das Geschäft und den Wert, den sie liefern.

Es erfordert auch eine Abkehr von den traditionellen NOC-Vorfallbehandlungsmethoden. Doch während Organisationen zum Service Ownership übergehen, 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 Technologieprobleme. Sie funktionierten wie ein Gehirn und sendeten Signale an die entsprechenden Anhängsel. Netzwerkproblem? Weiter zum Netzwerk. Sicherheitsproblem? Weiter zur Sicherheit. Die zentrale Funktion des NOCs bestand darin, den richtigen SME einzubeziehen, um ein Problem zu lösen. Dies bedeutete, Tabellenkalkulationen (und manchmal physische Kontaktbücher!) zu durchforsten, um herauszufinden, wer für was verantwortlich war.

Als alles vor Ort und persönlich erledigt war, machte das Sinn. Es gab weniger Dienste und Vorfälle konnten sauber nach Abteilungen getrennt werden. Wenn es ein Problem mit der Datenbank gab, konnte man den diensthabenden Datenbank-Mitarbeiter anrufen. Der Mitarbeiter (der wahrscheinlich im Büro oder in der Nähe genug war, um persönlich zu reagieren) konnte dann zum Rechenzentrum gehen und nachsehen.

Im Zeitalter der Remote-Arbeit und der Cloud, in dem Unternehmen Hunderte oder Tausende von Diensten haben, die von Dutzenden oder sogar Hunderten von Teams auf der ganzen Welt verwaltet werden, hat die Rolodex-Methode ihren Zweck überlebt. Es ist nahezu unmöglich, genaue Tabellen zu führen, um zu wissen, welche Teams für welche Dienste verantwortlich sind. Und wenn sich die Organisation ändert, veralten Aufzeichnungen schnell. Dienste können zwischen Teams verschoben werden. Teams ändern sich, wenn Personen zwischen ihnen wechseln oder das Unternehmen verlassen/neu hinzukommen. Jetzt muss ein L1-Responder zu hart arbeiten, um die richtige Person effizient und zeitnah zu identifizieren.

Unternehmen müssen diese manuellen Schritte vermeiden, um die richtige Person zu finden und Vorfälle direkt an SMEs weiterzuleiten, die einspringen und auf alle Probleme reagieren können. Dies kann auf verschiedene Weise geschehen. Für einige Unternehmen ist ein DevOps-Service-Ownership-Modell der richtige Weg. Diejenigen, die den Code schreiben, werden beauftragt, bei einem Vorfall zu reagieren und den Service zu reparieren. Die Warnung wird direkt an die Bereitschaftsperson im Entwicklungsteam weitergeleitet, die den Service unterstützt, und der SME übernimmt von dort aus.

Für andere Organisationen kann ein hybrider Ansatz sinnvoll sein, bei dem L1-Responder als erste Verteidigungslinie fungieren, bevor sie an verteilte, einsatzbereite Teams weitergeleitet werden. L1-Responder sollten kein Routing-Center sein, das das Problem mit einem anderen Team verbindet. Stattdessen sollten sie befugt sein, einen Vorfall selbst zu lösen. Sie können Ihre L1-Responder effektiver einrichten, indem Sie ihnen die Möglichkeit geben, sowohl Fehler zu beheben Und selektiv Vorfälle lösen. Der Zugriff auf Automatisierung und Ressourcen wie Runbooks kann L1-Respondern dabei helfen, den Diagnose- und Behebungsprozess zu beschleunigen, oft ohne die Fachexperten, die für den X-Dienst verantwortlich sind, durch eine Eskalation stören zu müssen. Indem sie die Automatisierung in die Hände von L1-Respondern legen, können Organisationen unnötige Eskalationen vermeiden und L1-Responder in die Lage versetzen, Probleme schneller zu lösen.

Prozess-Kater: Großereignisse werden nicht oder zu spät gemeldet

Wir haben es schon einmal gehört: Zeit ist Geld. Und wenn NOCs die primäre Methode waren, um sicherzustellen, dass auf Vorfälle reagiert wurde, hatten sie eine zusätzliche Verantwortung. Ein NOC musste sicherstellen, dass die Ressourcen gut verwaltet wurden. Dies 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 Leute wegen eines winzigen Problems unterbrachen. Diese Störungen hielten KMU von ihrer Arbeit ab, Innovationen zu schaffen. Daher war es für NOC-Responder von entscheidender Bedeutung, nur dann einen größeren Vorfall zu melden, wenn klar war, dass ein viel größeres Problem im Spiel war.

Aber jetzt ist Zeit kein Geld, sondern Betriebszeit. Kosten eines Großschadens die unbemerkt bleiben, sind größer als die Kosten für zusätzliche Hilfe. Stellen Sie sich vor, Sie sind ein Online-Händler und Ihre Warenkorbfunktion ist ausgefallen. Jede Minute, in der Ihre Kunden keine Artikel in ihren Warenkorb legen können, verlieren Sie Hunderttausende von Dollar. Außerdem sind die Erwartungen der Kunden in den letzten Jahren gestiegen. Kunden erwarten, dass ihre App, ihr Tool, ihre Plattform, ihr Streaming-Dienst usw. ohne Unterbrechungen funktioniert. Und es untergräbt das Vertrauen der Kunden, wenn dies nicht der Fall ist. Tatsächlich laut PWC , würde jeder dritte Kunde nach einer schlechten Erfahrung die Geschäftsbeziehung mit einer Marke, die er mochte, beenden.

Organisationen müssen größere Vorfälle früher melden, um die Auswirkungen auf die Kunden zu verringern. Ja, das kann bedeuten, dass man hin und wieder jemanden unnötig aufweckt. Aber das ist bei Service Ownership weitaus unwahrscheinlicher. SMEs, die für einen Service verantwortlich sind, wissen besser, wann sie einen größeren Vorfall melden müssen, als ein L1-Responder. Es gibt also weniger Fehlalarme.

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

NOCs dienen oft als Kommunikationszentrale für größere Vorfälle. 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 Leute kamen dorthin und der NOC-Koordinator hielt alle auf dem Laufenden. Heute, wo Teams und Systeme verteilt sind, gehören physische Kriegsräume der Vergangenheit an. Viele Unternehmen haben stattdessen virtuelle Kriegsräume mit einer Videokonferenzbrücke oder einem Chat-Kanal, der während eines Vorfalls geöffnet bleibt.

Andere Stakeholder möchten diesen War Room vielleicht wie einen physischen War Room behandeln und nach Belieben vorbeischauen. In dieser virtuellen Welt bedeutet dies jedoch, dass diese Stakeholder den Incident Respondern Fragen stellen. Dies verzögert die Lösung. Unternehmen mit virtuellen War Rooms, die ständig wechseln, können häufiger zu Missverständnissen und Frustrationen führen. Die Responder sind durch Unterbrechungen frustriert und die Stakeholder sind frustriert über die mangelnde Kommunikation.

Eine Möglichkeit, dies zu mildern, besteht darin, den Kriegsraum für Nichtteilnehmer zu schließen. Wenn jemand nicht Teil des Incident Response Teams ist, braucht er keinen Zugang zum virtuellen Kriegsraum des Reaktionsteams. Stattdessen braucht er einen interne Verbindung . Dies ist ein benannter Kommunikator des Vorfallreaktionsteams.

Der interne Kommunikationsbeauftragte konsolidiert Informationen zu Vorfällen und leitet sie an relevante Stakeholder weiter. Um dies zu erleichtern, können Kommunikationsbeauftragte Vorlagen für Statusaktualisierungsbenachrichtigungen . Diese Vorlagen geben vor, wie Mitteilungen für ein bestimmtes Publikum verfasst werden. Sie stellen sicher, dass die Beteiligten alle Informationen erhalten, die sie für ihre Entscheidungen benötigen. Und keiner der Einsatzkräfte muss die Arbeit am aktuellen Vorfall unterbrechen, um Updates weiterzugeben.

Kater sind nicht lustig, aber sie enden immer

NOCs sind für viele Organisationen eine bewährte Methode zur Bewältigung von Vorfällen. Doch im Zeitalter der digitalen Transformation sind NOC-Methoden veraltet. Nahtlose Kommunikation und schnelle Reaktion sind der Schlüssel zum Erhalt des Kundenvertrauens. In Zukunft werden Teams KMU sofort einbeziehen und größere Vorfälle eher früher als später melden. Sie werden während eines Vorfalls auch mit wichtigen Stakeholdern kommunizieren und dabei Grenzen setzen.

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