Automatisation du réseau : 4 bonnes pratiques pour ne pas tout casser

1/ Standardisez les équipements

Le risque de pannes est en vérité surtout lié aux architectures disparates – appelées des « snowflakes » – où une partie du réseau repose sur des équipements différents. L’absence de standard démultiplie l’éventualité d’une erreur humaine à chaque fois qu’une configuration est modifiée quelque part. Normaliser les équipements est une première bonne pratique à adopter pour que le réseau traite un minimum – voire pas – de cas particuliers.

L’utilisation de composants normalisés peut coûter un peu plus cher en matériel, mais cela réduit les coûts d’exploitation et le risque de pannes, car on utilise dès lors des procédures standard pour comprendre les défaillances, les atténuer avec des procédures génériques et les réparer. Surtout, l’utilisation d’équipements normalisés est le socle essentiel de l’automatisation, laquelle va servir à industrialiser la configuration initiale des appareils et leurs mises à jour, à valider leur connectivité et à les dépanner.

2/ Commencez par automatiser les relevés

La meilleure façon d’adopter l’automatisation est de commencer par des tâches simples. Élaborez des scripts qui effectuent une analyse basique, en lecture seule, comme par exemple la recherche d’une adresse pour accéder à un serveur, le test de la connectivité entre deux serveurs, ou encore la comparaison entre une configuration type et celle d’un équipement. Il s’agit d’automatiser ces tâches de diagnostic que vous effectuez souvent et qui sont si chronophages.

Ne cherchez pas à lancer des scripts de reconfiguration automatique tant que vous ne vous êtes pas pleinement familiarisé avec les moyens d’automatisation à votre disposition.

3/ Testez sur des instances virtuelles

L’automatisation du réseau doit reposer sur les mêmes bonnes pratiques que celles utilisées dans le développement d’applications, en l’occurrence il faut mener des tests approfondis. Historiquement, les tests réseau posaient problème, car il était trop coûteux et trop long de mettre en place une ferme d’équipements témoins, que l’on pouvait malmener sans impacter la production.

Ce n’est plus le cas aujourd’hui, car tous les fournisseurs proposent à présent des instances virtuelles de la plupart de leurs équipements, souvent à un prix modique ou gratuitement, avec toutefois des performances limitées. Ces instances sont votre solution pour valider en amont n’importe quel changement de configuration.

L’équipe réseau aura sans doute besoin de travailler avec le reste du service informatique pour déployer un environnement virtuel de test qui reflète le mieux possible le réseau en place. Idéalement, l’environnement de test comprendra des serveurs et des clients virtuels pour générer du trafic.

4/ Validez avec des scripts pré- et post-configuration

Pour vérifier que votre réseau est connecté et fonctionne comme prévu dans vos configurations de tests, il faut tenir compte de l’état du réseau. C’est-à-dire lire l’état des interfaces sur chaque équipement, l’attribution des adresses, le voisinage des équipements et les informations concernant les protocoles des couches 2 et 3. Dans cette phase, vous n’apportez toujours aucune modification au réseau. Le script de validation doit simplement créer une alerte lorsqu’une vérification échoue, ce qui permet aux équipes de prendre ensuite les mesures appropriées.

Ces scripts de validation serviront à l’avenir lors d’un remplacement des équipements par des modèles plus récents, pour effectuer des contrôles de validation avant et après le changement. Si un contrôle de validation avant modification échoue, il faut alors annuler le remplacement de l’appareil tant que le problème n’a pas été résolu. De même, si un contrôle de post-validation échoue, alertez le personnel en charge de la connexion qu’une erreur humaine s’est sans doute glissée dans leur intervention. Veillez à répéter ces validations jusqu’à ce que le réseau soit revenu à l’état prévu.