Rekomendacje dotyczące definiowania celów niezawodności
Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej niezawodności Well-Architected Reliability:
| RE:04 | Zdefiniuj wartości docelowe niezawodności i odzyskiwania dla składników, przepływów i całego rozwiązania. Zwizualizuj cele do negocjacji, uzyskaj i ustaw oczekiwania oraz ustaw działania mające na celu osiągnięcie idealnego stanu. Do tworzenia modelu kondycji można użyć zdefiniowanych wartości docelowych. Model kondycji definiuje stany, które są w dobrej kondycji, pogarszającej się kondycji i w złej kondycji. |
|---|
W tym przewodniku opisano rekomendacje dotyczące definiowania metryk docelowych dostępności i odzyskiwania dla obciążeń o znaczeniu krytycznym. Cele niezawodności są pochodne dzięki ćwiczeniom na warsztatach z interesariuszami biznesowymi.
Wartości docelowe zostały ulepszone dzięki monitorowaniu i testom. Należy pracować z wewnętrznymi interesariuszami w celu ustanowienia oczekiwań niezawodności. To ćwiczenie pomoże także interesariuszom w zakresie wyboru projektu architektury i zrozumieniu, że projektujesz, aby jak najlepiej spełniać uzgodnione cele.
Microsoft Power Platform umożliwia obsługę większości zagadnień dotyczących dostępności i niezawodności na poziomie infrastruktury. Jednak odpowiedzialność za dostępność budowanych obciążeń należy do Ciebie. Ważne jest, aby zrozumieć, że nawet przy Microsoft zaangażowaniu w wysoką dostępność ryzyko przestoju systemu nigdy nie jest zerowe.
Rozważ użycie następujących metryk do ilościowego określania wymagań biznesowych.
| Termin | Definicja |
|---|---|
| Cel poziomu usług (SLO) | Wartość docelowa procentowa reprezentująca stan składnika i warstwy niezawodności. Im wyższa warstwa, tym bardziej wiarygodne jest składnik. Złożona umowa SLO reprezentuje zagregowany element docelowy całego obciążenia i odpowiada za SLO składników. |
| Wskaźniki na poziomie usługi (SLI) | Metryka emitowana przez usługę. Metryki SLI są agregowane w celu ilościowego określenia wartości SLO. |
| Umowa dotycząca poziomu usług (SLA) | Umowa kontraktowa zawarta między dostawcą usługi a klientem usługi. Umowa definiuje SLO. Niepowodzenie umowy może spowodować konsekwencje finansowe dla dostawcy usługi. |
| Czas średni do odzyskiwania (MTTR) | Czas przywracania składnika po wykryciu błędu. |
| Średni czas między niepowodzeniem (MTBF) | Czas trwania, dla którego obciążenia mogą wykonywać oczekiwane funkcje bez przerwy, do momentu jego awarii. |
| Cel czasu odzyskiwania (RTO) | Maksymalny dopuszczalny czas, w czasie, gdy aplikacja nie może być dostępna po zdarzeniu. |
| Cel punktu odzyskiwania (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żytkowników i systemów. Zidentyfikuj i oceń te przepływy według tego, jak krytyczne są dla Twoich wymagań. Użyj tych wartości, aby obciążenia związanego z architekturą, przeglądem, testowaniem i zarządzaniem zdarzeniami. Niepowodzenie realizacji celów wpłynie na działalność poza poziomem tolerancji.
Kluczowe strategie projektowania
Dyskusje techniczne nie powinny stymulować sposobu definiowania wartości docelowych niezawodności dla przepływów krytycznych. Zamiast tego interesariusze biznesowi powinni się skoncentrować na swoich wymaganiach i oczekiwaniach użytkowników końcowych w zakresie obciążenia. Eksperci techniczni pomagają interesariuszom w przypisywaniu liczbowych wartości spełniających te wymagania. Wymiana informacji pozwala ekspertom technicznym na dyskusję i zawarcie umowy w sprawie dopuszczalnych SLO.
Rozważ przykład mapowania wymagań na mierzalne wartości numeryczne. Interesariusze szacują, że w przypadku krytycznego przepływu użytkowników godzina przestoju w godzinach pracy powoduje utratę X dolarów w przychodzie miesięcznym. Ta kwota w dolaraxh jest porównywana z szacowanym kosztem projektowania przepływu, w przypadku dostępności SLO 99,95 procent, a nie 99,9 procent. Przed podjęciem decyzji należy określić, czy ryzyko utraty przychodów nie zmniejsza dodanych kosztów i nie jest konieczne do zarządzania, aby chronić je.
Postępuj zgodnie z tym wzorcem podczas analizy przepływów i tworzenia pełnej listy wartości docelowych.
Należy pamiętać, że wartości docelowe niezawodności różnią się od wartości docelowych wydajności. Celem niezawodności jest skupienie się na dostępności i odzyskiwaniu danych. Aby ustawić cele niezawodności, należy rozpocząć od zdefiniowania jak najmniejszej liczby wymagań, a następnie zdefiniowanie bardziej konkretnych metryk spełniających najwyższe wymagania.
Wymagania dotyczące niezawodności i odzyskiwania najwyższego poziomu oraz korelowane metryki mogą obejmować na przykład dostępność aplikacji 99,9 procent dla wszystkich regionów lub docelowy poziom RTO 5 godzin dla regionu Ameryka. Zdefiniowanie tych typów celów pomaga określić, które przepływy krytyczne są związane z tymi celami. Następnie można rozważyć wartości docelowe na poziomie składnika.
Metryki dostępności
Wartości docelowe dostępności odpowiadają metrykom SLO, SLA i SLI.
SLO i SLA
Metryki dostępności korelują z wartościami SLO, które są używać do definiowania wartości SLA. SLO obciążenia określa, ile przestojów można zrównać w danym okresie; na przykład mniej niż 1 godzina na miesiąc. Aby upewnić się, że możesz osiągnąć cel SLO, przejrzyj Microsoft umowy SLA dla każdego składnika.
Aby ustanowić swoje SLO, pomyśl o:
Wymagania niefunkcyjne obciążenia (na przykład wskaźniki szczytowych żądań, użytkownicy współbieżni) w ciągu najbliższych 1–2 lat.
Dostępne metryki dotyczące tego, co można mierzyć w danym okresie. Te dane będą informować o tym, jakie SLI należy określić.
Po zebraniu umów SLA dla poszczególnych składników obciążenia należy obliczyć złożoną umowę SLA. Złożona umowy SLA powinny być zgodne z docelowym SLO obciążenia. Obliczanie złożonej umowy SLA obejmuje kilka czynników, w zależności od projektu architektury.
Definiowanie odpowiednich SLO wymaga czasu i dokładnego rozważenia. Interesariusze biznesowi powinni poznać bezpieczeństwo danych. Te opinie powinny poinformować o celach.
Wartości SLA
W poniższej tabeli zdefiniowano typowe wartości SLA.
| SLA | Przestój na tydzień | Przestój na miesiąc | Przestój na rok |
|---|---|---|---|
| 99% | 1.68 godziny | 7.2 godziny | 3.65 dni |
| 99,9% | 10.1 min | 43.2 min | 8.76 godziny |
| 99,95% | 5 min | 21.6 min | 4.38 godziny |
| 99,99% | 1.01 min | 4.32 min | 52.56 min |
| 99,999% | 6 s | 25.9 s | 5.26 min |
Myśląc o złożonych umowach SLA w kontekście przepływów użytkowników i systemów należy pamiętać, że różne przepływy użytkowników i systemów mają różne definicje krytyczności. Podczas tworzenia złożonych SLA należy uwzględnić te różnice. Przepływy niekrytyczne mogą zawierać składniki, które należy pominąć w obliczeniach, ponieważ nie wpływają na obsługę klienta, jeśli nie są dostępne.
SLI
Można pomyśleć o składnikach SLI jako metrykach na poziomie składnika, które wpływają na SLO. Najważniejsze SLI to te, które wpływają na przepływy krytyczne z punktu widzenia klientów. W przypadku wielu przepływów umowy SLA obejmują przepustowość, wydajność, poziom błędów i dostępność. Dobre rozwiązanie SLI jest pomocne w identyfikowaniu SLO narażonych na ryzyko naruszenia. W miarę możliwości należy korelować SLI z określonymi klientami.
Aby uniknąć zbierania bezużytecznych metryk, należy ograniczyć liczbę wskaźników SLI dla każdego przepływu. W miarę możliwości celem jest posiadanie trzech SLI dla przepływu.
Metryki odzyskiwania
Wartości docelowe odzyskiwania odpowiadają metrykom 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 Microsoft umów SLA. Microsoft publikuje gwarancje czasu odzyskiwania i celu punktu odzyskiwania tylko dla niektórych produktów, takich jak SQL Database.
Definicje realistycznych celów w zakresie odzyskiwania danych polegają na analizie trybu awarii oraz planach i testowaniu pod kątem ciągłości działania i odzyskiwania po awarii. Przed zakończeniem tej pracy należy omówić z interesariuszami cele, do których aspirują, i upewnić się, że projekt architektury zapewnia wsparcie celów w zakresie odzyskiwania danych zgodnie z Twoją najlepszą wiedzą. Należy wyraźnie komunikować się z interesariuszami, że żadne części obciążenia, które nie są dokładnie testowane pod kątem metryk odzyskiwania, nie powinny mieć gwarancji SLA. Upewnij się, że interesariusze rozumieją, że wartości docelowe odzyskiwania mogą zmieniać się w czasie, gdy są aktualizowane obciążenia. Obciążenie może być bardziej złożone, gdy nowe technologie poprawiają sposób pracy użytkownika. Te zmiany mogą zwiększyć lub zmniejszyć metryki odzyskiwania danych.
Uwaga
MTBF może być trudnym elementem do zdefiniowania i gwarantowania. Platformy jako usługa (PaaS) lub oprogramowanie jako usługa (SaaS) mogą zakończyć się błędem i odzyskać bez powiadomienia dostawcy usługi w chmurze, a proces może być całkowicie przejrzysty dla użytkownika. W przypadku definiowania wartości docelowych tej metryki należy obejmować tylko składniki pod kontrolą.
Budowanie modelu kondycji
Zebrane dane na potrzeby celów niezawodności są wykorzystywane do tworzenia modelu kondycji dla każdego obciążenia i skojarzonych z nimi przepływów krytycznych. Model kondycji definiuje stany dobrej, pogorszonej i złej kondycji* dla przepływów i obciążeń. Stany zapewniają odpowiednią priorytety operacyjne. Ten model jest również nazywany modelem sygnalizacji świetlnej. W modelu jest przypisywany kolor zielony do dobrej kondycji, żółty do pogorszonej i czerwony do złej. Model kondycji pozwala zagwarantować, że wiadomo, kiedy stan przepływu zmienia się z dobrej kondycji na pogorszoną lub złą.
Sposób definiowania stanów dobrej, pogorszonej lub złej kondycji zależy od wartości docelowych niezawodności. Oto kilka przykładów sposobów definiowania stanów:
Stan zielony lub dobrej kondycji oznacza, że kluczowe wymagania i wartości docelowe są w pełni spełnione i że zasoby są używane w optymalnej formie.
Stan żółty lub pogorszonej kondycji wskazuje, że dla jednego lub większej liczby składników przepływu są alerty dotyczące zdefiniowanego progu, ale przepływ jest operacyjny. Na przykład wykryto ograniczanie magazynów.
Stan czerwony lub zlej kondycji oznacza, że obniżenie jakości występuje dłużej niż zezwala na to cel niezawodności lub że przepływ stał się niedostępny.
Uwaga
Model kondycji nie powinien traktować wszystkich awarii tak samo. Model kondycji powinien rozróżniać błędy przejściowe i nieprzejściowe . Należy wyraźnie rozróżniać błędy, które można odzyskać, i stany prawdziwej katastrofy.
Model działa w oparciu o strategię monitorowania i alertów, która jest opracowywana i obsługiwana z wykorzystaniem zasad doskonalenia w sposób ciągły. Wraz z rozwojem prac trzeba rozwijać swoje modele kondycji.
Szczegółowe wskazówki dotyczące konfiguracji monitorowania i alertów można znaleźć w przewodniku po monitorowaniu kondycji.
Wizualizacja
Aby zespoły operacyjne i udziałowcy w zakresie obciążenia zostali poinformowani o stanie w czasie rzeczywistym i ogólnych trendach modelu kondycji obciążenia, należy rozważyć utworzenie pulpitów nawigacyjnych w rozwiązaniu do monitorowania. Rozwiązania do wizualizacji należy omawiać z interesariuszami, aby zapewnić, że dostarczasz im informacje, które będą dla nich łatwo wykorzystywane i łatwo je zużywają. Mogą także chcieć wyświetlić generowane raporty tygodniowo, miesięcznie lub kwartalnie.
Ułatwienia Power Platform
Power Platform Umowy SLA zawierają Microsoft zobowiązania dotyczące czasu pracy i łączności. Różne usługi mają różne umowy SLA, a czasami jednostki SKU w ramach usługi mają różne umowy SLA. Aby uzyskać więcej informacji, zobacz umowy dotyczące poziomu usług dotyczące usług online.
Umowy Power Platform SLA zawierają procedury uzyskiwania kredytu związanego z usługą, jeśli nie są spełnione warunki SLA, oraz definicje dostępności dla każdej usługi. Ten aspekt umowy SLA pełni rolę zasad ochrony porządku publicznego.
Microsoft Aplikacje biznesowe zapewniają funkcje ciągłości działania i odzyskiwania po awarii (BCDR) dla wszystkich środowisk produkcyjnych w aplikacjach Dynamics 365 i Power Platform SaaS. Dowiedz się, jak Microsoft zapewnić odporność danych produkcyjnych na regionalne przestoje.
Dopasowanie organizacyjne
Cloud Adoption Framework zapewnia zalecenia dotyczące umowy SLO i SLI związane z monitorowaniem w całej organizacji.
Aby uzyskać więcej informacji, zobacz SLO dotyczące monitorowania chmury.
Lista kontrolna niezawodności
Zapoznaj się z kompletną zestawem zaleceń.