La disponibilité avant tout

Toute entreprise est désormais une société de haute technologie.

Réfléchissez à ceci : créer, livrer et exploiter des logiciels est devenu une priorité pour les entreprises, quel que soit leur secteur d’activité.

Pour certaines, il s’agit de rester compétitives face aux attentes toujours croissantes des clients. Pour d’autres, il s’agit de rester à la pointe de l’innovation dans un marché en rapide évolution inondé de nouveaux acteurs.

Quelque soit votre secteur d’activité, vos logiciels définissent désormais l’expérience de vos clients et prospects à quasiment tous les niveaux, depuis la première connection et jusqu’aux actions et interactions les plus complexes.

Il est essentiel de s’assurer que ces expériences soient disponibles, en ligne et performantes.

Mais les logiciels ne sont pas opérationnels en permanence.

En particulier lorsque vous les modifiez et les améliorez constamment. Des périodes d’indisponibilité sont inévitables.

Les équipes techniques et DevOps ont un défi à relever, posé par un ensemble complexe de systèmes et d’infrastructure dont la finalité est d’assurer le bon fonctionnement de tous ces logiciels. Sans compter le réseau encore plus complexe et distribué d’agents chargés de surveiller toutes les composantes du stack.

Alors, quand un problème survient et que les logiciels répondent lentement, voire plus du tout, chaque minute passée à diagnostiquer et résoudre ce problème est une minute de perdue.

Et identifier le problème ne suffit pas. Vous devez comprendre pourquoi il s’est produit, et comment réagir. Pour ce faire, il vous faut consigner toute la séquence des événements et comprendre comment interagissent les différents systèmes. Comment y parvenir ?

Le contexte est essentiel

Vous avez besoin d’une vue unifiée de toutes vos données de télémétrie pour voir le mappage entre les expériences de clients et les applications, comment ces applications sont mappées à leur tour à l’infrastructure et enfin comment cette infrastructure est mappée aux autres systèmes environnants.

Une fois que vous avez relié tous ces points, vous pouvez commencer à voir ce qui risque de tomber en panne, ce qui est tombé en panne, pourquoi, et comment réagir.

Dans ce guide, nous allons regarder pourquoi ce type d’observabilité contextuelle est si important pour les entreprises modernes et ce qui vous empêche d’en bénéficier.

Le coût superficiel de l’indisponibilité est relativement facile à calculer.

C’est le coût moyen par minute d’indisponibilité, multiplié par le nombre de minutes que vous passez en indisponibilité.

Par exemple, quand le site Web de Costco s’est arrêté de fonctionner pendant plusieurs heures lors de la fête de Thanksgiving en 2019, la compagnie a perdu 11 millions de dollars en ventes.

Bien entendu, les coûts moyens d’indisponibilité varient selon les secteurs et vous ne faites pas exception. Mais il y a des moyennes qui peuvent vous servir de références.

Selon Gartner, le coût moyen de l’indisponibilité est de 5 600 $ par minute. Toutefois, il peut aller de 140 000 $ à 540 000 $ par heure. Il y a donc des variations.

En fait, 98 % des entreprises indiquent que les périodes d’indisponibilité leur coûtent plus de 100 000 $ par heure, 81 % les estiment à 300 000 $ par heure, et 33 % déclarent qu’une heure d’indisponibilité leur fait perdre entre 1 et 5 millions de dollars.

Les coûts quantifiables

Dans le meilleur des cas, les ingénieurs détectent un problème avant qu’ils n’affectent les clients. Dans le pire des cas, un problème reste inaperçu pendant des secondes, des minutes, voire plusieurs heures jusqu’à ce qu’un client affecté contacte l’entreprise pour le signaler.

Imaginez une entreprise d’e‑commerce qui subit un incident désactivant la passerelle de paiement pendant cinq minutes.

Si cinq ingénieurs passent deux heures à identifier, résoudre et documenter l’incident, le coût total de récupération est donc le coût horaire d’un ingénieur, multiplié par 10.

Et quid des ventes perdues ?

Pensez à une entreprise d’e‑commerce réalisant 24 000 ventes par minute, avec un revenu moyen de 280 000 $ par minute. La perte de revenu pendant l’indisponibilité du système est de 280 000 $ par minute, mais que dire des 24 000 clients mécontents ?

Il convient également d’intégrer le coût d’acquisition des clients, les effets négatifs et la mauvaise publicité faites par les clients en colère, sans parler du coût de réacquisition des clients qui sont partis ailleurs.

Plus qu’une simple question d’argent

Parlons des coûts humains liés à l’indisponibilité. Des alertes à 3 heures du matin aux vacances annulées en passant par le risque de licenciements, votre équipe est sous pression pour trouver et résoudre les erreurs d’indisponibilité. Qu’il s’agisse de la gêne occasionnée par des demandes continuelles de support ou de la frustration associée au dépannage, cette tension va provoquer des démissions.

Et les coûts d’opportunités sont encore plus élevés. Il faut prendre en compte la perte de productivité du personnel DevOps et des informaticiens qui doivent abandonner des projets plus stratégiques pour identifier, dépanner et documenter les pannes et les problèmes de performances.

C’est probablement le coût le plus important, et le plus difficile à évaluer.

Calculer le coût d’une baisse de productivité dépend de votre stratégie de croissance, du rôle du déploiement des logiciels dans cette stratégie et de la valeur de l’infrastructure dans votre entreprise.

Quels que soient les chiffres en jeu, le prix à payer est élevé et l’effet indirect de la perte de productivité est profond. L’entreprise perd du terrain face à ses concurrents, rate des opportunités de marché et commence à stagner.

L’indisponibilité a un coût, mais le manque de contexte coûte encore plus cher, en raison du caractère répétitif de cette indisponibilité. Cela entraîne une résolution longue et approfondie des problèmes et le mécontentement croissant des clients.

Sans connaître le contexte qui a provoqué la chute de votre système, vous ne pouvez pas récupérer de façon intelligente et vous ne créez pas les conditions de la résilience, quel que soit le temps de récupération.

Pourquoi est-il si difficile d’obtenir ce contexte ?

1. La complexité croissante des applications, de l’infrastructure et des services

Les outils de surveillance et les habitudes monolithiques du dépannage traditionnel, ainsi qu’une infrastructure statique et figée ne sont pas faites pour la complexité de l’infrastructure qui prévaut de nos jours.

Les infrastructures conteneurisées modernes déployées dans des environnements hybrides et multicloud sont, par définition, tentaculaires et éphémères, nécessitant des approches d’exploitation entièrement nouvelles.

L’automatisation, les pipelines d’intégration continue/livraison continue (CI/CD) et l’informatique orientée Kubernetes modifient les topologies et migrent en permanence les ressources.

Les applications modulaires se composent de différentes technologies open source et propriétaires, codées en plusieurs langues et frameworks qui évoluent rapidement.

Tout cet environnement devient très complexe.

2. Vos applications et votre infrastructure ne sont pas correctement alignées

En l’absence d’une vue intégrée et corrélée entre vos applications (notamment les services tiers par accès API) et l’infrastructure, vous ne disposez pas de la visibilité totale nécessaire pour prendre des décisions informées.

Et comme vos applications et votre infrastructure sont uniques à votre activité, compter sur les tableaux de bord statiques ordinaires n’est guère utile.

Certes, ils peuvent vous montrer la puissance de calcul qu’un serveur spécifique provisionne. Mais si vous essayez d’analyser l’état du système dans le contexte d’un workflow multicloud, vous avez besoin de développer votre propre application d’observabilité.

3. Profusion d’outils

Si vous utilisez plusieurs outils pour surveiller les différentes sections de votre stack, des zones d’ombre vont subsister. Pire encore, vous aurez beaucoup de mal à agréger une vue complète de l’interopérabilité de tous ces systèmes.

Analyser les incidents n’est pas chose facile. Et ces outils de surveillance open source ne sont pas vraiment gratuits.

Les entreprises doivent consacrer des ressources (en personnel) pour gérer ces outils, qui d’autre part ne sont pas 100 % fiables.

Chaque seconde perdue par un ingénieur DevOps obligé de changer de contexte d’un outil à un autre est une seconde d’indisponibilité dont vous pourriez vous passer.

Pour obtenir le type d’observabilité contextuelle qui vous aide à éviter les incidents ou à les résoudre plus intelligemment, vous devez utiliser une plateforme d’observabilité disposant de trois caractéristiques essentielles, c’est-à-dire être :

1. Ouverte. Afin de surveiller chaque système et source de données de performances que vous utilisez aujourd’hui ainsi que celles que vous utiliserez demain.
2. Connectée. Afin de suivre les performances de bout en bout de la chaîne, de l’expérience client dans son navigateur ou appareil mobile jusqu’à l’infrastructure sous-jacente, que ce soit dans le cloud, sur site ou dans un environnement hybride.
3. Programmable. Afin de développer des tableaux de bord personnalisés, des visualisations et des workflows qui représentent le contexte et les données spécifiques à votre activité.

La combinaison de ces trois caractéristiques vous aidera à garantir la disponibilité tout en permettant à votre équipe d’éviter de manière proactive les incidents à l’avenir.

Ainsi, vous pourrez aller au-delà d’une simple surveillance et profiter d’une véritable observabilité.

Dans un monde dominé par les logiciels, l’observabilité est l’objectif.

Les logiciels sont le principal point d’interaction entre votre entreprise et vos clients. Les temps de fonctionnement et de disponibilité et les performances des logiciels ne se mesurent pas seulement par leurs coûts.

Il s’agit de tenir vos promesses.

La clé pour maintenir le temps de fonctionnement et de disponibilité et des performances optimales réside dans la capacité à collecter, mettre en corrélation et contextualiser les données de vos logiciels.

Le contexte est nécessaire pour gérer l’indisponibilité comme le font les meilleurs éditeurs de logiciels : en amont.

Vous perdrez moins de temps et d’argent. Vous soulagerez vos équipes DevOps et d’infrastructure.

Plus important encore, vos clients sauront qu’ils peuvent compter sur vous.

New Relic est une plateforme ouverte, connectée et programmable qui vous donne une observabilité intégrale et contextuelle sur l’ensemble de votre stack technologique. Elle vous donne une vue consolidée de toutes vos données, depuis le navigateur et les appareils mobiles de vos clients jusqu’à vos applications et votre infrastructure, quel que soit leur environnement d’exécution. Elle réduit les zones d’ombre, fournit du contexte et vous propose des informations précises sur les limites organisationnelles artificielles, afin de vous aider à détecter et résoudre rapidement les problèmes.

Découvrez comment nous pouvons vous aider à maintenir la disponibilité de vos systèmes.