Les processus du centre d'exploitation du réseau (NOC) sont figés depuis des décennies. Mais il est temps que certains d'entre eux évoluent. La transformation numérique et l'ère du cloud ont conduit à l'essor de DevOps et, avec lui, à la propriété des services. Propriété du service Cela signifie que les développeurs assument la responsabilité de la prise en charge du logiciel qu'ils livrent à chaque étape du cycle de vie. Cela rapproche les équipes de développement de leurs clients, de l'entreprise et de la valeur qu'elles apportent.

Cela nécessite également de s'éloigner des méthodes traditionnelles de gestion des incidents du NOC. Pourtant, à mesure que les organisations évoluent vers la propriété des services, certains anciens processus du NOC demeurent. Voici trois processus NOC courants qui restent en suspens et comment les remplacer ou les mettre à jour.

Processus en suspens : les intervenants de niveau 1 ne sont pas en mesure de résoudre les problèmes

Les NOC étaient autrefois le centre de commandement des problèmes technologiques. Ils fonctionnaient comme un cerveau, envoyant des signaux aux appendices concernés. Un problème de réseau ? La voie vers le réseau. Un problème de sécurité ? La voie vers la sécurité. La fonction principale du NOC était d'impliquer le bon expert pour résoudre un problème. Cela signifiait fouiller dans des feuilles de calcul (et parfois dans des carnets de contacts physiques !) pour déterminer qui était responsable de quoi.

Lorsque tout se déroulait sur place et en personne, cela avait du sens. Il y avait moins de services et les incidents pouvaient être clairement séparés par département. Si la base de données rencontrait un problème, vous pouviez appeler l'intervenant de garde de la base de données. L'intervenant (qui serait probablement au bureau ou suffisamment proche pour intervenir en personne) pouvait alors se rendre au centre de données et y jeter un œil.

Aujourd'hui, à l'ère du télétravail et du cloud, où les entreprises disposent de centaines ou de milliers de services gérés par des dizaines, voire des centaines d'équipes réparties dans le monde entier, la méthode du Rolodex n'a plus d'utilité. Il est pratiquement impossible de tenir à jour des feuilles de calcul précises pour savoir quelles équipes sont responsables de quels services. Et, à mesure que l'organisation évolue, les dossiers deviennent rapidement obsolètes. Les services peuvent se déplacer d'une équipe à l'autre. Les équipes changent à mesure que les personnes passent d'une équipe à l'autre ou quittent/rejoignent l'entreprise. Désormais, un intervenant de niveau 1 doit travailler très dur pour identifier la bonne personne de manière efficace et rapide.

Les entreprises doivent trouver un moyen de supprimer ces étapes manuelles pour trouver la bonne personne et acheminer les incidents directement vers les experts en la matière qui peuvent intervenir pour répondre aux problèmes. Cela peut se faire de différentes manières. Pour certaines entreprises, un modèle de propriété de service DevOps est la bonne voie à suivre. Ceux qui écrivent le code sont chargés de répondre et de réparer le service en cas d'incident. L'alerte est acheminée directement vers la personne d'astreinte de l'équipe de développement qui prend en charge le service, et l'expert en la matière prend le relais.

Pour d'autres organisations, il peut être judicieux d'adopter une approche hybride dans laquelle les intervenants de niveau 1 servent de première ligne de défense avant de passer aux équipes distribuées et de garde pour leurs services. Les intervenants de niveau 1 ne doivent pas être un centre de routage qui relie le problème à une autre équipe. Au lieu de cela, ils doivent être habilités à résoudre eux-mêmes un incident. Vous pouvez configurer vos intervenants de niveau 1 pour qu'ils soient plus efficaces en leur permettant de résoudre les problèmes et sélectivement résoudre les incidents. L'accès à l'automatisation et aux ressources telles que les manuels d'exploitation peut permettre aux intervenants de niveau 1 d'accélérer le processus de diagnostic et de correction, souvent sans avoir à perturber les experts en la matière qui sont en charge du service X via une escalade. En mettant l'automatisation entre les mains des intervenants de niveau 1, les organisations peuvent éviter les escalades inutiles et permettre aux intervenants de niveau 1 de résoudre les problèmes plus rapidement.

Processus en souffrance : les incidents majeurs ne sont pas signalés ou le sont trop tard

Nous l'avons déjà entendu : le temps, c'est de l'argent. Et lorsque les NOC étaient la principale méthode de réponse aux incidents, ils avaient une responsabilité supplémentaire. Un NOC devait s'assurer que les ressources étaient bien gérées. Cela signifiait qu'aucun personnel inutile ne répondait aux problèmes. Les NOC étaient souvent tenus pour responsables s'ils signalaient un incident majeur trop tôt et interrompaient les gens pour un problème mineur. Ces perturbations empêchaient les PME de se consacrer à l'innovation. Il était donc crucial pour les intervenants du NOC de ne signaler les incidents majeurs que lorsqu'il était clair qu'il s'agissait d'un problème beaucoup plus grave.

Mais aujourd'hui, le temps n'est plus de l'argent, c'est le temps de disponibilité qui est de l'argent. coût d'un incident majeur Les coûts qui passent inaperçus sont plus importants que le coût d'une aide supplémentaire. Imaginez que vous êtes un détaillant en ligne et que votre fonction de panier d'achat est en panne. Chaque minute pendant laquelle vos clients ne peuvent pas ajouter d'articles à leur panier, vous perdez des centaines de milliers de dollars. De plus, les attentes des clients ont augmenté au cours des dernières années. Les clients s'attendent à ce que leur application, leur outil, leur plateforme, leur service de streaming, etc. fonctionnent sans interruption. Et la confiance des clients s'érode lorsque ce n'est pas le cas. En fait, selon PWC , 1 client sur 3 cesserait de faire affaire avec une marque qu’il aime après une mauvaise expérience.

Les entreprises doivent signaler les incidents majeurs plus tôt pour atténuer l'impact sur les clients. Oui, cela peut signifier réveiller quelqu'un inutilement de temps en temps. Mais c'est beaucoup moins probable avec la propriété du service. Les PME responsables d'un service savent mieux quand appeler un incident majeur qu'un intervenant de niveau 1. Il y a donc moins de fausses alertes.

Gueule de bois des processus : des salles de guerre qui vont et viennent

Les NOC servent souvent de centre de communication en cas d'incident majeur. Cela permet aux intervenants qui travaillent à résoudre un problème de rester concentrés sur leur tâche. À l'époque où de nombreuses entreprises avaient tout (et tout le monde) sur site, il y avait un cellule de crise Les gens se rendaient sur place et le coordinateur du NOC tenait tout le monde au courant. Aujourd'hui, avec des équipes et des systèmes distribués, les salles de guerre physiques appartiennent au passé. De nombreuses entreprises disposent désormais de salles de guerre virtuelles avec un pont de vidéoconférence ou un canal de discussion qui reste ouvert pendant un incident.

D’autres parties prenantes pourraient vouloir traiter cette salle de guerre comme une salle physique, en y intervenant à leur guise. Mais, dans ce monde virtuel, cela signifie que ces parties prenantes posent des questions aux intervenants en cas d’incident. Cela retarde la résolution. Les entreprises qui ont des salles de guerre virtuelles qui vont et viennent peuvent être confrontées à davantage de problèmes de communication et de frustration. Les intervenants se sentent frustrés par les interruptions et les parties prenantes se sentent frustrées par le manque de communication.

Une façon d'atténuer ce problème est de fermer la salle de guerre aux non-participants. Si une personne ne fait pas partie de l'équipe d'intervention en cas d'incident, elle n'a pas besoin d'accéder à la salle de guerre virtuelle de l'équipe d'intervention. Au lieu de cela, ce dont elle a besoin, c'est d'un liaison interne Il s’agit d’un communicateur désigné de l’équipe d’intervention en cas d’incident.

Le responsable de la communication interne consolide les informations sur les incidents et les transmet aux parties prenantes concernées. Pour faciliter cette tâche, les responsables de la communication peuvent utiliser modèles de notification de mise à jour de statut . Ces modèles indiquent comment élaborer des communications destinées à un public spécifique. Ils garantissent que les parties prenantes reçoivent toutes les informations nécessaires à la prise de décisions. Et aucun intervenant n'a besoin d'arrêter de travailler sur l'incident en cours pour partager les mises à jour.

Les gueules de bois ne sont pas amusantes, mais elles finissent toujours

Les NOC sont un moyen éprouvé de gérer les incidents pour de nombreuses organisations. Mais les méthodes NOC deviennent obsolètes à l'ère de la transformation numérique. Une communication fluide et une réponse rapide sont essentielles pour préserver la confiance des clients. À l'avenir, les équipes impliqueront immédiatement les PME et signaleront les incidents majeurs le plus tôt possible. Elles communiqueront également avec les principales parties prenantes tout au long d'un incident tout en fixant des limites.

Et les équipes ont souvent besoin d’une plateforme d’opérations numériques pour les aider à soutenir cette transition. PagerDuty permet aux équipes d'apporter les meilleures pratiques en matière d'incidents majeurs à leur organisation, résolvant ainsi les incidents critiques plus rapidement et prévenant de futurs événements. Essayez-nous gratuitement pendant 14 jours.