Zalecenia dotyczące definiowania celów niezawodności
Dotyczy tego zalecenia listy kontrolnej dotyczącej 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, aby negocjować, zdobywać konsensus, określać oczekiwania i prowadzić działania w celu osiągnięcia idealnego stanu. Użyj zdefiniowanych obiektów docelowych do skompilowania modelu kondycji. Model kondycji definiuje, 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. Należy czerpać cele dotyczące niezawodności z ćwiczeń warsztatowych z uczestnikami projektu biznesowego. Następnie uściślij te cele, monitorując i testując obciążenia.
Ustaw realistyczne oczekiwania z wewnętrznymi uczestnikami projektu na temat niezawodności obciążeń. Następnie mogą korzystać z umów umownych, aby przekazać te oczekiwania klientom. Realistyczne oczekiwania pomagają również uczestnikom projektu zrozumieć i wspierać decyzje projektowe dotyczące architektury oraz wiedzieć, że projektujesz w celu optymalnego spełnienia celów, na które się zgadzasz.
Rozważ użycie poniższych metryk w celu określenia ilościowych wymagań biznesowych.
| Termin | Definicja |
|---|---|
| Cel poziomu usług (SLO) | Miara wydajności i niezawodności obciążenia lub aplikacji. Cel slo to konkretny, wymierny cel ustawiony dla konkretnych interakcji z klientami. Jest to element docelowy ustawiony dla obciążenia lub aplikacji na podstawie jakości usług, które klienci oczekują otrzymania. |
| Wskaźnik poziomu usług (SLI) | Ilościowy pomiar konkretnego aspektu wydajności usługi. Możesz użyć SLI, aby zmierzyć zgodność obciążenia z slo. |
| Umowa dotycząca poziomu usług (SLA) | Umowa umowna między dostawcą usług a klientem obsługi. Niedopełnienie 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, przez który 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. |
Kluczowe strategie projektowania
Cele dotyczące niezawodności reprezentują żądany cel jakości obciążenia zgodnie z obietnicą dla użytkowników i uczestników projektu biznesowego. Ten cel obejmuje zarówno dostępność, jak i możliwość odzyskiwania obciążenia. Należy pamiętać, że cele dotyczące niezawodności różnią się od celów wydajności, ale należy uwzględnić cele wydajności w celach niezawodności. Rozważ następujące cele dotyczące niezawodności:
Cele dostępności definiują standardy jakości systemu, które mają pozostać dostępne i funkcjonalne. Jeśli nie spełnia tych standardów, system jest uznawany za zawodny. Użyj celów SLO, aby sprawdzić, czy system spełnia te standardy. Osoby biorące udział w projekcie biznesowym i technicznym współpracują, aby ustawić realistyczne cele SLO i rozważyć czynniki takie jak analiza porównawcza, środowisko użytkownika i profil obciążenia.
Cele poprawności zapewniają, że obciążenie prawidłowo wykonuje swoje funkcje z spójną jakością. Aby zmierzyć poprawność, kwantyfikuj wskaźniki obciążenia, aby można je było połączyć w ujednolicony, obiektywny wynik.
Cele odzyskiwania odpowiadają metryce RTO, RPO, MTTR i MTBF, które kwantyfikują skuteczność planów i testowania ciągłości działania i odzyskiwania po awarii.
Aby ustawić cele dotyczące niezawodności, interesariusze biznesowi definiują szerokie wymagania. Następnie eksperci techniczni oceniają bieżący stan obciążenia i pracują nad osiągnięciem i utrzymaniem celów dzięki monitorowaniu i alertom. Obie strony muszą uzgodnić realistyczne cele.
Zidentyfikuj i oceniaj przepływy użytkowników i systemów na podstawie ich znaczenia dla wymagań biznesowych. Użyj tych wyników, aby pokierować projektowaniem, przeglądem, testowaniem i zarządzaniem zdarzeniami obciążenia. Ustaw cele dotyczące niezawodności dla tych przepływów i dowiedz się, że niepowodzenie realizacji tych celów może znacząco wpłynąć na Twoją firmę.
Kompromis: może istnieć różnica między limitami technicznymi systemu a jego wpływem biznesowym, na przykład przepływnością a transakcjami na sekundę. Mostkowanie tej luki może być trudne. Dążyć do praktycznego i ekonomicznego rozwiązania zamiast nadmiernego inengineeringu.
Ustawianie celów dostępności
Ogólny cel slo obciążenia odzwierciedla całościową jakość, w tym wszystkie jego zależności. Dojrzała deklaracja slo powinna wskazywać ogólny cel biznesowy dla tego obciążenia, a nie tylko złożony z tych zależności. Jeśli na przykład klienci oczekują dostępności na 99,99%, ogólny cel SLO powinien dążyć do tego celu, nawet jeśli jedna część osiągnie tylko 99,80%.
Uczestnicy projektu oceniają środowisko klienta i zastanów się, jak przestój wpływa na przychody. Porównują tę stratę z kosztami projektowania i obsługi przepływu biznesowego. Decydenci zdecydują następnie, czy powinni wydać więcej pieniędzy na niezawodność, aby uniknąć utraty przychodów i utrzymać swoją reputację.
Właściciele obciążeń używają celów finansowych do określania celów. Wymagania biznesowe są mapowe na metryki mierzalne. Celem jest zidentyfikowanie zestawu czynników wpływających na jakość środowiska klienta.
Architekci obciążeń podejmują wiele decyzji technicznych w oparciu o cele SLO. Cele SLO mogą:
Podczas rozważania innych zależności należy służyć jako krytyczne dane wejściowe do decyzji dotyczących architektury.
Udostępnij widok niemal w czasie rzeczywistym i wspólne zrozumienie kondycji obciążenia, aby umożliwić obiektywne dyskusje. Pomagają również zespołowi ds. obciążeń ustalić priorytety wysiłków w celu poprawy niezawodności i opracowywania nowych funkcji.
Pełni rolę podstawowego sygnału dla operacji wdrażania, które napędzają automatyczne wycofywanie w przypadku wystąpienia problemów i zapewnia walidację, że zmiany osiągną oczekiwane ulepszenia środowiska klienta.
Przyspieszanie korygowania i odzyskiwania przez skupienie się na celach, automatyczne powiadamianie klientów o problemach i budowanie zaufania między zespołami w organizacji.
Ważne
Musisz znać różnicę między umowami SLA i umowami SLA. Mimo że umowy SLA i umowy SLA mogą używać podobnych danych, ich intencja jest inna. Umowa SLA to formalna umowa między organizacją a jej klientami, która ma bezpośrednie konsekwencje finansowe i prawne, jeśli organizacja nie spełnia swojej obietnicy. Organizacje używają celów SLO, aby ocenić, czy potencjalny przestój mieści się w dopuszczalnych limitach.
Umowy SLA i umowy SLA współdzielą relację biznesową i powinny być kontrolowane niezależnie. Jeśli umowa SLA służy jako taktyka biznesowa, organizacja może celowo ustawić ją na wartość wysoką na podstawie celów właściciela firmy. Z drugiej strony cele SLO mogą być wyższe. Rozważmy obciążenia o znaczeniu krytycznym jako przykład. Ta klasa obciążenia nie może sobie pozwolić na długie przestoje, ponieważ skutki, w tym straty finansowe, a nawet zagrożenia dla bezpieczeństwa ludzkiego, są znaczące. W związku z tym cele SLO zwykle są przeznaczone na 99,999% czasu pracy, powszechnie określane jako pięć dziewiątek. Jeśli cele slo nie spełniają tych celów, organizacje muszą szybko reagować, aby wyeliminować błędy i zapobiec wynikam umowy SLA, która zakończyła się niepowodzeniem.
Przykład w tym artykule określa wysoką umowę SLA w celu zapewnienia obsługi celów biznesowych.
Dostawcy platformy i technologii w chmurze publikują umowy SLA w swoich ofertach. Należy wziąć pod uwagę umowy SLA w ramach obliczeń SLO, ale nie należy ich używać, ponieważ nie należy ich używać bez zrozumienia zakresu pokrycia umowy SLA. Aby uzyskać więcej informacji, zobacz Ocena wpływu umów SLA firmy Microsoft.
Rozważ typowe cele SLO i wpływające na czynniki
Każdy cel slo jest przeznaczony dla określonych kryteriów jakości. Weź pod uwagę te typowe cele SLO w celu uzyskania niezawodności. Ta lista nie jest wyczerpująca. Dodaj cele SLO na podstawie wymagań biznesowych.
Wskaźnik powodzenia mierzy powodzenie żądań i procesów względem tych, które zwracają błąd lub kończą się niepowodzeniem.
Opóźnienie mierzy czas między chwilą zainicjowania żądania operacji a dostępnością wyniku lub ukończeniem procesu.
Pojemność mierzy współbieżne użycie, takie jak liczba odpowiedzi opartych na ograniczeniach.
Dostępność mierzy czas pracy z perspektywy klientów.
Przepływność mierzy minimalną szybkość transferu danych w określonym czasie. Przepływność jest mierzona jako jednostka szybkości danych, taka jak transakcje na sekundę (TPS) lub żądania na sekundę (RPS).
Poznaj scenariusze i tolerancje dla obciążenia na platformie Azure. Zarówno usługi platformy Azure, jak i składniki aplikacji wpływają na cel slo obciążenia. Połącz odpowiedzi z poniższej tabeli, aby uzyskać ogólny cel slo. Użyj tych pytań jako przykładów, aby ocenić narzędzie składnika obciążenia.
| Charakterystyka składników | Interakcje klientów | Inne czynniki |
|---|---|---|
| — Czy uwidacznia interfejsy API żądań lub odpowiedzi? — Czy ma on interfejsy API zapytań? - Czy jest to składnik obliczeniowy? - Czy jest to składnik przetwarzania zadań? |
- Dostęp do płaszczyzny sterowania i płaszczyzny zarządzania dla publicznych usług platformy Azure. - Dostęp do płaszczyzny danych, na przykład operacje tworzenia, odczytu, aktualizacji i usuwania (CRUD). |
— Czy proces wydawania obejmuje przestój? - Jakie jest prawdopodobieństwo wprowadzenia usterek? Jeśli obciążenie integruje się z innymi systemami, może być konieczne rozważenie usterek integracji. - Jak rutynowe operacje , takie jak stosowanie poprawek, wpływają na cel dostępności? Czy uwzględniono zależności partnerów? - Czy personel jest wystarczający , aby wspierać stałą kopię zapasową w nagłych wypadkach i nagłych wypadkach rotacji na wezwanie? - Czy aplikacja ma hałaśliwych sąsiadów poza zakresem kontroli, które mogą potencjalnie powodować zakłócenia? |
Określanie zakresu slo
Cele SLO można ustawić na różnych poziomach, takich jak dla każdej aplikacji, obciążenia lub określonego przepływu w systemie. Ustaw cele SLO specyficzne dla poziomu, aby można było dostosować cele SLO na podstawie ważności każdego składnika.
W rozwiązaniach oprogramowania jako usługi (SaaS) zmierz cele SLO na klienta, aby zoptymalizować środowisko każdego klienta. Klienci mogą mieć różne zasoby infrastruktury w swoich segmentach. W takich przypadkach cel slo obejmujący cały system, który agreguje wszystkie zasoby w różnych segmentach klientów, może nie mieć sensu. Zamiast tego zmierz cele SLO, które są zgodne z konkretnym kontekstem każdego klienta. Aby uzyskać więcej informacji, zobacz Modele dzierżawy dla rozwiązania wielodostępnego.
Definiowanie złożonych celów slo
Cele SLO muszą być wymierne i mierzone w oknie obserwacji.
Cele SLO są często procentami, takimi jak 99,90%, ale mogą być również instrukcjami. Użyj obu metod, aby uzyskać wartość liczbową zawierającą wszystkie czynniki.
Cel slo składa się z mierzalnych wskaźników SLI, które definiują dopuszczalne czynniki. Wskaźniki SLI to metryki z ustawionym progiem, który można otrzymywać alerty. Można je zbierać z platformy lub aplikacji. Różne składniki emitują odpowiednie wskaźniki SLA. Podczas wybierania wskaźników SLI należy wziąć pod uwagę czynniki wpływające na cel slo.
Na przykład aby obliczyć cel slo dla przepływu, który używa interfejsu API odpowiedzi i żądania, zmierz opóźnienie serwera i czas przetwarzania żądań. Współczynniki przepływności i błędów nie mają zastosowania do środowisk obliczeniowych ciągłych, takich jak maszyny wirtualne, zestawy skalowania ani usługa Azure Batch.
W przypadku dostępu do płaszczyzny sterowania rozważ współczynniki błędów i opóźnienia odpowiedzi interfejsu API oraz długotrwałe operacje, takie jak tworzenie zasobów. Dostęp do płaszczyzny danych zależy od używanych interfejsów API, z których każdy ma własne cele SLO.
Dobry SLI pokazuje, kiedy można naruszyć cel slo. Zwykle jest mierzona w percentylach. Poniżej przedstawiono niektóre często używane percentyle i szacowany czas niezgodności z oczekiwaną dostępnością.
| Cel cząstkowy | Niezgodność na tydzień | Niezgodność na miesiąc | Niezgodność na rok |
|---|---|---|---|
| 99% | 1,68 godz. | 7,20 godz. | 3,65 dnia |
| 99.90% | 10,10 minut | 43,20 minut | 8,76 godz. |
| 99,95% | 5 min | 21,60 minut | 4,38 godz. |
| 99,99% | 1,01 min | 4,32 min | 52,56 min |
| 99.999% | 6 s | 25,90 sekund | 5,26 min |
Ważne
Złożona wartość slo to rozkład produktu czynników przyczyniających się.
Przykładowy złożony cel SLO wynosi 99,95% × 99,99999% = ~99,95%.
Podczas tworzenia złożonych celów SLO dla różnych przepływów należy wziąć pod uwagę ich różną krytyczność i istotność. Przepływy mogą mieć składniki, które są uznawane za niekrytyczne i pomijane z obliczeń. Możesz uzasadnić ich pominięcie na podstawie tego, czy ich krótka niedostępność wpływa na środowisko klienta. W niektórych przypadkach składnik może nie być istotny dla przypadku użycia, który należy wziąć pod uwagę dla celu slo. Można również pominąć te składniki z obliczeń.
Ta sama zasada ma zastosowanie do operacji. Niektóre operacje mogą powodować ryzyko lub wpływać na cel slo, a inne są nieistotne. Decyzja powinna być wyraźna i oparta na konsensusie.
Ilustracyjny przykład sposobu definiowania i mierzenia celów SLO i SLI można znaleźć w sekcji Przykład .
Ocena wpływu umów SLA firmy Microsoft
Umowa SLA firmy Microsoft zapewnia wgląd w dostępność obszarów zatwierdzonych przez firmę Microsoft. Umowy SLA nie gwarantują oferty jako całości. Podczas oceniania umów SLA należy dobrze zrozumieć pokrycie, które jest dostępne wokół opublikowanego percentylu.
Rozważ użycie usługi Web Apps — funkcji usługi aplikacja systemu Azure Service. Funkcja jest uznawana za dostępną, gdy zwraca stan 200 OK w danym przypadku użycia. W ramach tego konkretnego kontekstu i przedziału czasu nie obejmuje ona finansowej gwarancji dostępności funkcji, takich jak Easy Auth lub przełączanie miejsc. Należy wziąć pod uwagę obszary, które nie zostały jawnie wymienione w umowie, zgodnie z najlepszymi rozwiązaniami platformy.
Jeśli zatem obciążenie opiera się na miejscach wdrożenia, nie można uzyskać celu slo wyłącznie z poziomu umowy SLA usługi App Service. Jako zespół ds. obciążeń musisz zabezpieczyć i przewidzieć dostępność czasu pracy. Jednak to przewidywanie może być niepewne, dlatego ścisłe wiązanie celu slo z umową SLA platformy może być problematyczne.
Rozważmy inny przykład. Jeśli usługa Azure Front Door ma dostępność na 99,99%, projekt musi być zgodny z określonymi kryteriami opublikowanymi w umowie. Na przykład zaplecze musi zawierać magazyn, potrzebna jest GET operacja, która może pobrać plik o rozmiarze co najmniej 50 KB, a agentów należy wdrożyć w wielu miejscach w co najmniej pięciu różnych lokalizacjach geograficznych. Ten wąski przypadek użycia usługi Azure Front Door nie gwarantuje funkcji, takich jak buforowanie, reguły routingu ani zapora aplikacji internetowej. Te aspekty wykraczają poza zakres umowy SLA.
Implementowanie obiektów docelowych w wielu regionach
Z perspektywy niezawodności wdrożenie wieloregionowe jest implementacją zasady nadmiarowości. Celem jest ograniczenie ryzyka awarii regionalnej lub obniżonej wydajności. Ta strategia, odpowiednio zaprojektowana, może poprawić cele SLO, ponieważ dodaje region pomocniczy do celów trybu failover.
Istnieją dwa główne przypadki użycia:
Wzorzec wysokiej dostępności, w którym obciążenie jest dystrybuowane między regionami w celu zwiększenia pojemności. Wysoka dostępność nie ogranicza użytkowników obciążeń do regionu, a wydajność całego systemu przyczynia się do celu slo.
Wzorzec grodziowy, w którym można ograniczyć klientów do określonych regionów w celu ich segmentowania. W takich przypadkach należy traktować wdrożenia wieloregionowe jako oddzielne wdrożenia lub sygnatury w każdym regionie. Zmierz kondycję każdej sygnatury oddzielnie, przy użyciu wskaźników SLI, które są odpowiednie dla obciążenia. Rozważ cel slo ogólnego obciążenia na podstawie kondycji każdej sygnatury. Jeśli możesz przejść w tryb failover między sygnaturami, ogólny cel slo obciążenia jest wyższy, ponieważ awaria w jednej sygnaturze można odzyskać za pośrednictwem przejścia w tryb failover do innej sygnatury.
Zwróć uwagę na to, ile nadmiarowości należy spełnić w przypadku wysokich celów SLO. Na przykład firma Microsoft gwarantuje wyższe umowy SLA dla wdrożeń w wielu regionach usługi Azure Cosmos DB niż gwarantuje wdrożenia w jednym regionie.
Definiowanie metryk odzyskiwania
Definicje realistycznych celów odzyskiwania, takich jak metryki RTO, RPO, MTTR i MTBF, opierają się na analizie trybu awarii oraz planach i testowaniu ciągłości działania i odzyskiwania po awarii. Podczas definiowania tych celów należy uwzględnić gwarancje odzyskiwania zapewniane przez platformę. Firma Microsoft publikuje gwarancje czasu odzyskiwania i celu punktu odzyskiwania tylko dla niektórych produktów, takich jak Usługa Azure SQL Database.
Przed zakończeniem tej pracy należy omówić cele aspiracyjne z uczestnikami projektu i upewnić się, że projekt architektury obsługuje cele odzyskiwania zgodnie z najlepszymi informacjami. Jasno 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ą się zmieniać wraz z upływem czasu podczas aktualizowania obciążeń. Obciążenie może stać się bardziej złożone podczas dodawania klientów lub wdrażania nowych technologii w celu poprawy jakości obsługi klienta. Te zmiany mogą zwiększyć lub zmniejszyć metryki odzyskiwania.
Uwaga
MtBF może być trudne do zdefiniowania i zagwarantowania. Modele platformy jako usługi (PaaS) lub 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 elementy docelowe dla tej metryki, obejmują tylko składniki, które znajdują się pod kontrolą.
Podczas definiowania celów odzyskiwania zdefiniuj progi w celu zainicjowania odzyskiwania. Jeśli na przykład węzeł internetowy jest niedostępny przez ponad pięć minut, automatycznie dodaj nowy węzeł do puli. Zdefiniuj progi dla wszystkich składników i zastanów się, co obejmuje odzyskiwanie określonego składnika, 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ń, takich jak utrata danych lub przerwy w sesji dla klientów, operacje odzyskiwania.
Monitorowanie i wizualizowanie obiektów docelowych
Użyj danych zbieranych dla celów niezawodności, aby utworzyć model kondycji dla każdego obciążenia i skojarzonych przepływów krytycznych. Model kondycji definiuje stany w dobrej kondycji, obniżonej wydajności i złej kondycji dla przepływów i obciążeń. Gdy stan ulegnie zmianie, model powinien otrzymywać alerty o odpowiedzialnych podmiotach. Aby zapoznać się ze szczegółowymi zagadnieniami i zaleceniami dotyczącymi projektowania, zobacz Wskazówki dotyczące modelowania kondycji.
Aby informować zespoły operacyjne i osoby biorące udział w projekcie obciążeń, utwórz wizualizację, która odzwierciedla stan w czasie rzeczywistym i ogólne trendy modelu kondycji obciążenia. Omówienie rozwiązań wizualizacji z osobami biorącymi udział w projekcie w celu zapewnienia, że dostarczasz informacje, które je cenią i które są łatwe do spożycia. Mogą również chcieć zobaczyć wygenerowane raporty co tydzień, co miesiąc lub co kwartał.
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 produkty w ramach usługi mają różne umowy SLA. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące Usługi online.
Umowa SLA platformy Azure obejmuje procedury uzyskiwania środków na korzystanie z usług, jeśli obciążenie nie spełnia umowy SLA wraz z definicjami dostępności dla każdej usługi. Ten aspekt umowy SLA działa jako zasady wymuszania.
Zapoznaj się z pulpitami nawigacyjnymi usługi Azure Monitor dla systemu wizualizacji.
Przykład
Firma Contoso, Ltd. projektuje nowe środowisko mobilne dla systemu obsługi biletów zdarzeń. Oto architektura wysokiego poziomu.
Logo Grafana jest znakiem towarowym swojej firmy. Użycie tego znaku oznacza nie jest dorozumiane.
Składniki
Poniżej przedstawiono niektóre składniki ilustrujące koncepcję definicji slo. W tej architekturze znajdują się składniki, które nie znajdują się na poniższej liście. Na przykład mimo że usługa Key Vault jest częścią krytycznego przepływu żądania, nie jest częścią przypadku użycia odpowiedzi. Jeśli usługa Key Vault jest niedostępna, aplikacja nadal działa przy użyciu wpisów tajnych ładowanych podczas uruchamiania. Jeśli jednak aplikacja musi być skalowana, dostępność usługi Key Vault stanie się krytyczna, ponieważ nowe węzły muszą zostać załadowane z wpisami tajnymi. W tym przykładzie operacje skalowania nie są brane pod uwagę. Inne składniki są pomijane w celu zwięzłości.
Usługa Azure Front Door to pojedynczy punkt wejścia, który uwidacznia interfejs API używany przez klientów do wysyłania żądań.
Usługa Azure Container Apps to środowisko, które jest właścicielem zespołu obciążeń i używa go do uruchamiania logiki biznesowej dla aplikacji.
Wystąpienie zarządzane SQL jest własnością innego zespołu i jest krytyczną zależnością obciążenia.
Usługa Azure Private Link zapewnia prywatną łączność między usługą Azure Front Door i wdrożeniami usługi Container Apps. Wystąpienie zarządzane SQL jest również udostępniane aplikacji za pośrednictwem prywatnego punktu końcowego.
W tej architekturze zespół interfejsu API definiuje początkowy cel slo dla krytycznych przepływów w aplikacji. Przyjmują strategię opisaną w temacie Czynniki wpływające na cele SLO. Mają one na celu zdefiniowanie celów, które obejmują podstawowe funkcje bez nadmiernego podkreślenia funkcji uzupełniających. Mierzy kondycję trzech krytycznych przepływów użytkownika, które obejmują wszystkie podstawowe funkcje chmury i wykonują kod we wszystkich wdrożeniach. Jednak te przepływy nie obejmują całego kodu ani dostępu do danych. Oto czynniki wpływające.
Obliczanie złożonego celu slo
Cel slo dotyczący dostępności platformy Azure: umowa SLA dotycząca zobowiązania finansowego dla platformy Azure służy jako serwer proxy do oceny niezawodności platformy.
Składnik platformy Azure Odpowiednie pokrycie umowy SLA Umowa SLA nie jest objęta umową SLA Skorygowany cel slo Azure Front Door 99,99% dla pomyślnych operacji HTTP GETBuforowanie, aparat reguł 99.98% Aplikacje kontenera 99,95% na podstawie wdrożonych aplikacji, które są osiągalne przez wbudowany ruch przychodzący Skalowanie automatyczne, możliwości magazynu tokenów 99,95% Wystąpienie zarządzane SQL 99,99% na podstawie połączenia z wystąpieniem programu SQL Server Wydajność, przechowywanie danych 99.80% Private Link 99,99% na podstawie całych minut, gdy sieć prywatnego punktu końcowego nie zaakceptowała ruchu lub gdy ruch nie przepływa między punktem końcowym a usługą Private Link Poszczególne błędy trwające krócej niż minutę 99,99% Korekta jest oparta na kilku czynnikach, które zależą od obietnicy zespołu obciążenia do celów. Jednym z czynników może być zaufanie do możliwości platformy w oparciu o wcześniejsze doświadczenie. Na przykład w przypadku usługi Container Apps i Private Link zespół czuje się komfortowo, biorąc wartość umowy SLA w następujący sposób.
Istnieją również czynniki zniuansowane. Na przykład zespół obniża wartość celu slo dla usługi SQL Managed Instance do 99,80%, aby uwzględnić potencjalne błędy w operacjach danych, takie jak zmiany schematu i tworzenie kopii zapasowych.
Zespół ustawia złożony cel slo, obliczając wpływ poszczególnych, skorygowanych wartości SLO. Ta wartość wynosi 99,72%.
Istnieją inne czynniki przyczyniające się do tego celu. Architektura opiera się na składnikach sieciowych platformy Azure, takich jak sieci wirtualne i sieciowe grupy zabezpieczeń, które nie mają opublikowanej umowy SLA. Zespół ds. obciążeń decyduje się wziąć pod uwagę te czynniki o dostępności 99,99% dla każdego składnika.
Złożony cel slo oparty na przewidywanej dostępności platformy: 99,68% miesięcznie.
Cel slo kodu aplikacji: Zespół potwierdza, że usterki w kodzie aplikacji lub procedurach składowanych mogą mieć wpływ na dostępność systemu i przydzielą jedną godzinę miesięcznego przestoju, aby uwzględnić błędy związane z kodem.
Używają one typowych percentyli przestojów do oszacowania celu slo dla poszczególnych czynników, takich jak wady kodu, problemy ze skalowaniem i inne zagadnienia związane z kodem.
Złożony cel slo oparty na kodzie i dostępności danych: 99,86% miesięcznie.
Cel slo konfiguracji zasobów i aplikacji: zespół rozpoznaje, że zasoby w chmurze i kod aplikacji muszą być prawidłowo skonfigurowane. Ten element docelowy obejmuje konfigurowanie reguł skalowania automatycznego, wdrażanie reguł sieciowej grupy zabezpieczeń i wybieranie prawidłowego rozmiaru jednostek SKU. Aby uwzględnić błędy konfiguracji, budżetuje 10 minut miesięcznego przestoju, czyli około 99,98% dostępności.
Złożony cel slo oparty na dostępności konfiguracji: 99,95% miesięcznie.
Cel slo operacji: Zespół ds. obciążeń opracowuje dobrą kulturę DevOps, postępując zgodnie z zasadami dobrze zaprojektowanej struktury dla doskonałości operacyjnej. Wdrażają zasoby w chmurze, konfigurację i kodują każdy przebieg.
Zespół uważa wdrożenia za ryzyko, ponieważ mogą zdestabilizować uruchomiony system. W wyniku aktualizacji certyfikatu TLS, zmian DNS lub błędów narzędzi mogą występować błędy. Zespół rozważa również potencjalne przestoje spowodowane przez poprawki awaryjne. Budżetują łącznie 20 minut miesięcznego przestoju, który wynosi około 99,95% dostępności.
Okna obsługi są wyznaczonymi okresami, w których następuje konserwacja lub aktualizacje systemu. Interfejs API jest przeważnie nieużywany przez około cztery godziny każdego dnia. Aby zmniejszyć ryzyko niedostępności, zespół może zaplanować zadania konserwacji w tych mniej aktywnych godzinach. Takie podejście prowadzi do wyższego celu slo, ale zespół decyduje się nie uwzględnić okna obsługi w ramach celu slo.
Złożony cel slo oparty na dostępności operacji: 99,95% miesięcznie.
Cel slo zależności zewnętrznych: Zespół uważa wystąpienie zarządzane SQL za podstawową zależność, która ma już 99,80% dostępności uwzględnianą w ogólnej dostępności platformy. Nie są brane pod uwagę żadne inne zależności zewnętrzne.
Złożony cel slo oparty na zależnościach zewnętrznych: Nie dotyczy.
Określanie ogólnego wyniku złożonego celu slo
Ogólny cel slo złożony jest ustawiony na 99,45%, co odpowiada około czterech godzinom przestoju miesięcznie.
Aby spełnić cel slo tylko cztery godziny niedostępności miesięcznie, zespół obciążenia ustanawia rotację na wywołaniach. Zarówno obsługa klienta, jak i syntetyczne monitorowanie transakcji mogą wywoływać obsługę inżynierii niezawodności lokacji (SRE, site reliability engineering) w celu szybkiego rozpoczęcia kroków odzyskiwania w celu rozwiązania problemów ze slo.
Ustawianie umowy SLA obciążenia
Umowa SLA dla obciążenia wynosi 99,90% dostępności miesięcznie.
Działy prawne i finansowe zespołu ds. obciążeń ustawiły umowę SLA dla obciążenia na poziomie 99,90% dostępności miesięcznie, co przekracza cel slo na poziomie 99,45%. Podejmuje tę decyzję po przeanalizowaniu wypłat finansowych w porównaniu z przewidywanym wzrostem klientów w oparciu o atrakcyjną umowę SLA. Umowa SLA obejmuje dwa podstawowe przepływy użytkowników i obejmuje zagadnienia dotyczące wydajności, a nie tylko dostępność. Jest to obliczone ryzyko podjęte przez zespół biznesowy, aby czerpać korzyści z działalności biznesowej, a zespół inżynierów jest świadomy zobowiązania.
Ustawianie celu slo poprawności
Podstawowe przepływy użytkowników aplikacji muszą być dostępne i odpowiednio, a nawet konkurencyjne, dynamiczne. Zespół ustawia cel slo czasu odpowiedzi specjalnie dla interfejsu API, z wyłączeniem czasu przetwarzania klienta i przechodzenia przez sieć internetową. Oceniają ten cel slo tylko w okresach dostępności. Wybierają 75. percentyl jako cel slo i miarę wydajności, która przechwytuje typowe środowisko klienta i wyklucza scenariusze z najgorszymi przypadkami.
Pokrewne łącza
Modelowanie kondycji i obserwowanie obciążeń o krytycznym znaczeniu na platformie Azure
Lista kontrolna dotycząca niezawodności
Zapoznaj się z pełnym zestawem zaleceń.