Grace à Mouvement DevOps , nous comprenons maintenant pourquoi chaînes de distribution de logiciels Les silos sont une mauvaise chose. Ils compliquent la communication entre les différentes équipes, ce qui entraîne des retards de livraison, des retours en arrière et des bugs.

En matière de gestion des incidents, il existe un autre type de cloisonnement à prendre en compte : celui qui sépare les données de gestion des incidents d'un fournisseur ou d'un produit à un autre. Ces cloisonnements entravent la résolution des incidents, car ils compliquent la collecte et l'analyse des données de surveillance provenant de sources multiples.

Comment briser ces silos pour que les opérations de gestion des incidents se déroulent efficacement ?

Identifier les silos

La première étape pour travailler au-delà des silos de gestion des incidents est de comprendre pourquoi ces silos existent en premier lieu.

La raison est simple : Infrastructures modernes L'infrastructure est constituée de matériels et de logiciels divers. La plupart des composants ont des besoins de surveillance spécifiques. Ils génèrent des informations dans un certain format, selon un certain rythme, et nécessitent que les données soient collectées d'une certaine manière. Les informations de surveillance associées à chaque partie de l'infrastructure sont donc stockées dans un silo, car elles ne sont pas facilement comparables aux données provenant d'autres parties de l'infrastructure.

Prenons comme exemple un centre de données composé de dix serveurs bare metal exécutant Windows et de dix autres serveurs bare metal exécutant Linux. Dans ce scénario, l'entreprise aurait besoin d'outils de surveillance différents pour ses serveurs Windows et Linux. Bien que certaines informations de surveillance pour chaque type de système d'exploitation (comme le fait que l'hôte soit opérationnel) soient les mêmes, d'autres données ne le seraient pas. Et dans tous les cas, les données devraient être collectées par des outils compatibles avec le système d'exploitation en question. Chaque contexte devient donc un silo distinct, avec son propre écosystème miniature de outils et données de surveillance .

Il s'agit d'un exemple simple. Les choses sont beaucoup plus compliquées dans la plupart des situations réelles, où vous n'avez pas seulement deux types différents de serveurs bare-metal à surveiller, mais des serveurs virtuels fonctionnant sur un ou plusieurs types d'hyperviseurs, des postes de travail exécutant différents types de systèmes d'exploitation de bureau et des appareils mobiles fonctionnant avec un éventail très varié de systèmes d'exploitation mobiles, de versions, etc.

Briser les silos

Comment éliminer les silos qui séparent chaque contexte de surveillance au sein de votre infrastructure afin d'obtenir une solution transparente et visibilité de surveillance holistique ? La solution comporte deux parties.

Étape 1 : Centraliser la collecte des données

La première étape consiste à mettre en œuvre une solution de gestion des incidents capable de collecter des informations provenant de divers types d'environnements, puis de transmettre ces informations à un emplacement central. De cette façon, les ingénieurs peuvent surveiller l'ensemble de l'infrastructure à partir d'un seul point de vue. Ils n'ont pas besoin de regarder à l'intérieur des silos individuels pour surveiller différentes parties de l'infrastructure.

La collecte centralisée des données nécessite une solution de gestion des incidents suffisamment intelligente pour regrouper les informations de surveillance provenant de plusieurs sources. Il ne s'agit pas d'une tâche simple : la prise en charge d'un large éventail d'environnements et de points de terminaison nécessite intégration avec de nombreux types de systèmes de surveillance différents , parfois même des outils personnalisés.

Étape 2 : Traduire les données

La deuxième étape est souvent négligée. En plus de regrouper les données provenant de nombreux outils de surveillance et de les centraliser dans un emplacement central, les équipes de gestion des incidents doivent également traduire toutes les données dans un format cohérent.

La traduction des données est le seul moyen de garantir que chaque ingénieur soit en mesure d'interpréter et de réagir aux alertes provenant de n'importe quelle source. Si les données ne sont pas traduites, les ingénieurs devraient avoir une expertise particulière dans un type particulier de système de surveillance ou connaître le schéma d'un certain fournisseur, afin de comprendre les données provenant de ce système. Rendre toutes les données disponibles dans un emplacement central ne serait donc pas d'une grande aide pour briser les silos, car il resterait de hautes barrières séparant les différents contextes de surveillance.

Considérez, par exemple, les différentes manières dont Zabbix et Nagios utilisez le terme « alias ». Sur l'ancien système de surveillance, un alias sert essentiellement de raccourci pour tout type de terme de configuration. Sur Nagios, en revanche, un alias est un nom donné à un hôte. Sa signification est plus spécifique. Si vous ne comprenez pas cette différence et que vous voyez les données des systèmes Zabbix et Nagios agrégées dans un tableau de bord centralisé, les choses peuvent facilement devenir confuses.

Pour une gestion efficace des incidents, vous avez besoin d'une solution capable de traduire la terminologie spécifique au fournisseur et à la plate-forme en un langage unique et cohérent. Ce n'est qu'avec la normalisation des événements, telle que celle permise par le Format d'événement commun PagerDuty , les intervenants peuvent interpréter facilement et avec précision les données provenant de plusieurs sources.

La complexité des infrastructures modernes rend difficile d’éviter les silos. Cela ne signifie pas pour autant que les informations de surveillance doivent être conservées dans ces silos, car elles ne sont utiles que si elles peuvent être comprises et exploitées. En regroupant les informations de surveillance provenant de diverses sources et en les traduisant dans un langage compréhensible par tous les membres de l’équipe d’astreinte, les équipes de gestion des incidents peuvent briser les silos qui existent au sein de leur infrastructure. Elles bénéficieront alors d’une communication transparente et d’une réponse agile et en temps réel aux incidents.

^{Dunatov, Devin. « Speeding », 17 juillet 2012. Image en ligne. https://www.flickr.com/photos/ddunatov/7588797542 >}