Als wir vor fünf Jahren unseren Tech-Stack von virtuellen Maschinen auf die Google Cloud Platform umstellten, begannen wir auch, eine Reihe von Open-Source-Tools zum Monitoring einzusetzen. Die Vielfalt und Komplexität der notwendigen Tools stellte allerdings bald im Hinblick auf Verwaltung und Kosten ein Problem dar. Wir verwalten bei Crisp täglich Tausende von Alerts von Social Media – mit großen Fluktuationen. Viele der generierten Alerts beruhten auf beliebigen Schwellenwerten, die für einzelne Engineers sinnvoll waren, aber für ein unglaubliches Alert-Rauschen sorgten. Es dauerte Wochen, bis neue Engineers das Tracing eines Alerts gemeistert hatten.
Um das Ganze zu straffen, suchten wir also nach einem konsolidierten Observability-Tool. Unser Auswahlkriterium war das Preismodell, denn wir waren der Ansicht, dass ein hostbasierter Preis klarer sei als das Preismodell von New Relic, das sich auf den Daten-Throughput stützt. Ein Jahr später hatten wir aus Kostengründen aber immer noch eine Reihe von Monitoring-Tools am Hals. Wir überdachten also unsere Herangehensweise noch einmal, sahen uns auf dem Markt um und wechselten zu New Relic.
New Relic erwies sich für uns letztendlich als die bessere Wahl, und zwar aus folgenden Gründen:
Kalkulierbares Preismodell
Bei unserem ersten Observability-Tool war es so: Sobald wir die Logging- und anderen Tools früherer Anbieter abzuschalten begannen, schnellten die Kosten in die Höhe. Und wir konnten unser neues Tool nicht überall einsetzen, wo wir es brauchten, z. B. in der Entwicklung, im Staging … – so kehrten wir doch wieder zu den verschiedenen Logging-Tools zurück.
Wir sind schließlich auf New Relic umgestiegen, weil wir eine Lösung benötigten, die all die verschiedenen Apps, die wir verwendeten, zusammenführt, und zwar ohne Überraschungen bei der Abrechnung. Um zu einer zentralen Benutzeroberfläche, einer Single Pane of Glass, zu gelangen, deaktivierten wir als Erstes die vorherigen Anbieter. Wir waren das hostbasierte Preismodell gewohnt, deshalb hat uns ein Modell, das anhand der Datenerfassung abgerechnet wird, ein bisschen Sorge bereitet. Aber jetzt, da wir wissen, wie es funktioniert, sind wir sehr zufrieden. Es ist einfach zu verstehen, und wenn andere Anbieter nicht ins Hintertreffen geraten wollen, werden sie wahrscheinlich auch zu diesem Modell übergehen.
Wir können nur schwer abschätzen, welche Datenmengen wir jeweils handhaben, da wir das Monitoring der sozialen Medien für verschiedene Kunden übernehmen. Passiert irgendwo auf der Welt etwas Berichtenswertes, schlägt sich das in den Nachrichten nieder und wir müssen die entsprechenden Informationen sammeln. Mit den Data-Dropping-Regeln in New Relic können wir die Datenerfassung managen und steuern, welche Daten in unseren Observability-Tools gespeichert werden. So blieben unsere Kosten gleich, während der ROI unseres Monitoring-Tools anstieg – mit Daten in Echtzeit.
Onboarding der Engineers in nur drei Monaten
Als wir noch diverse verschiedene Tools verwendeten, hat das Onboarding neuer Engineers trotz Rationalisierung der früheren Anbieter insgesamt ca. 18 Monate gedauert. Bei New Relic dauert das Ganze sechs Monate, wobei neue Engineers meist schon nach drei Monaten in der Lage sind, sich um die meisten Observability-Tasks zu kümmern. So haben alle mehr Zeit für produktive Arbeit und Burnout ist kein Thema mehr – früher haben wir uns darüber ziemliche Sorgen gemacht.
Unser Ops-Team ist jetzt ein Center of Excellence. Das haben wir dank Ressourcen wie der New Relic University und der New Relic Dokumentation geschafft: Alle Mitglieder des Teams kennen sich jetzt bestens mit den Best Practices für Observability und Monitoring aus. Und jeden Monat melden sich Teammitglieder freiwillig für Kurse an.
New Relic hat unsere Auffassung und Handhabung von Alerts komplett umgekrempelt – sie sind jetzt Teil unserer Monitoring-Strategie. Um den Prozess für die Teams möglichst zu automatisieren, werden die New Relic Alerts zudem in PagerDuty eingebunden. Wir haben mit New Relic bisher nur gute Erfahrungen gemacht – ich kann mich an keinen anderen Anbieter in den letzten zehn Jahren erinnern, der sich so für uns eingesetzt hat. Der Support von New Relic für einzelne Teammitglieder, die Ressourcen der New Relic University, die Monat für Monat verfügbaren Schulungen, das Onboarding: Besser könnte es wirklich nicht sein.
Hilfe beim Proof-of-Concept
Als wir mit der Konzeption unseres Single-Pane-of-Glass-Modells begannen, standen uns die Engineers von New Relic bei jedem Schritt zur Seite. Beim ersten Meeting sagte unser New Relic Engineer zu uns: „Wir müssen ein technisches Dokument für Ihren Proof-of-Concept schreiben. Wir möchten Ihre fünf wichtigsten Metriken definieren, damit wir sicherstellen können, dass wir diese erfüllen. Und wenn nicht, damit wir wissen, warum.“ Das hat mich sofort beeindruckt: Jemand, der sich auskannte und der sichergehen wollte, dass New Relic genau die Lösungen liefert, die wir benötigen, und dass unsere Dashboards genau auf unsere Anforderungen zugeschnitten sind.
Verbesserte Workflows: MTTR um 95 % verkürzt
Mit New Relic prüfen unsere Teams jetzt nicht mehr zuerst die Logs, sondern sehen sich zunächst die Dashboards an, weil wir Live-Daten haben. So können wir Probleme schnell und punktgenau lokalisieren. Unsere Engineers rufen ein Diagramm auf und sehen sofort, wie sich ein Release auswirkt, oder sie können sich unsere Service-Level im Kontext ansehen. Früher war Observability Sache des Site-Reliability-Engineering-Teams. Jetzt nutzen auch andere Teams täglich die Dashboards. Und die New Relic eigenen SLIs und SLOs nehmen wir auch in unsere Dashboards auf.
Unsere Engineers benutzen New Relic ständig, sie sind immer angemeldet, prüfen, was los ist und wie sie unsere Service-Level Objectives einhalten können. Sie entwickeln zunehmend ein OpenTelemetry-Mindset – nämlich bereits vor dem Staging einer Version über das Troubleshooting nachzudenken. Dank der Single Pane of Glass ist das möglich, denn damit haben sie alles im Blick.
Die Konsolidierung unserer Tools hat uns jetzt schon eine 95-prozentige Verbesserung der mittleren Lösungszeit (MTTR) eingebracht: von drei Stunden auf sage und schreibe fünf bis zehn Minuten mit New Relic! Zusätzlich findet im Engineering-Team ein Kulturwandel statt: Unsere Engineers berücksichtigen jetzt bei ihrer Arbeit zunehmend unsere Position in der Branche als weltweit führendes Risk-Intelligence-Unternehmen.
Und als Nächstes? Business as Usual und TerraForm
Unser nächstes Ziel ist die Neugewichtung unserer Metriken für Business as Usual (BAU) gegenüber Projektmetriken. Bei unserem früheren Anbieter verbrachten unsere Engineers 80–85 % ihrer Zeit mit BAU-Analysen. Das möchten wir auf 25 % reduzieren, damit mehr Zeit für das Projekt-Monitoring bleibt. Mit New Relic konnten wir das Verhältnis bereits auf 50/50 umschichten, denn unsere betrieblichen Systeme, automatischen Alerts und Tracking sorgen dafür, dass Troubleshooting und Observability für die täglichen Geschäftsabläufe weitaus weniger Zeit in Anspruch nehmen und wir uns stattdessen auf die Features konzentrieren können, die kurz vor dem Roll-out stehen.
Crisp gehört zur Kroll-Gruppe und ist ein Unternehmen für Risk Intelligence, das seine Kunden durch Tracking von Datenpunkten im Web und in sozialen Medien vor neuen Online-Gefahren schützt. Wir sorgen dafür, dass Marken- und Unternehmensplattformen geschützte Orte sind, ohne Mobbing, Rassismus oder Sexismus und ohne böswillige Eindringlinge.
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.
