BlackLine spart durch Toolkonsolidierung 16 Mio. US-Dollar pro Jahr

BlackLine vertreibt cloudbasierte Buchhaltungssoftware, die wichtige Finanzabschlussprozesse in Unternehmen automatisiert und steuert. Fällt die Software aus, beispielsweise während eines Jahresabschlusses, kann dieser nicht durchgeführt werden und Unternehmen riskieren empfindliche Strafen. Wir möchten diesen Prozess so angenehm und nahtlos wie möglich gestalten, und die Performance unseres Produkts spielt dabei eine wichtige Rolle. BlackLine benötigt daher Monitoring für eine Reihe von Services, darunter Monolith-Anwendungen, Microservices und Drittanbieter-Apps. Zusätzlich decken wir zahlreiche verschiedene Anwendungen, Technologien und Regionen ab. 

Weniger Monitoring-Tools

Wir benutzten damals so um die neun Tools zum Monitoring unseres Stacks, darunter AppDynamics, GreyLog, Scom, Fog light, Elastic, LogicMonitor und SquaredUp. Das heißt, wir hatten eine sehr fragmentierte Sicht auf unsere Systeme. Zusätzlich gab es tagtäglich 5.000 bis 10.000 Alerts. Wir verarbeiten mehrere Millionen Transaktionen pro Stunde und brauchten deshalb eine Lösung, die solche Datenmengen handhaben kann und uns bestimmte Infos gibt, z. B. Application Performance Management (APM) und Service Maps. Und nicht zuletzt sind die Daten, die wir für unsere Kund:innen handhaben, meist hochvertraulich und stellen daher besondere Anforderungen an die Sicherheit. 

Die mentale Belastung während eines Incidents steigt für Engineers zusätzlich an, wenn sie sich mit mehreren Tools herumschlagen müssen. Denn sie müssen dann nicht nur das System verstehen, sondern auch mühsam die Infos der einzelnen Tools korrelieren, interpretieren und eventuelle Lücken schließen. Um simple Informationen herauszufiltern, müssen sie mehrere Bildschirme im Auge behalten. Und die meisten Vorfälle finden nicht dann statt, wenn wir in Topform sind, sondern nachts um drei. Nicht gerade der Zeitpunkt, zu dem man Daten aus zehn verschiedenen Bildschirmen fischen möchte. Wir brauchten Systeme, die das für uns übernahmen – damit wir uns darauf konzentrieren konnten, das eigentliche Problem zu ermitteln, anstatt erst zu ermitteln, wie wir das Problem ermitteln könnten.

Egal für welche neue Monitoring-Lösung wir uns entschieden – sie musste rasch implementiert werden und umgehend Rendite bringen.

Ein neuer Umgang mit Incidents

Eines der größten Probleme bei uns war die mittlere Zeit bis zur Fehlererkennung (MTTD). Wir wollten die Probleme natürlich vor unseren Kund:innen finden, aber wenn man wie wir damals diverse verschiedene Monitoring-Tools hat, kann hier und da etwas untergehen. In der Vergangenheit verbrachten wir nach einem Incident viel Zeit mit dem Parsen von Dateien und Logs, um die Daten zu korrelieren und herauszufinden, was eigentlich wichtig war. All das ist zeitaufwändig, und mit New Relic überspringen wir diese Schritte einfach, denn es zeigt uns genau, worauf wir unsere Energie konzentrieren sollten. 

In New Relic werden die Informationen anders dargestellt und Sie können sie anders nutzen als in anderen Monitoring-Tools. New Relic liefert uns von Anfang bis Ende Kontext und Korrelation, und wir müssen kein Orakel befragen, um herauszufinden, wann und warum eine Anwendung entwickelt wurde. Das spart Zeit. Und eigene Monitoring-Schulungen für unsere Mitarbeitenden fallen jetzt auch weg, denn nach der Anmeldung bei New Relic ist sofort offensichtlich, wie es funktioniert – auch für Firmenneulinge. Allen Benutzer:innen, ganz gleich wo, werden einheitliche Informationen auf dieselbe Weise präsentiert. So lässt sich ein globales Team aufbauen, in dem nicht in jeder Zeitzone ständig jemand verfügbar sein muss. Ich bin ein Fan schlanker Teams und meine Leute sollen eine Work-Life-Balance haben – und Tools, die ihnen das ermöglichen.

Der Wechsel zum proaktiven Monitoring

Für SREs ist APM eine der nützlichsten Funktionen: die Möglichkeit, quasi ins Innere einer Anwendung zu blicken, ihr Verhalten über einen Zeitraum hinweg zu beobachten und herauszufinden, wie bestimmte Aufrufe in einem verteilten Ökosystem im Vergleich zueinander ausgeführt werden. Durch diese Funktion werden Engineers entlastet, denn das APM-System zeigt uns die Interaktionen. APM zeigt an, wenn ein Problem auftritt – oder aufzutreten droht. Und vor allem zeigt es an, ob sich ein Use Case vom ursprünglichen Zweck weg entwickelt hat.

New Relic hilft uns, Probleme zu ermitteln, bevor unsere Kund:innen sie bemerken, und erlaubt die Erstellung besserer Richtlinien und Prozesse hinsichtlich Informationsdarstellung und Alerting. Es weist uns auch auf zu erwartende Performance-Einbußen hin. Nicht jeder Incident ist ein plötzlicher Spike. Manchmal ist es ein schleichender Prozess bis hin zum Ausfall: Wir setzen mehr Ressourcen ein, sehen höhere Fehlerquoten und längere Antwortzeiten. Wenn solche Signale trotz Alert-Rauschen, Log-Schwemme und allem anderen zu uns durchdringen können, sind wir in der Lage, Probleme aus dem Weg zu räumen, bevor sie sich zu einem Incident auswachsen. Je mehr Daten wir den Engineers geben, desto besser. Denn sie kennen den Code, den sie schreiben, in- und auswendig und wissen, wie er sich verhalten soll – und zwar nicht nur den Funktionsumfang, sondern wie er den Arbeitsalltag unserer wichtigsten Zielgruppe, der Kundschaft, beeinflussen kann.

BlackLine konnte 13 Probleme vor der Produktion identifizieren, nur durch Verwendung der New Relic Infrastructure Agents – und noch bevor überhaupt irgendwelche Alerts eingerichtet waren. Die Korrelationsfunktionen sind beeindruckend: Man kann sofort alles durchgehen und sehen, wie APM und Logs zusammenhängen – bis hin zur SQL-Ebene. Einfach durch Installieren eines Agents ist das Real-User Monitoring in Echtzeit über die Datenebene möglich, sodass Sie Metriken und Alert-Bedingungen für die Systemzuverlässigkeit einrichten können, quasi wie SLAs. Und so konnten wir den Druck bereits herausnehmen, bevor unsere Kund:innen überhaupt etwas mitbekamen. 

ROI durch Monitoring-Tools

Kosten sind auch bei uns ein wichtiges Thema. Vor jedem neuen Projekt müssen wir einen hohen ROI nachweisen. Was uns an New Relic beeindruckt hat, war die Tatsache, dass wir nicht pro Host zahlen mussten – wir haben Hosts auf dem gesamten Globus verteilt, zahlreiche verschiedene Cloudmodelle und auch On-Prem-Systeme. Deshalb ist die Bepreisung auf Datenerfassungsbasis besser für uns, denn unsere Daten können aus allen möglichen Quellen stammen. Die Abrechnung pro Host kann schnell ins Geld gehen, wenn man wie wir weltweit Zehntausende Hosts nutzt. Das Modell von New Relic ist transparent, wir wissen im Voraus, was uns in Rechnung gestellt wird, und wir haben integrierte Dashboards, die uns den Trend unserer Kostenentwicklung zeigen und unsere zukünftigen Kosten prognostizieren.

Letztes Jahr konnten wir mit New Relic um die 244 Probleme in gerade einmal fünf Stunden beheben. Das proaktive Monitoring spart uns pro Jahr geschätzte 16 Mio. US-Dollar ein. Und wenn wir Incidents im Vorfeld verhindern können, führt dies zu zufriedeneren Kund:innen und einer besseren Customer Experience. Mit New Relic können alle Daten zur Korrelation über Real-User Monitoring, Synthetics, Logs in Context und Distributed Tracing erfasst werden. 

Neue Wege zur Anwendungsentwicklung, zum Schreiben von Code und zur Dashboard-Erstellung

New Relic hat zu unserer Weiterentwicklung maßgeblich beigetragen, sowohl als Führungskräfte als auch als Beitragende. Es zeigt uns, wie sich Code entwickeln muss. Es liefert Live-Feedback zur Verwendung des Produkts. Das zwingt uns dazu, mehr darüber nachzudenken, wie unsere Kund:innen unsere Produkte einsetzen – und damit auch unsere Services. Durch solch eine Feedbackschleife verbessern wir unsere Entwicklungsarbeit, denn wenn wir das nächste Mal etwas Neues entwickeln und auf einer Plattform wie New Relic bereitstellen, suchen wir nach neuen Problemen und neuen Arten der Anwendungsentwicklung – anstatt nur das Gleiche wie immer zu machen, inklusive der gleichen Fehler.

Wenn Sie sich mit den Grundlagen von SQL-Skripts auskennen, können Sie New Relic Query Language (NRQL) zur Erstellung von Dashboards, Alerts sowie Alerts als Code einsetzen. NRQL lässt das Build-as-Code-Prinzip zu, sodass Vorgänge mühelos reproduzierbar und stabil sind. Auf anderen Plattformen ist dies so nicht möglich. New Relic entlastet die Entwickler:innen also auch in dieser Hinsicht. Mit New Relic haben wir alles an der Hand, was wir brauchen: Performance, Metriken und Monitoring. So haben unsere Kund:innen die Gewissheit, dass wir den Service überwachen, für den sie zahlen, und die Tools optimal einsetzen.