Oubliez le temps de disponibilité. Un MTTR faible est le nouveau « 5 9 » de l'informatique
Les pannes coûtent cher. Qu’ils soient finalement le résultat d’une attaque ou d’une défaillance logicielle ou matérielle n’a pas d’importance. Les coûts par minute d’arrêt augmentent, en raison de la dépendance croissante aux API et aux applications Web de l’économie numérique moderne.
Pour certains, ces coûts sont faramineux. On estime que les 40 minutes d'indisponibilité d'Amazon en 2013 leur ont coûté 2,64 millions de dollars. Cela représente 1 100 $ par seconde pour ceux qui ne sont pas enclins à faire le calcul. Si vous pensez que c'est horrible, pensez à Google, dont une interruption de service de 5 minutes au cours de la même année leur a coûté 109 000 $ par minute. (ou 1 816,67 $ par seconde) pour un total énorme de 545 000 $. Pendant 5 minutes. Techniquement, si c'est tout ce qu'ils ont souffert, c'est le fameux « 5 9 » que l'informatique est chargée d'accomplir.
À quelle fréquence les pannes se produisent-elles ? Trop souvent, apparemment. Si vous n'avez jamais vu celui-ci, jetez un œil à la carte des pannes en direct de Pingdom . Il a été construit à partir de données recueillies auprès de plus de 700 000 utilisateurs dans le monde. Cette carte morbidement fascinante montre les pannes survenues au cours de la dernière heure à travers le monde. Les flashs lumineux représentant les pannes sont une touche agréable ; ils mettent vraiment en valeur l'impact qu'ils font auprès des utilisateurs.
C'est à dire un indésirable.
L’économie numérique aggrave ce problème. Plus tôt cette année, une panne S3 chez Amazon a mis hors service de nombreuses applications et sites Web de clients. Mais pour ne pas imputer ce problème aux fournisseurs de cloud public, une visite rapide sur le site builtwith.com effacera rapidement cette croyance. Le pourcentage de sites tirant parti des CDN et des API est peut-être alarmant si l'on considère la dépendance que cela entraîne vis-à-vis du temps de disponibilité de quelqu'un d'autre . Il est difficile de trouver un site qui ne s'appuie pas sur au moins une API ou un service externe, ce qui augmente le risque de temps d'arrêt, car si ce service externe est en panne, vous l'êtes aussi.
Fondamentalement, l’informatique a opté pour « 5 9 » car il est impossible d’atteindre une disponibilité de 100 %. Aujourd’hui, alors que les coûts par seconde montent en flèche en raison du passage de l’économie au monde numérique, la clé est de minimiser les temps d’arrêt. En d’autres termes, définir des objectifs qui nécessitent un temps moyen de résolution (MTTR) faible est tout aussi important, voire plus, que d’essayer d’éliminer les temps d’arrêt.
L'une des mesures clés des « organisations hautement performantes » dans le rapport 2016 State of DevOps de Puppet Labs est le MTTR, défini comme le temps nécessaire pour restaurer le service lorsqu'un incident de service se produit (par exemple, une panne imprévue ou une dégradation du service). Les organisations les plus performantes (selon l'évaluation du rapport) prennent moins d'une heure tandis que les organisations moyennes et peu performantes prennent « moins d'une journée ». « En d’autres termes », note le rapport, « les plus performants ont eu un MTTR 24 fois plus rapide que les moins performants. »
Vous remarquerez que la question n’était pas « si » il y a un incident de service. C'était « quand » il y a un incident de service. L’hypothèse est qu’un incident se produira et la clé est donc de minimiser le temps de résolution. Une enquête menée en 2016 par IHS a révélé que « en moyenne, les personnes interrogées subissent 5 temps d'arrêt par mois et 27 heures d'arrêt par mois » coûtent en moyenne 1 $ aux organisations de taille moyenne et jusqu'à 60 millions de dollars à leurs homologues plus grandes.
Si nous partons du principe que la loi de Murphy préside toujours à Moore et Conway, la réponse est d’essayer de minimiser le MTTR afin de réduire le temps (et les coûts) associés aux inévitables temps d’arrêt.
Cela signifie que la visibilité est essentielle, ce qui implique une surveillance. Beaucoup, beaucoup de surveillance. Mais pas seulement le site Web, l’application Web ou l’API : nous devons surveiller l’ensemble de la pile . Du réseau aux services applicatifs jusqu'à l'application elle-même. Ce n’est pas quelque chose que tout le monde fait, et quand ils le font, ils semblent le faire de manière incohérente.
Considérez l’ enquête xMatters|Atlassian DevOps Maturity 2017 dans laquelle 50 % des répondants ont déclaré qu’ils « attendent que les opérations déclarent un incident majeur » avant de répondre. Un tiers des entreprises, ce qui est inquiétant, « sont informées des interruptions de service par leurs clients ».
Dans une économie numérique, chaque seconde compte. Non seulement parce que cela coûte de l’argent, mais aussi parce que cela a un impact négatif sur les revenus futurs . La diminution de la valeur de la marque et de la confiance des clients se traduit par une diminution des achats, du nombre d’utilisateurs et, à terme, par une stagnation de la croissance. Ce n’est pas la direction que les organisations devraient prendre.
La surveillance est la première étape pour détecter les problèmes qui provoquent des pannes. Mais la surveillance seule ne suffit pas à améliorer le MTTR. La communication le fait. Alerter les parties prenantes concernées dès que possible et leur fournir les informations dont elles ont besoin pour résoudre le problème contribuera à accélérer le délai de résolution. Cela signifie que le partage , l’un des quatre piliers clés de DevOps, est essentiel pour améliorer le MTTR. Même si vous n'adoptez pas encore d'autres aspects de DevOps au niveau de l'entreprise, le partage est une initiative que vous devriez envisager d'élever au niveau supérieur. Que ce soit via ChatOps ou par courrier électronique, une application mobile ou une page wiki mise à jour dynamiquement, il est impératif que les informations recueillies grâce à la surveillance soient largement partagées dans toute l'organisation.
Un problème au niveau d'un commutateur ou d'un serveur peut sembler anodin, mais s'il n'est pas résolu, il peut finir par mettre hors service la moitié des services dont dépend une application critique. Dans l' étude State of the Network 2017 menée par Viavi , 65 % des administrateurs réseau et systèmes citent « déterminer si le problème est causé par le réseau, le système ou les applications » comme leur principal défi lors du dépannage des problèmes d'application. Une meilleure visibilité et une surveillance complète de la pile constituent un moyen de relever ce défi, en garantissant que les personnes chargées de trouver la cause première disposent d'autant d'informations que possible sur l'état et la santé de tous les composants du chemin de données .
La visibilité est la clé de l’avenir de l’informatique. Sans cela, nous ne pouvons pas atteindre le niveau d’automatisation nécessaire pour remédier aux pannes avant qu’elles ne surviennent. Sans visibilité, nous ne pouvons pas réduire le MTTR de manière significative. Sans cela, nous ne pouvons vraiment pas maintenir la croissance de l’entreprise à un rythme durable.
La visibilité, comme la sécurité, doit être un élément de première classe dans la stratégie qui fait avancer l'informatique. Parce que des pannes surviennent et que c’est la visibilité qui permet aux organisations de récupérer rapidement et efficacement, en causant le moins de dommages possible à leur marque et à leurs résultats.