Zalecenia dotyczące definiowania celów niezawodności

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

RE:04	Zdefiniuj cele dotyczące niezawodności i odzyskiwania dla składników, przepływów i ogólnego rozwiązania. Wizualizuj cele do negocjowania, uzyskiwania konsensusu, ustawiania oczekiwań i prowadzenia działań w celu osiągnięcia idealnego stanu. Użyj zdefiniowanych celów, aby skompilować model kondycji. Model kondycji określa, jak wyglądają stany dobrej kondycji, obniżonej wydajności i złej kondycji.

W tym przewodniku opisano zalecenia dotyczące definiowania metryk docelowych dostępności i odzyskiwania dla krytycznych obciążeń i przepływów. Cele dotyczące niezawodności są oparte na ćwiczeniach warsztatowych z uczestnikami projektu biznesowego. Cele są uściśline przez monitorowanie i testowanie.

Wraz z wewnętrznymi uczestnikami projektu ustaw realistyczne oczekiwania dotyczące niezawodności obciążeń, aby uczestnicy projektu mogli komunikować się z klientami za pośrednictwem umów umownych. Realistyczne oczekiwania pomagają również uczestnikom projektu zrozumieć i wspierać decyzje projektowe dotyczące architektury oraz wiedzieć, że projektujesz, aby optymalnie spełnić uzgodnione cele.

Rozważ użycie poniższych metryk, aby określić wymagania biznesowe.

Okres	Definicja
Cel poziomu usług (SLO)	Wartość docelowa procentowa reprezentująca kondycję składnika i warstwę niezawodności. Im wyższa warstwa, tym bardziej niezawodna jest składnik. Złożony cel slo reprezentuje zagregowany cel całego obciążenia i odpowiada za składniki SLO.
Wskaźnik poziomu usług (SLI)	Metryka emitowana przez usługę. Metryki SLI są agregowane w celu określenia wartości SLO.
Umowa dotycząca poziomu usług (SLA)	Umowa umowna między dostawcą usług a klientem obsługi. Umowa definiuje cele sla. Brak spełnienia umowy może mieć konsekwencje finansowe dla dostawcy usług.
Średni czas odzyskiwania (MTTR)	Czas potrzebny na przywrócenie składnika po wykryciu błędu.
Średni czas między awarią (MTBF)	Czas trwania, dla którego obciążenie może wykonywać oczekiwaną funkcję bez przerwy, dopóki nie ulegnie awarii.
Cel czasu odzyskiwania (recovery time objective, RTO)	Maksymalny dopuszczalny czas niedostępności aplikacji po zdarzeniu.
Cel punktu odzyskiwania (recovery point objective, RPO)	Maksymalny dopuszczalny czas trwania utraty danych podczas zdarzenia.

Zdefiniuj wartości docelowe obciążenia dla tych metryk w kontekście przepływów użytkownika i przepływów systemowych. Zidentyfikuj i oceniaj te przepływy , tak aby były krytyczne dla Twoich wymagań. Użyj wartości, aby zwiększyć projekt obciążenia pod względem architektury, przeglądu, testowania i operacji zarządzania zdarzeniami. Brak spełnienia celów będzie mieć wpływ na działalność poza poziom tolerancji.

Kluczowe strategie projektowania

Dyskusje techniczne nie powinny prowadzić do definiowania celów niezawodności dla przepływów krytycznych. Zamiast tego uczestnicy projektu biznesowego powinni skupić się na klientach, którzy definiują wymagania obciążenia. Eksperci techniczni pomagają uczestnikom projektu przypisywać realistyczne wartości liczbowe, które są skorelowane z tymi wymaganiami. W miarę dzielenia się wiedzą eksperci techniczni pozwalają na negocjacje i wzajemne konsensusy dotyczące realistycznych umów SLA.

Rozważmy przykład mapowania wymagań na mierzalne wartości liczbowe. Uczestnicy projektu szacują, że w przypadku krytycznego przepływu użytkownika czas przestoju w regularnych godzinach pracy powoduje utratę X dolarów miesięcznych przychodów. Ta kwota w dolarach jest porównywana z szacowanym kosztem projektowania przepływu, który ma poziom slo dostępności wynoszący 99,95 procent, a nie 99,9 procent. Decydenci muszą omówić, czy ryzyko tej straty przychodu przewyższa dodatkowe koszty i obciążenie związane z zarządzaniem wymagane do ochrony przed nim. Postępuj zgodnie z tym wzorcem podczas analizowania przepływów i tworzenia pełnej listy obiektów docelowych.

Należy pamiętać, że cele dotyczące niezawodności różnią się od celów wydajności. Cele dotyczące niezawodności koncentrują się na dostępności i odzyskiwaniu. Aby ustawić cele dotyczące niezawodności, zacznij od zdefiniowania najszerszych wymagań, a następnie zdefiniuj bardziej szczegółowe metryki, aby spełnić wymagania wysokiego poziomu.

Wymagania dotyczące niezawodności i odzyskiwania najwyższego poziomu oraz skorelowane metryki mogą obejmować na przykład dostępność aplikacji na poziomie 99,9 procent dla wszystkich regionów lub docelowy cel czasu odzyskiwania wynoszącego 5 godzin dla regionu Ameryki. Zdefiniowanie tych typów obiektów docelowych ułatwia określenie, które przepływy krytyczne są zaangażowane w te cele. Następnie możesz rozważyć cele na poziomie składnika.

Kompromis: Różnica koncepcyjna może istnieć między ograniczeniami technicznymi składników obciążenia a tym, co oznacza dla firmy, na przykład przepływność w megabitach na sekundę w porównaniu z transakcjami na sekundę. Tworzenie modelu między tymi dwoma widokami może być trudne. Zamiast overengineering rozwiązania, spróbuj podejść do niego w ekonomiczny, ale znaczący sposób.

Metryki dostępności

Umowy SLA i umowy SLA

Metryki dostępności są skorelowane z umowami SLA, których używasz do definiowania umów SLA. Cel slo obciążenia określa, ile przestojów można tolerować w danym okresie, na przykład mniej niż 1 godzinę miesięcznie. Aby upewnić się, że można spełnić cel slo, zapoznaj się z umowami SLA firmy Microsoft dla każdego składnika. Zwróć uwagę na to, ile nadmiarowości potrzebujesz, aby spełnić wymagania dotyczące wysokich umów SLA. Na przykład firma Microsoft gwarantuje wyższe umowy SLA dla wdrożeń usługi Azure Cosmos DB w wielu regionach niż gwarantuje wdrożenia w jednym regionie.

Uwaga

Umowy SLA platformy Azure nie zawsze obejmują wszystkie aspekty usługi. Na przykład Azure Application Gateway ma umowę SLA dotyczącą dostępności, ale funkcja Web Application Firewall platformy Azure nie zapewnia gwarancji, aby uniemożliwić przechodzenie złośliwego ruchu. Rozważ to ograniczenie podczas opracowywania umów SLA i umów SLA.

Po zebraniu umów SLA dla poszczególnych składników obciążenia oblicz złożoną umowę SLA. Złożona umowa SLA powinna być zgodna z docelowym celem slo obciążenia. Obliczanie złożonej umowy SLA obejmuje kilka czynników, w zależności od projektu architektury. Rozważmy poniższe przykłady.

Uwaga

Wartości umowy SLA w poniższych przykładach są hipotetyczne i są przeznaczone tylko do celów demonstracyjnych.Nie są one przeznaczone do reprezentowania bieżących wartości obsługiwanych przez firmę Microsoft.

Złożone umowy SLA obejmują wiele usług, które obsługują aplikację, z różnymi poziomami dostępności. Rozważmy na przykład Azure App Service aplikację internetową, która zapisuje dane w usłudze Azure SQL Database. Hipotetycznie te umowy SLA mogą być następujące:

• App Service aplikacje internetowe = 99,95%
• SQL Database = 99,99%

Jakiego maksymalnego przestoju można oczekiwać dla tej aplikacji? Jeśli któraś z usług ulegnie awarii, cała aplikacja ulegnie awarii. Prawdopodobieństwo niepowodzenia każdej usługi jest niezależne, więc złożona umowa SLA dla tej aplikacji wynosi 99,95 procent × 99,99 procent = 99,94 procent. Ta wartość jest niższa niż poszczególne umowy SLA. Ten wniosek nie jest zaskakujący, ponieważ aplikacja, która opiera się na wielu usługach, ma więcej potencjalnych punktów awarii.

Możesz ulepszyć złożoną umowę SLA, tworząc niezależne ścieżki rezerwowe. Jeśli na przykład SQL Database jest niedostępna, umieść transakcje w kolejce do przetworzenia później:

W tym projekcie aplikacja jest nadal dostępna, nawet jeśli nie może nawiązać połączenia z bazą danych. Jednak nie powiedzie się, jeśli baza danych i kolejka nie powiedzie się w tym samym czasie. Oczekiwany procent czasu jednoczesnej awarii wynosi 0,0001 × 0,001, więc oto złożona umowa SLA dla tej połączonej ścieżki:

Baza danych lub kolejka = 1,0 − (0,0001 × 0,001) = 99,99999%

Łączna złożona umowa SLA:

Aplikacja internetowa i (baza danych lub kolejka) = 99,95 procent × 99,99999 procent = ~99,95 procent

Takie podejście stanowi kompromisy:

• Logika aplikacji jest bardziej złożona.
• Płacisz za kolejkę.
• Należy wziąć pod uwagę problemy ze spójnością danych.

W przypadku wdrożeń obejmujących wiele regionów złożona umowa SLA jest obliczana w następujący sposób:

• N to złożona umowa SLA dla aplikacji wdrożonej w jednym regionie.

• Język R to liczba regionów, w których aplikacja jest wdrażana.

Oczekiwana szansa, że aplikacja ulegnie awarii we wszystkich regionach w tym samym czasie, to ((1 − N) ^ R). Jeśli na przykład hipotetyczna umowa SLA z jednym regionem wynosi 99,95 procent:

• Połączona umowa SLA dla dwóch regionów = (1 − 1 − 0,9995) ^ 2) = 99,999975 procent

• Połączona umowa SLA dla czterech regionów = (1 − (1 − 0,9995) ^ 4) = 99,9999999%

Definiowanie odpowiednich obiektów SLA wymaga czasu i starannego rozważenia. Osoby biorące udział w projekcie biznesowym powinny zrozumieć, jak kluczowi klienci korzystają z aplikacji. Powinny one również zrozumieć odporność na niezawodność. Ta opinia powinna poinformować cele.

Wartości umowy SLA

W poniższej tabeli zdefiniowano typowe wartości umowy SLA.

Umowa SLA	Czas przestoju w ciągu tygodnia	Czas przestoju w ciągu miesiąca	Czas przestoju w ciągu roku
99%	1,68 godz.	7,2 godz.	3,65 dnia
99,9%	10,1 min	43,2 min	8,76 godz.
99,95%	5 minut	21,6 min	4,38 godz.
99,99%	1,01 min	4,32 min	52,56 min
99.999%	6 s	25,9 s	5,26 min

Podczas myślenia o złożonych umowach SLA w kontekście przepływów należy pamiętać, że różne przepływy mają różne definicje krytycznych. Podczas tworzenia złożonych umów SLA należy wziąć pod uwagę te różnice. Przepływy niekrytyczne mogą zawierać składniki, które należy pominąć z obliczeń, ponieważ nie wpływają one na środowisko klienta, jeśli są one krótko niedostępne.

Uwaga

Obciążenia dostępne dla klientów i obciążenia użytku wewnętrznego mają różne cele SLO. Zazwyczaj obciążenia z użyciem wewnętrznym mogą mieć znacznie mniej restrykcyjne cele SLA niż obciążenia dostępne dla klientów.

Interfejsy SLA

Pomyśl o wskaźnikach SLI jako metrykach na poziomie składników, które przyczyniają się do celu slo. Najważniejsze wskaźniki SLI to te, które wpływają na krytyczne przepływy z perspektywy klientów. W przypadku wielu przepływów wskaźniki SLI obejmują opóźnienia, przepływność, szybkość błędów i dostępność. Dobry SLI pomaga określić, kiedy cel slo jest zagrożony naruszeniem. Skoreluj sLI z określonymi klientami, jeśli jest to możliwe.

Aby uniknąć zbierania bezużytecznych metryk, ogranicz liczbę wskaźników SLI dla każdego przepływu. Jeśli to możliwe, należy dążyć do trzech wskaźników SLI na przepływ.

Metryki odzyskiwania

Cele odzyskiwania odpowiadają metryce RTO, RPO, MTTR i MTBF. W przeciwieństwie do celów dostępności cele odzyskiwania dla tych pomiarów nie zależą w dużym stopniu od umów SLA firmy Microsoft. Firma Microsoft publikuje gwarancje celu odzyskiwania i celu punktu odzyskiwania tylko dla niektórych produktów, takich jak SQL Database.

Definicje realistycznych celów odzyskiwania opierają się na analizie trybu awarii oraz planach i testowaniu ciągłości działania i odzyskiwania po awarii. Przed zakończeniem tej pracy omówij cele aspiracyjne z uczestnikami projektu i upewnij się, że projekt architektury obsługuje cele odzyskiwania zgodnie z najlepszymi informacjami. Wyraźnie komunikują się z uczestnikami projektu, że wszystkie przepływy lub całe obciążenia, które nie są dokładnie przetestowane pod kątem metryk odzyskiwania, nie powinny mieć gwarantowanych umów SLA. Upewnij się, że uczestnicy projektu rozumieją, że cele odzyskiwania mogą ulec zmianie w miarę aktualizowania obciążeń. Obciążenie może stać się bardziej złożone w miarę dodawania klientów lub wdrażania nowych technologii w celu poprawy jakości obsługi klienta. Te zmiany mogą zwiększać lub zmniejszać metryki odzyskiwania.

Uwaga

MtBF może być trudne do zdefiniowania i zagwarantowania. Platformy jako usługa (PaaS) lub oprogramowanie jako usługa (SaaS) mogą zakończyć się niepowodzeniem i odzyskać bez powiadomienia od dostawcy usług w chmurze, a proces może być całkowicie niewidoczny dla Ciebie lub Twoich klientów. Jeśli zdefiniujesz cele dla tej metryki, uwzględnij tylko składniki, które znajdują się pod kontrolą.

Podczas definiowania celów odzyskiwania zdefiniuj progi inicjowania odzyskiwania. Jeśli na przykład węzeł internetowy jest niedostępny przez ponad 5 minut, nowy węzeł zostanie automatycznie dodany do puli. Zdefiniuj progi dla wszystkich składników, biorąc pod uwagę, jakie odzyskiwanie dla określonego składnika obejmuje, w tym wpływ na inne składniki i zależności. Progi powinny również uwzględniać błędy przejściowe , aby upewnić się, że akcje odzyskiwania nie są zbyt szybkie. Dokumentowanie i udostępnianie uczestnikom projektu potencjalnych zagrożeń związanych z operacjami odzyskiwania, takimi jak utrata danych lub przerwy w sesji dla klientów.

Tworzenie modelu kondycji

Użyj danych zebranych dla celów niezawodności, aby utworzyć model kondycji dla każdego obciążenia i skojarzone przepływy krytyczne. Model kondycji definiuje stan dobrej kondycji, obniżonej wydajności i złej kondycji dla przepływów i obciążeń. Stany zapewniają odpowiednią priorytetyzację operacyjną. Ten model jest również nazywany modelem sygnalizacji świetlnej. Model przypisuje kolor zielony dla dobrej kondycji, żółty dla obniżonej wydajności i czerwony w złej kondycji. Model kondycji zapewnia, że wiadomo, kiedy stan przepływu zmienia się ze dobrej kondycji na obniżoną kondycję lub jest w złej kondycji.

Sposób definiowania stanu dobrej kondycji, obniżonej wydajności i złej kondycji zależy od celów niezawodności. Poniżej przedstawiono kilka przykładów sposobów definiowania stanów:

• Zielony lub w dobrej kondycji wskazuje, że kluczowe wymagania i cele niefunkcjonalne są w pełni spełnione i że zasoby są używane optymalnie. Na przykład 95 procent żądań jest przetwarzanych w <=500 ms przy użyciu węzła Azure Kubernetes Service (AKS) na poziomie X procent.

• Żółty lub obniżony poziom wydajności wskazuje, że co najmniej jeden składnik przepływu wysyła alerty względem zdefiniowanego progu, ale przepływ działa. Na przykład wykryto ograniczanie przepustowości magazynu.

• Czerwony lub w złej kondycji oznacza, że degradacja trwała dłużej niż dozwolone przez cele niezawodności lub że przepływ stał się niedostępny.

Uwaga

Model kondycji nie powinien traktować wszystkich błędów tak samo. Model kondycji powinien rozróżniać błędy przejściowe i nietransientne . Powinno to wyraźnie odróżnić oczekiwane przejściowe, ale możliwe do odzyskania awarie i prawdziwy stan awarii.

Ten model działa przy użyciu strategii monitorowania i zgłaszania alertów, która została opracowana i obsługiwana zgodnie z zasadami ciągłego ulepszania. W miarę rozwoju obciążeń modele kondycji muszą ewoluować wraz z nimi.

Aby zapoznać się ze szczegółowymi zagadnieniami i zaleceniami dotyczącymi modelu kondycji aplikacji warstwowej, zobacz wskazówki dotyczące modelowania kondycji znalezione w obszarach projektowania obciążeń o krytycznym znaczeniu. Aby uzyskać szczegółowe wskazówki dotyczące monitorowania i konfigurowania alertów, zobacz przewodnik monitorowania kondycji .

Wizualizacja

Aby zapewnić zespołom operacyjnym i uczestnikom projektu obciążenia informacje o stanie czasu rzeczywistego i ogólnych trendach modelu kondycji obciążenia, rozważ utworzenie pulpitów nawigacyjnych w rozwiązaniu do monitorowania. Omówienie rozwiązań wizualizacji z osobami biorącymi udział w projekcie w celu zapewnienia, że dostarczasz informacje, które mają one wartość i które są łatwe do spożycia. Mogą również chcieć zobaczyć wygenerowane raporty co tydzień, co miesiąc lub kwartalnie.

Ułatwienia platformy Azure

Umowy SLA platformy Azure zapewniają zobowiązania firmy Microsoft dotyczące czasu pracy i łączności. Różne usługi mają różne umowy SLA, a czasami jednostki SKU w usłudze mają różne umowy SLA. Aby uzyskać więcej informacji, zobacz Umowy dotyczące poziomu usług dla Usługi online.

Umowa SLA platformy Azure obejmuje procedury uzyskiwania środków na korzystanie z usług, jeśli umowa SLA nie jest spełnina, wraz z definicjami dostępności dla każdej usługi. Ten aspekt umowy SLA działa jako zasady wymuszania.

Linki pokrewne

• Well-Architected Framework — wskazówki dotyczące modelowania kondycji: modelowanie kondycji i obserwowanie obciążeń o znaczeniu krytycznym na platformie Azure

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności