Crisp avance vers la tarification à l'ingestion pour le monitoring

Pendant la transition de notre stack technologique de machines virtuelles à la plateforme Google Cloud, il y a de cela cinq ans, nous avons choisi une gamme d'outils de monitoring open source. Malheureusement, la complexité et la multiplicité des outils nécessaires sont rapidement devenues difficiles à gérer et coûteuses. Chez Crisp, nous gérons au quotidien des milliers d'alertes provenant des réseaux sociaux et les fluctuations sont monnaie courante. À l'époque, de nombreuses alertes étaient basées sur des valeurs seuils aléatoires qui étaient logiques pour l'ingénieur, mais qui se déclenchaient trop souvent et faisaient beaucoup de bruit à l'échelle internationale. Il fallait des semaines à un ingénieur pour apprendre à tracer une alerte.

Pour rationaliser les opérations, nous voulions passer à un seul outil d'observabilité, et nous avons choisi le prestataire d'observabilité en fonction de son forfait tarifaire. Nous pensions qu'un prix basé sur les hôtes était plus clair que le modèle de tarification en fonction du débit de données de New Relic. Un an plus tard, nous étions toujours bloqués par différents outils de monitoring en raison des coûts. Nous avons donc décidé de revoir notre stratégie, d'étudier ce que proposait le marché des outils et de passer à New Relic.

Continuez à lire pour savoir pourquoi New Relic répond mieux à nos besoins.

Modèle de tarification prévisible

Avec notre premier prestataire d'observabilité, nous recevions des factures astronomiques dès que nous désactivions le logging et d'autres outils pour tout centraliser en un endroit. Nous ne pouvions pas placer notre nouvel outil partout où nous le souhaitions (dans nos environnements de développement ou de simulation) et nous devions de nouveau gérer la complexité des outils de logging. 

Lorsque nous sommes passés à New Relic, nous avions besoin d'une solution qui allait uniformiser les différentes applications que nous utilisions et assurer la prévisibilité des coûts.  Nous avons commencé par désactiver les prestataires précédents pour créer un point de visibilité centralisé. Nous avions l'habitude de penser à la tarification basée sur l'hôte au lieu de l'ingestion, c'était donc nouveau pour nous et cela nous a un peu effrayés au début. Nous la comprenons désormais et c'est en fait simple. À mon avis, d'autres prestataires vont bientôt passer à ce modèle sinon, ils resteront à la traîne.

Parce que nous monitorons les pages de réseaux sociaux de différents clients, il est très difficile de savoir quelle quantité de données nous allons traiter à un moment donné. Il peut s'agir d'un événement quelconque qui fait la une des informations et nous devons collecter ces données. Avec les règles de suppression des données dans New Relic, nous pouvons gérer l'ingestion et assurer la prévisibilité des données qui sont enregistrées dans notre outil d'observabilité. Nous avons réussi à maintenir nos coûts fixes tout en améliorant le retour sur nos investissements en outils de monitoring, avec des données en temps réel.

Onboarding des ingénieurs en 3 mois

Malgré tous nos outils et la simplification du process avec les prestataires précédents, il fallait environ 18 mois pour compléter le parcours de formation (onboarding) d'un ingénieur. Avec New Relic, nous pouvons effectuer l'onboarding de nouveaux agents dans les 6 mois et ils sont dûment formés. Ils peuvent s'occuper de la plupart des besoins d'observabilité dans les trois mois. Nous évitons ainsi le burnout qui nous préoccupait auparavant, car nos collaborateurs retrouvent le temps de travailler.

Avec l'aide de New Relic University et de la documentation (entre autres), nous avons transformé nos opérations techniques en un centre d'excellence et tous les membres de l'équipe sont devenus des experts en matière d'observabilité et de bonnes pratiques de monitoring. Ils s'inscrivent d'eux‑mêmes aux cours mensuels.

New Relic a changé la façon dont nous réfléchissons aux alertes et dont nous les traitons. En effet, nous avons intégré les alertes à notre stratégie de monitoring et les alertes de New Relic sont ensuite reliées à PagerDuty pour automatiser le processus des équipes. L'expérience que nous avons eue avec New Relic est sans égal. Aucun autre partenaire avec lequel j'ai travaillé au cours des 10 dernières années n'a investi autant d'efforts. L'assistance individualisée de la part d'un membre de l'équipe New Relic, les ressources de New Relic University, la formation mensuelle disponible, l'onboarding, tout cela s'est avéré exceptionnel. 

Assistance sur une preuve de concept

Lorsque nous avons commencé la conception de notre point de visibilité centralisé, les ingénieurs de New Relic nous ont aidés à chaque étape du processus. Lors de notre première réunion avec New Relic, notre ingénieur nous a dit : « Il va falloir que nous établissions un document technique pour votre preuve de concept. Nous voulons définir les 5 principales métriques qui vous sont absolument nécessaires : nous allons nous assurer que nous les obtenons et sinon, nous comprendrons pourquoi ». J'ai immédiatement était convaincu : cette personne voulait s'assurer que nous allions recevoir les solutions dont nous avions besoin et que nos dashboards répondraient exactement à nos impératifs métier. 

Amélioration des workflows et du MTTR de 95 %

Avec New Relic, nos équipes ne consultent plus les logs en premier, mais plutôt les dashboards, car nous avons accès aux données en temps réel et pouvons ainsi rapidement et facilement identifier la cause profonde des problèmes. Nos ingénieurs voient un graphique et comprennent instantanément l'impact qu'a eu une version, ou comprennent nos niveaux de service dans leur contexte. Alors qu'auparavant, l'observabilité était le problème de l'équipe des ingénieurs chargés de la fiabilité du site, nous avons désormais l'adhésion de l'entreprise et tout le monde tire parti de l'utilisation des dashboards au quotidien. Nous intégrons aussi des SLI et SLO, développés dans New Relic, à nos dashboards.

Nos ingénieurs utilisent constamment New Relic, ils y sont connectés, ils demandent ce qu'il se passe et comment respecter nos objectifs de niveau de service. Ils font la transition vers un état d'esprit OpenTelemetry. En d'autres termes, ils réfléchissent à la résolution des problèmes avant même que la version ne passe à l'étape de simulation grâce au point de visibilité centralisé pour observer les données.

En consolidant nos outils, nous avons déjà vu une amélioration de 95 % du temps moyen de récupération (MTTR) qui est passé de 3 heures à 5 à 10 minutes avec New Relic Nous observons également un changement de culture dans notre équipe d'ingénierie. Les ingénieurs sont en train de changer fondamentalement la façon dont ils réfléchissent, ce qui est bien mieux aligné avec notre rôle commercial, en tant que leader international en intelligence des risques.

Prochaine étape : les biais du statu quo et TerraForm

Notre prochaine étape consiste à améliorer nos métriques sur les biais du statu quo en les transformant en métriques relatives au projet. Avec notre prestataire précédent, nous avions constaté que nos ingénieurs passaient 80 à 85 % de leur temps sur l'analyse des biais (un pourcentage que nous voulons réduire à 25 %) et le reste était consacré au monitoring des projets. Avec New Relic, nous sommes déjà passés à 50/50, car nos systèmes opérationnels, les alertes automatisées et le suivi ont réduit le temps passé au dépannage et à l'observabilité manuelle nécessaires pour les activités quotidiennes de notre entreprise au profit de la vérification des nouvelles fonctionnalités que nous publions.