Le MTTR ne signifie pas « temps moyen de redémarrage »

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Échouer rapidement est aujourd’hui le mantra de la vitesse. Qu’il s’agisse du DevOps ou de l’entreprise, évoluer dans une économie numérique exige une disponibilité aussi proche que possible de la perfection.

Si cette philosophie est séduisante en théorie, elle se traduit souvent, dans la pratique, par davantage de défaillances. En ne cherchant pas la cause profonde (MTTR) et en nous contentant d’assurer la disponibilité, nous perdons des données précieuses à un rythme sans précédent. Soyons réalistes : lorsque seule la disponibilité compte, le MTTR ne signifie plus « temps moyen jusqu’à la remise en route », mais « temps moyen jusqu’à la résolution ». Or, sans résolution — sans connaître la cause de l’indisponibilité —, impossible d’empêcher que cela se reproduise.

Cette approche est préjudiciable à l’entreprise.

En réalité, vous ne perdez pas des paquets, mais des fractions de centime. Et comme nous l’enseigne le grand classique du criminel qui détourne des fractions de centime sur des transactions pour amasser des millions, chaque fraction de centime compte. À chaque seconde pendant laquelle un composant, un service ou un serveur ne répond pas, vous perdez de la valeur, tant sur le plan de l’expérience que sur celui de l’existence même de l’entreprise. Les consommateurs ne tolèrent ni les mauvaises performances ni les interruptions de service, et les comptes de l’entreprise non plus.

Et si vous connaissez un tant soit peu le débit et la bande passante, vous savez que ces deux mesures reposent sur le nombre de paquets par seconde que le système sous-jacent peut traiter. Cela vaut non seulement pour le réseau, mais aussi pour chaque composant intervenant dans une transaction : l’application, les services applicatifs, les routeurs, les commutateurs et les bases de données. Tout élément doté d’une connexion réseau est soumis au même calcul et limité par sa capacité à acheminer des paquets.

ATTENTION : CALCULS À VENIR

La vitesse des réseaux actuels nous permet précisément de le faire à un rythme de plusieurs millions de paquets par seconde. Les transactions commerciales, bien entendu, s’effectuent principalement par l’intermédiaire d’un réseau — au sens littéral — de transactions HTTP, chacune transmettant des informations essentielles à l’activité de l’entreprise. Le nombre de paquets nécessaires à une transaction dépend de la quantité de données requise. Un paquet transporte en moyenne 1 500 octets de données (c’est la MTU). Ainsi, si un message HTTP contenant une charge utile JSON représentant une transaction nécessite 4 500 octets (après chiffrement, bien sûr), cela correspond à environ trois paquets. Soyons donc généreux et considérons qu’une transaction commerciale numérique classique nécessite cinq paquets. Un réseau à 10 Gbit/s peut traiter un peu moins de 15 millions de paquets par seconde. À condition de disposer d’une capacité de calcul suffisante, on pourrait donc dire que cela équivaut à 3 millions de transactions. Supposons que chaque transaction vaille une fraction de centime (un tiers). Cela représente 1 million de dollars par seconde.

En réalité, personne ne traite de transactions à une telle vitesse ou dans de tels volumes. Même Visa — qui traite incontestablement des données à des cadences dont la plupart des entreprises n’ont pas besoin — affirme disposer d’une capacité d’environ 24 000 transactions par seconde. En attribuant la même valeur à ces transactions — un tiers de centime — cela représente tout de même 8 000 dollars par seconde.

Autrement dit, une défaillance dans la chaîne transactionnelle, composée de routeurs, de commutateurs, d’infrastructures de services réseau et applicatifs, d’infrastructures applicatives et de composants, est une Très Mauvaise Chose™. Elle coûte cher, car une défaillance signifie que les paquets ne sont plus traités, pas plus que les centimes qu’ils représentent. Or, aucun secteur de l’économie numérique ne peut se passer de la transmission de paquets.

Jusqu’à présent, la réponse tient dans le mantra « échouer rapidement » : il suffit de lancer une nouvelle instance de X, de Y, de Z ou de tout autre composant défaillant. Mais ce composant est tombé en panne *pour une raison*, et il est absolument essentiel d’identifier cette raison et d’y remédier. Rapidement. Car entre la défaillance et le rétablissement s’écoulent encore de précieuses secondes qui coûtent de la valeur à l’entreprise. Si le composant est tombé en panne une fois, il risque fort de recommencer. Encore et encore.

VISIBILITÉ : LA CLÉ DE VOÛTE SUR LAQUELLE REPOSE LE MTTR

C’est pourquoi la visibilité est si essentielle à la réussite dans l’économie numérique. En effet, c’est elle qui permet à toutes les équipes opérationnelles d’identifier la cause d’une défaillance et d’y remédier. Malheureusement, la visibilité est souvent sacrifiée au profit de la rapidité. Il ne s’agit pas de la vitesse des transactions à proprement parler, mais du délai de rentabilisation. Dans notre empressement à commercialiser les applications plus rapidement et plus fréquemment, nous n’avons pas suffisamment investi dans la visibilité nécessaire pour limiter les défaillances.

On pourrait même avancer que la philosophie « fail fast » du DevOps est une réponse à cette lacune. Faute de pouvoir identifier et traiter la cause d’une défaillance, le DevOps considère qu’il vaut mieux rétablir la disponibilité que perdre du temps. Or, cette capacité devient de plus en plus difficile à assurer à mesure que les entreprises adoptent des approches multicloud pour déployer leurs applications.

En 2018, moins d’un tiers des personnes interrogées (31 %) citaient le manque de visibilité parmi les défis du multicloud. En 2019, cette proportion a dépassé un tiers (39 %), plaçant la visibilité à égalité avec les performances et la sécurité parmi les principaux défis du multicloud. La visibilité est une composante essentielle de l’« observabilité » globale, qui réunit la surveillance, l’analyse et les alertes afin de fournir à tout moment de précieuses informations sur l’état d’un système. Elle est particulièrement importante en cas de défaillance, car l’état du système est réparti entre plusieurs silos informatiques, qui permettent ou non le partage d’informations susceptibles de conduire rapidement à une résolution plutôt qu’à un simple redémarrage.

La capacité d’un maillage de services à apporter de la valeur grâce au traçage distribué illustre parfaitement l’intérêt de la visibilité. Mais nous devons l’étendre à l’ensemble de la chaîne des services applicatifs qui assurent la mise à l’échelle et la sécurité des applications exécutées dans un environnement conteneurisé. Cela inclut également 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é couvrant les environnements, l’infrastructure et les applications est indispensable pour identifier et résoudre les problèmes à l’origine d’interruptions de service ou de mauvaises performances.

La visibilité est indispensable pour permettre aux entreprises de mesurer à nouveau leur réussite en fonction du MTTRésolution plutôt que du MTTRedémarrage.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie