Ce n'est pas une nouvelle de dire que les humains ne sont pas parfaits. Pourtant, de nombreuses organisations s'appuient sur une attente irréaliste selon laquelle leurs équipes informatiques ne feront jamais d'erreur. Selon les recherches en cours de l'Uptime Institute, l'informatique prend du retard dans le maintien des systèmes et des services en cours d'exécution, avec davantage de pannes signalées, chacune d'une durée plus longue et d'un impact négatif plus important sur l'entreprise. Et la migration de vos services informatiques vers les fournisseurs de cloud n'est PAS la solution.
Votre Panne d'Amazon Web Services (AWS) en 2017 en est un parfait exemple. L'hystérie s'ensuit après toute panne majeure, et la pression exercée sur les équipes informatiques à ce moment-là peut être écrasante pour identifier et résoudre rapidement le problème. Pourtant, quelque chose d'aussi banal qu'une faute de frappe peut être la cause du problème. Une simple erreur humaine, et pourtant, elle a causé des ravages dans le classement Fortune 2000 à l'échelle mondiale.
Dans le cas d'Amazon, c'est exactement ce qui s'est passé lorsqu'un ingénieur a tenté de résoudre un problème avec son système de facturation :
"Un membre autorisé de l'équipe S3 utilisant un playbook établi a exécuté une commande destinée à supprimer un petit nombre de serveurs pour l'un des sous-systèmes S3 utilisé par le processus de facturation S3. Malheureusement, l'une des entrées de la commande a été saisie incorrectement et un plus grand nombre de serveurs a été supprimé que prévu. »
Comme la plupart des erreurs humaines, celle-ci aurait pu être évitée, et pas seulement avec une frappe un peu plus attentive. En fait, des modifications peuvent être apportées à des appareils individuels uniquement pour se rendre compte que les services informatiques qui traversent ces appareils ont été affectés involontairement. Dans le monde des réseaux, le problème peut être assez aigu. Traditionnellement, l'ingénierie réseau a nécessité beaucoup de travail manuel, de la collecte de données au dépannage manuel. Le travail manuel, en particulier le travail manuel fastidieux, conduit souvent à l'erreur humaine. Et il est rare que toutes les applications et tous les services impliqués dans les appareils modifiés soient soumis à un contrôle qualité de manière proactive pour s'assurer qu'ils sont pleinement opérationnels. Dans le cas d'AWS, un ingénieur travaillait sur un playbook établi et a fait une simple erreur de frappe, mais il se peut que la modification ait été effectuée correctement, mais elle a eu des conséquences inattendues sur les services informatiques. Cela arrive tout le temps.
At NetBrain, nous avons conçu l'ensemble de notre système d'automatisation de diagnostic de problèmes de réseau pour aider à minimiser le travail manuel fastidieux et incohérent en mettant en œuvre l'automatisation du réseau via Executable Runbooks. Et en tirant parti de notre modèle de réseau en temps réel et des résultats escomptés attendus, nous pouvons vérifier que le changement a été bon pour l'entreprise.
Au lieu de s'appuyer sur des efforts traditionnels de terrain où les connaissances se trouvent souvent sur un bout de papier ou sont isolées au sein d'une équipe d'experts, les ingénieurs réseau peuvent codifier leurs processus de meilleures pratiques éprouvés dans des exécutables qui peuvent être partagés avec des collègues, puis avec une intervention humaine minimale. La puissance de l'automatisation basée sur l'intention va au-delà de la réduction des erreurs. Elle accélère également le temps de dépannage tout en répartissant la charge de travail des tâches avancées sur plusieurs membres de l'équipe. Cela permet de réduire la dépendance excessive aux connaissances tribales et de renforcer la culture de collaboration au sein des équipes réseau, sécurité et gestion du changement. C'est un moyen de faire évoluer les connaissances et l'expérience dans n'importe quelle organisation.
Numériser les meilleures pratiques et automatiser leur exécution est la clé. Si AWS avait exploité quelque chose de similaire à Executable Runbooks, il est tout à fait possible que la panne ait pu être évitée. Dans notre monde, les équipes réseau peuvent facilement créer, exécuter et partager des exécutables Runbooks. Et avec eux, ils peuvent résoudre les problèmes, diagnostiquer la lenteur du réseau, se prémunir de manière proactive contre les erreurs de configuration, etc., le tout sans craindre que la dame aux gros doigts ne chante.
Apprendre En savoir plus sur Exécutable Runbooks et comment les ingénieurs réseau peuvent partager leurs connaissances, réduire le travail manuel et améliorer le réseau.