Sytuacje awaryjne

Podczas utrzymywania rozbudowanego systemu, może dojść do wielu sytuacji, które będą wymagały nagłych działań.

Stosowanie Feature Flag pozwala szybko rozwiązać niektóre z możliwych problemów.

Coś poszło nie tak przy wdrożeniu

Załóżmy, że rozwijaliśmy jakąś funkcję naszego systemu i jesteśmy gotowi przełączyć odpowiednią Feature Flag'ę na produkcji. Chcielibyśmy, aby użytkownicy zobaczyli efekty naszej pracy. Testy automatyczne są zielone, dział QA wykonał dodatkowe testy eksploracyjne. Product Owner potwierdził wdrożenie. Przełączamy stan flagi na produkcji, system działa.

Mija pare minut i dzwoni pierwszy klient z problemem, powoli zauważamy rosnącą liczbę wyjątków w naszej aplikacji. Okazuje się, że system jest w nieprawidłowym stanie. Wygląda to tak, jakby pewnych danych brakowało. Jest to powiązane z naszą nową funkcją, ale przecież "u mnie działa".

Jeśli problem jest na tyle poważny, że użytkownik może uszkodzić swoje dane i w efekcie nie jest w stanie dalej korzystać z naszego systemu, to mamy do czynienia z sytuacją awaryjną. Gdzieś istnieje scenariusz, o którym jeszcze nie wiemy, a który doprowadza system do takiego stanu.

Najlepiej w takim momencie wyłączyć flagę developerską i uznać, że wdrożenie się nie powiodło. Wyłączenie flagi sprawi, że problem nie dotknie większej liczby użytkowników. Zatrzymamy krwawienie. Może się też okazać, że wyłączenie flagi poprawi sytuację klientów, którzy zostali objęci problemem, bo przestaną odczuwać jego skutki. Ich dane się magicznie nie naprawiły, ale być może system nie próbuje już czytać danych, których nam brakuje.

Dopiero po wyłączeniu Feature Flagi możemy usiąść i spokojnie analizować co pominęliśmy. Dopiero teraz analizujemy log'i, stacktrace'y, znajdujemy przyczynę problemu. Później dopisujemy test automatyczny, który potrafi sprawdzić taki scenariusz i dostarczamy rozwiązanie. Gdy poprawka jest gotowa i wdrożona na produkcję należy jeszcze naprawić uszkodzone dane użytkowników objętych problemem i dopiero wtedy można rozważać ponownie przełączenie Feature Flag'i.

Flaga deweloperska staje się flagą operacyjną

Czasami flagi deweloperskiej lepiej nie usuwać.

Często dodając do naszej aplikacji nowe funkcje, wpływamy tym samym na wydajność całego systemu.

Wyobraźmy sobie, że jesteśmy w podsumowaniu koszyka w sklepie internetowym. Poza informacjami o produktach, które wybraliśmy, gdzieś obok wyświetlane są produkty rekomendowane lub w jakiś sposób komplementarne do tych, które już chcemy kupić. Wygenerowanie tej personalizowanej listy rekomendowanych produktów może trwać kilkanaście milisekund.

W czasie małego ruchu w sklepie nikt nie zwróci uwagi na to drobne opóźnienie, ale jeśli okaże się, że mamy nagle kilka tysięcy użytkowników i każdemu musimy wygenerować personalizowane rekomendacje, to może się okazać, że ta funkcja serwisu nie potrafi się odpowiednio skalować.

Może też zawsze dojść do awarii w usłudze generowania rekomendacji i z punktu widzenia naszego systemu, ta funkcja nie będzie dostępna.

Jeśli system jest całkowicie nieużywalny przez to, że zawiodła dodatkowa (być może zewnętrzna) usługa, to dobrze byłoby mieć możliwość jej szybkiego odłączenia w celu minimalizacji strat.

Wtedy możemy zastosować flagę operacyjną, której przełączenie wyłączy daną funkcję w systemie lub zastąpi ją jakąś uproszczoną implementacją. Prawdopodobnie sprzedamy zero rekomendowanych produktów, ale za to sprzedamy cokolwiek, bo klienci będą mogli finalizować swoje zamówienia.

Info

Stosowanie flag operacyjnych nie zawsze musi być powiązane z wyłączaniem funkcji systemu. Czasami ich zmiana powoduje stosowanie innych algorytmów, lepiej dostosowanych do sytuacji, w której się znaleźliśmy.