Bildquelle: Pexels / https://www.pexels.com/photo/257736/
Neue Funktionen brauchen einen gut sichtbaren Ausschalter
Neue Funktionen gehen heute oft nicht mehr als ein großer Schalter für alle Nutzer live. Sie werden für einzelne Teams, Kundengruppen, Standorte oder interne Testkreise freigegeben. Das klingt nach einem Entwicklungsthema. Im Betrieb entscheidet diese Technik aber darüber, ob eine riskante Änderung kontrolliert bleibt oder ob Support, Fachbereich und Nutzer plötzlich vor einem schwer erklärbaren Verhalten stehen.
Für ITSM-Generalisten ist der wichtigste Begriff dabei der Feature Flag. Gemeint ist ein steuerbarer Schalter in der Software. Er kann eine Funktion aktivieren, begrenzen oder wieder ausschalten, ohne dass sofort ein kompletter neuer Softwarestand ausgerollt werden muss. Solche Schalter können Releases entspannen, brauchen aber klare Regeln, damit sie nicht zu versteckten Betriebsrisiken werden.
Der Schalter ist nur so gut wie seine Zuständigkeit
Atlassian beschreibt Feature Flags als Möglichkeit, Funktionen getrennt vom Code-Deployment zu veröffentlichen und gezielt zu steuern. Genau diese Trennung ist nützlich. Sie kann aber auch eine Lücke öffnen. Wer darf eine Funktion einschalten. Wer darf sie wieder ausschalten. Wer prüft, welche Nutzergruppe betroffen ist. Wer informiert den Service Desk, bevor Rückfragen kommen.
Ein Feature Flag ohne Besitzer ist für den Betrieb schwer kontrollierbar. Im Fehlerfall reicht es nicht, dass irgendein Entwicklungsteam den Schalter kennt. Die Organisation braucht eine eindeutige Rolle, eine Kontaktkette und eine Entscheidungsschwelle. Sonst bleibt während einer Störung unklar, ob ein Problem durch Infrastruktur, Daten, Nutzerrechte oder eine gerade aktivierte Funktion ausgelöst wurde.
Kontrollierte Freigabe ersetzt keine Betriebsfreigabe
Feature Flags ermöglichen kleine Freigabeschritte. Eine Funktion kann zuerst intern getestet werden, danach mit wenigen Nutzern, später mit größeren Gruppen. Das reduziert Risiko, wenn Messwerte, Supportsignale und Rückmeldungen wirklich beobachtet werden. Ohne diese Beobachtung wird aus dem kontrollierten Rollout nur eine unsichtbare Veränderung im Alltag.
Für IT Service Management zählt deshalb nicht nur die technische Fähigkeit zum Umschalten. Entscheidend ist die Frage, welche Servicewirkung erwartet wird. Ändert sich ein Arbeitsablauf. Gibt es neue Fehlermeldungen. Können Nutzer alte und neue Oberfläche parallel sehen. Wird der Service Desk vorab informiert. Gibt es einen kurzen Textbaustein für Rückfragen. Erst diese Punkte machen die Freigabe betrieblich sauber.
Der Rückweg muss vor dem Start feststehen
Ein großer Vorteil von Feature Flags ist der schnelle Rückweg. Eine fehlerhafte Funktion kann oft deaktiviert werden, ohne dass das gesamte System zurückgesetzt werden muss. Dieser Vorteil entsteht aber nur, wenn der Rückweg vorbereitet ist. Der Schalter muss bekannt sein, erreichbar bleiben und getestet werden. Außerdem muss klar sein, ob das Abschalten Daten, laufende Vorgänge oder Nutzerberechtigungen beeinflusst.
Martin Fowler beschreibt Feature Toggles als Technik, mit der verschiedene Codepfade zur Laufzeit gesteuert werden können. Für den Betrieb bedeutet das: Ein Rückschalter ist kein Ersatz für Denken. Manche Funktionen schreiben Daten, ändern Prozesse oder erzeugen neue Abhängigkeiten. Dann reicht ein einfaches Ausschalten nicht aus. Der Rückweg braucht eine fachliche Prüfung und eine klare Kommunikation.
Dokumentation schützt vor alten Schaltern
Feature Flags haben eine zweite Schwäche. Sie können liegen bleiben. Ein Schalter, der nur für einen kurzen Rollout gedacht war, bleibt dann dauerhaft im System. Das erschwert Tests, Fehlersuche und Sicherheitsbewertung. Nach Monaten weiß niemand mehr sicher, ob der Schalter noch gebraucht wird, welche Nutzergruppe daran hängt und ob ein Entfernen riskant wäre.
OpenFeature verfolgt einen offenen Standardansatz für Feature-Flagging und beschreibt unter anderem Anbieter, Auswertungslogik und die Einbettung in Anwendungen. Solche Standards helfen bei Technik und Integration. Die Betriebsdisziplin ersetzen sie nicht. Jede Organisation braucht zusätzlich ein Ablaufdatum, eine Dokumentation und eine regelmäßige Prüfung alter Flags.
Der Service Desk braucht verständliche Symptome
Für Nutzer ist es egal, ob eine Funktion per Release, Konfiguration oder Flag verändert wurde. Sie sehen nur, dass eine Schaltfläche erscheint, eine Maske anders reagiert oder ein Prozess plötzlich einen anderen Schritt verlangt. Der Service Desk muss solche Änderungen erklären können. Dazu braucht er keine tiefen Entwicklerdetails, sondern eine kurze, verständliche Einordnung.
Hilfreich ist eine einfache Betriebsnotiz pro relevanter Freigabe. Welche Funktion wurde aktiviert. Welche Nutzergruppe ist betroffen. Welche sichtbaren Änderungen gibt es. Welche Fehlerbilder sind erwartbar. Wann wird zurückgeschaltet. Wer entscheidet. Wo wird der Status dokumentiert. Diese Notiz spart im Ernstfall Zeit, weil Support, Betrieb und Entwicklung mit derselben Lage arbeiten.
Eine kleine Prüfliste verhindert stille Risiken
Vor jeder größeren Freigabe per Feature Flag sollte eine kurze Prüfliste stehen. Der Flag hat einen Besitzer. Der Zweck ist dokumentiert. Die betroffene Nutzergruppe ist klar. Der Service Desk kennt die sichtbaren Änderungen. Messwerte und Rückmeldungen werden beobachtet. Der Rückweg wurde getestet. Das Ablaufdatum ist gesetzt. Nach dem Rollout wird entschieden, ob der Schalter entfernt oder in den normalen Betrieb übernommen wird.
Diese Punkte machen Feature Flags nicht langsamer. Sie machen sie verlässlicher. Gerade weil der technische Schalter schnell ist, muss die Organisation vorher klären, welche Wirkung er im Service hat. Dann wird aus Feature-Flagging kein versteckter Sonderweg, sondern ein nützliches Werkzeug für sichere, schrittweise Veränderung.
Fazit
Neue Funktionen brauchen nicht nur einen schnellen Start, sondern auch einen klaren Ausschalter. Feature Flags können Releases entlasten, Risiken begrenzen und Störungen schneller entschärfen. Dafür müssen sie im ITSM-Alltag sichtbar sein. Zuständigkeit, Rückweg, Supportinformation und Ablaufdatum entscheiden darüber, ob der Schalter wirklich Kontrolle schafft oder nur eine weitere unbekannte Variable im Betrieb wird.
