Feature-Schalter machen Releases leiser, aber den Betrieb nicht einfacher

Kurz gesagt Feature-Schalter, oft auch Feature Flags genannt, trennen die technische Auslieferung einer Änderung von der sichtbaren Freigabe für Nutzer. Ein Team kann neuen Code bereits produktiv bereitstellen und die Funktion trotzdem nur für bestimmte Gruppen, einzelne Tests oder einen späteren Zeitpunkt aktivieren. Das senkt Druck bei Releases, verschiebt aber Verantwortung in den laufenden Betrieb.

Für ITSM-Generalisten klingt das zunächst nach einer einfachen Entlastung. Weniger große Release-Tage, weniger harte Umschaltmomente und schnellere Rückwege wirken attraktiv. Genau deshalb werden Feature-Schalter in modernen Liefermodellen gern genutzt. Sie erlauben schrittweise Einführung, kontrollierte Tests und ein schnelles Abschalten, falls eine neue Funktion Probleme macht.

Der operative Haken liegt in der zweiten Hälfte der Geschichte. Ein Schalter ist keine Entscheidung. Er ist nur ein technisches Mittel, mit dem Entscheidungen schneller wirken können. Wenn unklar bleibt, wer einen Schalter setzen darf, welche Nutzergruppe betroffen ist, wie lange der Schalter existieren soll und wann alte Schalter wieder entfernt werden, entsteht ein neues Betriebsrisiko.

Ein Feature-Schalter ist mehr als ein Ein-Aus-Knopf

Feature Flags werden in der Softwareentwicklung genutzt, um Funktionen unabhängig vom eigentlichen Deployment zu steuern. Martin Fowler beschreibt solche Feature Toggles als Möglichkeit, unterschiedliche Codepfade gezielt ein- oder auszuschalten. Atlassian ordnet Feature Flags ähnlich ein: Teams können Funktionen stufenweise aktivieren, Tests mit ausgewählten Nutzern durchführen und Risiken bei Änderungen verringern.

Für den Betrieb ist entscheidend, dass diese Schalter nicht nur Entwicklungswerkzeuge sind. Sie verändern, wer wann welche Funktion sieht, wie Fehlerbilder entstehen und wie ein Rückweg im Störfall aussieht. Ein Problem kann dann nicht mehr nur heißen: die neue Version ist kaputt. Es kann auch heißen: die Version läuft, aber ein bestimmter Schalter trifft die falsche Nutzergruppe, hängt an einer alten Annahme oder wurde nach einem Test nie bereinigt.

Kleine Freigaben brauchen klare Rollen

Der große Vorteil von Feature-Schaltern liegt in der feineren Steuerung. Eine Funktion kann erst intern, dann für wenige Kunden und später breiter aktiviert werden. Microsoft beschreibt dieses Prinzip im Zusammenhang mit progressiver Einführung und Experimenten. Aus Managementsicht klingt das nach weniger Risiko. Aus Betriebssicht entsteht aber eine neue Frage: Wer besitzt die Freigabe?

Wenn Produktteam, Entwicklung, Service Desk und Betrieb unterschiedliche Erwartungen haben, wird der Schalter zur stillen Machtstelle. Das Produktteam möchte lernen, ob eine Funktion angenommen wird. Die Entwicklung möchte schnell liefern. Der Betrieb möchte stabile Services und klare Rückwege. Der Service Desk muss Anfragen beantworten können, ohne erst zu erraten, welche Nutzer gerade in welcher Variante stecken.

Darum braucht jeder produktive Feature-Schalter mindestens einen fachlichen Besitzer, einen technischen Besitzer und eine definierte Betriebsabsprache. Diese Absprache muss klären, wer aktivieren darf, wer deaktivieren darf, wie die Änderung kommuniziert wird und welche Messwerte nach der Aktivierung beobachtet werden.

Der Service Desk darf nicht der letzte sein, der davon erfährt

Ein häufiger Fehler entsteht nicht im Code, sondern in der Kommunikation. Eine Funktion wird für eine Teilgruppe aktiviert, Nutzer melden ein anderes Verhalten, der Service Desk findet aber keinen klaren Hinweis im Wissenssystem. Dann sieht dieselbe Anwendung für verschiedene Nutzer unterschiedlich aus, ohne dass der Support den Grund erkennt.

Für ITSM bedeutet das: Feature-Schalter gehören in den Betriebsfluss. Sie müssen in Changes, Release Notes, Support-Hinweisen und Störungsreviews sichtbar sein. Nicht jeder Schalter braucht ein großes Change Advisory Board. Aber jeder Schalter, der Nutzerverhalten, Berechtigungen, Datenflüsse, Abrechnung, Sicherheit oder kritische Prozesse betrifft, braucht nachvollziehbare Information.

Praktisch reicht oft eine kleine Pflichtstruktur: Name des Schalters, Zweck, betroffene Nutzergruppe, Startzeitpunkt, geplanter Endzeitpunkt, Besitzer, Rückweg, Beobachtungswerte und Support-Hinweis. Diese Informationen machen den Unterschied zwischen kontrollierter Einführung und versteckter Änderung.

Alte Schalter werden technische Schulden

Feature-Schalter sind besonders gefährlich, wenn sie nach erfolgreicher Einführung liegen bleiben. Dann wächst die Zahl der Varianten im System. Tests werden schwerer, Fehlerbilder unübersichtlicher und niemand weiß mehr sicher, ob ein alter Schalter noch gebraucht wird. Aus einem Werkzeug für schnelle Lieferung wird ein Schatteninventar.

Deshalb gehört zu jedem Schalter ein Ablaufdatum. Kurz laufende Release-Schalter sollten nach der stabilen Einführung entfernt werden. Länger laufende Berechtigungs- oder Experiment-Schalter brauchen regelmäßige Reviews. Dauerhafte Steuerungen müssen wie Konfiguration behandelt werden, nicht wie vergessene Entwicklungsreste.

Dieser Aufräumteil ist unattraktiv, aber wichtig. Ohne ihn entstehen Verzweigungen, die bei späteren Störungen schwer zu erklären sind. Der Betrieb sieht dann Symptome, die nur in einer bestimmten Schalterkombination auftreten. Genau solche Situationen kosten im Ernstfall Zeit.

Kontrollierte Releases brauchen Beobachtung

Ein Feature-Schalter macht den Release leiser, aber nicht blind. Wer schrittweise aktiviert, muss gleichzeitig prüfen, ob die Aktivierung gut läuft. Dafür braucht es vorher definierte Signale: Fehlerraten, Antwortzeiten, Supportkontakte, Abbruchraten, Logmeldungen, fachliche Erfolgswerte und Rückmeldungen aus dem Service Desk.

Wichtig ist die Verbindung zwischen technischer Messung und Nutzerwirkung. Eine neue Funktion kann technisch stabil laufen und trotzdem den Support belasten, weil Nutzer sie nicht verstehen oder ein Prozessschritt fehlt. Umgekehrt kann ein kleiner technischer Fehler stark wirken, wenn er eine kritische Nutzergruppe betrifft. Feature-Schalter entfalten ihren Wert erst, wenn solche Signale während der Einführung zusammengeführt werden.

Eine kurze Betriebscheckliste

• Hat jeder produktive Feature-Schalter einen fachlichen und technischen Besitzer?
• Ist klar, welche Nutzergruppe betroffen ist und wie der Service Desk das erkennt?
• Gibt es einen definierten Rückweg mit Verantwortlichem und Kommunikationsweg?
• Wurden Beobachtungswerte vor der Aktivierung festgelegt?
• Hat der Schalter ein Ablaufdatum oder einen Review-Termin?
• Werden alte Schalter nach erfolgreicher Einführung wirklich entfernt?

Fazit

Feature-Schalter können Releases entspannen, weil nicht jede Änderung als großer Umschaltmoment sichtbar wird. Für den Betrieb sind sie aber nur dann ein Gewinn, wenn sie mit Verantwortung, Transparenz und Aufräumarbeit verbunden werden. Der eigentliche Reifegrad zeigt sich nicht daran, wie schnell ein Team schalten kann. Er zeigt sich daran, ob Support, Betrieb und Produktseite gemeinsam wissen, was gerade geschaltet ist, warum es geschaltet ist und wann der Schalter wieder verschwindet.

Quellen und Einordnung Martin Fowler zu Feature Toggles, Atlassian zu Feature Flags, Microsoft zu progressiver Einführung und Experimenten sowie GitHub zur kleinen, häufigen Auslieferung im GitHub Flow.