MTTR n'est pas le « temps moyen de redémarrage »
« Échouer vite » est le mantra de la vitesse aujourd’hui. Qu'il s'agisse de DevOps ou d'entreprise, le principe de fonctionnement dans une économie numérique exige une disponibilité aussi proche que possible de la perfection.
Bien que la théorie de cette philosophie soit bonne, dans la pratique, le résultat n’est souvent qu’un échec supplémentaire. En ne nous concentrant pas sur la recherche de la cause première (MTTR) et en nous concentrant uniquement sur la garantie de la disponibilité (uptime), nous perdons des données précieuses à un rythme sans précédent. Admettez-le : lorsque la disponibilité est votre seule préoccupation, le MTTR devient le temps moyen de redémarrage au lieu du temps moyen de résolution . Et sans une résolution - une raison pour le temps d'arrêt - vous ne pouvez pas empêcher que cela se reproduise.
Cette approche est préjudiciable à l’entreprise.
Vous voyez, vous ne laissez pas tomber des paquets, vous laissez tomber des morceaux de pièces de monnaie. Et comme nous l’enseigne le cliché criminel classique consistant à détourner des fractions de centimes des transactions pour accumuler des millions, chaque fraction de centime compte. Chaque seconde pendant laquelle un composant, un service, un serveur ne répond pas, vous perdez de la valeur, à la fois expérientielle et existentielle. Les consommateurs ne toléreront pas de mauvaises performances ni de temps d'arrêt, et les registres commerciaux ne peuvent tolérer ni l'un ni l'autre.
Et si vous connaissez un peu le débit et la bande passante, vous savez que la base des deux calculs réside dans les paquets par seconde qui peuvent être traités par le système sous-jacent. Cela n’est pas seulement vrai dans le réseau, mais pour chaque composant qui interagit avec une transaction. L'application. Les services de application . Routeurs. Interrupteurs. Bases de données. S'il dispose d'une connexion réseau, il est lié à ce même calcul et contraint par sa capacité à transmettre des paquets.
AVERTISSEMENT: LES MATHS EN AVANT
La vitesse des réseaux actuels garantit que nous faisons exactement cela à un rythme de millions de paquets par seconde. Les transactions commerciales sont bien entendu principalement effectuées via un réseau (littéral) de transactions HTTP, chacune transmettant des informations cruciales pour la conduite des affaires. Le nombre de paquets requis pour effectuer une transaction dépend de la quantité de données requises. Le paquet moyen transporte 1 500 octets de données (c'est le MTU). Ainsi, si un message HTTP transportant une charge utile JSON représentant une transaction nécessite 4 500 octets (après cryptage, bien sûr), cela représente environ trois paquets. Alors soyons généreux et disons qu’une transaction commerciale numérique typique nécessite cinq paquets. Un réseau de 10 Gbit/s peut traiter un peu moins de 15 millions de paquets par seconde. En supposant que suffisamment de capacité de calcul soit disponible, on pourrait alors dire que cela équivaut à 3 millions de transactions. Supposons que chaque transaction vaut une fraction (un tiers) d’un centime. Cela représente 1 million de dollars par seconde.
Aujourd’hui, personne ne traite réellement les transactions à cette vitesse ou à ce volume. Même Visa, qui traite incontestablement les données à des vitesses dont la plupart des entreprises n'ont pas besoin, affirme que sa capacité est d'environ 24 000 transactions par seconde. En supposant que la valeur de ces transactions soit la même - un tiers de centime - cela représente toujours 8 000 $ par seconde.
Le fait est qu’une défaillance dans la chaîne de transaction composée de routeurs, de commutateurs, d’infrastructures de services réseau et application , d’infrastructures d’applications et de composants est une très mauvaise chose™. C'est coûteux, car une défaillance signifie que les paquets ne sont pas traités, et les centimes qu'ils représentent non plus. Et il n’y a aucun secteur de l’économie numérique qui ne dépende de la transmission de paquets.
La réponse jusqu'à présent réside dans le mantra « échouer rapidement » : il suffit de lancer une nouvelle instance de X ou Y ou Z ou de tout autre composant ayant échoué. Mais ce composant a échoué *pour une raison* et il est de la plus haute importance que la raison soit découverte et traitée. Rapidement. Parce qu’il y a encore des secondes coûteuses entre la panne et la restauration qui coûtent de la valeur commerciale. Si cela a échoué une fois, il est probable que cela échouera à nouveau. Et encore.
VISIBILITÉ: LA CLÉ DE VUE SUR LAQUELLE REPOSE MTTR
C’est pourquoi la visibilité est si essentielle à la réussite dans l’économie numérique. Car c’est la visibilité qui permet à toutes les opérations de trouver et de remédier à la cause de la défaillance. Malheureusement, c’est souvent la visibilité qui est sacrifiée au profit de la vitesse. Pas la vitesse littérale des transactions, mais le temps de valorisation. Dans notre hâte de commercialiser nos applications plus rapidement et plus fréquemment, nous n’avons pas suffisamment investi pour offrir la visibilité nécessaire pour atténuer les échecs.
En fait, on pourrait soutenir que la philosophie « fail fast » de DevOps est une réponse à cet échec. Sans la capacité de trouver et de résoudre la cause de l'échec, DevOps a déterminé qu'il était préférable de restaurer la disponibilité plutôt que de perdre du temps. Cette capacité devient de plus en plus difficile à mesure que les organisations adoptent des approches multi-cloud pour déployer des applications.
En 2018, le défi multi-cloud de la visibilité était cité par moins d'un tiers (31 %). En 2019 , ce chiffre est passé à plus d'un tiers (39 %), à égalité avec les performances et la sécurité comme principaux défis du multi-cloud. La visibilité est un élément essentiel de l'« observabilité » globale qui rassemble la surveillance, l'analyse et l'alerte pour fournir des informations précieuses sur l'état d'un système à tout moment. C'est particulièrement important en cas de panne, car l'état du système est réparti sur plusieurs fiefs informatiques qui peuvent ou non permettre le partage d'informations pouvant conduire rapidement à une résolution au lieu d'un simple redémarrage .
La capacité d’un service mesh à ajouter de la valeur grâce au traçage distribué est un excellent exemple de visibilité. Mais nous devons étendre cela pour inclure l’ensemble de la chaîne de services application qui font évoluer et sécurisent les applications exécutées dans un monde conteneurisé. Et cela inclut les composants distribués et les applications exécutées dans le cloud public qui peuvent faire partie de la chaîne d’exécution. Une visibilité sur les environnements, les infrastructures et les applications est nécessaire pour détecter et résoudre les problèmes qui entraînent des temps d'arrêt ou de mauvaises performances.
La visibilité est impérative pour permettre aux organisations de revenir à la mesure du succès sur la résolution MTT plutôt que sur le redémarrage MTT.