Les 5 meilleurs tickets de support réseau à automatiser
Qu'est-ce qui vous frustre le plus dans le support réseau ? Rien de mieux que de jouer au détective sur un problème de réseau obscur et d'être le héros informatique qui le résout. Mais trop...
Imaginez une panne de réseau au milieu de la journée de travail dans votre organisation. Imaginez maintenant que personne ne sache quoi faire parce que votre ingénieur réseau senior est en vacances plongée sous-marine dans le Pacifique Sud, et il ou elle est la seule personne qui sait quoi que ce soit sur le réseau. Cela peut sembler idiot, mais la réalité est que la prévalence des connaissances tribales dans les services informatiques entraîne tout le temps des scénarios comme celui-ci.
Le terme « savoir tribal » fait référence à des informations qui sont détenues de près par un petit groupe de personnes, peut-être même une seule personne, et qui sont cachées involontairement ou délibérément au groupe plus large. C'est une pratique courante dans les départements informatiques d'aujourd'hui et cela nuit à une équipe technique très performante.
Nos systèmes ne fonctionnent pas dans le vide.
Les composants individuels de nos infrastructures informatiques sont tellement imbriqués que les ingénieurs doivent travailler en équipe pour résoudre les problèmes. Considérez le problème commun d'une application lente. Est-ce la latence du réseau qui fait mal performance de l'application? Un serveur d'applications lui-même pourrait-il être sous-alimenté ? Pourrait-il même être l'ordinateur de l'utilisateur final qui est le problème ?
Étant donné que le réseau fait partie d'un ensemble plus vaste de pièces interdépendantes et qu'aucun ingénieur ne peut tout savoir sur toutes choses, le partage des connaissances entre les ingénieurs et les équipes est essentiel. Néanmoins, certains gardent l'information très étroitement gardée. De cette façon, ils peuvent sembler être le héros du réseau, bien qu'il n'y ait rien d'héroïque à cacher des informations importantes à l'équipe.
Cela peut se manifester de plusieurs façons. Un service informatique n'a peut-être qu'un seul ingénieur réseau et tous les diagrammes de réseau et les feuilles de calcul sont sur son disque personnel. Peut-être qu'un service informatique compte quelques ingénieurs réseau, mais ils ne partagent aucune information avec l'équipe des applications. Peut-être que les managers gardent délibérément des informations pour eux-mêmes afin de s'assurer qu'ils sont toujours le héros.
D'après mon expérience, les services informatiques traitent ce problème de différentes manières (voire pas du tout). Pour certains, la réponse réside dans les flux de travail formels. Pour d'autres, la réponse est la culture. En fin de compte, en ce qui concerne les connaissances tribales et le héros du réseau, la réponse n'est pas de s'assurer qu'une seule personne sait Moins, mais que le reste de l'équipe sait plus.
En ce qui concerne les connaissances tribales et le héros du réseau, la réponse n'est pas de s'assurer qu'une seule personne sait Moins, mais que le reste de l'équipe sait plus.
Mais comment y arriver ?
L'objectif n'est pas nécessairement d'embaucher toute une équipe de CCIE, même si ce serait plutôt cool. Il s'agit de donner aux ingénieurs les connaissances et les outils dont ils ont besoin pour traiter les incidents et travailler à travers les silos de connaissances. La réponse est de faire tomber les barrières et de rendre l'information facilement accessible.
Si vous avez lu Le projet Phénix, de Gene Kim, Kevin Behr et George Spafford, vous connaissez bien Brent, le goulot d'étranglement technique du service informatique de Parts Unlimited. Dans l'histoire, Brent ne fait rien de mal en soi, mais il est le seul détenteur de certaines connaissances techniques et un point de défaillance majeur pour toute l'équipe. Brent est intelligent, désireux de travailler et trouve rapidement des solutions, mais ses connaissances inestimables sont dans sa seule tête - laissant les membres de l'équipe tirer dans le noir lorsque Brent n'est pas là.
Au fil du temps, la solution présentée pour résoudre le problème des connaissances tribales chez Parts Unlimited est de développer une culture de collaboration et de partage des connaissances, même si cela fait mal. Les auteurs présentent une solution qui ne consiste pas à se débarrasser de Brent ou à le démolir, mais à permettre à toute l'équipe de se hisser à son niveau.
Dans le roman, on nous présente un service informatique fictif avec des scénarios et des attitudes idéalistes, alors comment un réal Le service informatique gère-t-il son propre Brent ?
Cela se résume à la collaboration et au partage des connaissances, mais la clé est que cela doit être simple, cohérent et faire partie du flux de travail d'une équipe. Combien de fois avez-vous commencé à utiliser un outil d'organisation tel que Trello, Asana ou même des Post-it, pour ensuite abandonner parce qu'ils ne vous aidaient pas ? Le problème n'est pas avec ces outils - c'est avec la discipline pour les utiliser.
NetBrain aborde directement cette question de partage des connaissances et de collaboration, tant au niveau des incidents qu'au niveau des infrastructures. Mais ce qui le rassemble vraiment, c'est comment NetBrain peut s'intégrer entièrement à un service informatique existant systèmes afin de rendre le partage des connaissances facile, cohérent et intégré au flux de travail quotidien.
Tout d'abord, NetBrain offre une intégration API riche, permettant à tout système tiers tel qu'un système de billetterie, un outil de surveillance ou un appareil IDS de se déclencher NetBrain pour passer à l'action. NetBrain peut s'intégrer dans une base de données existante, rendant la CMDB d'un service informatique toujours cohérente et à jour. NetBrain devient facilement partie intégrante du flux de travail d'un service informatique.
En second lieu, Dynamic Maps permettent au réseau de se documenter. Dynamic MapLes s sont des diagrammes de réseau à la demande que vous pouvez publier sous forme d'URL pour que toute l'équipe puisse les utiliser. Cela fournit à toute une équipe des informations détaillées et spécifiques sur le réseau qui sont trop souvent détenues par un ou très peu d'ingénieurs.
Troisièmement, Exécutable Runbooks permettre aux équipes de digitaliser leurs bonnes pratiques. Runbooks peut être utilisé pour automatiser les étapes de dépannage du réseau et intégrer les données dans le Runbook flux de travail. Celle-ci est ensuite jointe au Dynamic Maps, ce qui facilite le partage des résultats et le suivi des résultats dans le contexte d'un incident.
Imaginez avoir toute une équipe de héros du réseau.
Toutes les informations sur le réseau existent déjà à l'intérieur des appareils, donc une solution programmable qui peut rassembler ces informations et les présenter à l'équipe permet à n'importe quel ingénieur d'effectuer et d'annuler des modifications. Au lieu d'un ingénieur sur appel qui a du mal à entendre l'ingénieur principal lui parler sur un téléphone satellite depuis une plage des Fidji, n'importe quel membre de l'équipe est habilité à travailler sur le problème - éliminant ainsi les connaissances tribales et donnant à toute l'équipe une chance d'être un héros du réseau.