Haben Sie sich jemals gefragt, ob Anbieter von Feature-Flags ihre eigenen Produkte nutzen? Bei Optimizely verkaufen wir nicht einfach nur Feature-Flags – wir leben und atmen sie jeden Tag. Tatsächlich nutzen wir unsere Feature-Experimentierplattform, um neue Funktionen auf unserer Feature-Experimentierplattform bereitzustellen. Ja, das ist meta. Wir verwenden Feature-Flags, um Feature-Flags zu veröffentlichen. 🤯 Das ist kein nettes Extra. So entwickeln wir schneller, stellen sicherer bereit und skalieren Innovationen. Bevor wir uns mit unseren konkreten Anwendungsfällen befassen, wollen wir klären, warum das so wichtig ist:
Wir nutzen unsere Plattform für Feature-Experimente, um neue Funktionen bereitzustellen und so schneller zu entwickeln, sicherer zu implementieren und Innovationen in großem Umfang voranzutreiben. So funktioniert es.
Die meisten Teams gehen bei ihren Feature-Releases unnötige Risiken ein, indem sie:
- direkt in die Produktion pushen und hoffen, dass nichts kaputt geht
- alle Features unabhängig vom Risiko mit demselben Deployment-Prozess behandeln
- Engpässe schaffen, bei denen Produktentscheidungen Engineering-Deployments erfordern
- komplexe Branching-Strategien entwickeln, die die Integration verzögern
Wir wissen das, weil wir es selbst erlebt haben.
Ohne Feature-Flags wird jedes Release zu einem riskanten Spiel, bei dem UX, Entwicklungszeit und Umsatz auf dem Spiel stehen.
Wie genau nutzt Optimizely unsere eigene Feature-Flagging-Technologie?
Hier sind drei Beispiele aus der Praxis unseres Entwicklungsteams:
Lernen Sie Optimizely Opal kennen – Ihre unbegrenzte Ressource, die Nutzern hilft, bessere Experimente zu erstellen, Ergebnisse zu analysieren und neue Ideen zu generieren. Opal basiert im Hintergrund auf modernsten LLM-Modellen unserer strategischen Partner wie Google und Microsoft. Aber jetzt wird es interessant.
Wir verwenden Feature-Flags nicht nur, um zu steuern, ob KI-Funktionen aktiviert oder deaktiviert sind, sondern auch, um deren Funktionsweise präzise abzustimmen.
Beispielsweise verwenden wir Feature-Flags, um Folgendes zu steuern:
- Welches LLM-Modell Opal antreibt (Wechsel zwischen Modellen je nach Bedarf)
- Wie diese Modelle konfiguriert sind (Temperatur, Token, Parameter)
- Welche Prompt-Vorlagen wir verwenden
- Welche Benutzersegmente Zugriff auf welche KI-Funktionen erhalten
Bei der Instrumentierung eines solchen Feature-Flags besteht ein Ansatz darin, die Konfiguration des LLM für jede Variante fest zu kodieren.
Das Problem? Jede Änderung erfordert den Eingriff von Entwicklern und führt so zu Engpässen, wenn es auf schnelles Handeln ankommt.
Wir gehen anders vor.
Die alte Methode? Fest codierte Konfigurationen = langsame Iteration.
Unsere Methode? Dynamische Flag-Variablen = volle Kontrolle, keine Deployments.
Dieser Ansatz ermöglicht es unserem Produktteam, das Verhalten der KI ohne Abhängigkeiten von der Entwicklung zu ändern. Wir können verschiedene Eingabeaufforderungen testen, Modelle wechseln und Parameter über unser Feature-Experimentier-Dashboard anpassen – ganz ohne Codeänderungen.
Das führte zu Folgendem:
- Deutlich schnellere Umsetzung von der Idee bis zur Produktion von KI-Funktionen
- Mehr Experimente, die von Produktteams mit denselben Entwicklungsressourcen durchgeführt werden können
- Weniger nächtliche Anrufe bei der Entwicklungsabteilung (Gott sei Dank für die Not-Aus-Funktion 💙)
Aber es gibt einen noch wichtigeren Vorteil: Schlaf.
Unsere Entwickler werden nicht mehr nachts angerufen, um dringende Probleme mit neuen KI-Funktionen zu beheben, da wir problematische Funktionen sofort über unser Feature-Flag-Dashboard deaktivieren können.
Sprechen wir über die Angst vor dem Launch.
Kennt ihr das Gefühl, wenn man kurz vor der Veröffentlichung einer wichtigen Funktion steht und auf die Flut von Supportanfragen wartet? Diese „Launch-Day-Angst“? Ja, wir vermissen es auch nicht.
Wir verwenden Feature-Flags, um Canary-Tests für schrittweise, datenbasierte Rollouts durchzuführen, die riskante Releases in sichere, skalierbare Markteinführungen verwandeln.
Als wir unser Custom Flags Dashboard veröffentlichten, eine bedeutende Änderung der Kernfunktionalität, haben wir es nicht einfach allen gleichzeitig zur Verfügung gestellt.
Stattdessen sind wir wie folgt vorgegangen:
- Zuerst haben wir es 5 % unserer Kunden (hauptsächlich kleinere Accounts) zur Verfügung gestellt.
- Wir haben Fehlerraten, Leistungskennzahlen und Nutzerfeedback überwacht.
- Wir haben die Verfügbarkeit schrittweise auf 20 %, dann 50 % und schließlich 100 % erhöht.
- Wir haben die Kunden vorab benachrichtigt, bevor sie die Änderung erhielten.
Dieses Vorgehen war sowohl vorsichtig als auch notwendig. Da unsere Plattform als kritische Infrastruktur für die Feature-Releases unserer Kunden dient, könnten sich Störungen auch auf deren Nutzer auswirken.
Bei der Migration unserer gesamten Datenpipeline zur Google Cloud Platform (GCP) haben wir Feature Flags intensiv genutzt, um den Übergang zu steuern. Canary-Tests sind aber nicht nur für Frontend-Änderungen gedacht. Wir haben sie auch für die schrittweise Einführung von Infrastruktur-Updates eingesetzt und so das Risiko während der Bereitstellung minimiert.
Durch die Verwendung von Feature Flags zur Steuerung der Migration konnten wir:
- Risikominderung: Wir konnten bei Leistungseinbußen sofort zum vorherigen Zustand zurückkehren.
- Geschäftskontinuität: Unsere Kunden sind auf die kontinuierliche Datenverarbeitung angewiesen.
- Validierung im großen Maßstab: Wir konnten vor der vollständigen Implementierung überprüfen, ob die neuen Systeme die reale Last bewältigen.
Wir haben diese umfangreiche Infrastrukturmigration trotz der Migration von Milliarden von Ereignissen täglich mit nur wenigen von Kunden gemeldeten Vorfällen abgeschlossen.
Was lernen wir daraus? Je größer die Änderung, desto wichtiger sind Feature-Flags zur Risikominimierung.
Manchmal geht etwas kaputt (es ist Software, das verstehen wir).
Aber es gibt einen gewaltigen Unterschied zwischen „Wir untersuchen das Problem und werden in Kürze eine Lösung bereitstellen…" vs. „Wir haben es deaktiviert. Erledigt.“
Not-Aus-Schalter sind unerlässlich, weil sie Produktionsvorfälle von hektischen Notfällen in kontrollierte, methodische Reaktionen verwandeln.
Bei Optimizely hat jede Funktion einen Not-Aus-Schalter – ein Feature-Flag, mit dem wir sie sofort deaktivieren können. Keine Codeänderungen. Keine Bereitstellungen. Kein Stress.
Unser Datendatei-Erstellungsdienst stellt sicher, dass Flag-Updates die Endbenutzer in Sekundenschnelle erreichen und damit Streaming-Diensten ohne die komplizierte Infrastruktur Konkurrenz machen.
Wenn wir Probleme durch unsere Überwachungssysteme erkennen, können wir die problematische Funktion sofort deaktivieren, ohne Zeitdruck untersuchen und während der normalen Arbeitszeit eine geeignete Lösung bereitstellen. Keine nächtlichen Notfalleinsätze mehr.
Diese Funktion ist aus mehreren Gründen besonders wichtig für unser Unternehmen:
- Vertrauenserhalt: Als Plattform, die die Kundenerfahrung ermöglicht, ist die Minimierung von Ausfallzeiten unerlässlich.
- Globale Auswirkungen: Mit Kunden in verschiedenen Zeitzonen gibt es nie einen „guten Zeitpunkt“ für einen Ausfall.
- Komplexe Abhängigkeiten: Funktionen interagieren oft auf unerwartete Weise, und eine schnelle Isolierung hilft bei der Diagnose.
Flags sind jedoch kein Allheilmittel…
Funktionsflags ersetzen keine solide Rollback-Strategie.
Wir verwenden unser Produkt, um Updates für sich selbst zu veröffentlichen („Flags auf Flags“). Im schlimmsten Fall, wenn ein fehlerhaftes Feature die Benutzeroberfläche unzugänglich macht, könnten wir das Feature nicht remote deaktivieren. Deshalb pflegt unser Entwicklungsteam neben Feature-Flags auch robuste Rollback-Prozesse, wodurch wir mehrere Schutzebenen schaffen. Dieser mehrschichtige Ansatz ist unerlässlich, wenn man kritische Infrastruktur entwickelt, auf die andere angewiesen sind.
Die oben genannten Anwendungsfälle – von KI-Feinabstimmung über Canary-Tests bis hin zu Kill-Switches – zeigen, dass Feature-Flags nicht nur ein Entwicklungswerkzeug sind. Sie ermöglichen eine erfolgreiche Produktstrategie. Durch die Trennung von Deployment und Release können wir: schneller vorankommen: Code kontinuierlich in die Produktion bringen, ohne unfertige Features preiszugeben. Mehr experimentieren: Ideen mit echten Nutzern testen, bevor wir sie endgültig implementieren. Risiken reduzieren: Die Offenlegung von Fehlern begrenzen und sofortige Rollback-Optionen bereitstellen. Produktteams stärken: Nicht-technischen Stakeholdern die Kontrolle über Feature-Rollouts geben. Für unser Team haben Feature-Flags die Herangehensweise an Releases grundlegend verändert. Statt aufdringlicher, risikoreicher Produkteinführungen betrachten wir Releases heute als Regler, den wir schrittweise aufdrehen und dessen Auswirkungen wir dabei messen können.
„Feature Flags ermöglichen uns schnelles Handeln, ohne etwas kaputt zu machen. Sie sind unser Sicherheitsnetz und unsere Geheimwaffe.“
— Britt Hall, Senior Director, Produktmanagement
Mit Blick auf die Zukunft sehen wir, wie sich Feature-Flags in mehreren wichtigen Aspekten weiterentwickeln:
- Essenzielle Not-Aus-Schalter für autonome KI: Da Unternehmen von Funktionen, die die Benutzerfähigkeiten erweitern, zu Funktionen übergehen, die diese vollständig automatisieren (wie Agenten, die selbstständig Ziele erreichen), werden Feature-Flags zu entscheidenden Not-Aus-Schaltern. Wenn Ihre KI zunehmend autonom agiert, wird die Fähigkeit, problematisches Verhalten sofort zu deaktivieren, zu einer unerlässlichen Voraussetzung.
- KI-Sicherheit durch kontinuierliche Überwachung und Anpassung: KI-Sicherheit ist ein aktives Forschungsgebiet. Insbesondere im B2C-Bereich haben die Nutzer unterschiedliche Hintergründe, weshalb es wichtig ist, das Potenzial der KI zur Verstärkung identitätsbasierter Vorurteile (Alter, Geschlecht usw.) zu überwachen. Feature-Flags ermöglichen es Teams, KI-Modelle in Echtzeit anzupassen, sobald besorgniserregende Muster auftreten.
- Komplexitätsmanagement in der KI-gestützten Entwicklung: Während KI hervorragend darin ist, Code für neue Projekte zu schreiben, hat sie Schwierigkeiten, die Komplexität etablierter, umfangreicher Codebasen zu verstehen. Heute eignet sich KI hervorragend für Aufgaben wie das Schreiben von Unit-Tests. Doch mit zunehmender Komplexität der Systeme werden Tools wie Feature-Flags unerlässlich für sicheres Testen, Bereitstellen und Iterieren – insbesondere in einer KI-gesteuerten Welt.
- KI-Modelle ohne zusätzlichen Entwicklungsaufwand testen: Wenn Unternehmen ihre eigenen KI-Funktionen entwickeln, ermöglichen Feature-Flags das Testen verschiedener KI-Modelle ohne zusätzliche Codeänderungen. Nach der Implementierung des Flags können Sie direkt über Ihr Feature-Experimentier-Dashboard und ohne zusätzlichen Entwicklungsaufwand evaluieren, welche Modelle unter realen Bedingungen am besten abschneiden.
Wenn Sie Feature-Flags noch nicht verwenden oder diese nur für einfache Ein-/Ausschalter nutzen, erfahren Sie hier, wie Sie sie optimieren können:
- Beginnen Sie mit den risikoreichsten Features: Identifizieren Sie, wo Sie am dringendsten Not-Aus-Schalter benötigen.
- Fügen Sie Ihren Flags Variablen hinzu: Steuern Sie nicht nur, ob ein Feature aktiviert ist, sondern auch, wie es funktioniert.
- Klare Zuständigkeiten festlegen: Legen Sie fest, wer welche Flags wann aktivieren oder deaktivieren darf.
- Rollout-Muster erstellen: Erstellen Sie Vorlagen für verschiedene Release-Typen (hohes vs. niedriges Risiko).
- Flags mit Observability verknüpfen: Stellen Sie sicher, dass Sie in APM-Plattformen wie Datadog identifizierte Probleme schnell mit dem entsprechenden Flag korrelieren können. Änderungen.
- Flag-Governance einführen: Prozesse zum Erstellen, Überprüfen und Entfernen von Flags erstellen, um technische Schulden zu vermeiden.
Der häufigste Einwand betrifft technische Schulden: „Werden all diese Flags nicht unseren Code unnötig aufblähen?“
Das ist zwar eine berechtigte Sorge, aber wir haben festgestellt, dass strategische, langlebige Flags enorm wertvoll sind. Erwägen Sie die Implementierung permanenter Flags in Bereichen, in denen Sie kontinuierlich experimentieren, wie z. B. auf Ihren Landingpages im oberen Bereich des Verkaufstrichters oder im Checkout-Prozess. Mit Flag-Variablen können Sie jeden Aspekt dieser stark frequentierten Bereiche ohne Codeänderungen steuern.
Dieser Ansatz ermöglicht „unbegrenztes A/B-Testing“ – die Durchführung iterativer Experimente ohne Abhängigkeiten von der Entwicklung. Testen Sie zunächst, was für alle am besten funktioniert, und führen Sie dann gezielte Tests für besonders wertvolle Kundensegmente durch. Das Ergebnis ist eine kontinuierlich optimierte Benutzererfahrung, die sich mit Ihren Geschäftsanforderungen weiterentwickelt und über Ihr Feature-Flag-Dashboard verwaltet wird.
Wir bei Optimizely haben aus erster Hand erlebt, wie Feature-Flags die Entwicklung von einer Reihe großer, stressiger Launches in einen reibungslosen, kontinuierlichen Prozess mit kontrollierten Rollouts und datengestützten Entscheidungen verwandeln.
Möchten Sie sehen, wie Feature-Flags den Entwicklungsprozess Ihres Teams verbessern können?
👉 Testen Sie Feature-Experimente kostenlos – Erhalten Sie lebenslang kostenlose Feature-Flags!
Oder, wenn Sie neugierig sind, wie andere Unternehmen Feature-Flags intelligenter einsetzen, sehen Sie sich unsere Kundengeschichten an. Und wenn ihr Flaggen auf eine coole Art und Weise verwendet, lasst uns darüber reden. Wir würden uns freuen, von euch zu hören.