Uruchamiasz portal oparty na LAMP do zbierania opinii użytkowników w regionie us-central1, w dwóch strefach, z automatycznie skalowanymi zarządzanymi grupami instancji, z wyjątkiem bazy danych. Obecnie obsługuje on małą grupę z dostępnością na poziomie 99,99%. Zanim udostępnisz go wszystkim użytkownikom, jaka strategia testowania odporności zapewni, że system utrzyma SLA pod większym, nieuwierzytelnionym obciążeniem?

Poprawna odpowiedź to stworzenie syntetycznych, losowych danych wejściowych użytkowników i odtworzenie syntetycznego obciążenia, aż logika autoskalowania zostanie uruchomiona na co najmniej jednej warstwie, a następnie wprowadzenie chaosu do systemu poprzez zakończenie działania losowych zasobów w obu strefach. Ta strategia symuluje realistyczne obciążenie i testuje odporność systemu na awarie, w tym zdolność do autoskalowania i odzyskiwania po błędach w wielu strefach, co jest kluczowe dla utrzymania SLA. Pierwsza opcja jest nieodpowiednia, ponieważ odtwarzanie danych wejściowych istniejących użytkowników nie symuluje obciążenia nieuwierzytelnionego ani nie testuje odporności na losowe awarie. Trzecia opcja, stopniowe zwiększanie liczby użytkowników, jest zbyt powolna i nieefektywna do szybkiego testowania odporności pod dużym obciążeniem. Czwarta opcja skupia się na statycznym skalowaniu i nie testuje dynamicznej odporności systemu ani jego zdolności do radzenia sobie z awariami.