Cel: zaprojektować feature flag (flagę funkcjonalności) tak, aby jej wyłączenie było przewidywalnym działaniem operacyjnym, a nie kolejnym źródłem awarii.

Scenariusz: przycisk „Wyłącz” nie wystarcza

Fikcyjny scenariusz edukacyjny. Portal obsługuje wnioski. Nowy mechanizm automatycznego uzupełniania danych działa dla 10% użytkowników. Zespół korzysta z feature flag new-prefill i plan zwiększenia udziału do 50%. Po godzinie rośnie liczba błędnych wniosków. Operator wyłącza feature flag, ale część procesów nadal korzysta z zapamiętanej decyzji, a kolejka zawiera już zadania uruchomione według nowej logiki.

Feature flag steruje wyborem ścieżki kodu, lecz nie cofa skutków wcześniej wykonanych operacji. Dlatego sama możliwość zmiany wartości flagi nie jest jeszcze planem wycofania zmiany.

Trzy decyzje przed wdrożeniem

  1. Co dokładnie przełączamy? Określ punkt oceny feature flag: wejście do procesu, każde żądanie czy konkretne działanie. Dla jednego wniosku wynik powinien być spójny. Jeżeli wariant zostaje przypisany na początku procesu, zapisz identyfikator wariantu przy instancji procesu; nie zakładaj, że zmiana feature flag przepisze jego historię.
  2. Co oznacza brak dostawcy feature flags? Ustal zachowanie domyślne dla każdej operacji. W tym przykładzie brak pewnej konfiguracji może wyłączyć automatyczne uzupełnianie, ale nie powinien uniemożliwić ręcznego złożenia wniosku. Nie stosuj zasady „zawsze false” bez analizy skutków dla bezpieczeństwa i dostępności.
  3. Kto i na jakiej podstawie może wyłączyć funkcję? Wskaż właściciela, uprawnienia, próg alarmowy, sposób propagacji zmiany, maksymalny akceptowalny czas reakcji i sposób potwierdzenia, że system faktycznie przeszedł na starą ścieżkę.

Kontrakt operacyjny feature flag

Do opisu feature flag dołącz sześć pól: właściciel, zakres oddziaływania (usługi, użytkownicy, procesy), wartość awaryjna, sygnał wyłączenia (metryka i próg), czas propagacji oraz termin usunięcia feature flag. To propozycja praktyki projektowej, nie wymaganie specyfikacji OpenFeature.

Rozdziel feature flag sterującą udostępnieniem nowej funkcjonalności od trwałego ustawienia biznesowego. Pierwsza powinna mieć plan usunięcia wraz z martwą gałęzią kodu. Drugie jest elementem modelu produktu i wymaga innego procesu zarządzania. Każda dodatkowa kombinacja feature flags zwiększa liczbę możliwych stanów, które trzeba rozumieć i testować.

Pięć prób, które ujawnią fałszywe poczucie kontroli

  1. Wyłącz feature flag podczas aktywnego procesu: sprawdź, czy istniejące i nowe wnioski zachowują się zgodnie z opisanym kontraktem.
  2. Odłącz dostawcę feature flags: zweryfikuj zachowanie przy błędzie, braku konfiguracji i danych nieaktualnych.
  3. Sprawdź opóźnienie propagacji na wszystkich instancjach i w zadaniach asynchronicznych; nie utożsamiaj kliknięcia w panelu ze zmianą zachowania całej usługi.
  4. Zweryfikuj, że uprawniony operator potrafi wykonać zmianę, a nieuprawniony nie może; zapisz kto, kiedy i dlaczego zmienił konfigurację.
  5. Po zakończeniu wdrożenia usuń feature flag i nieużywaną gałąź kodu, a następnie uruchom testy regresji.

Co wynika ze źródeł, a co jest decyzją zespołu?

Specyfikacja OpenFeature opisuje m.in. wartości domyślne przy ocenie feature flags, kontekst oceny oraz zdarzenia dostawcy takie jak PROVIDER_READY, PROVIDER_ERROR i PROVIDER_STALE. Nie definiuje natomiast uniwersalnego czasu propagacji ani biznesowego progu wyłączenia funkcji. Te wartości trzeba ustalić i zmierzyć dla konkretnej implementacji. Pete Hodgson opisuje różne kategorie flag oraz koszt ich długiego utrzymywania; przedstawiony wyżej sześciopolowy kontrakt jest naszą propozycją ich operacyjnego uporządkowania.

Pytanie do architekta: jeżeli o 14:00 trzeba wyłączyć nową funkcję, jaki dowód o 14:05 pozwoli stwierdzić, że nie wpływa już na nowe operacje — i co z tymi rozpoczętymi wcześniej?

Źródła