Das unbekannte Unbekannte ans Licht bringen

Meta verfügt über ein Ökosystem von Produkten, die täglich von Milliarden von Nutzer*innen verwendet werden, sei es für soziale Verbindungen oder für geschäftliche Interaktionen. Diese Milliarden von Nutzer*innen verlangen von uns auch, dass wir kontinuierlich – und in immer schnellerem Tempo – neue Funktionen und Verbesserungen für unsere Produkte bereitstellen. Aufgrund der großen Nutzer*innenbasis liefern wir jeden Tag Tausende von Codeänderungen aus, um diese Erwartungen zu erfüllen.

Die kontinuierliche Veröffentlichung einer so großen Anzahl von Produktverbesserungen birgt die Gefahr, dass es zu Rückschritten bei der Anwendungsintegrität kommt, wodurch sich das Nutzungserlebnis verschlechtern kann. Bei Meta verfügen wir über ein ausgeklügeltes System von Präventionstools, um die Veröffentlichung von fehlerhaften Produktänderungen zu verhindern. Diese Präventionstools überwachen verschiedene Produktsignale und erkennen Rückschritte vor der Veröffentlichung von Apps. Diese Signale können in drei Bereiche unterteilt werden: Performance, Zuverlässigkeit (Reliability, funktional und systemisch) und Effizienz. Diese werden zusammen als „PRE“ der Produkte bezeichnet. Prävention beginnt mit der Erfassung verschiedener Beobachtungs- und Analyse-Traces während der Code-Entwicklung. Zusätzlich erfassen Beobachtungs- und Überwachungstools Daten aus der internen Nutzung der Produkte in Vorproduktionsumgebungen. In diesen Vorproduktionsumgebungen werden die Produkte sowohl mit manuellen als auch mit automatischen Qualitätssicherungstools getestet.

Und obwohl diese Mechanismen dazu dienen, die Qualität von Codeänderungen zu bewerten, bevor die Änderungen in die Produktionsumgebung gelangen – und somit Auswirkungen auf die Nutzer*innen zu vermeiden –, kann es vorkommen, dass Änderungen mit Auswirkungen auf die Nutzer*innen es bis in die Produktion schaffen und daher überarbeitet und erneut in die Produktion eingebracht werden müssen. Um die Möglichkeit zu verringern, dass ein Problem eine große Bevölkerungsgruppe betrifft, verwenden wir verschiedene Mechanismen zur inkrementellen Veröffentlichung von Änderungen.

Wenn eine Änderung nicht die von Nutzer*innen erwartete Funktionalität erbringt, definieren wir dies als Rückschritt. Wir verwenden das Wort Signal, um anzuzeigen, dass Nutzer*innen uns wissen lassen, dass etwas nicht ihren Erwartungen entspricht. Wir erfassen Rückschrittsignale so schnell wie systemisch möglich mithilfe von Daten-Insights und instrumentiertem Code und arbeiten dann daran, die Auswirkungen auf die Nutzer*innen zu verringern, indem wir entsprechende Korrekturen bereitstellen. In den Fällen, in denen wir keine eindeutigen Signale von unseren Tools erhalten, verlassen wir uns auf Nutzermeldungen als Signal, dass ein Rückschritt stattgefunden hat. Diese Meldungen erreichen uns über verschiedene Wege. Beispielsweise können Nutzer*innen ihr Telefon schütteln, um ein Problem in dem Anwendungskontext zu melden, in dem sie sich zum Zeitpunkt des Auftretens des Problems befinden.

Um sicherzustellen, dass wir die Anforderungen unserer Kund*innen so schnell wie möglich – manchmal sogar noch am selben Tag – erfüllen, hat Meta stark in eine Reihe von Zuverlässigkeitsprogrammen und -systemen investiert, sodass wir eine umfassende und hohe Reaktionsfreudigkeit sicherstellen können.

Signale können von unseren öffentlichen Nutzer*innen (Einzelpersonen, Unternehmen, Gruppen usw.) oder von internen Nutzer*innen stammen. Wir prüfen die Signale von internen Nutzer*innen sorgfältig, um zu verhindern, dass unerwünschte Änderungen in die Produktion gelangen. Beachte, dass es sich bei den Signalen um Summen handelt, beispielsweise um die Anzahl der Fehler pro Million Nutzer*innen. Signale können auch von automatisierten Testtools und -szenarien, Entwicklungstools (wir warnen Entwickler*innen vor Änderungen, die Laufzeitprobleme verursachen könnten) sowie aus Systemprotokollen und vielen anderen Quellen stammen. Wir verfügen außerdem über Tools, die diese Signale nutzen, um Ursachen schnell zu ermitteln und entsprechende Korrekturen vorzunehmen.

Nachdem ein Rückschritt identifiziert wurde, ermitteln wir schnell die zuständigen Techniker, um Korrekturen anzuwenden und die korrigierte Version zu veröffentlichen. Je nach Komplexität des Rückschritts wenden wir eine Reihe von Methoden an, um die richtigen Techniker zu finden. Beispielsweise nutzen wir Metas Wissen im Bereich maschinelles Lernen (ML). Aufgrund der Funktionsweise von ML ist dies ein kontinuierlicher Prozess, der uns begleitet, während wir neue Funktionen veröffentlichen und unsere Modelle neu trainieren, um mit den ständigen Veränderungen Schritt zu halten.

Und ja, es gibt ein Endgame: Wir beschreiten den ganzen Weg von der Erkennung von Rückschritten über ihre Minderung bis hin zu ihrer Verhinderung und nachhaltigen Eindämmung. Dabei maximieren wir die Reaktionsfreudigkeit, den Return on Investment und die Effizienz.

Im nächsten Abschnitt werden wir genauer darauf eingehen, wie wir mit Sicherheit feststellen, dass ein Rückschritt stattgefunden hat, und wie wir darauf reagieren.

Unbekannte in Bekannte umwandeln und quantifizieren

Wenn wir von Unbekannten sprechen, beziehen wir uns auf einen Fehler, der bei einem*einer Nutzer*in oder in einem System auftritt. Die erste Information über einen möglichen Fehler kann aus verschiedenen Quellen stammen.

• Synthetische Tests der ordnungsgemäßen Funktion unserer Anwendungen und bestimmter Produkte innerhalb dieser Anwendungen.
• Interne Nutzer*innen, die gezielt auf Fehler testen. Dies können unsere speziellen Testteams oder die breitere Nutzer*innenbasis von Meta sein.
• Externe Nutzer*innen, die ein Problem haben und es über den Problemberichtsdialog in unseren Apps melden.

Diese Fehler sind so lange Unbekannte, bis sie als Vorfälle gekennzeichnet werden, die bei Nutzer*innen auftreten. Wenn die Anzahl solcher Fehlermeldungen einen bestimmten Schwellenwert erreicht, betrachten wir einen Fehler als richtig positiven Vorfall, der ein Rückschrittereignis darstellt: Eine Codeänderung hat einen neuen Fehler verursacht und wir müssen schnell handeln, um ihn zu beheben. Es gibt zwei Haupttypen von Meldungen:

• „Bekannte Unbekannte“: Instrumentierter Code erkennt und meldet den Rückschritt. Wir haben eine Reihe von Tools, die uns helfen, dieses Signal zu erzeugen.
• „Unbekannte Unbekannte“: Der Rückschritt wird nicht intern erkannt und wir müssen uns darauf verlassen, dass Nutzer*innen den Rückschritt melden.

Darüber hinaus lassen sich Rückschritte in verschiedene Kategorien einteilen, z. B. Codefehler, Spam-ähnliche Problem oder andere Verstöße gegen die Inhaltsrichtlinien. Wir konzentrieren uns auf den ersten Bereich, in dem wir Probleme mit dem Nutzungserlebnis angehen wollen, die mit Codefehlern zusammenhängen. Wie macht man das, wenn Nutzer*innen Tausende von Problemen melden?

Signale und Insights erzeugen

Um die große Menge an Meldungen zu bewältigen, generieren wir spezifische Signale, die uns auf Probleme aufmerksam machen. Der erste Signaltyp informiert uns bei richtig eingestellten Schwellenwerten darüber, dass tatsächlich ein Vorfall oder ein Rückschritt aufgetreten ist. Beachte, dass je nach Art des Rückschritts mehrere Ereignisse aufgetreten sein können. So kann ein Rückschritt beispielsweise mehrere Produkte betreffen, weil sie auf einer gemeinsamen Codebasis beruhen. Wir suchen nach solchen Gemeinsamkeiten und behandeln sie als einen einzigen Vorfall, um Ressourcen optimal zu nutzen. Das folgende Diagramm ist ein Beispiel dafür, wie wir die Abweichung von der Trendlinie, die auf einen Rückschritt hinweist, visuell erkennen können.

Wir erfassen dann zusätzliche Signale, von denen einige auf die Art des Rückschritts hinweisen, mit dem wir es ggf. zu tun haben. Diese Signale liefern Insights in die mit dem Rückschritt verbundenen Symptome und werden von Algorithmen für maschinelles Lernen generiert, die auf bestimmte Meta-Produkte abgestimmt sind. Die Algorithmen analysieren die Nutzer*innen-Meldungen, um festzustellen, wodurch der Rückschritt verursacht wurde, und somit zu bestimmen, welches Entwicklungsteam ihn am besten beheben kann, indem eine Codekorrektur oder eine andere Maßnahme angewendet wird.

Viele andere Signale werden auch auf der Grundlage der erfassten Protokolldaten generiert. Bei diesen Diagnoseprotokollen kann es sich um clientseitige oder serverseitige Protokolle handeln, die – mit Zustimmung der Nutzer*innen – zur Ermittlung der Ursache erfasst werden. Apps beinhalten Flows zum Einholen der Einwilligung von Nutzer*innen, um zu ermitteln, ob diese Art von Daten auf der Grundlage der Nutzungsberechtigungen erfasst werden darf. Wir berücksichtigen außerdem die Langlebigkeit dieser Daten, um sicherzustellen, dass die geltenden Vorschriften eingehalten werden.

Aus der Kombination der Signale können wir den Rückschritt erkennen und ihn dem geeigneten Produktteam zuweisen, um das Problem schnell zu mindern und das Nutzungserlebnis so wiederherzustellen, das es den Erwartungen entspricht.

Insights werden ebenfalls aus der Gesamtheit der Erkenntnisse abgeleitet. Wir sehen uns die Daten im Hinblick auf gemeinsame Ursachen an und um herauszufinden, ob Änderungen vorgenommen werden müssen, um ein erneutes Auftreten der Rückschritte zu verhindern. Dies ist ein wichtiger Aspekt eines robusten Ansatzes zur Behebung von Problemen mit dem Nutzungserlebnis, da er uns hilft, die Rückschrittfläche im Laufe der Zeit zu minimieren.

Unsere mobilen Apps enthalten nicht nur Navigationspfade, über die Nutzer*innen ein Problem melden können, sondern bieten auch die Möglichkeit, ein Problem durch Schütteln des Geräts anzuzeigen. Auf diese Weise können kontextbezogene Telemetriedaten erfasst werden. Diese Telemetriedaten werden durch Black-Box-Signale aus der App weiter ergänzt. Die Black Box ist wie ein Flugschreiber, der automatisch bestimmte Protokolle (gemäß Einwilligung der Nutzer*innen) über die Vorgänge in der App zum Zeitpunkt der Fehlermeldung aufzeichnet, damit wir das Problem besser diagnostizieren können.

Alle diese Telemetriedaten werden in eine Reihe von Zeitleistenansichten eingefügt, um den Entwicklungsteams zu helfen, die Ursache des Problems zu ermitteln. Aufgrund des schnellen Veröffentlichungsrhythmus unserer Apps sowie von Änderungen an serverseitigen App-Komponenten wäre es ohne diese Funktion schwierig, das Problem genau zu lokalisieren. Telemetriedaten aus einem längeren Zeitraum helfen uns, Muster in den Rückschritten zu erkennen und sie in Zukunft zu vermeiden.

Skalierung auf kleinere Produktflächen

Da wir nun in der Lage sind, präzisere Signale zu erzeugen, können wir einen größeren Teil der Rückschrittfläche angehen, der früher unentdeckt geblieben wäre. Eine Fläche stellt ein bestimmtes Angebot innerhalb eines Produkts dar, z. B. News Feed oder Reels. Dies ist eine Herausforderung, da Produkte nicht nur viele granulare Funktionen haben, sondern auch regelmäßig neue Funktionen eingeführt werden. Somit ist die Rückschrittfläche nicht nur groß, sondern wächst im Laufe der Zeit noch weiter. Daher müssen wir unsere defensiven und offensiven Strategien ständig anpassen.

Skalierung ist nur möglich, wenn mehrere Bedingungen erfüllt sind:

1. Wir benötigen eine genaue Abdeckung und eine korrekte Klassifizierung der bestehenden Produktflächen.
2. Wir müssen die Rückschrittfläche für bestehende Produkte reduzieren (sprich: Prävention).
3. Wir müssen die Reichweite unserer Algorithmen auf neue Produktflächen ausweiten.

Wenn die oben genannten Bedingungen nicht erfüllt sind, laufen wir Gefahr, dass ein „aufgeblähtes“ System entsteht, das aufgrund seiner Größe, Komplexität und Ungenauigkeit nicht verwaltet werden kann. Unsere Bemühungen zielen also darauf ab, ein Gleichgewicht aufrechtzuerhalten und gleichzeitig unser Tagesgeschäft effizient abzuwickeln.

Es geht um mehr als Fehler

Während wir die Rückschrittfläche weiter reduzieren (ohne in unserer Wachsamkeit nachzulassen), konzentrieren wir uns verstärkt auf andere wichtige Bereiche: Prävention und Nutzer*innen-Freundlichkeit.

Bei Prävention geht es um Folgendes:

1. Wie lernen wir aus früheren Rückschritten?
2. Welche Schutzmaßnahmen können wir ergreifen, damit diese Rückschritte nicht wieder auftreten?
3. Wie können wir langfristig sicherstellen, dass die Rückschrittfläche immer kleiner wird?

Wie bereits erwähnt, tragen wir Daten aus früheren Rückschritten zusammen, um aus ihnen zu lernen. Diese Erkenntnisse können beispielsweise in folgende Maßnahmen umgesetzt werden:

1. Einfügen von Markierungen in unseren Code, die uns in der Zukunft schon in der Vorproduktionsumgebung vor möglichen Rückschritten warnen, sodass wir verhindern können, dass eine unerwünschte Änderung in die Produktion gelangt
2. Erhöhen der Testabdeckung auf verschiedenen Ebenen, um solche Rückschritte zu erkennen
3. Ändern des Produkts selbst, um diese Probleme zu beheben

Prävention hilft uns, Rückschritte im Entwicklungszyklus immer weiter nach links zu verlagern und damit die Kosten zu senken. Dies wird dadurch erreicht, dass wir bereits zu einem früheren Zeitpunkt im Entwicklungsprozess – angefangen bei der Codeerstellung und Veröffentlichungszyklen in der Vorproduktionsphase – ausreichend aussagekräftige Signale erhalten. Dies verbessert nicht nur das Nutzungserlebnis, sondern senkt auch die Entwicklungskosten und hilft uns, Ressourcen umzuleiten und für die Entwicklung neuer Produkte einzusetzen.

Wenn wir es schaffen, Rückschritte effizienter zu handhaben, können wir uns stärker auf Probleme konzentrieren, die Nutzer*innen verwirren oder die Nutzer*innen-Freundlichkeit beeinträchtigen. Diese Anliegen sind wichtiger und von höherem Wert, da sie sich auf die Verbesserung von Produkten konzentrieren und nicht auf deren Korrektur. Im Laufe der Zeit sollte das Verhältnis von Problemen mit der Nutzer*innen-Freundlichkeit zu Rückschritten zunehmen und die Gesamtzahl von Problemen mit der Nutzer*innen-Freundlichkeit und von Rückschritten sollte abnehmen.

Letztendlich führt dies zu einem Nutzungserlebnis, das sich sowohl in Bezug auf die Funktionalität als auch auf die Nutzer*innen-Freundlichkeit kontinuierlich verbessert.

Dieser Artikel wurde in Zusammenarbeit mit Bijan Marjan, einem Technical Program Manager bei Meta, verfasst.