Guide de préparation pour les pics d'utilisation

Ces dernières années, j'ai eu l'occasion d'accompagner plusieurs clients dans l'implémentation de l'observabilité pour leur infrastructure et leurs applications dans les activités quotidiennes. C'est lorsqu'on constate la manière dont les équipes utilisent les données lors d'incidents pendant la haute saison que l'on sait que cette implémentation a réussi. 

Pour les entreprises d'e-commerce, la haute saison représente en général la plus grosse opportunité de revenus de l'année. C'est à travers l'application et le stack technologique sur lequel elle s'exécute que les entreprises capturent du revenu et encouragent la fidélité de la clientèle dans un contexte de plus en plus concurrentielle. 

Les équipes d'ingénierie qui gèrent les stacks d'applications doivent non seulement pouvoir observer ce qu'il se passe, mais également isoler rapidement la cause du problème, la résoudre et réaffecter les efforts selon les impacts sur l'activité.

Dans ce blog, nous aborderons les éléments suivants :

• Comprendre comment se préparer aux pics d'utilisation
• Les erreurs courantes dans la préparation aux pics d'utilisation
• Le processus de planification pas à pas pour se préparer aux pics d'utilisation

Pour des informations plus détaillées, consultez le lien vers le document complet en bas de ce blog.

Comprendre comment se préparer aux pics d'utilisation

Disponibilité ne signifie pas forcément performance. 

Être préparé aux pics d'utilisation signifie au minimum que votre application est disponible continuellement aux utilisateurs en cas de surcharge. Toutefois, cette préparation implique bien que plus la disponibilité de l'application.

La disponibilité et les performances de l'application doivent s'aligner sur les objectifs commerciaux de votre entreprise. Après tout, le but de votre application est de fournir un moyen d'accomplir un ensemble d'objectifs commerciaux. 

Tout le monde, de la direction aux équipes d'ingénierie, peut observer l'état de santé actuel de l'entreprise, plus spécialement lors d'une surcharge de demandes ou de problèmes système, que ce soit au niveau logiciel ou matériel, et leurs impacts sur l'entreprise et l'expérience clientèle. Ce qui détermine une préparation réussie aux pics d'utilisation, c'est de comprendre comment les performances de l'application se rapportent aux impacts commerciaux.

Erreurs courantes dans la préparation aux pics d'utilisation

Voici plusieurs erreurs courantes que j'ai observées :

Erreur n° 1 : commencer trop tard

La première erreur courante est de commencer trop tard. Souvent, les équipes débutent les activités de préparation aux pics d'utilisation un ou deux mois avant la saison haute. Les conflits de priorités et de ressources font que seule une petite portion de tâches est effectuée et nombre de lacunes et d'inconnues sont laissées au hasard.

Erreur n° 2 : ne pas rapprocher les performances de l'application et les objectifs commerciaux

L'équipe se concentre uniquement sur les données d'application et d'infrastructure d'un point de vue technique sans comprendre l'impact des dégradations et des erreurs sur la source de revenu ou la satisfaction de la clientèle. Si les impacts sur l'entreprise ne sont pas bien compris, on risque de ne pas donner la bonne priorité aux différents problèmes.  

Erreur n° 3 : silos d'informations

L'architecture moderne des microservices ainsi que la gestion continue des CI/CD ont souvent causé la compartimentation des équipes d'ingénierie. Chaque équipe comprend uniquement les tenants et les aboutissants des parties dont elle est responsable, mais elle conçoit moins les dépendances et encore moins comment les performances de son application affecte tout le processus commercial. Ce manque de compréhension de la vision globale entrave la manière dont l'équipe partage les informations et ralentit le triage lors d'un incident.  

Erreur n° 4 : ne pas inclure la préparation aux pics d'utilisation dans le développement

Comme les activités de préparation aux pics d'utilisation sont limitées à l'environnement de production, les équipes perdent une occasion d'apprendre comment l'application fonctionne, et d'identifier les maillons faibles, les indicateurs clés, les alertes efficaces et les actions de mitigation potentielles lors du développement et du test dans les environnements hors production. Ce qui est observé dans les environnements hors production peut renforcer la version finale face aux pics de demandes.

Planifier correctement sa préparation aux pics d'utilisation

Les sections suivantes comportent des recommandations pour vous guider et vous préparer aux événements de forte demande. Nous les avons décomposées en huit phases :

Phase 1 : vérification et planification

Dans cette phase, les tâches sont d'identifier les membres clés, le cadre délégué et les objectifs commerciaux associés à ce projet. Il est également important d'examiner la portée, les objectifs, les métriques et le plan de communication. 

Phase 2 : identifier les processus commerciaux critiques

La prochaine étape est d'identifier et de décrire les processus commerciaux critiques qui capturent les revenus ou ont une incidence cruciale sur la satisfaction et la fidélité de la clientèle. Vous pouvez les identifier en vous basant sur les flux de données d'exécution des demandes.

Phase 3 : vérifier la collecte des données

L'objectif de cette phase est de vérifier les données requises pour étayer les données de performances et les données commerciales. Bien souvent, il faut un certain degré d'instrumentation personnalisée pour les données commerciales, comme par exemple la valeur du panier. Lorsque l'équipe vérifie les données disponibles, elle doit prendre en considération les métriques, événements, logs et traces, pas seulement les métriques et les événements. Voici une liste des capacités de la plateforme et des ressources New Relic disponibles pour améliorer l'observabilité :

• Détecter les agents obsolètes (à l'aide d'Agent Groundskeeper)
• Utiliser les logs contextuels pour accélérer le MTTR lors du dépannage des problèmes de l'application
• Dépanner avec le tracing distribué pour identifier les ralentissements ou les erreurs dans plusieurs services
• Améliorer le site web et afficher les éléments web vitaux avec les données de navigateur
• Analyser et dépanner les pannes avec les données mobiles
• Observer l'intégrité de l'infrastructure avec les données d'infrastructure
• Afficher les performances Kubernetes et de l'application en contexte
• Monitorer vos services cloud dans AWS, GCP et Azure avec les intégrations à l'infrastructure
• Utiliser les workloads pour vous concentrer sur les choses importantes à vos yeux
• Utiliser Errors Inbox pour aider les équipes à voir les erreurs dans un seul endroit et à collaborer
• Utiliser la gestion des vulnérabilités pour garder le contrôle sur les vulnérabilités critiques 
• Suivre le processus de gestion de la qualité des alertes pour améliorer l'efficacité des alertes
• Tirer profit du niveau de service pour la gestion des niveaux de service
• Automatiser les dashboards et les alertes à l'aide de Terraform
• Afficher les modifications causées par le déploiement ou un événement significatif avec Change Tracking
• Utiliser les logs New Relic pour réduire le MTTR et dépanner plus rapidement
• Autoriser les développeurs à afficher les performances dans l'IDE avec CodeStreams de New Relic
• Améliorer l'observabilité en général avec les guides de maturité d'observabilité
• Monitorer les fonctions AWS Lambda, Azure Functions et Google Cloud

Phase 4 : implémentation en production

Dans cette phase, l'objectif est de mettre en œuvre dans l'environnement de production les tâches identifiées dans la phase précédente. Chaque équipe d'application travaille sur son application. Cela peut impliquer le déploiement d'agents supplémentaires, la mise à jour des agents, une instrumentation personnalisée, la configuration des conditions d'alertes, les workflows de notifications, les actions de résolution et les dashboards requis. 

Phase 5 : vérification entre équipes et opérations communes

L'enjeu de cette phase est de partager les résultats avec toutes les équipes. C'est particulièrement important pour les équipes qui dépendent les unes des autres. L'objectif est que les équipes adjacentes puissent développer une bonne compréhension des impacts sur leur application respective lorsqu'un incident survient dans les autres applications. 

Phase 6 : derniers réglages

Cette phase se déroule juste avant le gel du code où seuls les correctifs de bugs critiques seront déployés. Cela signifie qu'il n'y a pas non plus de nouveaux déploiements New Relic. C'est également une excellente opportunité de continuer le réglage des alertes et des dashboards, car l'équipe de développement est plus disponible pour ces activités qui n'ont aucun impact sur l'application. 

Phase 7 : période de gel

C'est la dernière ligne droite ! Si vous avez bien fait ce qu'il faut aux phases précédentes, vous ne devriez pas avoir de surprises. Vous pouvez toujours ajouter/modifier/supprimer les alertes et les dashboards selon les besoins, car ces changements n'interféreront pas avec les applications. 

Phase 8 : leçon apprise 

Une fois la saison haute terminée, comme dans toute bonne gestion de projet, il faut faire le constat des choses apprises.

D'abord, les membres clés de l'équipe de préparation aux pics d'utilisation et les leaders/architectes d'application examinent les performances globales de l'équipe face aux problèmes rencontrés. Ensuite, il faut discuter des changements d'environnement connus pour la prochaine saison, comme les nouvelles versions de logiciel, les nouveaux stacks technologiques et/ou les nouveaux processus commerciaux et les impacts associés sur l'observabilité.

Résumé

La préparation aux pics d'utilisation, c'est un projet, pas juste une tâche. Elle demande une exécution pas à pas, de l'environnement hors production à l'environnement de production. Elle doit également impliquer des personnes du développement, des opérations et de la direction dans la planification, de la préparation et de l'exécution. Il doit y avoir une connexion claire entre les données commerciales et les données de performances ou opérationnelles pour garantir que la préparation soit alignée sur les objectifs commerciaux. 

Lorsqu'elle est mise en œuvre correctement, la saison haute sera beaucoup moins stressante pour toutes les parties prenantes. 

Pour obtenir des informations détaillées et des exemples, consultez la documentation complète sur la préparation aux pics d'utilisation.