Wie Veygo mit Serverless das Kundenerlebnis verbessert

Auch zu Spitzenbedarfszeiten und an Feiertagen müssen wir mit der erhöhten Nachfrage Schritt halten. Eine Serverless-Architektur macht das möglich, ohne dass wir den Rest des Jahres für ungenutzte Server zahlen müssen. Veygo bietet kurzfristige Kfz-Versicherungen an, und das Vertrauen unserer Kund:innen gewinnen wir, indem wir ihnen zeigen, wie unkompliziert und schnell der Abschluss einer Kfz-Versicherung sein kann. Bei einer Serverless-Infrastruktur werden die Computing-Ressourcen nach Bedarf hochgefahren, sodass wir unsere IT-Ressourcen optimal anpassen können und unseren Kund:innen jederzeit gerecht werden – ein Muss in einer Branche mit hohem Volumen und geringen Margen.

Wir wollten die Salesforce-Kundendaten aus unseren mobilen und Web-Apps im gesamten Betrieb integrieren und entschieden uns deshalb für Serverless. Schließt jemand zum Beispiel eine Versicherung ab, löst ein Event eine AWS-Lambda-Funktion aus, die Daten an Salesforce sendet, damit Verwaltungsaufgaben durchgeführt werden, beispielsweise um eine Versicherungspolice mit dem entsprechenden Kundenkonto zu verknüpfen. Unser Kundenbetreuungsteam kann das dann im Kundengespräch sofort abrufen und zum Beispiel das Abschlussdatum der Police, eventuelle Policenänderungen, eine Kündigung usw. sehen. So hat das Betreuungsteam alle notwendigen Daten sofort zur Hand und die Kund:innen müssen nicht mehr alles vorlesen.

Die kundenseitigen Anwendungsprogrammierschnittstellen (APIs) sind über das AWS API Gateway verfügbar. Wir haben das Serverless Framework verwendet, um unsere Architektur zu konfigurieren und bereitzustellen. In der Serverless-Konfigurationsdatei haben wir die Endpunkte beschrieben und angegeben, wann AWS-Lambda-Funktionen aufgerufen werden sollen. So ging auch die Integration in AWS WAF für die Sicherheit, AWS X-Ray fürs Tracing und AWS Lambdas zum Erstellen der serverlosen Funktionen ziemlich leicht vonstatten.

Serverless Monitoring mit Dashboards

In serverlosen Umgebungen sind Sie quasi einen Schritt von der Infrastruktur losgelöst. Aber natürlich müssen Sie weiterhin wissen, was in Ihrem Tech-Stack los ist und was Ihre Kund:innen sehen. Wir haben also Dashboards erstellt, um eine schlanke, agile Arbeitskultur zu fördern. Diese Dashboards zeigen uns eine begrenzte Auswahl von Hauptmetriken, anhand derer wir das Kundenerlebnis beurteilen können. Und unser Engineering-Team kann Probleme sofort zielgenau angehen, sobald sie auftreten. Zusätzlich führen wir jede Woche Nachbesprechungen durch, um Bereiche mit Verbesserungsbedarf zu identifizieren. Das Ganze geht nur als Team. Wir tauschen uns über erfolgreiche Problembehebungen aus, damit alle etwas dazulernen. Wir besprechen unsere Infrastruktur und feiern unsere Erfolge.

Um unsere serverlosen Lambda-Funktionen sowie die Metriken in unserem API Gateway zum Monitoring von „500“-Fehlern im Blick zu behalten, verwenden wir das New Relic Monitoring-Plug-in für Lambda-Funktionen. Wir haben Dashboards erstellt, die die Lambda-Funktionen und die API-Aufrufe am selben Ort zeigen, zusammen mit zurückgewiesenen Anfragen. Durch dieses Plug-in werden unsere Engineers über Slack benachrichtigt und können dann im Dashboard nachsehen, welche Lambda-Funktion betroffen ist.

In unserem Kunden-API-Dashboard werden die API-Endpunkte, Anzahl der Anfragen und Fehlerzahl angezeigt. Wird ein Alert generiert, sehen Sie sofort, wo das Problem liegt. Zusätzlich enthält das Dashboard Quicklinks, die direkt zur Lambda-Funktion für einen bestimmten API-Endpunkt führen, sowie die AWS-Lambda-Metriken in New Relic, die Sie einsehen können. Und Logs haben Sie auch. Insgesamt haben Sie damit alles, was Sie brauchen, um jegliche Probleme rund um Ihre Serverless-APIs anzugehen.

4 wichtige Metriken 

Throughput

Deployment-Häufigkeit messen

Im Moment haben wir ca. 140 Releases pro Monat, das möchten wir auf 200 erhöhen. Alle Aufgaben sind in kleine Tickets aufgeteilt, durch die wir uns rasch durcharbeiten können. Es ist unheimlich motivierend, wenn man mehrere kleinere Tasks hat, die man nacheinander erledigen kann – anstelle eines riesigen Bergs an Arbeit, der fast unüberwindbar scheint. Je schneller wir diese kleineren Tickets abarbeiten, desto früher können sie in die Produktion gehen, und das Team hat das Erfolgserlebnis, dass wir ständig etwas liefern. 

We benutzen ein Dashboard auch, um uns selbst zur Rechenschaft zu ziehen. Es zeigt die Anzahl der Releases pro Tag, pro Woche und pro Monat. Zusätzlich verfolgen wir die Releases pro App sowie eventuelle Trends. Diese Dashboards sollen uns ebenfalls dabei helfen, auf 200 Releases monatlich zu kommen.

Vorlaufzeit für Änderungen messen

Unsere Vorlaufzeit für Änderungen beträgt je nach Anwendung zwischen 10 Minuten und einer Stunde. Das möchten wir messen, damit wir sichergehen, dass Code nach dem Commit ohne Verzögerungen in die Produktion geht. Eine Verbesserung der Vorlaufzeit wirkt sich auch positiv auf die Deployment-Häufigkeit aus, da die Engineers nicht lange warten müssen, bevor sie mit der nächsten Aufgabe weitermachen können. Und die MTTR (mittlere Wiederherstellungszeit) profitiert davon ebenfalls, da jede Änderung zur Behebung eines Fehlers schneller in die Produktion geht.

Stabilität

Ausfallrate nach Anpassungen messen

Mit einer hohen Anzahl an Releases wird es immer schwieriger, eine effiziente Liefer-Pipeline sicherzustellen. Wenn man alles in kleinere Aufgaben herunterbricht, das Release-Deployment dann aber zwei Tage in Anspruch nimmt, ist das nicht gerade effizient.

Unser Hauptzweig ist in Git, das die notwendigen Schritte durchführt, um ein Release in die Produktion zu pushen. Dort werden auch alle Tests für Sie durchgeführt – Integrationstests, UI-Tests usw. – bevor es in die Produktion geht. Dazu brauchen Sie eine Qualitätsmetrik, denn Sie müssen sicherstellen, dass Ihre Effizienzbewertung die Agilität der CI/CD-Pipeline nicht beeinträchtigt, z. B. weil fehlerhafter Code gepusht wird, der letztendlich Releases verzögert.

Momentan arbeiten wir daran, intern die ideale Qualitätsmetrik zu ermitteln. Wir gehen derzeit davon aus, dass sie auf der Anzahl fehlgeschlagener Releases basieren könnte, z. B. wenn Sie von 100 Releases zwei rückgängig machen müssen. Qualitätsmetriken reichen aber nicht aus, Effizienz ist ebenfalls ein wichtiger Faktor. Wenn Sie sich nur auf die Release-Anzahl konzentrieren, kann es sein, dass Sie zwar viele Releases haben, aber ein großer Anteil fehlerhaft ist. Deshalb müssen beide Metriken berücksichtigt werden.

MTTR messen

Die MTTR sollte eine Stunde nicht überschreiten. Wir möchten das messen und uns daran halten, denn wenn Transparenz hinsichtlich der Wiederherstellungsdauer herrscht, können wir entscheiden, ob wir Ausgaben für einen zusätzlichen Anbieter rechtfertigen können. Unser Ziel ist es, die MTTR jederzeit zu überwachen, damit wir die richtigen Entscheidungen für eine widerstandsfähige Infrastruktur treffen.