Experimentieren: Was bringt es den Backend-Entwicklern?
Ein Interview mit Tech Lead, Frank Hu, über die Vorteile des Experimentierens mit Funktionen, die Ihre Benutzer nicht sehen können.


Hier bei Optimizely nutzen die Produkt- und Technikteams das Experimentieren in ihren täglichen Arbeitsabläufen. Es ist so eng mit dem Unternehmen verwoben, dass man leicht vergisst, dass das Experimentieren nicht für jedes Team an erster Stelle steht. Ich habe kürzlich eine Frage von einem Backend-Entwickler gehört, der in einem anderen Unternehmen arbeitet. Die Frage lautete: "Sind A/B-Testing und Experimentieren nicht nur dazu da, Conversions zu fördern? Wie würde ich sie bei den Dingen einsetzen, an denen ich im Hintergrund arbeite und die ein Benutzer nicht sehen kann?"
Ich zählte mehrere Dinge auf, die man in diesem Szenario testen könnte: Algorithmus-Optimierungen, API-Verbesserungen, Architektur-Frameworks und Migrationen. Das sind alles Gelegenheiten zum Experimentieren, um die Auswirkungen von Änderungen zu messen, die Sie einführen, unabhängig davon, ob die Arbeit direkte Auswirkungen auf die Benutzeroberfläche hat oder nicht.
Das Ziel eines Backend-Experiments könnte sein, die Verbesserung der Latenzzeit oder des Speichers zu messen. Nicht alle Tests sind darauf ausgerichtet, Klicks, Käufe und Engagement direkt zu fördern. In vielen Fällen besteht das Ziel eines Tests vielleicht nur darin, die Vorher-Nachher-Szenarien zu quantifizieren.
Travis Beck, ein Ingenieur bei Optimizely, schrieb einen Blogbeitrag, in dem er ein Experiment zur Verbesserung der Backend-Performance vorstellte. Ich wollte mehr über diese Art von Experimenten und die Denkweise der Ingenieure, die sie durchführen, erfahren. Ich habe mich mit Frank Hu, einem Senior Software Engineer bei Optimizely, zusammengesetzt, um herauszufinden, was in einem Backend-Experiment steckt und was dabei herauskommen könnte.
Perri: Hallo Frank, vielen Dank, dass Sie sich die Zeit für ein Gespräch mit mir nehmen. Ich hatte gehofft, Sie könnten mir ein wenig über Ihren technischen Hintergrund und Ihre Rolle hier bei Optimizely erzählen?
Frank: Sicher. Bevor ich zu Optimizely kam, war ich Gründungsmitglied eines Y Combinator-Startups namens MailTime, einer mobilen Lösung zur Modernisierung der Art und Weise, wie Menschen mit E-Mails umgehen. Betrachten Sie es als eine Art Instant Messaging-Schnittstelle für E-Mails. Danach kam ich zu Optimizely. Ich bin jetzt seit zweieinhalb Jahren hier.
Angefangen habe ich als Ingenieur in unserem Monetarisierungsteam, wo ich mich um die Zuordnung von Funktionen zu unseren Preisplänen gekümmert habe. Jetzt bin ich der technische Leiter unseres Dateninfrastrukturteams und verantwortlich für alle Ereignisdaten, die unsere Kunden an Optimizely senden. Das sind etwa 10 Milliarden Ereignisse pro Tag, die wir in Echtzeit zurücksenden, um sie in Experiment-Berichten für unsere Kunden zu verwenden.
Perri: Welche Erfahrungen haben Sie mit A/B-Testing und Experimentieren gemacht, bevor Sie zu Optimizely kamen?
Frank: Bevor ich an Optimizely teilnahm, haben wir bei meinem Start-up A/B-Testing durchgeführt. Da wir ein viel kleineres Team waren, konzentrierten sich die Experimente hauptsächlich auf die Benutzeroberfläche. Wir hatten unsere eigene Methode entwickelt, mit der wir die Nutzer in ihre jeweiligen Testvarianten einteilen konnten. Mit unserem Analysetool versuchten wir zu verstehen, was passierte, wenn der Test live ging - aber es sagte uns nicht unbedingt, was sich verändert hatte, oder etwas über die statistische Signifikanz. Es erübrigt sich zu sagen, dass das Verständnis der Metriken für den Ingenieur, der sich um die Aufteilung des Traffics und die Erstellung der vollständigen Benutzeroberfläche für jede Variante des Experiments kümmern musste, eine Qual war. Das war ein langwieriger Prozess.
Perri: Erzählen Sie mir von einem der ersten und wirkungsvollsten Experimente, die Sie mit Optimizely durchgeführt haben. Was waren die Ergebnisse?
Frank: Damals, als ich im Monetarisierungsteam von Optimizely war, haben wir die Zuordnung unserer Funktionen zu Abrechnungen und Plänen überarbeitet. Wir haben den Code so umgestaltet, dass jede Funktion ein- und ausgeschaltet werden konnte und für Konten in verschiedenen Tarifen mit Optimizely Full Stack zugänglich war.
Discover Why Forrester Recognized Optimizely as a Leader
Die Umstrukturierung war eine große Sache, denn zuvor hatten die Geschäftsanalysten entschieden, welche Funktionen in welchen Tarifen enthalten sein sollten. Es war kein sehr datengesteuerter Prozess und jedes Mal, wenn wir die Planstruktur ändern wollten, mussten die Ingenieure ein neues Modell in der Datenbank erstellen. Wir hatten über 300 Funktionen. Es war ein großes Projekt und eine Menge Arbeit.
Die Ergebnisse waren die Vorabinvestition wert. Dadurch, dass wir jedes Feature mit Feature Flags aufgeschlüsselt haben, konnten unsere Produktmanager die Planstruktur selbst verwalten, anstatt sich ganz auf die Ingenieure zu verlassen. Und dadurch, dass wir die Änderung als Test ansahen, konnten wir die Daten nutzen, um zu verstehen, wie die Pläne von Anfang an strukturiert sein sollten.
All dies bedeutete eine enorme Zeitersparnis für die Produktmanager, die für die Features verantwortlichen Ingenieure und die für die Code-Releases zuständigen Ingenieure. Es ermöglichte eine asynchrone Zusammenarbeit und reduzierte die Abhängigkeiten bei der Veröffentlichung von Funktionen erheblich. Und schließlich sorgte es für ein neues Maß an Transparenz, da die Mitarbeiter nicht jedes Mal tief in den Code eindringen mussten, wenn sie wissen wollten, welche Funktionen entwickelt und aktualisiert wurden.
Perri: Dient das Experimentieren bei Backend-Prozessen einem anderen Zweck als bei UI-Funktionen?
Frank: Ja, sie sind unterschiedlich. Bei UI-Experimenten wissen Sie wirklich nicht, wie die Auswirkungen oder Ergebnisse aussehen werden. Bei Backend-Prozessen wissen Sie oft, dass die von Ihnen vorgeschlagene Lösung wahrscheinlich besser sein wird als der Status Quo, aber Sie wissen nicht genau, wie viel besser sie sein wird. Durch Experimentieren können Sie feststellen, ob Ihre Lösung fertig ist oder ob Sie noch Arbeit haben, um die gewünschten Ergebnisse zu erzielen.
Im Backend haben Sie es mit komplexen Systemen zu tun, was zwangsläufig bedeutet, dass auch Ihre Tests komplex sind. Wenn Sie z.B. die Einführung eines Microservice im Vergleich zu einem Service Mesh in Erwägung ziehen, haben Sie vielleicht eine vertretbare Theorie, aber woher wollen Sie ohne Tests in der Produktion mit echten Daten wissen, ob es wirklich das Beste in der Praxis ist? Sicher, Sie können Benchmarks und Stichproben verwenden, um verteilte Systeme zu testen. Aber Stichproben sind nicht repräsentativ für die echte Produktionsumgebung. Es ist sehr schwierig, eine Produktionsumgebung zu replizieren.
Statistisch aussagekräftige Experimente, die in der Produktion durchgeführt werden, ermöglichen es Ihnen, die Auswirkungen anhand echter Daten zu erkennen und die Kompromisse zu bewerten.
Perri: Haben Sie einen Rat für Backend-Ingenieure, die anfangen wollen, aber noch nicht regelmäßig experimentieren?
Frank: Nun, die experimentelle Entwicklung ist nicht so einfach wie die Verwendung eines visuellen Editors wie Optimizely Web, mit dem man per Drag & Drop Änderungen an der Benutzeroberfläche zum Testen vornehmen kann. Ich betrachte das Experimentieren als eine neue Art, Code zu refaktorisieren. Sicherlich gibt es einige Parallelen zur testgetriebenen Entwicklung. Und wenn es um Performance-Tuning geht, wird es nur in der Produktionsumgebung gelöst. Full Stack Experimentieren macht es Ihnen leicht, in der Produktion zu testen.
Der letzte Punkt, den ich Ihnen empfehlen würde, wenn Sie mit dem Testen Ihres Produkts beginnen, ist, dass mit zunehmender Komplexität Ihres Systems auch die Komplexität Ihrer Experimente zunimmt. Und das macht es sogar noch wichtiger, die Tests durchzuführen.
Ein experimentierorientierter Ansatz bei der Softwareentwicklung kann enorme Vorteile für die Validierung Ihrer Arbeit, die Aufdeckung der besten Lösungen und die Rationalisierung der effizienten Kommunikation und Prozesse zwischen den Teams haben. Sind Sie bereit, von der Theorie zur Praxis überzugehen? Tauchen Sie ein in die Dokumentationen für Full Stack-Entwickler und erfahren Sie, wie Sie Experimentieren und Feature Management in die Praxis umsetzen können. Suchen Sie nach einer kostenlosen Lösung, mit der Sie noch heute beginnen können? Optimizely Rollouts bietet kostenloses Feature Flagging und wurde mit denselben Full Stack SDKs und der gleichen Plattform entwickelt.