Dans un environnement en constante mutation, la contextualisation est vitale
La manière dont les équipes publient et exploitent les logiciels a évolué rapidement ces dix dernières années. En conséquence, les opérateurs IT doivent gérer une superficie qui ne cesse de grandir tant en taille qu'en complexité.
Si les changements étaient considérés auparavant comme présentant un risque pour toute l'infrastructure, ils constituent désormais la base de l'avantage concurrentiel.
En ce qui vous concerne, vous adoptez des pratiques DevOps pour livrer les applications et l'infrastructure plus rapidement et plus fréquemment. Vous modernisez vos applications afin de gagner une plus grande rapidité d'exécution, une évolutivité plus dynamique et une meilleure performance. Vous passez dans le cloud. Vous choisissez des microservices. Vous exploitez des systèmes d'orchestration de conteneurs comme Kubernetes.
Les changements rapides et incessants font désormais partie de l'ADN de la gestion de l'infrastructure.
Il y a plus de changements apportés aux logiciels, plus de configurations, plus d'alertes, plus de tout. En même temps, la pression est plus forte en termes de détection et de résolution des problèmes plus rapidement, mais aussi en besoin de stabilité et de fiabilité au niveau des systèmes de production.
La complexité que nous avons créée au nom de la rapidité et de l'évolutivité a entraîné la nécessité de complètement repenser les stratégies de monitoring. Le fait est que dans de nombreux cas, vous ne saurez pas comment votre système va fonctionner tant qu'il n'est pas en production, et cela requiert que ce système soit observable une fois en production.
Ce changement d'approche aide les équipes à garder le contrôle de leurs systèmes dynamiques.
Différentes équipes utilisent souvent différents outils pour assurer le monitoring de la partie du stack dont elles sont responsables, et c'est un problème. Un outil pour les développeurs, un pour les opérateurs IT, un pour les responsables commerciaux ; un outil pour les logs, un pour les métriques, un pour les traces, un pour le site, un pour le cloud...
Dans chaque cas, l'outil adopté est sans aucun doute celui qui convient à l'équipe.
Mais dans la pratique, cela signifie également que chaque équipe gère plus d'alertes, plus de données télémétriques et plus de données opérationnelles (critiques, mais fragmentées).
Les changements rapides et incessants font désormais partie de l'ADN de la gestion de l'infrastructure.
Chaque outil ne montre qu'une pièce du puzzle, alors qu'en réalité, l'image complète est dynamique. Les lignes entre les différentes pièces du stack sont floutées. Une application se plante et vous devez trouver ce qui s'est passé dans le code ou l'infrastructure avant que les dommages ne se propagent, mais soudain l'utilisation d'éléments de solutions disparates pour chaque composant système exige que vous y consacriez du temps et de l'argent.
Vos données se retrouvent coincées dans des silos et chaque outil a un vocabulaire différent. Résultat : les équipes essaient d'avancer à contre-courant, et surtout, vos MTTD et MTTR sont impactés.
Mais les coûts ne sont pas simplement financiers. Ils ont un effet de cascade sur toute l'entreprise. Les équipes IT et opérationnelles passent beaucoup trop de temps à faire du dépannage et pas assez à innover. L'alignement et la collaboration entre les équipes en souffrent. Le moral des employés en souffre.
L'activité en souffre.
Dans ce guide, nous allons étudier l'impact négatif qu'a l'éparpillement des outils sur votre activité. Nous verrons ensuite la myriade de possibilités qui s'ouvre à toutes vos équipes quand vous surmontez le problème.
Le problème de l'éparpillement des outils est-il vraiment si grave ?
Les chiffres seuls ne racontent pas tout, mais selon une enquête réalisée par 451 Research, 39 % des participants doivent jongler avec entre 11 et 30 outils de monitoring pour surveiller leurs environnements (applications, infrastructure et cloud), et parmi eux, 8 % doivent maîtriser entre 21 et 30 outils.
Il est vrai qu'un grand nombre de ces outils sont probablement en open source (et donc « gratuits »), mais les coûts associés (avant même qu'il n'y ait une panne) montent très vite.
Cela ralentit vos équipes
Le premier problème de l'éparpillement des outils est la simple somme de temps perdu lorsqu'un membre de l'équipe change de contexte en passant d'un outil à l'autre. Les quelques secondes ou minutes nécessaires dans une situation particulière se transforment en problème beaucoup plus important quand elles se reproduisent dans toute l'organisation.
Cela réduit la résolution des données
Si vous utilisez différents outils pour monitorer différentes parties de votre stack informatique, vous n'aurez pas la visibilité suffisante sur votre environnement parce que vous ne pourrez pas corréler la santé du système avec les performances des applications de tous vos composants.
Cela ajoute des tâches d'administration
Bien que certains outils puissent être gratuits au départ, vous devez quand même les configurer et en assurer la maintenance et la gestion (licences, ressources en interne, modules, stockage, matériel, accès à l'API et administration). Même au sein d'une seule équipe, c'est beaucoup de travail.
Mais multipliez ça sur tout un environnement distribué et soudain, le manque d'efficacité est plus qu'évident.
Tout cela se traduit par des incidents qui prennent plus longtemps à résoudre. Dans certains cas, la cause profonde peut même ne pas être identifiable parce que les données sont trop éparpillées. C'est le début des problèmes qui peuvent facilement impacter négativement l'expérience utilisateur. Surtout quand ceux sont eux qui vous les signalent.
Il existe un lien direct entre les temps d'indisponibilité et le coût pour l'entreprise, ce dernier pouvant s'avérer très cher.
Selon Gartner, le coût moyen d'une heure d'indisponibilité est de 300 000 dollars. Toutefois, 33 % des entreprises indiquent que le coût réel se situe entre 1 et 5 millions de dollars.
D'un point de vue plus global, il est nécessaire d'avoir une vue très claire de ce qui ne va pas pour pouvoir empêcher les problèmes.
Et si on agrandit encore le cadre, on découvre tout ce qui est possible avec le contexte nécessaire.
Que se passe-t-il quand on dispose du contexte nécessaire ?
L'observabilité et le monitoring n'existent plus de manière isolée.
La pratique réussie du monitoring et de l'observabilité vise trois objectifs principaux :
- Un meilleur chiffre d'affaires
- L'amélioration de l'engagement des clients
- La création d'efficiences opérationnelles
Tous ces objectifs concernent l'activité.
Pour les atteindre, il ne suffit pas de collecter le plus de données possible. Il faut plutôt faire le lien entre vos données et surtout, avoir la capacité de poser des questions essentielles à votre système.
Mais même si « plus de données » signifie qu'il y a potentiellement plus d'informations, il faut aussi tenir compte du fait que plus vous utilisez d'outils et plus cela devient compliqué.
Ainsi plus d'outils ≠ plus d'informations.
Si le monitoring est un moyen de parvenir à une fin, les seuls facteurs importants sont les suivants :
- Quelle est la valeur métier apportée par votre solution de monitoring ?
- Cette solution est-elle efficace et utile pour la résolution des problèmes ?
- Les données sont-elles aisément exploitables pour identifier et résoudre les problèmes critiques ?
Le temps perdu à passer entre les outils et à diagnostiquer et résoudre les problèmes peut être crucial.
Le monitoring vous permet de collecter des métriques sur tout votre stack, mais s'il ne peut pas vous aider à résoudre les problèmes métier critiques, vous gaspillez vos ressources.
C'est pour cela que le contexte est essentiel et qu'une plateforme d'observabilité unique change complètement la donne.
La force du contexte
Lorsque vous avez une plateforme unique pour observer tout votre stack, vous obtenez l'observabilité avec contexte.
C'est une observabilité de bout en bout : sur toute l'infrastructure, mais aussi sur les applications et l'expérience utilisateur, sur le Web et les applications mobiles, en intégrant tous les types de données télémétriques (métriques, événements, logs et traces), le tout au même endroit.
Elle tire la logique de vos données en remontant à la surface les liens importants entre elles, et ainsi en aidant les équipes à trouver et à dépanner les problèmes plus rapidement.
Cela peut vous permettre d'être plus agile dans la configuration de vos données afin de développer des applications utiles pour vos équipes et qui relient la performance et l'état de santé de l'infrastructure aux résultats commerciaux et à l'expérience des clients.
La capacité à créer et personnaliser vos visualisations interactives permet à vos équipes de voir leurs propres données configurées exactement comme elles les souhaitent et de la manière la plus pertinente pour elles.
Quand vous pouvez combiner tout ce que vous savez sur votre entreprise avec des fonctions puissantes de développement d'applications, vous avez bien plus qu'une simple contextualisation : vous avez le contexte exact pour vos besoins précis. Ainsi, vous passez de la lutte contre les incendies à la protection contre les feux.
Voici quelques exemples de ce à quoi cela peut ressembler. Explorez-les et réfléchissez aussi à ce que vous pourriez programmer pour aider à la résolution des problèmes métier critiques.
Maîtriser vos dépenses dans le cloud
Comparez la taille de vos instances cloud à leur utilisation afin que les équipes puissent rapidement identifier les ressources qui sont potentiellement en excès. Soyez encore plus précis et sélectionnez des hôtes, régions et autres configurations pour spécifier vos propres cas d'utilisation métier.
Bien comprendre la conversion des clients
Analysez et personnalisez les étapes du parcours de vos clients dans une interface interactive. Visualisez les données standard de chaque étape, telles que les vues d'une page, le taux et le nombre d'erreurs. Explorez plus en profondeur les métriques de chaque étape.
Créez aisément de nouvelles intégrations à l'infrastructure
Les points de terminaison utilisés par vos équipes opérationnelles se multiplient de manière exponentielle. Profitez de la puissance d'une intégration agnostique tout-en-un qui facilite plus que jamais l'agrégation des données à partir de sources tierces pour que vos équipes aient le contexte nécessaire pour diagnostiquer l'environnement de leur infrastructure spécifique.
L'infrastructure a besoin de contexte
Tout comme l'observabilité, l'infrastructure n'existe pas en vase clos. Elle existe dans le contexte d'un stack plus important, qui lui même existe dans le contexte plus large de l'expérience des clients, l'essence même de la réussite de votre entreprise.
Ainsi, même si la constance des changements qui définit aujourd'hui la gestion de l'infrastructure moderne rend plus difficiles la détection et la résolution rapides des problèmes d'application, il est plus important que jamais de bien la comprendre.
C'est pourquoi les solutions ponctuelles, qui dépendent de données en silo pour faire le monitoring d'une partie du stack, comme les logs ou l'infrastructure Linux, créent un tel paradoxe. Elles répondent seulement au besoin de l'équipe qui les utilise, et créent le chaos dès que vous sortez des limites qu'elles imposent.
Dans la course à l'amélioration du MTTR, à la réduction des temps d'indisponibilité et à la prévention des interruptions de l'expérience utilisateur, vous devez pouvoir répondre immédiatement à deux questions en cas de plantage : qu'est-ce qui est cassé et pourquoi ?
Ce n'est qu'avec tout le contexte qu'une plateforme d'observabilité peut vous faire passer rapidement du problème lui-même à sa cause, et accorder aux équipes le pouvoir de vite répondre à ces questions et de minimiser ainsi les chances d'indisponibilité ou de mauvaise expérience utilisateur.
En corrélant au même endroit les données disparates de l'infrastructure, des logs, des changements de configuration, des applications, et des services frontend, on a une plateforme d'infrastructure et d'observabilité moderne qui permet de faire remonter les données à la surface en les contextualisant correctement.
En d'autres termes, les équipes IT comprennent précisément comment leur infrastructure impacte les applications et inversement.
Si vous pensez que vous devriez obtenir plus d'informations tangibles de vos données, contactez-nous pour en discuter.
New Relic One permet aux équipes de développement et IT d'avoir accès aux mêmes données sur une plateforme unique avec des capacités de corrélation des applications et de l'infrastructure ultrarapides et précises pour identifier et résoudre les problèmes plus rapidement.
Ainsi, quoi qu'il arrive dans vos logiciels, vous pouvez trouver et résoudre le problème avant qu'il n'impacte l'expérience utilisateur.
