Strategie architektury projektowania strategii testowania niezawodności

Dotyczy tego zalecenia listy kontrolnej dotyczącej niezawodności platformy Azure Well-Architected Framework:

RE:08 Przetestuj scenariusze odporności i dostępności, stosując zasady inżynierii chaosu. Użyj testów niezawodności, aby sprawdzić, czy Twoje obciążenie robocze może wytrzymać awarie, skalować się odpowiednio do zapotrzebowania i odzyskiwać sprawność w ramach zdefiniowanych celów.

Testowanie niezawodności przechwytuje słabości architektury, zanim spowodują awarie. Bez celowego testowania w scenariuszach awarii nie można wiedzieć, czy wzorce odporności działają faktycznie, czy obciążenie jest odzyskiwane w ramach zdefiniowanych celów.

Niezawodność obciążenia zwiększa się podczas testowania pod kątem zagrożeń bezpieczeństwa, które wpływają na dostępność, problemy z wydajnością, które sprawiają, że system jest bezużyteczny i luki operacyjne, które ograniczają reakcję na zdarzenia. Użyj strategii opisanych w tym artykule, aby ustalić harmonogram testów, który regularnie weryfikuje obciążenie robocze pod kątem scenariuszy awarii. Rozwijanie testów w miarę zmian architektury i zdarzeń ujawnia nowe słabości. Zyskaj pewność, że Twoje obciążenie robocze jest odporne na awarie, skaluje się tak, aby sprostać zapotrzebowaniu, i odzyskuje sprawność w ramach docelowych wartości RTO i RPO, a jednocześnie twórz mechanizm informacji zwrotnej, który z czasem wzmacnia poziom niezawodności.

Kluczowe strategie przedstawione w tym artykule opierają się na podstawowych rozwiązaniach testowania opisanych w temacie Strategie architektury OE:09 na potrzeby testowania. Najpierw zapoznaj się z tym artykułem. Zalecenia zawarte w tym przewodniku dotyczą niezawodności i koncentrują się na uzyskaniu pewności, że obciążenie robocze jest w stanie przetrwać awarie i odzyskać sprawność zgodnie z przyjętymi celami.

W poniższej tabeli zdefiniowano kluczowe terminy niezawodności używane w tym artykule.

Definicje

Termin Definicja
Availability Czas działania obciążenia aplikacji w dobrej kondycji bez znaczących przestojów.
Inżynieria chaosu Praktyka, która bezpiecznie obejmuje testowanie chaosu w kulturze zespołu, praktykach inżynieryjnych i cyklu życia programowania w celu ciągłego ulepszania odporności systemu.
Testowanie w warunkach chaosu Kontrolowany eksperyment, który weryfikuje konkretną hipotezę odporności na temat tego, jak obciążenie powinno zachowywać się w warunkach zakłócających działanie.
Wstrzykiwanie błędów Technika, która celowo wprowadza błędy do składnika, zależności lub ścieżki systemowej.
Odzyskiwalność Możliwość przywracania normalnych operacji po zakłóceniu w ustalonym czasie odzyskiwania (RTO) i uzgodnionych celach punktu odzysku (RPO).
Resiliency Zdolność obciążenia do wytrzymania błędów (takich jak błędy przejściowe, awarie infrastruktury, skoki zapotrzebowania) i kontynuowanie działania w akceptowalnym środowisku użytkownika.
Failover Proces przełączania do składnika pomocniczego po awarii podstawowego składnika.
Failback Proces, w którym przywraca się działanie w regionie podstawowym po jego odzyskaniu.
Budżet błędu Maksymalny akceptowalny poziom awarii systemu w określonym okresie, pochodzący z celów poziomu usług (SLO).

Definiowanie zakresu testowania niezawodności na podstawie typów usług

Podczas definiowania zakresu testowania niezawodności należy wziąć pod uwagę wspólny model odpowiedzialności używanych usług. Każdy typ usługi (IaaS, PaaS, SaaS) ma różne gwarancje niezawodności i różne poziomy kontroli nad obsługą awarii. Skoncentruj testy na tych aspektach niezawodności, za które odpowiadasz.

  • Dopasuj głębokość testowania do odpowiedzialności. W przypadku usług infrastruktury (IaaS) twój zespół jest właścicielem większości decyzji dotyczących niezawodności, więc zainwestuj w dokładną walidację poprzez inżynierię chaosu i wstrzyknięcie błędów. W przypadku usług platformy (PaaS) i oprogramowania (SaaS) dostawca zarządza dużą częścią podstawowej niezawodności. Skoncentruj się na tym, jak Twoje obciążenie robocze współpracuje z tymi usługami, na przykład jak radzi sobie z przełączeniem awaryjnym infrastruktury w usłudze PaaS, dławieniem, degradacją usług lub zmianami wzorców obciążenia.

  • Uwzględnij obciążenia mieszanych usług. Gdy obciążenie obejmuje wiele typów usług, obowiązki związane z testowaniem różnią się w zależności od składników. Możesz testować przełączenie awaryjne komponentów infrastruktury opartej na maszynach wirtualnych w czasie awarii strefy dostępności, ale w przypadku bazy danych PaaS zaprojektowanej pod kątem wysokiej dostępności polegać na gwarancjach dostawcy. Zidentyfikuj, gdzie znajdują się te granice, i upewnij się, że testy obejmują luki między nimi.

Testowanie pod kątem docelowych poziomów niezawodności — kompleksowo

Cele niezawodności, takie jak SLO, RTO i RPO, określają, jak obciążenie powinno się zachowywać w przypadku awarii. Używaj ich jako kryteriów zaliczenia i odrzucenia w całych krytycznych przepływach, a nie tylko dla poszczególnych komponentów.

  • Zweryfikuj proces odzyskiwania w całym przepływie. Pojedynczy składnik może zostać odtworzony w docelowym czasie odtworzenia (RTO), ale całkowity czas przywracania może przekroczyć założony cel, jeśli trzeba również odtworzyć zależne komponenty. Uwzględnij łączny czas odzyskiwania w całym przepływie, w tym czas wykrywania problemu i reagowania.

  • Określ zakres testów za pomocą celów SLO i budżetów błędów. Budżet błędu określa nakład, jaki można przeznaczyć na wstrzykiwanie błędów. Ogranicz testowanie chaosu, aby utrzymać się w ramach celów SLO, i wykorzystaj docelowe parametry odzyskiwania przepływu do zdefiniowania granic każdego testu.

Tworzenie scenariuszy niezawodności z krytycznych przepływów i trybów awarii

Zacznij od krytycznych przepływów w obciążeniu i trybów awarii, które mogą mieć na nie wpływ. Wykorzystaj analizę trybów uszkodzeń, aby zidentyfikować scenariusze awarii o największym wpływie i opracować testy, które weryfikują strategie odporności i odtwarzania.

Określanie priorytetów według wpływu i prawdopodobieństwa. Nie każdy tryb awarii gwarantuje te same inwestycje testowe. Najpierw skoncentruj się na scenariuszach z najwyższym potencjalnym wpływem użytkownika i najwyższym prawdopodobieństwem występowania. Niech analiza trybów awarii stanowi podstawę tej priorytetyzacji.

Zweryfikuj mechanizmy odporności na uszkodzenia i odzyskiwania po awarii

Skoncentruj się na scenariuszach, które najprawdopodobniej spowodują przestój lub pogorszą komfort użytkowania. Użyj strategii opisanych w tej sekcji, aby opracować testy, które zweryfikują zdolność obciążenia roboczego do radzenia sobie z awariami i skutecznego odzyskiwania sprawności.

Tworzenie kopii zapasowej i przywracanie

Testowanie tworzenia i przywracania kopii zapasowych powinno sprawdzić, czy twoje podejście do ochrony danych spełnia cele odzyskiwania.

  • Ustal harmonogram testów. Określ częstotliwość testowania przywracania na podstawie częstotliwości zmiany konfiguracji kopii zapasowej, schematu danych lub infrastruktury. Częstsze zmiany wymagają częstszego testowania przywracania.

  • Ustaw cele odzyskiwania. Mierz rzeczywiste czasy przywracania w odniesieniu do docelowych wartości RPO i RTO, aby potwierdzić, że strategia tworzenia kopii zapasowych spełnia cele odzyskiwania.

  • Nie zakładaj kompletności tworzenia kopii zapasowej. Kopie zapasowe można błędnie skonfigurować w celu przechwycenia tylko podzestawu danych. Zweryfikuj integralność i kompletność danych, a nie tylko to, czy operacja przywracania zakończy się pomyślnie.

  • Testowanie w izolacji. Zweryfikuj operacje przywracania w środowisku oddzielnym od środowiska produkcyjnego, aby można było przeprowadzać dokładne kontrole bez przerywania obciążeń na żywo.

Błędy przejściowe

Przejściowe awarie, takie jak chwilowe przerwy w sieci, krótka niedostępność usługi i przekroczenia limitu czasu połączenia, są typowymi zagrożeniami dla niezawodności. Sprawdź, czy aplikacja radzi sobie z tymi awariami bez wpływu na użytkowników. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

  • Skup się na tym, co jesteś właścicielem. Jeśli pakiety SDK lub usługi platformy automatycznie obsługują ponawianie prób i mechanizm wyłącznika awaryjnego, przetestuj, co się stanie, gdy te wbudowane mechanizmy zostaną wyczerpane, na przykład gdy wszystkie próby ponowienia zakończą się niepowodzeniem lub gdy otworzy się wyłącznik awaryjny.

  • Zweryfikuj konfiguracje obsługi błędów. Oceń konfiguracje obsługi błędów dla swojego obciążenia roboczego. Sprawdź, czy zasady ponawiania, progi wyłącznika i wartości limitu czasu zachowują się zgodnie z oczekiwaniami w realistycznych warunkach awarii.

  • Przetestuj granicę między przejściowym i trwałym niepowodzeniem. Sprawdź, czy obciążenie robocze płynnie przechodzi od mechanizmu ponawiania prób do trybu awaryjnego lub ograniczenia działania, gdy awaria utrzymuje się dłużej niż przewidują oczekiwane progi.

  • Uwzględnij przejściowe awarie wynikające z mechanizmów odpornościowych. Nadmiarowość stref i podobne architektury często powodują przejściowe błędy podczas normalnych operacji przełączania awaryjnego. Na przykład baza danych z nadmiarowością strefową może powodować przejściowe awarie połączeń, gdy ruch jest przekierowywany do sprawnej strefy podczas awarii. Sprawdź, czy obciążenie może obsługiwać te oczekiwane błędy przejściowe bez znaczącego wpływu na użytkownika.

Reakcja na obciążenie i skalowanie

Sprawdź, czy Twoje obciążenie robocze zachowuje niezawodność przy zmianach zapotrzebowania, zarówno podczas nagłych skoków, jak i stopniowego wzrostu. Aby uzyskać więcej informacji, zobacz strategia skalowania. Aby uzyskać wskazówki dotyczące testowania obciążenia i stresu, zobacz Zalecenia dotyczące testowania.

  • Przetestuj zarówno skalowanie w poziomie, jak i skalowanie w pionie. Sprawdź, czy nowe zasoby są uruchamiane wystarczająco szybko oraz czy skalowanie w dół nie powoduje utraty żądań ani nie pozostawia osieroconych zasobów.

  • Uwzględnij opóźnienie skalowania. Zawsze występuje opóźnienie między spełnieniem warunków uruchamiających skalowanie a udostępnieniem nowych zasobów. Określ, czy obciążenie robocze może sprostać zapotrzebowaniu w tym okresie, czy też trzeba z wyprzedzeniem udostępnić dodatkowe zasoby.

Błędy zależności

Obciążenie prawdopodobnie zależy od usług spoza bezpośredniej kontroli, takich jak interfejsy API innych firm, usługi platformy zarządzanej lub udostępnione usługi wewnętrzne. Sprawdź, czy obciążenie obsługuje błędy w tych zależnościach bez znaczących zakłóceń dla użytkowników.

  • Kategoryzuj zależności według poziomu krytyczności. Nie wszystkie zależności uzasadniają te same inwestycje testowe. Określanie priorytetów testów dla zależności, które znajdują się w przepływach krytycznych i które nie mają wbudowanej nadmiarowości lub ścieżek rezerwowych.

  • Przetestuj mechanizm awaryjny dla każdej zależności. Gdy zależność stanie się niedostępna, obciążenie robocze powinno przełączyć się na alternatywną ścieżkę lub tryb działania, zamiast całkowicie ulec awarii. Upewnij się, że każdy mechanizm rezerwowy uruchamia się prawidłowo oraz że pozostałe, niepowiązane funkcje nadal działają.

  • Uwzględnij błędy częściowe i kaskadowe. Zależności rzadko kończą się niepowodzeniem w sposób binarny. Nie testuj tylko całkowitych awarii. Obejmuje zwiększenie opóźnienia, sporadyczne błędy i częściową dostępność danych.

  • Zweryfikuj izolację i ograniczenie zakresu skutków awarii. Sprawdź, czy pojedyncza awaria zależności nie powoduje efektu kaskadowego w niepowiązanych funkcjach.

Samozachowanie i odzyskiwanie

Zweryfikuj, jak projekt zapewniający samonaprawę i samoochronę reaguje na awarie, w tym czy obciążenie robocze może nadal działać w ograniczonym zakresie, gdy pełne przywrócenie sprawności nie jest natychmiast możliwe.

  • Przetestuj kompleksowo automatyczne odzyskiwanie. Oceń modele kondycji, aby upewnić się, że obejmują one odpowiednie kontrole. Sprawdź, czy te testy dokładnie wykrywają błędy, wyzwalają zautomatyzowane korygowanie zgodnie z oczekiwaniami i zwracają system do stanu dobrej kondycji w dopuszczalnych przedziałach czasu.

  • Zweryfikuj ręczne procedury odzyskiwania. Automatyczne odzyskiwanie nie obejmuje każdego scenariusza. Testuj manualne runbooki w realistycznych warunkach, aby upewnić się, że operatorzy mogą realizować je pod presją i w założonym docelowym czasie odzyskiwania.

  • Zweryfikuj działanie mechanizmu łagodnej degradacji. Gdy komponent ulegnie awarii, obciążenie robocze powinno działać w ograniczonym zakresie, zamiast całkowicie przestać działać. Przetestuj, czy może działać w trybie zredukowanym, takim jak kolejkowanie żądań ręcznego przeglądu, i czy obniżona wydajność jest akceptowalna dla użytkowników. Upewnij się, że twój zespół wie, jak obsługiwać obciążenie w tym stanie i jak przywrócić pełną funkcjonalność.

Zdarzenia i odzyskiwanie po awarii (DR)

W przypadku wystąpienia zdarzenia lub awarii możliwość szybkiego wykrywania go i skutecznego reagowania jest krytyczna. Przetestuj plany i procesy, aby upewnić się, że dotyczą one katastroficznych awarii i poważnych zdarzeń. Użyj dedykowanego środowiska do testowania odzyskiwania po awarii, aby uniknąć wpływu na obciążenia produkcyjne. Aby uzyskać więcej informacji, zobacz Plan odzyskiwania po awarii.

  • Weryfikowanie mechanizmów wykrywania zdarzeń. Zasymuluj zdarzenia, aby sprawdzić, czy dzienniki monitorowania przechwytują niezbędne informacje i czy alerty są wyzwalane odpowiednio. Na przykład przetestuj, jak szybko są wykrywane zwiększone współczynniki niepowodzeń żądań i jak często są próbkowane dane monitorowania.

  • Testowanie procesów zarządzania zdarzeniami. Upewnij się, że twój zespół może skutecznie postępować zgodnie z procedurami reagowania na zdarzenia. Aby uzyskać więcej informacji, zobacz Reagowanie na zdarzenia.

  • Przetestuj pełny tryb failover i powrót po awarii. Testowanie poszczególnych elementów w izolacji może przegapić błędy koordynacji, które pojawiają się tylko podczas rzeczywistego przełączania. Zweryfikuj pełną sekwencję trybu failover, w tym przełączanie systemu DNS, przywracanie kopii zapasowych i spójność replikacji danych oraz ponowne nawiązywanie połączenia z klientem. Przetestuj również powrót po awarii do wdrożenia podstawowego, co jest często bardziej złożone niż początkowe przełączenie.

  • Zweryfikuj pojemność w środowisku przełączenia awaryjnego. Upewnij się, że środowisko przełączania awaryjnego ma odpowiednie, wstępnie przydzielone zasoby, aby mogło natychmiast po przełączeniu awaryjnym przejąć ruch bez załamania pod obciążeniem. Przetestuj, czy środowisko może zapewnić ciągłość działania, gdy uruchomią się mechanizmy skalowania, i zweryfikuj swoje podejście do skalowania. Aby uzyskać więcej informacji, zobacz Ładowanie i skalowanie odpowiedzi.

  • Mierz względem swoich celów. Jeśli test odzyskiwania po awarii nie spełnia celu czasu odzyskiwania (RTO) ani celu punktu odzyskiwania (RPO), przeanalizuj braki i odpowiednio zaktualizuj plan odzyskiwania po awarii.

  • Weryfikowanie osób i procesów. Testy DR powinny weryfikować kanały komunikacji, potwierdzać, że operatorzy mają niezbędny dostęp oraz uprawnienia do wykonywania procedur odtwarzania, a także zapewniać, że w sytuacji presji czasu mogą szybko znaleźć instrukcje operacyjne dotyczące DR.

Testowanie i ocenianie planu przy użyciu ćwiczeń na tablecie

Ćwiczenia typu tabletop pomagają wykryć luki w testowaniu niezawodności, zanim ujawni je rzeczywisty incydent. Symulując scenariusze awarii z zespołem, możesz zidentyfikować nietestowane warunki i sprawdzić, czy procedury odpowiedzi działają zgodnie z oczekiwaniami.

  • Symulowanie realistycznych zdarzeń. Zapoznaj się ze scenariuszem awarii, takim jak awaria regionalna lub uszkodzone wdrożenie, i opisz kroki, które należy wykonać w celu wykrycia, reagowania na nie i odzyskiwania po nim. Te dyskusje często ujawniają założenia dotyczące zachowania systemu, które nie zostały zweryfikowane przez testowanie.

  • Przekształcanie wyników w przypadki testowe. Wykorzystaj luki i niewiadome, które ujawniają się w trakcie ćwiczenia, aby opracować nowe testy niezawodności. Jeśli zespół wykryje, że nikt nie wie, jak działa obciążenie, gdy określona zależność ulegnie awarii, jest to scenariusz, który ma zostać dodany do strategii testowania.

Korzystaj z planowanych i nieplanowanych awarii

Gdy obciążenie jest w trybie offline z powodu planowanej konserwacji lub nieplanowanej awarii, masz unikatową okazję do przeprowadzania testów i ulepszania zrozumienia obciążenia.

Planowane prace konserwacyjne

Podczas okien serwisowych przeznaczonych na aktualizacje lub poprawki testuj komponenty i przepływy, które nie są objęte pracami konserwacyjnymi. Testy można uruchamiać bez ryzyka nieoczekiwanego obniżenia obciążenia lub przełączenia go w tryb offline. Jeśli masz wystarczająco dużo czasu, przetestuj również składniki związane z konserwacją po zakończeniu pracy.

Nieplanowana awaria

Każda nieplanowana awaria jest okazją do wzmocnienia strategii testowania niezawodności. Po przywróceniu usługi i zakończeniu przeglądu po zdarzeniu użyj wyników, aby ulepszyć testy.

  • Przetestuj środki zaradcze. Jeśli zastosowano obejście lub tymczasową poprawkę, sprawdź, czy może obsłużyć oczekiwane obciążenie przed wprowadzeniem stałej poprawki.

  • Skanuj pod kątem podobnych słabych stron. Przejrzyj inne komponenty pod kątem takich samych wzorców konfiguracji lub wzorców projektowych, które przyczyniły się do awarii. Dodaj testy dla tych komponentów, zanim zawiodą w ten sam sposób.

Łączenie różnych typów testów

Po uruchomieniu różnych typów testów można ujawnić problemy z niezawodnością, które nie są widoczne, gdy każdy test działa w izolacji. Obciążenie robocze może radzić sobie z określonym obciążeniem w normalnych warunkach, ale to samo obciążenie powoduje awarie po wprowadzeniu usterki.

  • Użyj ponownie istniejącej infrastruktury testowej. Jeśli masz już infrastrukturę i uprzężę testową na potrzeby testowania obciążenia, użyj jej do jednoczesnego uruchamiania testów chaosu. Połączenie iniekcji obciążenia i błędów w tym samym przebiegu testu pokazuje, jak działa obciążenie w realistycznych warunkach, w których występuje zapotrzebowanie i awarie w tym samym czasie.

  • Rozpocznij pracę w środowiskach nieprodukcyjnych. Rozpocznij testowanie niezawodności w środowiskach o niższym ryzyku, w których można bezpiecznie eksplorować tryby awarii. Do testów w środowisku produkcyjnym przechodź dopiero wtedy, gdy wyciągniesz już wszystkie wnioski ze środowisk nieprodukcyjnych i wdrożysz zabezpieczenia pozwalające ograniczyć skalę ewentualnych skutków oraz szybko wycofać zmiany.

Korzystanie z iniekcji błędów i inżynierii chaosu

Iniekcja błędów i inżynieria chaosu pomagają zwiększyć zaufanie do odporności obciążenia, celowo wprowadzając błędy i obserwując odpowiedź. Przed uruchomieniem eksperymentów upewnij się, że istnieją strategie ograniczania ryzyka.

  • Regularnie uruchamiaj eksperymenty chaosu. Oceń zakres testu. Wstrzykuj błędy do komponentów i przepływów, które uważasz za niezawodne. Wraz ze zmianami w architekturze pojawiają się nowe scenariusze awarii, a wcześniejsze założenia mogą przestać być aktualne. Uruchamiaj eksperymenty na regularnych cyklach, aby przechwytywać regresje, weryfikować nowe zależności i potwierdzić, że ostatnie zmiany nie wprowadziły słabych stron.

  • Użyj analizy trybu awarii, aby skoncentrować eksperymenty. Każdy eksperyment powinien być ukierunkowany na konkretną usterkę lub zestaw błędów i mieć wyraźną hipotezę, taką jak testowanie zdolności danego przepływu do wytrzymania utraty określonego składnika. Gdy eksperymenty ujawniają nowe tryby awarii lub nieodkryte zależności, zaktualizuj analizę trybu awarii, aby zachować aktualność.

  • Ogranicz zakres wpływu podczas eksperymentów. Wskaż komponenty, które można szybko przywrócić, i realistycznie określ oczekiwania dotyczące wpływu każdego wstrzyknięcia błędu. Jeśli eksperyment wykracza poza zakres lub generuje nieoczekiwane wyniki, zatrzymaj go. Równoważenie zbierania znaczących danych przy jednoczesnym zminimalizowaniu wpływu na użytkowników.

  • Miara względem linii bazowych. Ustal spójne metryki niezawodności i wydajności dla przepływów i komponentów w każdym eksperymencie. Porównaj metryki stanu obniżonej wydajności z tymi punktami odniesienia, aby zrozumieć pełny wpływ błędu i określić, czy projekt odporności spełnia jego cele.

  • Uwzględnij wyniki w strategii testów. Korzystaj z wyników eksperymentów, aby prowadzić nowe testy, aktualizować plany odzyskiwania i informować o elementach listy prac korygowania. W miarę powstawania nieoczekiwanych zachowań utwórz ukierunkowane testy dla tych zachowań i zaprojektuj strategie korygowania.

Kompromis: testowanie iniekcji błędów w środowisku produkcyjnym może być destrukcyjne i może spowodować przestój. Bądź otwarty wobec interesariuszy co do tej możliwości. Umieść zabezpieczenia, aby można było zatrzymać eksperymenty i szybko wycofać się, i zachować elastyczność co do tego, kiedy uruchamiać testy lub unikać ich w okresach poufnych. Aby chronić przed niezamierzoną awarią, zaplanuj wystarczającą nadmiarowość i upewnij się, że uczestnicy projektu rozumieją kompromis kosztów.

Ryzyko: Testowanie niezawodności może rozszerzać zasięg w wielu trybach awarii, ale należy je zatrzymać, gdy nie będzie już dostarczać znaczącej wartości. Jeśli masz już zaległą listę znanych problemów z niezawodnością, nadaj priorytet ich rozwiązaniu zamiast dodawać więcej testów.

ułatwienia dostępu do Azure

Plany testów platformy Azure to oparte na przeglądarce rozwiązanie do zarządzania testami, które zapewnia wszystkie możliwości wymagane do zaplanowanego testowania ręcznego, testowania akceptacyjnego użytkownika, testowania eksploracyjnego i zbierania opinii od uczestników projektu.

Azure Chaos Studio to zarządzana usługa, która korzysta z testowania chaosu w celu ułatwienia mierzenia, zrozumienia i poprawy odporności aplikacji w chmurze i usługi.

Azure App Testing to usługa, która umożliwia uruchamianie testów funkcjonalnych przy użyciu Playwright Workspaces i testów wydajnościowych przy użyciu Azure Load Testing w celu identyfikowania problemów w aplikacjach.

Azure Service Health ma okienko planowanej konserwacji, które jest dedykowaną sekcją w portalu Azure, który informuje o nadchodzących działaniach konserwacyjnych. Wyróżnia zdarzenia, które mogą mieć wpływ na zasoby Azure, pomagając przygotować się z wyprzedzeniem.

Monitor połączeń to funkcja usługi Azure Network Watcher , której można używać do syntetycznego monitorowania i testowania łączności sieciowej w czasie rzeczywistym zarówno w środowiskach platformy Azure, jak i hybrydowych. W scenariuszach inżynierii chaosu monitor połączeń może służyć do wstrzykiwania błędów do docelowych składników sieciowych i stale mierzyć kluczowe metryki, takie jak opóźnienie i utrata pakietów. Ta funkcja umożliwia zespołom obserwowanie wpływu zakłóceń na niezawodność sieci, zarówno dla poszczególnych składników przepływu, jak i na kompleksowe ścieżki sieciowe. Aby ocenić wpływ błędów i zidentyfikować obszary poprawy, porównaj dane telemetryczne monitora połączeń z metrykami punktu odniesienia.

Lista kontrolna dotycząca niezawodności

Zapoznaj się z kompletnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności

  • Last updated on