Google Cloud udostępnia testy wstrzykiwania awarii
Google Cloud potrafi teraz celowo zepsuć twoje własne zasoby. Fault Injection Testing (FIT) wszedł w preview 27 sierpnia 2026 roku. Robi dwie rzeczy: wywołuje failover Cloud SQL albo degraduje ruch na load balancerze Layer 7.
Zakres jest wąski. Obejmuje jednak dwa testy stale odkładane, bo własne skrypty są ryzykowne i mało powtarzalne.
Dwie awarie w wersji preview
- failover Cloud SQL — przełączenie instancji o wysokiej dostępności ze strefy podstawowej do zapasowej;
- degradacja ruchu — dodanie opóźnień i kodów błędów HTTP na load balancerze Layer 7.
Pierwszy test sprawdza więcej niż samo przełączenie stref. Ujawnia twoje założenia o puli połączeń, DNS, ponawianiu transakcji i startup probes.
Drugi weryfikuje budżety timeoutów, politykę ponowień, circuit breakery i błędy widziane przez użytkowników.
FIT nie jest jeszcze pełną platformą chaos engineering. Brak wyłączania maszyn, utraty pakietów, obciążania CPU, awarii storage i eksperymentów wieloetapowych.
Dry run wyłapuje zły wybór celu
FIT najpierw wykonuje dry run tylko do odczytu. Sprawdza uprawnienia i zwraca dokładną listę zasobów objętych testem. Wstrzyknięcie startuje dopiero po zatwierdzeniu tej listy.
Ten krok blokuje klasyczny wypadek: nieaktualny selektor o dużo szerszym zasięgu. Zapisz zwrócony zakres razem z dowodami z testu. Przerwij, jeśli lista odbiega od oczekiwań.
Każdy szablon ma też limit czasu. Po upływie timera FIT wycofuje awarię. Stop and revert zatrzyma ją wcześniej, gdy zrobi się niebezpiecznie.
To zabezpieczenia, a nie wycofanie zmian w danych. Wymuszony failover nadal zostawi niekompletne transakcje, rosnące kolejki albo zdublowane skutki uboczne.
Twój pierwszy eksperyment
Google zaleca w preview środowisko nieprodukcyjne. Pierwszy test ma być na tyle mały, by dało się go zdiagnozować:
- Wybierz jedną usługę nieprodukcyjną o znanych zależnościach.
- Zdefiniuj stan stabilny: success rate, opóźnienie, liczbę błędów, długość kolejki, łączność z bazą.
- Zbuduj szablon dla instancji Cloud SQL albo load balancera Layer 7.
- Uruchom dry run i poproś drugiego inżyniera o sprawdzenie każdego celu.
- Ustaw krótki czas i obserwuj telemetrię aplikacji oraz infrastruktury.
- Celowo użyj stop and revert, nawet gdy wszystko wygląda dobrze.
- Zapisz czas odtworzenia i każde błędne założenie.
W Cloud SQL sprawdź, czy stare połączenia wracają do życia, a nowe powstają bez ręcznej pomocy. Przy degradacji ruchu porównaj opóźnienia z timeoutami klienta. Ponowienia ukrywające błąd nadal zwielokrotniają obciążenie backendu, więc obserwuj też liczbę żądań.
Dostęp i ograniczenia preview
| Element | Status |
|---|---|
| Interfejsy | Konsola, gcloud, REST API |
| Włączenie | Poproś zespół obsługi konta o dodanie projektu |
| API | Włącz Fault Testing API |
| Rola | roles/faulttesting.operator |
| Regiony i cennik | Brak danych — potwierdź z zespołem konta |
Status preview jest realnym ograniczeniem. Google odradza użycie produkcyjne. Zbieraj dowody w środowisku testowym i wróć do FIT, gdy warunki wsparcia spełnią twoje wymagania.
Gdzie FIT daje najwięcej
Wygraną jest powtarzalność. Ręcznie koordynowana próba failoveru zmienia się w sprawdzony szablon uruchamiany po zmianach obsługi połączeń, polityki load balancera lub logiki ponowień.
Usługa pasuje też do kryteriów akceptacji migracji. Zamiast odhaczać wysoką dostępność, pokażesz zachowanie całej aplikacji po przejęciu roli przez instancję zapasową.