Bei Car IQ dreht sich alles um finanzielle Transaktionen in Echtzeit: Fahrer:innen nutzen unsere Services an der Zapfsäule zum Tanken und Bezahlen des Kraftstoffs. Kommt es dabei zu Störungen, kann dies die Fahrer:innen daran hindern, ihre Arbeit zeitgerecht zu erledigen. Für uns als kundenorientiertes Unternehmen ist es wesentlich, dass wir Probleme in unserem Workflow erkennen, sobald sie auftreten. Nicht nur können wir sie auf diese Weise schnell prüfen und gegebenenfalls beheben, wir können auch unseren Kund:innen versichern, dass wir uns bereits um das Problem kümmern – selbst wenn eine Transaktion aufgrund eines Benutzerfehlers (Tageslimits, Ausgabenregelungen, Entfernung usw.) fehlschlägt.
Hinsichtlich der Infrastruktur hatten wir mehrere Ziele:
- Wir wollten sofort von Problemen wissen, sobald sie auftreten. Nicht erst, wenn Kund:innen sie entdecken.
- Das Alerting sollte clever genug sein, um uns auch Hinweise zur Ursachenfindung und Fehlerbehebung zu liefern.
Um diese Ziele zu erreichen, machten wir uns Folgendes zunutze:
- Dashboards mit Distributed-Tracing-Agents
- Alerts
- Synthetic Monitoring
Vor der unternehmensweiten Implementierung von New Relic mussten wir uns manchmal wöchentlich mit kritischen Incidents herumschlagen. Und die Ursachenfindung in unserer verteilten, cloudbasierten Architektur war nicht immer leicht. Wenn eine Transaktion fehlschlug und die Ursache nicht offensichtlich war, brauchten wir zur Fehlersuche oft mehrere Logfenster, Zeitstempelabgleiche und manchmal sogar manuelle Datenbank-Lookups. Im Prinzip ging es darum, nach und nach verschiedene mögliche Gründe auszuschließen, bis nur noch einer übrig war. Dies bescherte uns nicht nur eine längere mittlere Wiederherstellungszeit (MTTR), sondern belastete auch die Kundenbeziehungen und störte die Arbeitsabläufe der Entwickler:innen.
1. Dashboards für Infrastruktur und Operations
Ist es Ihnen schon mal passiert, dass Sie sich in Ihrem Haus umsehen und sofort wissen, dass etwas nicht stimmt? Den Effekt haben für uns die Dashboards: Sie liefern eine vertraute Übersicht der bisherigen und aktuellen Performance unserer Infrastruktur, und wenn irgendwas nicht in Ordnung ist, fällt dies sofort auf. Dank der Visualisierungen, die uns den Zustand unserer Infrastruktur zu jedem beliebigen Zeitpunkt anzeigen, können wir unsere Abläufe im Auge behalten, Leistungsabfälle sofort beheben und so für maximale Effizienz sorgen. Beim Einrichten unserer Dashboards haben wir uns den Dashboard-Assistenten zunutze gemacht, der zu New Relic gehört.
Nachdem wir die grundlegenden Variablen und API-Keys angegeben hatten, zeigten uns die Dashboards innerhalb von 20 Minuten einen Überblick über unsere Infrastruktur. Und durch Eingabe von Custom-Attributen und Event-Typen erhielten wir ganz gezielt die Details, die wir überwachen wollten.
Die Dashboards sind quasi unsere Benutzeroberfläche. Wir klicken auf eine Transaktion und sehen ihren Verlauf in allen unseren Services. Distributed Tracing nimmt in unseren Dashboard-Ansichten eine wesentliche Rolle ein: Wir richten in unseren Microservices New Relic Agents ein, die die Transaktionen automatisch mit Trace-IDs versehen, und können so Fehlerursachen ermitteln, ohne andere Teams um Transaktionsdaten oder Logs bitten zu müssen. Zusätzlich haben wir für unsere Teams Schulungen zu den Vorteilen von Distributed Tracing organisiert und ihnen gezeigt, wie sie mit Errors Inbox mehr aus Metriken herausholen können.
2. Mühelose Priorisierung dank präzise definierter Alerts
Damit wir eventuell auftretende Probleme jeweils sofort angehen können, haben wir Alerts eingerichtet.
Die große Herausforderung bei Alerts ist allerdings die Verhinderung übermäßig vieler Meldungen. Dazu kommt es, wenn Schwellenwerte zu niedrig oder zu weit gefasst sind, denn dann wird alles Mögliche gemeldet, auch Kleinigkeiten, die bereits automatisch behoben wurden. Deshalb haben wir nach der Implementierung von New Relic als Erstes die Alerts justiert.
Bei der Feinabstimmung von Alerts ist es wichtig, die korrekten Schwellenwerte festzulegen, damit nur Relevantes gemeldet wird. Auf diese Weise konnten wir unser Reporting sehr verschlanken und uns gezielt tatsächlichen Fehlern und Infrastrukturproblemen zuwenden.
Die Schwellenwerte und Alert-Bedingungen richteten wir über unsere Dashboards ein und legten dort auch fest, wie die Alerts unsere Teams erreichen sollten. Beispielsweise haben wir einen Fehlerquoten-Alert eingerichtet, der ausgelöst wird, wenn auf einem unserer Server innerhalb von zwei Minuten mehr als fünf Fehler auftreten. Und über die mit New Relic gelieferten Integrationen konnten wir die Alerts direkt mit unserem DevOps-Slack-Kanal verknüpfen.
3. Synthetic Monitoring: Regelmäßige systemweite Stichproben
Wie in jedem Unternehmen mit APIs, einer verteilten Architektur und einer riesigen Cloudinfrastruktur sind regelmäßige stichprobenartige Überprüfungen auch bei uns ein absolutes Muss. Dies muss allerdings über einfache Zustandsprüfungen hinausgehen, denn von einem Endpunkt eine 200-Antwort zu erhalten ist eine Sache, aber wie prüfen Sie die Integrität Ihrer Daten? Wie lässt sich in der Produktion einmal pro Minute, alle zwei Minuten oder alle fünf Minuten ein vollständiger Test durchführen, damit Sie sofort im Bilde sind, wenn etwas nicht wie erwartet funktioniert? Mithilfe von Best Practices für das Synthetic Monitoring sind wir in der Lage, zusätzliche Tests durchzuführen und sicherzustellen, dass unsere Live-Datensysteme rund um die Uhr stabil und leistungsfähig sind. Mit Dashboards, die Distributed Tracing zulassen, und mit präzise justierten Alerts blieb dann nur noch eines zu tun: die Implementierung von Health-Checks für das Synthetic Monitoring.
Automatisierte DevOps: Ein Gamechanger fürs Geschäft
Unseren Rückstand hinsichtlich DevOps-Problemen haben wir in den letzten sechs Monaten endlich aufgeholt, wir konnten unsere Infrastruktur optimieren und die Gesamtkosten für die Cloud senken. Das hat auch unser Arbeitsverhältnis zum CTO und zu den technischen Teams im gesamten Unternehmen verändert, denn jetzt führen wir viele zukunftsorientierte Gespräche. Wir können uns auf das Produkt und die Veröffentlichung neuer Funktionen konzentrieren und schlagen uns viel seltener mit Notfällen herum. Die Lieferquote des Engineering-Teams ist um mindestens 50 % gestiegen. Wir bringen ständig neue Produkte auf den Markt und können die zusätzliche Zeit dazu nutzen, strategische Partnerschaften und Integrationen auszuweiten.
Unternehmen wie unseres müssen davon wegkommen, den Infrastrukturzustand, den Transaktionsverlauf und die UX manuell im Blick behalten zu wollen. Stattdessen sollten unsere Systeme so weit automatisiert sein, dass sie uns sagen, was los ist, und uns dabei helfen, unseren Fokus auf das Wesentliche zu lenken. Eine hochleistungsfähige, solide und zuverlässige Infrastruktur ist die Grundvoraussetzung für unser künftiges Marktwachstum.
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.
