Google Cloud udostępnia testy wstrzykiwania awarii
27 sierpnia 2026 roku Google ogłosił wersję preview usługi Fault Injection Testing (FIT). Jest to natywna usługa do celowego zakłócania działania zasobów Google Cloud i sprawdzania zachowania aplikacji. Pierwsza wersja ma wąski zakres: może wywołać failover Cloud SQL w konfiguracji wysokiej dostępności albo zdegradować ruch przechodzący przez load balancer Layer 7.
Ten ograniczony zakres nadal jest przydatny. Failover bazy danych i degradacja sieci to dwa testy często odkładane przez zespoły, ponieważ doraźne skrypty są ryzykowne, trudne do weryfikacji i mało powtarzalne. FIT zamienia je w szablony eksperymentów z jawnym celem, rodzajem awarii i czasem trwania.
Dwa rodzaje awarii w wersji preview
Publiczna wersja preview obsługuje dwa scenariusze:
- failover Cloud SQL: przełączenie instancji o wysokiej dostępności ze strefy podstawowej do strefy zapasowej;
- degradację ruchu aplikacji: selektywne dodanie opóźnienia i kodów błędów HTTP przez load balancer Layer 7.
Pierwszy scenariusz sprawdza więcej niż samą zdolność Cloud SQL do przełączenia. Ujawnia założenia dotyczące puli połączeń, obsługi DNS, ponawiania transakcji, startup probes i odtwarzania działania aplikacji. Drugi pozwala zweryfikować budżety timeoutów, politykę ponowień, circuit breakery, zachowanie fallbacków i błędy widoczne dla użytkownika.
FIT nie jest więc jeszcze uniwersalną platformą chaos engineering. Ogłoszenie nie obejmuje dowolnego wyłączania maszyn wirtualnych, utraty pakietów, obciążania CPU, awarii storage ani wieloetapowych eksperymentów. Usługę należy oceniać na podstawie dwóch obsługiwanych ścieżek, a nie możliwości sugerowanych przez jej szeroką nazwę.
Dry run ogranicza błędy w wyborze celu
Przed wstrzyknięciem awarii FIT wykonuje automatyczny dry run tylko do odczytu. Sprawdza uprawnienia i zwraca aktualną listę wszystkich zasobów objętych eksperymentem. Operator uruchamia zakłócenie ręcznie dopiero po przejrzeniu tego zakresu.
Taki workflow ogranicza typowe ryzyko testów awarii: nieaktualny selektor lub nieoczekiwanie szeroki zbiór celów. Dry run nie dowodzi, że eksperyment jest bezpieczny, ale tworzy punkt kontroli przed operacją zakłócającą. Zespół powinien zapisać zwrócony zakres razem ze zmianą lub dowodami z testu i przerwać procedurę, jeśli lista odbiega od oczekiwanego inventory.
Usługa ogranicza też czas awarii wartością zdefiniowaną w szablonie. Po upływie timera FIT wycofuje zakłócenie. Jeśli aplikacja wcześniej zacznie zachowywać się niebezpiecznie, operator może użyć funkcji stop and revert, aby zatrzymać eksperyment i rozpocząć przywracanie normalnego stanu.
Te mechanizmy są zabezpieczeniami, a nie strategią wycofywania zmian w danych aplikacji. Wymuszony failover bazy lub seria błędów HTTP może nadal ujawnić nieidempotentne ponowienia, niekompletne transakcje, wzrost kolejki albo skutki uboczne w usługach zależnych. Kryteria odtworzenia i dashboardy obserwacyjne trzeba przygotować przed rozpoczęciem testu.
Praktyczny pierwszy eksperyment
Google zaleca używanie FIT w środowisku nieprodukcyjnym podczas fazy preview. Pierwszy test powinien być wystarczająco mały, aby łatwo zdiagnozować wynik:
- Wybierz jedną usługę nieprodukcyjną ze znanymi zależnościami i obserwowalną ścieżką sukcesu.
- Zdefiniuj sygnały stanu stabilnego, takie jak poprawne requesty, opóźnienie, liczba błędów, długość kolejki i łączność z bazą.
- Utwórz szablon dla instancji Cloud SQL o wysokiej dostępności albo load balancera Layer 7.
- Uruchom dry run i poproś drugiego inżyniera o sprawdzenie każdego zasobu na liście.
- Zacznij od krótkiego czasu i obserwuj telemetrię aplikacji oraz infrastruktury.
- Celowo przetestuj stop and revert, nawet jeśli system wygląda na zdrowy.
- Zapisz czas odtworzenia, błędne założenia i zmiany potrzebne przed kolejnym testem.
W eksperymencie Cloud SQL należy sprawdzić, czy istniejące połączenia odzyskują sprawność i czy nowe powstają bez ręcznej interwencji. Przy degradacji przez load balancer warto porównać zaobserwowane opóźnienia i błędy z timeoutami oraz ponowieniami klienta. Ponowienia ukrywające awarię przed użytkownikiem mogą jednocześnie zwielokrotnić obciążenie backendu, dlatego oprócz końcowego success rate trzeba obserwować liczbę requestów.
Dostęp i ograniczenia wersji preview
FIT jest dostępny przez konsolę Google Cloud, CLI gcloud i REST API. W fazie preview dostęp nie jest standardowym mechanizmem samoobsługowym. Google poleca zwrócić się do zespołu obsługi konta Google Cloud o dodanie projektu do wersji preview, następnie włączyć Fault Testing API i nadać operatorom rolę roles/faulttesting.operator.
Ogłoszenie nie zawiera listy dostępnych regionów ani cennika FIT. Nie należy więc zakładać, że wersja preview jest globalnie dostępna albo bezpłatna. Te szczegóły trzeba potwierdzić z zespołem obsługi konta przed zaplanowaniem wdrożenia.
Status preview jest ważniejszym ograniczeniem operacyjnym. Google jawnie zaleca użycie nieprodukcyjne podczas fazy preview. Szablony i dowody zebrane w środowisku testowym mogą wspierać prace nad odpornością produkcji, ale FIT nie powinien stać się mechanizmem produkcyjnym, dopóki warunki wsparcia i zachowanie usługi nie spełnią wymagań organizacji.
Gdzie FIT daje najwięcej korzyści
Najważniejszą zaletą jest powtarzalność. FIT może zamienić ręcznie koordynowany test failoveru w zweryfikowany szablon uruchamiany po zmianach obsługi połączeń, polityki load balancera, logiki ponowień lub procedur disaster recovery.
Usługa może też włączyć testy odporności do kryteriów akceptacji migracji. Zamiast traktować wysoką dostępność jako zaznaczoną opcję konfiguracyjną, zespół może pokazać zachowanie całej aplikacji po przejęciu roli primary przez instancję zapasową albo po wprowadzeniu opóźnień Layer 7 i błędów HTTP.
Wersja preview nie ma jeszcze zakresu pozwalającego zastąpić istniejący toolkit chaos engineering. Zapewnia jednak bezpieczniejszą, natywną ścieżkę dla dwóch istotnych rodzajów awarii w Google Cloud. Dry run, ograniczony czas oraz stop and revert ułatwiają przegląd i powtarzanie testów, ale odpowiedzialność za odtwarzanie aplikacji i bezpieczeństwo danych nadal pozostaje po stronie zespołu inżynierskiego.