Les 10 erreurs que les ingénieurs réseau font lors du dépannage | enterprise.netscout.com

Les 10 erreurs que les ingénieurs réseau font lors du dépannage

Il est facile d’effectuer ces erreurs lors du dépannage des problèmes de réseau et d’applications.
Ce livre blanc décrit 10 de celles-ci et comment les éviter.

  • TABLE DES MATIÈRES
  • Faire des hypothèses
  • Redémarrage du système
  • Mise à niveau du système
  • Validation
  • Aucune configuration de base
  • Défis du sans-fil
  • Suivi réseau déficient
  • Comprendre les technologies de base
  • Limites des ordinateurs portables
  • Conclusion
 

Temps de fonctionnement de 100 % ? Validé.

10 Gbit/s vers l’ordinateur de bureau ? C’est en cours.

Des applications et un réseau sans problème ? Eh bien non ! Cela ne se produit que dans nos rêves les plus fous.

Tant que nous n’atteignons pas la perfection du réseau (qui, en toute honnêteté, peut ne jamais se produire) les ingénieurs devront faire face à des problèmes au sein des systèmes réseau et applications qu’ils prennent en charge. Que le problème soit des ralentissements des performances, une mauvaise qualité audio/vidéo, des pertes de connexions ou autres événements qui tourmentent les réseaux d’aujourd’hui, les ingénieurs ont besoin de perfectionner continuellement leurs compétences en dépannage pour rester au fait de ces problèmes venant réduire l’efficacité opérationnelle. En outre, ils doivent éviter les pièges communs dans lesquels un trop grand nombre d’ingénieurs réseau tombent lors du dépannage des problèmes.

Prenons quelques exemples...

1. Faire des hypothèses sur la cause première d’un problème

Avouons-le : nous, les humains faisons des hypothèses fondées sur ce que nous croyons savoir. Quand un problème survient, nous ne pouvons pas nous empêcher de tirer des conclusions trop hâtives, surtout si nous avons le temps et l’expérience nécessaires au sein d’un environnement réseau particulier. Cependant, faire des hypothèses peut être une énorme erreur. Elles peuvent conduire à des modifications du réseau absurdes, des mises à niveau coûteuses et « améliorations » sans fondement - en se croisant les doigts et en espérant que le problème va disparaître. Cette erreur de dépannage doit être évitée à tout prix. Au lieu de cela, avant de prendre ces décisions instinctives, venez recueillir des faits concernant le problème. Il faut comprendre le qui, pourquoi, où, quoi et comment du problème avant de changer quoi que ce soit. Laissez-vous guider par les faits pour chaque décision que vous prenez.

 

2. Un dépannage de type « Ce correctif a fonctionné par le passé, nous allons essayer à nouveau »

Similaire à l’erreur numéro un, cette réponse commune aux problèmes de réseau repose aussi sur des hypothèses. Nous sommes tous victimes de notre propre expérience, il est donc facile de s’appuyer sur notre connaissance de ce qui a fonctionné la dernière fois, pensant que le même chose fonctionnera à nouveau. Dans de nombreux cas, un nouveau problème va montrer les mêmes symptômes qu’un problème précédent, mais la cause première peut être tout à fait différente.

Avant de modifier quoi que ce soit, assurez-vous d’isoler le domaine qui pose problème pour le réseau, serveur, application ou client. Identifiez clairement quel composant est responsable avant d’essayer l’approche conjecture et modification. Utilisez des outils qui se servent du protocole SNMP, NetFlow et de la capture des paquets, afin de clairement cerner le problème à une couche avant de procéder à la mise en place de la résolution.

3. Redémarrer pour essayer de faire disparaitre le problème

De routeurs aux commutateurs 10G, presque tous les appareils électroniques doivent être redémarrés à un moment ou un autre. C’est tout simplement comment fonctionnent les choses aujourd’hui. Toutefois, dans certains environnements informatiques, la réinitialisation d’un appareil est devenue la norme pour la première étape de dépannage. Cela est particulièrement vrai si un redémarrage de l’appareil ou du serveur a fonctionné dans le passé.

Si le redémarrage d’un périphérique résout un problème, le correctif ne peut être que temporaire, ce qui va entraîner un redémarrage dans un proche avenir. Bien sûr, un redémarrage peut s’avérer être nécessaire après une modification suite à une mise à jour, correctif ou configuration de logiciel. Cependant utiliser ce processus en tant que première intervention pour un problème réseau, redémarrer plusieurs fois un périphérique va seulement venir masquer la cause réelle. Avant le redémarrage d’un périphérique, venez recueillir autant d’informations que possible. Par exemple, est-ce que le point d’accès répond toujours aux utilisateurs actuels ? Le serveur accepte-t-il de nouvelles connexions TCP ? Est-ce que le CPU du commutateur est à 100 % d’utilisation ? Ces informations peuvent diriger des ingénieurs vers la cause réelle, plutôt que vers une solution provisoire.

 

4. Mettre à niveau le matériel pour essayer de faire disparaitre le problème

Une mise à niveau de 1 Gbit/s à 10 Gbit/s devrait augmenter les performances par un facteur de 10, pas vrai ?

Faux.

C’est rarement le cas. Trop souvent, face à des problèmes réseau - en particulier ceux impliquant le ralentissement des performances - les ingénieurs réseau sont tentés d’augmenter la bande passante WAN, d’effectuer des mises à niveau des commutateurs ou routeurs ou de mettre en œuvre des technologies d’accélération. Ce n’est pas un secret ; aucun de ces « correctifs » n’est gratuit. En fait, la mise à niveau en guise de première réponse à un problème peut réduire le budget à zéro, venir frustrer les gestionnaires, réduire la productivité des entreprises et au pire, coûter la place d’un ingénieur réseau (aïe !).

Avant la mise en œuvre d’une nouvelle technologie ou la mise à niveau d’une connexion de périphérique/système, il y a plusieurs questions qui doivent être posées et il est important d’y répondre : Pourquoi sommes-nous convaincus que cette amélioration des appareils/technologies pourra résoudre le problème ? Quel EST le problème original ? Le problème est-il vraiment causé par une déficience au niveau des capacités du réseau ou de la latence ?

S’il est agréable de disposer de nouveaux appareils sur le réseau, il n’est pas agréable de voir l’expression sur le visage du gestionnaire lorsqu’une solution onéreuse ne parvient pas à régler le problème. La mise à niveau de systèmes clés est justifiée parfois, mais soyez prudent lorsque vous effectuez la mise à niveau d’un périphérique en guise d’étape de dépannage.


 

5. Fournir de nouvelles connexions aux utilisateurs sans les valider

Nous l’avons tous fait des milliers de fois. Déballer et venir configurer un nouveau commutateur, l’installer, le raccorder dans la liaison montante, connectez la jonction de l’utilisateur final et regardez le voyant qui clignote.

Problème résolu, n’est-ce pas ?

Non. Il y a plusieurs choses qui peuvent affecter les performances dont les utilisateurs finaux bénéficient lorsqu’ils se connectent et se mettent au travail. La négociation de la liaison, des problèmes de câble, problèmes d’interface matérielle et autres facteurs venant réduire les débits peuvent influer sur la connexion.

Avant de présenter officiellement une liaison à un utilisateur final, elle doit être testée et validée. Cela inclut de mesurer la latence et le débit pour chaque connexion vers le centre de données de base. Comme nous l’avons mentionné, la plupart des ingénieurs vont connecter une liaison, rechercher un voyant de liaison, envoyer un ping et examiner le lien testé. Cependant, tous les problèmes décrits plus haut réussiraient ce test. Seulement un test des performances complet viendra valider la connexion et révéler ces problèmes avant que les utilisateurs ne viennent en faire l’expérience.

 

6. Ne pas venir créer une base de référence pendant l’exécution normale du réseau

Lors du dépannage d’un problème, les ingénieurs utilisent souvent des outils de surveillance pour les aider à recueillir et interpréter des informations sur le réseau. Même si ces outils peuvent afficher une quantité impressionnante de données statistiques, il est facile de se perdre dans les détails, si un référentiel « normal » n’existe pas.

Avant qu’un problème ne survienne, il faut établir la configuration de base de référence du réseau. Cela comprend la collecte du niveau d’utilisation du trafic et des statistiques de latence sur les liaisons réseau clés, des mesures de temps de réponse sur les applications métiers critiques, des échantillons de capture de paquets y compris les conversations typiques et protocoles et une évaluation complète du réseau sans fil. Ces rapports aideront les ingénieurs réseau lorsqu’un problème se pose car ils sauront ce que l’état « normal » du réseau est.


 

7. Manque d’expérience et absence d’outils sans fil

Le sans-fil peut être source d’ennuis, d’autant plus si de plus en plus d’utilisateurs finaux viennent s’affranchir des câbles et passent au 100 % Wi-Fi. Cette tendance, ainsi que l’augmentation des applications voix et vidéo que ces appareils entraînent, a augmenté considérablement la portée et la complexité des environnements sans fil. Même si ces systèmes sont mis en place et maintenus par des experts chevronnés de la RF, les clients peuvent toujours rencontrer de mauvaises performances, déconnexions du réseau et autres problèmes frustrants.

L’environnement sans fil étant facilement vulnérable à des problèmes de performances, il est souvent le premier à être blâmé quand un nouvel événement survient. Beaucoup d’ingénieurs réseau pointent du doigt le Wi-Fi tout simplement parce que c’est une zone du réseau qu’ils ne comprennent pas pleinement ou ne disposent pas des outils pour l’analyser. Plutôt que d’avoir un angle mort gigantesque au sein du réseau, les gestionnaires réseau devraient investir dans des outils et une formation pour mettre au fait les ingénieurs des avancées du sans-fil, venir les équiper pour répondre aux problèmes dans ce domaine.

 

8. Suivi réseau déficient

Problèmes auxquels les ingénieurs sont confrontés aujourd’hui sont complexes, intermittents et parviennent à se cacher dans l’ombre du système. Par le passé, un outil de ping montant/descendant était tout ce qu’il fallait pour surveiller le réseau. Cela a radicalement changé.

Résoudre les problèmes d’aujourd’hui nécessite des systèmes de surveillance qui sont aussi bien centrés sur le réseau que les applications, l’utilisation du protocole SNMP, NetFlow et la capture des paquets afin de ne laisser aucun angle mort en matière de visibilité. Ces systèmes ont besoin d’applications de surveillance 24/7/365 pour s’assurer que des problèmes intermittents sont détectés au bon moment, plutôt que de manquer l’événement lorsque les systèmes de surveillance vérifient un autre emplacement du réseau.

 

9. Incompréhension de l’exploitation de technologies de base

Qu’est-ce les protocoles spanning-tree, ARP, auto-négociation, ICMP de redirection et la fragmentation d’IP ont en commun ?

Ils sont tous désuets (plus de 20 ans pour chacun) et absolument essentiels pour le fonctionnement du réseau. Eh bien, peut-être pas la fragmentation IP dans tous les cas, mais cela valait la peine d’être mentionné. Les ingénieurs réseau doivent s’assurer qu’ils comprennent que leurs systèmes de pointe s’appuient sur les technologies de base. Quand vous préparez ce prochain examen de certification de prestataire, ne laissez pas de côté les protocoles et technologies qui jouent encore un rôle dans le bon fonctionnement des processus cette année et à l’avenir.


 

10. Utilisation d’ordinateurs portables pour capturer les paquets

L’interprétation de la capture de paquet et du fichier trace est l’étalon-or en matière d’analyse détaillée des détails lors d’enquêtes sur un problème. Cette méthode d’analyse est essentielle pour trouver la cause racine du problème, plutôt que simplement exonérer le réseau et rejeter la faute sur les parois.

Quand il s’agit de la collection de paquets, une erreur commune faite par les ingénieurs de réseau aujourd’hui est de mal comprendre les limites du matériel qu’ils utilisent pour la capture. Prenez par exemple Wireshark. Cet outil open source est connu et apprécié des ingénieurs du monde entier et est l’outil de réseautage disponible le plus téléchargé. Cependant, la plupart des gens utilisent cet outil sur des ordinateurs portables ou sur du matériel non testé qui ne peuvent pas faire face à des flux de trafic haut débit. En fait, la plupart des ordinateurs portables peinent à capturer en toute transparence à des débits supérieurs à 100 Mbit/s !

Il faut connaître les limites du matériel utilisé pour collecter les paquets avant la capture dans l’environnement de centre de données. Ne pas détecter des paquets provenant de fichiers trace peut facilement égarer un ingénieur, augmentant le temps de résolution d’un problème lancinant.

 

Conclusion

Ce n’est pas une liste exhaustive - il y a autres écueils sur lesquels tombent les ingénieurs de tous niveaux d’expérience de temps à autre. Avec un peu de préparation et de sensibilisation sur certaines erreurs communes, les ingénieurs peuvent réduire le temps de résolution, les frustrations, les coûts ou dépenses inutiles et éviter bien des tracas lors le dépannage des problèmes de réseau.

 
 
Powered By OneLink