3 mesures prises par Car IQ permettant aux DevOps de passer de la maintenance de l'infrastructure à la sortie de nouvelles fonctionnalités

Chez Car IQ, nous traitons les transactions financières en temps réel : nos clients sont les vrais conducteurs qui attendent à la station‑service pour payer et distribuer le carburant utilisant nos services. Toute interruption peut avoir de graves répercussions sur la capacité des conducteurs à terminer leur travail à temps. En tant qu'entreprise de technologie obsédée par les clients, il est fondamental que nous soyons immédiatement au courant des problèmes qui se produisent au sein de notre workflow. Pour que nous puissions non seulement les confirmer et les résoudre, mais aussi communiquer de manière proactive avec les clients et leur faire savoir que nous sommes au courant du problème — même dans les cas où les transactions échouent en raison d'une erreur de leur part (limites quotidiennes, règles de dépenses, proximité, etc.).

Du point de vue de l'infrastructure, nous voulions :

1. Être au courant des problèmes dès qu'ils se produisent — et non lorsqu'un client nous les signale.
2. Des alertes suffisamment intelligentes pour nous suggérer une résolution ou nous aider à identifier la cause profonde.

Pour y arriver, nous avons utilisé les éléments suivants :

1. Dashboards avec agents de tracing distribué
2. Alertes
3. Monitoring synthétique

Avant d'implémenter New Relic sur toutes nos opérations, nous devions gérer des incidents critiques quasiment toutes les semaines. Avec une architecture distribuée basée dans le cloud, il était parfois vraiment difficile de trouver leur véritable cause. Pour savoir pourquoi une transaction avait échoué d'une façon anormale exigeait de passer par plusieurs fenêtres de logs, de faire correspondre les horodatages et même parfois des recherches dans la base de données — il s'agissait plus ou moins d'un jeu de déduction. Cela augmentait non seulement le temps moyen de résolution (MTTR), mais aussi cela exacerbait les tensions au niveau des relations avec nos clients et interrompait les workflows des développeurs.

1. Des dashboards pour notre infrastructure et nos opérations

Ne vous est-il jamais arrivé d'entrer dans une pièce qui vous est très familière et de repérer immédiatement que quelque chose n'est pas à sa place ? C'est ce que font les dashboards pour nous — ils apportent une vue familière de haut niveau sur les performances historiques et actuelles de notre infrastructure. Si quelque chose ne va pas, nous pouvons le voir quasiment immédiatement. En disposant de vues qui nous permettent de voir la santé de notre infrastructure à tout moment, nous pouvons avoir l'œil sur nos opérations et trouver les moyens de maintenir une grande efficacité en résolvant les baisses de performances dès qu'elles se produisent. Lors du paramétrage de nos dashboards de surveillance, nous nous sommes appuyés sur les fonctionnalités de l'assistant de dashboards compris avec New Relic. 

Il nous a suffi d'entrer les variables environnementales et de partager les clés d'API pour obtenir la surveillance instantanée de notre infrastructure via les dashboards, et ce, en moins de vingt minutes. Nous avons pu paramétrer des attributs personnalisés et des types d'événements pour montrer les détails particuliers que nous voulions montrer.

Nos dashboards agissent comme une interface utilisateur. Nous pouvons cliquer sur une transaction et voir son parcours dans tous nos services. Les capacités de tracing distribué sont un élément essentiel des vues de nos dashboards : nous avons paramétré des agents New Relic sur nos microservices qui injectent automatiquement les identifiants de trace dans nos transactions. Ceci nous permet de rechercher les problèmes et de déterminer les causes profondes sans devoir demander les données ou logs de transaction à d'autres équipes. Nous avons également formé les équipes sur les avantages du tracing distribué et sur comment creuser en profondeur dans les métriques avec Errors Inbox.

2. Des alertes affinées pour faciliter la priorisation

Pour répondre aux problèmes tout au long de la journée, dès qu'ils se produisent, nous avons défini des alertes.

L'un des défis présentés par les alertes est l'atténuation de la fatigue due aux alertes : un grand nombre de messages non exploitables parce que les seuils sont définis trop bas ou trop larges. Ils vous informent des petits défauts qui se sont stabilisés ou qui ont été résolus avant que vous ayez besoin de vous en préoccuper. La première chose que nous avons faite lors de l'implémentation de New Relic a été d'affiner nos seuils d'alertes. 

Lors de l'affinement des alertes, il est important d'identifier les seuils qui mènent à une action. Rendez vos alertes exploitables afin de garantir qu'elles présentent un intérêt lorsqu'elles se déclenchent. Nous avons ainsi rapidement éliminé un grand nombre de rapports et nous avons pu nous concentrer sur les véritables erreurs et problèmes d'infrastructure dès qu'ils remontaient à la surface.

Sur nos dashboards, nous avons établi des seuils, mais aussi défini les conditions d’alerte et comment nous voulions que ces alertes soient communiquées à nos équipes. Par exemple, nous avons défini une alerte pour toutes les fois où le taux d’erreur sur l'un de nos serveurs dépassait plus de cinq minutes. Et nous avons utilisé les intégrations dans New Relic pour associer les alertes directement avec notre canal Slack pour les DevOps.

3. Monitoring synthétique : des contrôles ponctuels réguliers sur tous nos systèmes

Comme toute autre entreprise avec des API, une architecture distribuée et une infrastructure cloud massive, il est absolument essentiel d'effectuer des contrôles réguliers. Cela nécessite d'aller au-delà des contrôles de la santé du système. En effet, trouver un point de terminaison et renvoyer 200 réponses est une chose, mais comment validez-vous l'intégrité de vos données ? Comment pouvez-vous valider l'exécution d'un test de bout en bout en production toutes les minutes, toutes les deux minutes, toutes les cinq minutes, et savoir dans la seconde que quelque chose ne fonctionne pas comme prévu ? En utilisant les bonnes pratiques du monitoring synthétique nous pouvons exécuter des scénarios de tests supplémentaires et assurer que nos systèmes de données en temps réel sont robustes et performants 24h/24. Avec les dashboards qui permettent le tracing distribué et les alertes affinées en place, notre dernier composant a été l'installation des contrôles de santé du monitoring synthétique.

Les DevOps automatisés changent la donne pour l'entreprise

Au cours des derniers six mois, le retard que nous avions accumulé avec les problèmes DevOps a disparu, nous avons pu perfectionner notre infrastructure et réduire le coût global du cloud. Cela a changé notre relation avec le directeur technique et les équipes d'ingénierie dans toute l'entreprise. Nous avons désormais beaucoup de conversations sur l'avenir. Nous sommes focalisés sur le produit et les fonctionnalités que nous lançons, avec moins de temps passé à réagir aux catastrophes et une plus grande attention mise sur la livraison. Les taux de livraison de l'équipe d'ingénierie ont augmenté d'au moins 50 %. Nous lançons de nouvelles choses tout le temps et nous utilisons le temps qu'il nous reste pour développer des partenariats et des intégrations stratégiques.

Les entreprises comme la nôtre ont besoin de s'éloigner d'une obsession manuelle sur la qualité de notre infrastructure et la capacité de faire le suivi des transactions et de l'expérience utilisateur : nos systèmes devraient être suffisamment automatisés pour nous dire ce qui se passe et nous aider à garder le contrôle des endroits où nous pouvons avoir un impact. Une infrastructure hautement performante, robuste et fiable est le principal enjeu de notre croissance commerciale future.