Wie reibungslose Deployments für 10x Banking Wirklichkeit wurden

Banken bieten Kundendienstleistungen, die fast alle von uns in Anspruch nehmen, hinken aber oft hinsichtlich neuer und kundenorientierter Technologien hinterher. 

Bei 10x Banking nutzen wir eine cloudnative Bankplattform für unser Kerngeschäft. Damit können Banken in Echtzeit mit ihren Kund:innen kommunizieren, Produkte in Minutenschnelle veröffentlichen, Daten effektiv nutzen und insgesamt ein vernetztes, einheitliches Kundenerlebnis liefern. Unsere Kerninfrastruktur für Bankgeschäfte basiert auf Amazon Web Services (AWS) und unterstützt einige der weltgrößten Finanzinstitute und deren Millionen von Kund:innen. Wir haben uns zum Ziel gesetzt, die Plattform durch Skalierung kontinuierlich an unseren wachsenden Kundenstamm anzupassen und den Funktionsumfang weiter zu optimieren – bei minimaler Störung. Dank Continuous Delivery – der Bereitstellung von Software in kurzen, sukzessiven Entwicklungszyklen – können wir unseren Kund:innen und deren Endbenutzer:innen jederzeit das bestmögliche und zuverlässigste Nutzungserlebnis bieten. In unserer Branche ein absolutes Muss.

Als Release Managerin bin ich für den Erfolg und die Verlässlichkeit unserer Deployments verantwortlich. Ich muss dafür sorgen, dass Fehlerquoten und mittlere Lösungszeit (MTTR) minimiert werden, um die Konsistenz und Zuverlässigkeit unserer Software stetig zu verbessern. Nachdem ich zu 10x Banking stieß, wurde mir schnell klar, wie wichtig Observability und Monitoring sind – nicht nur, um die allgemeine Performance unserer Technologie im Blick zu behalten, sondern auch um eventuelle Auswirkungen neuer Bereitstellungen oder Updates rasch zu erkennen. Deshalb begannen wir, New Relic zum Erstellen von Deployment-Markern und für das Change Tracking einzusetzen.

Und so haben sich unsere Release-Abläufe im Verlauf des ersten Jahrs mit Deployment-Markern entwickelt:

Konsolidierung von Tools und Datenquellen

Vor New Relic benötigten wir mehrere verschiedene Tools, um Daten aus verschiedenen Bereichen unseres Tech-Stacks zu überwachen und zu erfassen. Das hatte zur Folge, dass die Behebung eventueller Probleme zu viel Zeit in Anspruch nahm: Erstens fiel es uns schwer, die jeweilige Fehlerursache zu ermitteln, und zusätzlich fehlten uns die detaillierten Informationen, die zur effektiven Fehlerbehebung notwendig waren. 

Unsere Gesamtmission ist einfach: Wir möchten, dass die Bankbranche dank technologischer Innovationen floriert. Aber die Toppriorität für jede Bank ist natürlich die Uptime. Ausfallzeiten sind in dieser Branche besonders schwerwiegend und können zu einem Vertrauensbruch führen, da die Endbenutzer:innen sich darauf verlassen müssen, dass sie jederzeit auf ihr Geld zugreifen können. Observability verschaffte uns einen allgemeinen Überblick über unsere Architektur, sodass wir Anomalien schneller aufgreifen und Probleme beheben konnten, bevor sie zu Ausfällen führten. Das hat uns letztendlich auch den Weg zur Continuous Delivery geebnet: Wenn statt riesiger Katastrophen nur hier und da kleinere Problemchen auftreten, kann sich das Team auf die Entwicklung konzentrieren anstatt auf das Verhindern von Desastern. 

Sobald unsere Telemetriedaten in New Relic konsolidiert waren, begannen wir mit dem Change Tracking, um die Auswirkungen von Deployments und Konfigurationsänderungen zu erkennen. Wenn wir jetzt einen raschen Anstieg der Fehlerquoten sehen, können wir die Fehlerursache sofort punktgenau ausmachen und aus dem Weg schaffen, bevor die Kund:innen überhaupt etwas mitbekommen. Mit New Relic können wir zudem selbst festlegen, welche Bereiche unsere Kund:innen sehen und welche nicht. Denn wir sorgen dafür, dass das Backend reibungslos läuft, während unsere Kund:innen für das Frontend verantwortlich sind. 

Der Weg zur Continuous Delivery

Wir müssen Anomalien identifizieren und die mittlere Lösungszeit verringern, das ist klar. Aber unsere eigentliche Mission ist die Entwicklung innovativer Software. New Relic Dashboards bieten uns einen Gesamtüberblick über unseren gesamten Software-Lifecycle und damit die notwendigen fundierten Informationen, damit wir jedes Deployment zum richtigen Zeitpunkt ausrollen können (oder eben auch nicht). Auf den Dashboards sehen wir Deployment-Daten für mehrere Umgebungen gleichzeitig. Das war notwendig, damit alle Beteiligten im gesamten Unternehmen an einem Strang ziehen konnten: Jetzt haben alle die gleichen Informationen und sehen genau, inwieweit sich einzelne Bereitstellungen auf verschiedene Aspekte der Infrastruktur auswirken. 

Bei mehreren Deployments pro Tag schaffen die Deployment-Marker größere Sicherheit und Vertrauen in jedes Release und ermöglichen uns bei Bedarf eine rasche Fehleranalyse. Und die Integration von New Relic und Jenkins macht uns das Leben noch leichter! Dieses OpenTelemetry-Plugin zeigt die Ausführung von Jobs und Pipelines als Distributed Traces an, sodass wir unsere Deployment-Daten mühelos im Blick behalten und unsere Pipeline kontinuierlich verbessern können. Mein Job als Release Managerin ist jetzt dank dieser Transparenz – und unserem Wechsel hin zur Continuous Delivery – um einiges einfacher als früher. 

Release-Management kann im Chaos enden. Oder es kann strukturiert und harmonisch ablaufen. Die Daten, die wir mit New Relic erfassen, sorgen für Klarheit im Chaos und geben uns die notwendigen Performance-Infos in Echtzeit. In einem von rasantem Wandel geprägten Umfeld mit Fokus auf die Continuous Delivery bieten uns diese Metriken einen hilfreichen Einblick in das System als Ganzes. So sehen wir genau, welche Services und APIs jeweils verbessert werden müssen. Der Zustand eines Release lässt sich jederzeit prüfen, sodass wir nutzungsrelevante Probleme proaktiv beheben können.