BlackLine est une société de logiciels basée dans le cloud qui automatise et contrôle le processus de clôture financière des entreprises. Si les logiciels cessent de fonctionner au cours de cette période, la clôture des registres est impossible et les entreprises peuvent recevoir de lourdes pénalités. En tant qu'entreprise, nous voulons que ce processus soit le plus harmonieux possible. Et les performances de nos produits sont un élément essentiel. BlackLine propose une plage de services pour le monitoring, y compris les applications monolithiques, les microservices et les applications de tiers. En outre, nous couvrons une large gamme d'applications, de technologies et de régions, et subissons les complications qui accompagnent tout cela.
Décision de réduire le nombre d'outils de monitoring
Nous utilisions environ neuf outils pour le monitoring de notre stack, dont AppDynamics, GreyLog, Scom, Fog light, Elastic, LogicMonitor et SquaredUp. Pour cette raison, nous avions une vue fragmentée de notre domaine. Nous recevions également 5 000 à 10 000 alertes par jour. Avec des dizaines de millions de transactions par heure, nous avions besoin d'une solution qui pouvait traiter cette quantité de données et montrer des éléments comme la gestion des performances des applications (APM) et la cartographie des services. Nous faisions également face à des problèmes de sécurité supplémentaires concernant les données sensibles que nous traitions pour nos clients.
Au cours d'un incident, plusieurs outils ont donné aux ingénieurs une forte charge cognitive. Les ingénieurs doivent non seulement comprendre le système, mais ils doivent aussi faire la corrélation entre ce que les outils révèlent sur les interactions et combler les vides. Ils doivent examiner plusieurs écrans pour en déduire des informations simples. Et la plupart des incidents se déroulent lorsqu'on n'est pas au mieux de sa forme, ils se produisent à 3 heures du matin. À cette heure-là, vous ne voulez pas ouvrir 10 écrans différents pour faire la corrélation entre les données. Nous voulions des systèmes qui pouvaient le faire pour nous afin de pouvoir passer plus de temps à résoudre le problème et non à déterminer où se trouve le problème à résoudre.
Toute nouvelle solution de monitoring devait être déployée rapidement et présenter un retour sur investissement immédiat.
Changement de la culture de gestion des incidents
L'un des plus gros défis à relever était le temps moyen de détection (MTTD). Nous voulions détecter les problèmes avant nos clients. Lorsque vous avez différents outils de monitoring, les problèmes peuvent se perdre dans le bruit de fond. Auparavant, lorsque nous traitions les incidents, nous passions beaucoup de temps à analyser les fichiers et les logs pour faire la corrélation et identifier ce qui était important. Le temps passé à ça s'accumulait vite. New Relic permet de sauter ces étapes et montre où il faut consacrer son temps.
La différence entre New Relic et quelques outils de monitoring plus classiques est la façon dont les informations sont présentées et dont vous pouvez les utiliser. New Relic nous aide à comprendre le contexte et la corrélation dès le départ. Il n'est pas nécessaire de compter sur les historiens pour vous dire comment les applications ont été développées. Le temps gagné est important pour nous, mais surtout, nous n'avons plus à former tout le monde sur le monitoring. Quand une personne rejoint l'entreprise et se connecte immédiatement à New Relic, elle sait comment l'utiliser. Tous les utilisateurs, quels qu'ils soient, peuvent voir exactement les mêmes informations présentées de la même façon. Ce même point de vue aide à établir une équipe internationale qui n'exige pas que tout le monde soit réveillé en même temps. J'aime gérer une petite équipe et j'aime que ses membres trouvent un équilibre travail-vie personnelle et disposent des outils qui leur permettent d'y arriver.
Passage à un monitoring proactif
L'APM est l'une des fonctionnalités les plus utiles pour un SRE — cette solution permet de creuser en profondeur dans une application et de voir comment elle se comporte dans le temps et comment des appels spécifiques dans un écosystème distribué sont exécutés les uns par rapport aux autres. Cette fonctionnalité réduit la charge cognitive des ingénieurs, car le système d'APM nous indique comment il interagit. L'APM nous montre où se trouve un problème ou si un problème est sur le point de se produire, mais surtout si un cas d'utilisation a évolué depuis sa conception d'origine.
New Relic aide à détecter les problèmes avant qu'ils ne touchent nos clients. Cela nous permet d'établir de meilleures règles et processus sur la façon de transmettre les informations et d'envoyer des alertes. Cela nous aide également à comprendre quand nous sommes sur le point de voir une dégradation. Tous les incidents ne se sont pas forcément des pics, et il arrive parfois que la défaillance soit progressive : nous commençons alors à utiliser plus de ressources, à recevoir des taux d'erreur plus élevés, ou à voir des temps de réponse de l'application plus longs. Si nous obtenons ces signaux malgré tout le bruit, les alertes et les logs, alors nous pouvons nous y attaquer avant que cela ne se transforme en incident. Plus vous fournissez de données aux ingénieurs mieux c'est. Ils comprennent le code qu'ils écrivent et le comportement attendu, non seulement au niveau des fonctionnalités, mais aussi de l'impact possible sur le quotidien des personnes qui comptent le plus pour nous, nos clients.
BlackLine a détecté 13 problèmes avant qu'ils n'arrivent en production, grâce à la présence des agents d'infrastructure de New Relic, avant même que les alertes ne soient configurées. La corrélation est incroyable parce qu'elle est prête à l'emploi, on peut voir l'APM et sa relation aux logs, jusqu'au langage SQL. Nous pouvons voir le monitoring des utilisateurs en temps réel jusqu'à la couche de données en installant simplement un agent. Cela nous permet de placer des métriques et des conditions d’alerte pour le monitoring des SRE, comme les SLA. Ainsi, nous pouvons réduire la pression avant même qu'elle ne soit ressentie par nos clients.
Retour sur investissement des outils de monitoring
Il est très important pour nous de respecter notre budget. Avant le lancement de tout projet, nous devons nous assurer que le retour sur investissement est élevé. Ce qui nous a frappés avec New Relic c'est que nous n'étions pas facturés par hôte. Nous avons des hôtes éparpillés dans le monde entier et de nombreux modèles de cloud différents, ainsi que des systèmes sur site. L'ingestion est le meilleur modèle pour nous, car nos données proviennent de nombreux endroits différents. Si vous êtes facturés par hôte, surtout si vous en avez des dizaines de milliers autour du monde, les budgets peuvent rapidement vous échapper. New Relic nous a fourni un modèle facile à suivre. Nous savons exactement ce pour quoi nous sommes facturés et nous avons des dashboards intégrés qui nous indiquent la tendance et les dépenses futures prévues.
L'année dernière, 244 problèmes ont pris 5 heures à résoudre avec New Relic. Nous estimons une économie de 16 millions d'USD par an grâce au monitoring proactif. Les incidents que nous prévenons mènent à une plus grande satisfaction et une meilleure expérience de nos clients. Avec New Relic, toutes les données peuvent être ingérées pour montrer la corrélation par le biais du monitoring des utilisateurs réels, le monitoring synthétique, les logs en contexte et le tracing distribué.
De nouvelles façons de développer les applications, d'écrire du code et de créer des dashboards
New Relic nous a aidés à évoluer non seulement en tant que leader mais aussi en tant que contributeurs individuels. Il nous montre comment le code doit évoluer. Il fournit des rétroactions en temps réel sur la manière dont le produit est utilisé. Cela vous oblige à réfléchir davantage à la façon dont vos clients utiliseront vos produits — et donc à vos services au moment du développement. Cette boucle de rétroaction fait de vous un meilleur ingénieur. La prochaine fois que vous développez un logiciel et que vous le déployez sur une plateforme comme New Relic, vous cherchez les nouveaux problèmes, les nouvelles façons de développer les applications, au lieu de répéter le passé et de faire les mêmes erreurs.
Si vous connaissez les scripts SQL de base, vous pouvez utiliser le langage de requêtes de New Relic, NRQL, pour créer des dashboards, des alertes et des alertes en tant que code. NRQL permet le développement en tant que code, pour que les actions soient facilement reproduisibles et stables. Sur toute autre plateforme, il n'est pas possible de reproduire exactement la même chose la fois suivante. Heureusement, New Relic élimine cette charge cognitive. New Relic fournit les performances, les métriques et le monitoring dont nous avons besoin. Nous avons la confiance de nos clients qui savent que nous surveillons le service qu'ils paient et que nous utilisons les outils judicieusement.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.