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...
Éd. remarque : La transcription suivante a été tirée de l'enregistrement à la demande — aucune inscription nécessaire ni formulaire à remplir — de NetBrain's Automatisation juste à temps pour les opérations informatiques séminaire en ligne. Jason Baudreau, NetBrain VP du marketing, est votre hôte.
Parlons de la façon dont l'automatisation peut aider les équipes réseau à collaborer à la réponse aux incidents.
Lorsqu'un dépannage ou une escalade est nécessaire, il y a beaucoup d'inefficacités et un manque d'outils axés sur la collaboration. Les ingénieurs redoublent souvent d'efforts parce qu'ils ne sont tout simplement pas sur la même longueur d'onde ou qu'ils ne sont pas conscients de ce que fait l'autre membre de l'équipe. Et l'autre chose que nous voyons est le doigt pointé entre les équipes. Ce n'est pas rare du tout — qu'il s'agisse de l'équipe d'application et de l'équipe réseau, du équipe de sécurité, l'équipe du serveur — il y a toujours beaucoup de pointage du doigt sur qui est le problème.
Si vous regardez le temps moyen de réparation (MTTR), c'est vraiment le résultat de deux choses : ce que nous appelons MTTI, qui est, je pense, l'essentiel du défi, la réparation prenant moins de temps. Quand je dis MTTI, je fais en fait référence à deux choses :
- Le temps moyen pour identifier un problème. Dans le contexte de la collaboration, je vais parler de cela en termes d'escalade et de transfert.
- Mais aussi MTTI peut être un temps moyen pour inoncence. Nous savons que le réseau est coupable jusqu'à preuve du contraire. Malheureusement, ce défi incombe à l'équipe du réseau de prouver cette innocence aux autres équipes - les équipes d'application, les équipes de serveur, par exemple. Et ce n'est pas toujours facile.
Quand je parle aux ingénieurs, c'est un défi familier. . . .Les autres équipes supposent-elles que chaque problème de lenteur de l'application est vraiment un problème de réseau? Quel pourcentage du temps est-ce vraiment le réseau ?
Voyons comment l'automatisation peut relever ces deux défis. La réponse que nous avons trouvée est de documenter automatiquement les activités des utilisateurs à l'intérieur d'un runbookL’ runbook est intégré dans le Localisation URL afin que chacun puisse voir ce que font ses collègues pendant qu'ils dépanner à leurs côtés. Ceci est peut-être utilisé pour l'escalade, afin que l'ingénieur de niveau 2 puisse voir ce qui a déjà été effectué par le niveau 1. Fondamentalement, une carte du réseau peut aider tout le monde à comprendre qui a fait quoi, quand et quel a été le résultat. Encore une fois, mettez tout le monde sur la même longueur d'onde.
Découvrez à quoi ressemble la collaboration lorsque les workflows sont automatiquement documentés et partagés au sein de l'équipe.
Remarque : la démonstration en direct de la façon dont Executable Runbooks faciliter et améliorer la collaboration commence à 2:24.
Autres "chapitres" du webinaire :
Créez des logiciels, pas des humains, le middleware (Aperçu)
Comment l'automatisation améliore un flux de travail NetOps typique (introduction)
Discussion et démonstration de l'automatisation du réseau déclenchée par un événement
Simplifier la complexité du réseau avec l'automatisation interactive (avec démo)
Effectuez des modifications plus sûres : validation automatisée des modifications (avec démo)
Ou regardez l'intégralité Automatisation juste à temps pour les opérations informatiques enregistrement à la demande du webinaire — pas d'inscription nécessaire ni de formulaire à remplir.