> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2020/w29-business-metrics-monitoring-and-end-to-end-canary-releases.md).

# W29-Geschäftskennzahlen überwachen und durchgängige Canary-Releases

Der Produktionsvorfall bei Meituan Payments am Mittwoch hat bei mir zwei weiterführende Überlegungen ausgelöst.

Zunächst ein kurzer Rückblick. Ich war an nahezu allen entscheidenden Phasen beteiligt, von der Entdeckung über Reaktion und Diagnose bis zur Beseitigung der Auswirkungen. Obwohl Umfang und Folgen letztlich nicht besonders schwerwiegend waren, zeigt der Rückblick entlang des gesamten Ablaufs offene Risiken. **In gewisser Weise wurden unsere eigenen systemischen Risiken sichtbar. Daraus müssen wir unbedingt lernen.**

* **Entdeckung und Reaktion waren passiv und langsam.** Betroffen war der Onlinebanking-Zahlungskanal. Nachdem Nutzer zum Onlinebanking weitergeleitet worden waren, warteten die vor- und nachgelagerten Systeme auf die Erfolgsmeldung des zentralen Zahlungsdienstes. Die Störung im Zahlungsverlauf trat jedoch beim Onlinebanking auf. Weder Frontend noch Backend des Checkouts konnten sie erkennen. So erreichte uns das Problem erst über Kundenmeldungen an den Geschäftsbereich, die dieser an den Checkout weitergab. Als am Mittwochnachmittag viele Meldungen eingingen, wussten wir weder, wie lange das Problem bestand, noch, mit welcher Version es eingeführt worden war. Das erschwerte die Diagnose zusätzlich.
* **Die Diagnose verlief ungeordnet und chaotisch.** Weil die verursachende Version unbekannt war, untersuchten wir die gesamte Kette vom Frontend bis zum letzten nachgelagerten Dienst. Alle Rollen wurden einbezogen, die Situation war unübersichtlich. Die erste Reaktion auf einen Vorfall sollte sein, den Schaden durch einen schnellen Rollback zu begrenzen. Doch niemand wusste, an welcher Stelle, zu welchem Zeitpunkt und mit welcher Version der Fehler eingeführt worden war. Deshalb dauerte seine Eingrenzung recht lange.

Daraus ziehe ich zwei Schlussfolgerungen.

* **Erstens müssen wir die Überwachung von Geschäftskennzahlen entschlossen vorantreiben.** Die wichtigste Kennzahl im Zahlungsverkehr ist die **Zahlungserfolgsquote**. Anfangs verstand ich den Nutzen einer Echtzeitüberwachung dieser Kennzahl nicht wirklich. Dieser Vorfall hat mir den Antrieb gegeben, sie voranzubringen. Bei Abhängigkeiten von Dritten, etwa Weiterleitungen zum Onlinebanking, zu WeChat oder Alipay, erkennen wir deren Störungen nicht selbst. Nur eine Echtzeitüberwachung der Zahlungserfolgsquote kann sie sichtbar machen. Die B2B-Zahlungserfolgsquote wird derzeit in einem D+1-Bericht erzeugt, also am Folgetag. Es gibt weder Echtzeitdaten noch ein Monitoring. **Für ein Echtzeitmonitoring gibt es zwei Wege.** Einer wäre, das Checkout-Backend und das Datenteam zum Aufbau der nötigen Fähigkeiten zu bewegen. Das haben wir bereits versucht, damals fehlte dort der Antrieb. Der Vorfall könnte ihre Haltung verändert haben. Der andere wäre ein eigener Aufbau im Frontend über raptor. Über selbst definierte zusammengesetzte Kennzahlen könnte das Frontend Veränderungen der Zahlungserfolgsquote gegenüber der Vorperiode überwachen. Die absoluten Frontend-Werte wären zwar nicht exakt, für eine rechtzeitige Problemerkennung würden sie aber reichen. **Der Aufbau des Monitorings im Checkout-Frontend wird ein Schwerpunkt der Q3-Planung.**
* **Zweitens müssen wir durchgängige Canary-Releases für B2B-Zahlungen voranbringen.** Nach dem Vorfall richtete Meituan Payments eine Arbeitsgruppe zur Verbesserung von Monitoring und Alarmierung ein. Diese Gelegenheit können wir nutzen, um Canary-Releases über Frontend und Backend hinweg anzustoßen. Das Checkout-Frontend hat derzeit zwei Möglichkeiten. Erstens eine Aufteilung nach den Endziffern der Bestellnummer tradeno. Dann kann derselbe Nutzer bei mehreren Bestellungen allerdings in unterschiedlichen Checkout-Versionen landen, was die Nutzung erheblich beeinträchtigt. Zweitens können wir nach dem Ausrollen auf Canary-Instanzen bestimmte Nutzer auf eine Freigabeliste setzen und in Produktion prüfen. Nach erfolgreicher Prüfung folgt der vollständige Rollout. Beide Lösungen sind nicht optimal. **Ich hoffe, in Q3 eine durchgängige Canary-Auslieferung anhand einer eindeutigen Nutzerkennung aufzubauen. Sie soll künftige Iterationen sicher und reibungslos machen und zugleich die Grundlage für A/B-Tests schaffen.**