Model dojrzałości niezawodności

Zbuduj solidne podstawy do odporności w infrastrukturze i operacjach obciążenia, zamiast koncentrować się na zadaniach optymalizacji.

Poziom 1 modelu dojrzałości został zaprojektowany, aby pomóc zespołom ds. obciążeń stworzyć silną podstawę dla niezawodności systemu. Skupia się na inicjowaniu, który polega na konfigurowaniu podstawowych elementów dla przyszłych decyzji dotyczących niezawodności. Ten etap obejmuje głównie implementację funkcjonalną z drobnymi rozszerzeniami do bieżących rozwiązań.

Ten etap obejmuje badania, uzyskiwanie szczegółowych informacji i tworzenie spisu systemów. Korzysta również z wbudowanych funkcji niezawodności na platformie Azure, takich jak wdrożenie nadmiarowości strefowej, aby natychmiast uzyskać ulepszenia.

Tworząc te podstawy, możesz przygotować swój zespół do przejścia przez poziomy modelu dojrzałości niezawodności, aby stopniowo zwiększyć odporność i wydajność systemu.

Kluczowe strategie

√ Ocena możliwości odciążania odpowiedzialności operacyjnej

Ta strategia jest zasadniczo budowaniem a nie kupowaniem lub poleganiem. Decyzja zależy od tego, ile odpowiedzialności można zarządzać na tym etapie, przy jednoczesnym wspieraniu przyszłego rozwoju. Chcesz używać zasobów, które są istotne dla obciążenia, ale zawsze należy szukać sposobów na delegowanie ich konserwacji. Poniżej przedstawiono niektóre klasyczne przypadki użycia, w których warto zastosować to podejście.

• Odciążaj odpowiedzialność za platformę w chmurze , wybierając rozwiązania paaS (platform as a service). Zapewniają one gotowe rozwiązania do typowych potrzeb zapewnienia odporności, takich jak replikacja, przełączanie awaryjne i magazyny kopii zapasowych. W przypadku tego podejścia dostawca usług w chmurze obsługuje ulepszenia hostingu, konserwacji i odporności.

  Na przykład dostawca usług w chmurze replikuje dane między wieloma węzłami obliczeniowymi i dystrybuuje repliki w różnych strefach dostępności. Jeśli tworzysz własne rozwiązanie na maszynach wirtualnych, musisz samodzielnie zarządzać tymi aspektami, co może być czasochłonne i złożone.

• Przekazywanie obowiązków związanych z operacjami, które nie są bezpośrednio powiązane z celami biznesowymi obciążenia roboczego. Niektóre wyspecjalizowane operacje, takie jak zarządzanie bazami danych i zabezpieczenia, mogą potencjalnie wpływać na niezawodność obciążenia. Rozważ możliwość powierzania tych zadań doświadczonym zespołom, technologii lub obu jednocześnie.

  Jeśli na przykład twój zespół nie ma wiedzy na temat bazy danych, skorzystaj z usług zarządzanych, aby pomóc w przesunięciu odpowiedzialności dostawcy. Takie podejście może być przydatne podczas uruchamiania, ponieważ umożliwia zespołowi skupienie się na funkcjonalności pracy. Wiele przedsiębiorstw współużytkuje usługi zarządzane centralnie. Jeśli są dostępne zespoły platformy, użyj ich do obsługi tych operacji. Jednak takie podejście może dodawać zależności i złożoność organizacyjną.

  Alternatywnie, jeśli twój zespół ma odpowiednią wiedzę, możesz podjąć wyraźną decyzję o wykorzystaniu swoich umiejętności i wybraniu usług, które nie obejmują możliwości zarządzania.

• Odciążanie obowiązków od dostawców innych niż Microsoft. Wybierz produkty gotowe jako punkt wyjścia. Twórz niestandardowe rozwiązania tylko wtedy, gdy przyczyniają się one do wartości biznesowej twojego obciążenia pracy.

Ryzyko: Jeśli opcja zakupu lub opierania się na częściowo spełnia twoje wymagania, może być konieczne zaimplementowanie niestandardowych rozszerzeń. Ta metoda może spowodować sytuację "blokady dostosowywania", w której aktualizacje i modernizacja stają się niepraktyczne. Regularnie sprawdzaj wymagania i porównuj je z możliwościami rozwiązania. Opracuj strategię wyjścia, jeśli istnieje znaczne odchylenie między nimi.

Przeciwny scenariusz jest również ryzykiem. Chociaż opcja zakupu lub polegania może wydawać się prostsza na początku, może wymagać ponownej oceny i przeprojektowania później, jeśli ograniczenia usługi PaaS, rozwiązania dostawcy lub zasobów należących do platformy nie spełniają niezbędnego stopnia szczegółowości lub poziomu autonomii wymaganej dla obciążenia.

√ Identyfikowanie krytycznych przepływów użytkownika i systemu

Podział obciążenia na przepływy ma kluczowe znaczenie na tym etapie. Skoncentruj się na przepływach użytkowników i systemów . Przepływy użytkowników określają interakcje użytkowników, a przepływy systemowe określają komunikację między składnikami obciążenia, które nie są bezpośrednio skojarzone z zadaniami użytkownika.

Na przykład w aplikacji do handlu elektronicznego klienci wykonują działania frontonu, takie jak przeglądanie i zamawianie. Tymczasem transakcje zaplecza i procesy wyzwalane przez system spełniają żądania użytkowników i obsługują inne zadania. Te odrębne przepływy są częścią tego samego systemu, ale obejmują różne składniki i służą różnym celom.

Rozpocznij tworzenie wykazu przepływów na tym etapie. Obserwuj interakcje użytkowników i komunikację składników. Lista i kategoryzowanie przepływów, definiowanie ich punktów początkowych i końcowych oraz notowanie zależności. Dokumentowanie wyników i wyjątków przy użyciu diagramów w celu uzyskania przejrzystości. Ten wykaz może służyć jako ważne narzędzie do początkowej rozmowy z osobami biorącymi udział w projekcie biznesowym w celu zidentyfikowania najważniejszych aspektów z ich perspektywy. Ta rozmowa może wpłynąć na pierwszy poziom priorytetyzacji.

Klasyfikuj przepływ jako krytyczny, oceniając ryzyko i wpływ na podstawowe działania biznesowe. Jeśli spodziewasz się awarii, kontrolowane obniżanie funkcjonalności koncentruje się na utrzymywaniu tych krytycznych przepływów. W przykładzie handlu elektronicznego krytyczne przepływy obejmują wyszukiwanie produktów, dodawanie elementów do koszyka i finalizację zakupu, ponieważ te zadania są kluczowe dla działalności. Inne procesy, takie jak aktualizowanie danych produktów i utrzymywanie obrazów produktów, nie są tak krytyczne. Upewnij się, że krytyczne przepływy pozostają operacyjne podczas przestoju, aby zapobiec utracie przychodów, umożliwiając użytkownikom dalsze wyszukiwanie produktów i dodawanie elementów do koszyka.

Aby uzyskać więcej informacji, zobacz Azure Well-Architected Framework: Optymalizowanie projektowania obciążeń przy użyciu przepływów.

√ Wybieranie odpowiedniego modelu projektowego, zasobów i funkcji

Należy zastosować tę strategię na następujących poziomach:

• Architektura: Projekt obciążenia powinien uwzględniać oczekiwania dotyczące niezawodności w różnych warstwach infrastruktury. Początkowe decyzje mogą być wyborem między konteneryzacją lub usługą PaaS na potrzeby hostowania aplikacji. Możesz też rozważyć konfiguracje sieci, takie jak konfiguracja gwiaździsta lub pojedyncza sieć wirtualna.

  Należy również ustawić granice, które tworzą segmentację na podstawie funkcjonalności. Na przykład zamiast hostować wszystko na jednej maszynie wirtualnej z dyskiem wirtualnym z jedną strefą, rozważ podzielenie magazynu obliczeniowego i magazynu danych oraz użycie dedykowanych usług.

  Ostrzeżenie

  W scenariuszach migracji wdrożenie podejścia lift-and-shift bez przeglądania nowych możliwości może prowadzić do nieodebranych korzyści i nieefektywności. Ważne jest, aby wcześnie zbadać modernizację, aby uniknąć utknięcia w konfiguracjach, które są trudne do zmiany i korzystać z lepszych opcji i ulepszeń.

• Usługi platformy Azure: Użyj drzew decyzyjnych, aby ułatwić wybór odpowiednich usług dla projektu. Wybierz składniki spełniające bieżące potrzeby, ale pozostają elastyczne, dzięki czemu możesz przełączać usługi w miarę rozwoju obciążenia i wymagać większej liczby funkcji.

• Jednostki SKU lub warstwy w ramach usług platformy Azure: Przejrzyj funkcje każdej jednostki SKU i zapoznaj się z gwarancjami dostępności platformy. Oceń umowy o poziom usług, aby zrozumieć zakres pokrycia w odniesieniu do opublikowanego percentyla.

• Funkcje, które obsługują niezawodność: Wybierz usługi natywne dla chmury, aby zwiększyć dostępność za pomocą prostych konfiguracji bez zmiany kodu. Ważne jest, aby zrozumieć opcje i celowo wybrać konfiguracje, takie jak zwiększenie nadmiarowości strefy lub replikowanie danych do regionu pomocniczego.

√ Wdrażanie przy użyciu podstawowego poziomu nadmiarowości

W każdej części rozwiązania unikaj pojedynczych punktów awarii, takich jak pojedyncze wystąpienia. Zamiast tego utwórz wiele wystąpień, aby zapewnić nadmiarowość. Usługi platformy Azure często obsługują nadmiarowość, szczególnie w przypadku usług PaaS, które zwykle obejmują lokalną nadmiarowość domyślnie i opcje uaktualniania. Najlepiej użyć strefowej nadmiarowości, aby rozłożyć te wystąpienia w wielu centrach danych Azure. Jeśli tego nie zrobisz, przynajmniej zapewnij nadmiarowość lokalną, jednak ten sposób niesie ze sobą większe ryzyko. W przyszłych poziomach oceniasz, czy wymagania dotyczące niezawodności mogą być spełnione, rozszerzając rozwiązanie za pomocą składników geograficznie nadmiarowych.

Kompromis: Jednym z kluczowych kosztów alternatywnych jest zwiększony koszt nadmiarowości. Ponadto komunikacja między strefami może powodować opóźnienie. W przypadku starszych aplikacji, które wymagają minimalnego opóźnienia, nadmiarowość może obniżyć wydajność.

Ryzyko: Jeśli aplikacja nie jest przeznaczona dla środowiska z wieloma wystąpieniami, może mieć problemy z wieloma aktywnymi wystąpieniami, co może prowadzić do niespójnych danych. Ponadto jeśli aplikacja została utworzona dla konfiguracji lokalnej, która ma małe opóźnienia, użycie stref dostępności może zakłócić jej wydajność.

√ Włączanie metryk, dzienników i śladów w celu monitorowania przepływów

Wybierz narzędzia natywne dla platformy, takie jak Azure Monitor, aby zapewnić widoczność metryk, dzienników i śladów. Użyj wbudowanych funkcji, aby ustawić alerty pod kątem potencjalnych problemów. Musisz mieć podstawowe alerty, aby wysyłać powiadomienia i otrzymywać alerty. Skorzystaj z możliwości platformy Azure, które wskazują zmiany stanu kondycji usług, takich jak:

• Usługa Azure Service Health w celu sprawdzenia stanu kondycji na poziomie platformy.

• Usługa Azure Resource Health umożliwia sprawdzenie stanu kondycji na poziomie zasobu.

Skonfiguruj grupy akcji usługi Azure Monitor dla infrastruktury i aplikacji.

Kompromis: Zbierając więcej dzienników, należy zarządzać rosnącym wolumenem, co wpływa na koszty związane z przechowywaniem tych dzienników. Użyj zasad przechowywania, aby zarządzać woluminem. Użyj usługi Azure Monitor, aby ustawić dzienny limit w obszarze roboczym. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące konfiguracji dotyczące niezawodności.

Rozpocznij budowanie obserwowalności w opisanych poniżej warstwach.

Infrastruktura

Zacznij od włączenia dzienników diagnostycznych i upewnienia się, że zbierasz natywne metryki ze składników platformy na potrzeby analizy. Zbierz informacje o użyciu zasobów, takie jak procesor CPU, pamięć, dane wejściowe/wyjściowe i aktywność sieci.

Aplikacja

Zbierz metryki na poziomie aplikacji, takie jak zużycie pamięci czy latencja żądania, i rejestruj działania aplikacji. Wykonaj operacje rejestrowania w wątku lub procesie, który jest oddzielony od głównego wątku aplikacji. Takie podejście nie powoduje, że rejestrowanie spowalnia zadania podstawowe aplikacji.

Sprawdź również podstawowe testy dostępności w usłudze Application Insights.

Dane

Aby monitorować bazy danych na poziomie podstawowym, zbierz kluczowe metryki emitowane przez zasoby bazy danych. Podobnie jak w przypadku składników infrastruktury, śledź użycie zasobów w kontekście magazynów danych, takich jak metryki sieci. Zbieranie danych o tym, jak połączenia są grupowane, jest ważne dla poprawy wydajności na późniejszych etapach.

Aby zapewnić niezawodność, ważne jest śledzenie metryk połączenia, takich jak monitorowanie aktywnych i nieudanych połączeń. Na przykład w usłudze Azure Cosmos DB zwracany jest kod stanu 429, gdy liczba żądań przekracza przydzielone jednostki żądania i połączenia kończą się niepowodzeniem.

√ Rozpoczynanie tworzenia podręcznika ograniczania ryzyka awarii

Błędy wahają się od sporadycznych do nieco rozszerzonych awarii przejściowych i katastroficznych awarii.

Na poziomie 1 skoncentruj się na błędach platformy. Mimo że są one poza twoją kontrolą, nadal należy mieć strategie ich obsługi. Na przykład rozwiązać problemy związane z przerwami w strefach, używając stref dostępności. Przewiduj tymczasowe błędy na poziomie platformy i obsługuj je w swoim obciążeniu.

Proces obsługi tych błędów różni się w zależności od złożoności. Rozpocznij dokumentowanie potencjalnych niepowodzeń na poziomie platformy, powiązanych z nimi zagrożeń i strategii ograniczania ryzyka. To ćwiczenie jest przede wszystkim teoretyczne i dojrzewa wraz z automatyzacją na późniejszych poziomach.

Należy udokumentować błędy, w tym czynniki, takie jak ich prawdopodobieństwo, wpływ i strategie ograniczania ryzyka. Użyj skali krytycznej, która jest zgodna z celami obciążenia. Skala może obejmować następujące elementy:

• Wysoka. Kompletna awaria systemu, która powoduje znaczną stratę finansową i spadek zaufania użytkowników.

• Średni. Tymczasowe zakłócenia wpływające na część obciążenia i powodują niedogodności dla użytkowników.

• Niski poziom Niewielki problem z oprogramowaniem, który wpływa na nieodpowiądową funkcję aplikacji i powoduje minimalny przestój dla użytkowników.

Oto przykładowy szablon:

Na poziomie 1 nie dążyć do kompletności, ponieważ zawsze istnieją nieprzewidziane przypadki niepowodzenia. Jeśli wystąpią nieoczekiwane awarie, udokumentuj przyczyny i środki zaradcze w podręczniku. Traktuj ten zasób jako dokument żywy, który jest aktualizowany wraz z upływem czasu.

Dodaj mechanizmy odzyskiwania po błędach przejściowych

W środowisku chmury typowe są błędy przejściowe. Wskazują one krótkoterminowe problemy, które ponowienie prób zwykle może rozwiązać w ciągu kilku sekund.

Użyj wbudowanych zestawów SDK i konfiguracji, aby obsługiwać te błędy w celu zachowania aktywności systemu. Wbudowane konfiguracje są często ustawieniem domyślnym, więc może być konieczne przetestowanie w celu zweryfikowania implementacji. Ponadto zaimplementuj wzorce przeznaczone do obsługi błędów przejściowych w architekturze. Aby uzyskać więcej informacji, zobacz Wzorce projektowe architektury, które obsługują niezawodność.

Trwałe problemy mogą wskazywać na błąd, który nie jest przejściowy lub na początku awarii. Ten scenariusz wymaga więcej niż tylko rozwiązywania zlokalizowanych problemów w aplikacji. Obejmuje to zbadanie krytycznych przepływów użytkownika i systemu oraz dodanie technik samozachowawczych i działań naprawczych. Te metody są dojrzałymi praktykami opisanymi na poziomie 2.

√ Uruchamianie podstawowych testów

Integrowanie podstawowych testów niezawodności na wczesnym etapie cyklu tworzenia oprogramowania. Poszukaj możliwości testowania, począwszy od testów jednostkowych w celu zweryfikowania funkcjonalności i konfiguracji.

Ponadto opracuj proste przypadki testowe dla problemów, które można zidentyfikować w podręczniku ograniczania ryzyka. Skoncentruj się na większym wpływie, ograniczaniu nakładu pracy. Na przykład zasymuluj awarie sieci lub sporadyczne problemy z łącznością, aby zobaczyć, jak logika ponawiania prób rozwiązuje zakłócenia.

Ryzyko: Testowanie często wprowadza tarcie w cyklu programowania. Aby ograniczyć to ryzyko, testowanie niezawodności powinno być śledzone w ramach zadań programistycznych.

Programowanie funkcji jest priorytetem, a testowanie może powodować tarcie w cyklu programowania. Przed ukończeniem opracowywania funkcji łatwiej jest rozpocząć testowanie. Projektowanie niefunkcjonalnych aspektów aplikacji na początku pozwala rozszerzyć je w miarę dodawania funkcji, a nie tworzenia listy prac związanych z problemami w celu późniejszego rozwiązania. Mimo że takie podejście wymaga początkowo większego nakładu pracy, można nim zarządzać i zapobiec większym problemom później.

Upewnij się, że system pozostaje funkcjonalny i stabilny, włączając funkcje samozachowawcze i mając podstawowy plan odzyskiwania do zarządzania awariami.

Awarie w chmurze są nieuniknione. Strategie odporności powinny dążyć do utrzymania funkcjonalności systemu we wszystkich warunkach. Poziom 1 wprowadza metody rozwiązywania błędów przejściowych. Poziom 2 koncentruje się na włączeniu strategii samozachowawczych w celu zapobiegania, wykrywania i odzyskiwania po długotrwałych awariach. Jeśli nie zostały rozwiązane, te problemy mogą przekształcić się w pełne awarie.

Krytyczne przepływy identyfikowane na poziomie 1 mają priorytet. Wymagają one zwiększenia odporności i działań przywracających dla wszystkich składników, w tym aplikacji, usług i baz danych. Należy oczekiwać dostosowania początkowych rozmiarów aprowizacji, liczby wystąpień i zasad skalowania automatycznego, aby zmniejszyć ryzyko związane z niezawodnością.

Na tym poziomie należy celowo stosować praktyki monitorowania i testowania. Używaj zaawansowanych technik monitorowania, które są zgodne z potrzebami technicznymi i są ograniczone do zespołów programistycznych. Rozwiń prosty podręcznik, aby uwzględnić składniki architektoniczne, które opracowujesz i którymi zarządzasz, takie jak kod aplikacji.

Kluczowe strategie

√ Oceń bieżący stan odporności, aby chronić przed awariami

• Czy poziom nadmiarowości jest wystarczająco dobry, aby wytrzymać awarie? Zdefiniuj strategię nadmiarowości określającą liczbę nadmiarowych zasobów do utrzymania. Określ, gdzie umieścić te zasoby, lokalnie, w różnych strefach lub w lokalizacjach rozproszonych geograficznie. Oceń ustawienia platformy w chmurze i wybierz poziom spełniający potrzeby biznesowe i akceptowalne kompromisy.

• Czy składniki obciążenia są wystarczająco odizolowane, aby ograniczać swoje awarie? Wzorce, takie jak wzorzec bulkhead , ułatwiają budowanie odporności i izolacji błędów. Wzorzec bulkhead partycjonuje system na izolowane składniki, znane jako bulkheads, aby zapobiec awariom kaskadowym do innych części systemu.

• Czy składniki na ścieżce krytycznej komunikują się asynchronicznie? Jeśli nie, użyj metod komunikacji, takich jak kolejki. Takie podejście utrzymuje działanie systemu, nawet jeśli składnik podrzędny ulegnie awarii. Uniemożliwia to również systemowi wprowadzanie stanu nieokreślonego. Zapoznaj się z opcjami platformy Azure, w tym usługą Azure Service Bus dla kolejek i usługi Azure Event Hubs na potrzeby strumieni zdarzeń.

  Kompromis: Komunikacja asynchroniczna może pomóc w zapobieganiu awariom kaskadowymi przez oddzielenie procesów. Dodaje jednak opóźnienie w ścieżce komunikacyjnej, co może stanowić problem dla krytycznych składników. Przed wprowadzeniem zmian wzorca projektu należy ocenić wpływ na wydajność.

• Czy operacje zostały zaprojektowane pod kątem spójności? Zasoby, takie jak wpisy tajne aplikacji i certyfikaty, mogą wygasać i wymagać regularnego odświeżania. Niespójności w rutynowych aktualizacjach mogą powodować problemy z niezawodnością.

  W idealnym przypadku zidentyfikuj i eliminuj bieżące zadania obsługiwane przez człowieka, ponieważ są podatne na błędy i mogą powodować niespójności, które stanowią zagrożenie dla niezawodności. Odciążaj jak najwięcej zadań operacyjnych dostawcy usług w chmurze. Na przykład użyj tożsamości zarządzanych, którymi zarządza usługa Microsoft Entra ID, oraz certyfikatów protokołu Transport Layer Security (TLS), którymi zarządza usługa Azure Front Door.

  Monitorowanie jest wymagane w przypadku proaktywnych środków, takich jak śledzenie wygaśnięcia certyfikatu i odbieranie powiadomień. Aplikacja powinna rejestrować ważne zdarzenia, takie jak certyfikat TLS zbliżający się do wygaśnięcia. Korzystanie z wielu metod sprawdzania potencjalnych awarii pomaga zapewnić, że zostaną podjęte niezbędne działania.

• Dodawanie możliwości technicznych w systemie monitorowania

Na poziomie 1 zebrano dane monitorowania ze składników obciążenia, koncentrując się na infrastrukturze. Podstawowa analiza jest kompletna, a podstawowe alerty są ustawione. Ta konfiguracja jest niezbędna do zrozumienia podstawowej wydajności składników obciążenia i identyfikowania nietypowego zachowania.

Poziom 2 rozwija monitorowanie, dodając zaawansowane możliwości obserwowalności do zasobów systemowych i przyjmując bardziej ustrukturyzowane podejście do analizy danych z monitoringu. Korzystaj z narzędzi analitycznych zapewnianych przez usługę w chmurze. Na przykład narzędzia do analizy usługi Azure Monitor, takie jak szczegółowe informacje o maszynie wirtualnej i szczegółowe informacje o sieci, zapewniają wizualizacje kondycji i wydajności między zależnościami.

Zaplanuj możliwości obserwacyjności na następujących warstwach.

Aplikacja

• Odpowiadanie na sondowanie stanu zdrowia. Włącz możliwość aplikacji odpowiadania na żądania sprawdzania kondycji z sond. Aplikacja powinna mieć dedykowane punkty końcowe dla kontroli kondycji, które zapewniają informacje o stanie, co najmniej, takie jak zdrowa lub niezdrowa. Takie podejście umożliwia systemom monitorowania ocenę, czy aplikacja działa prawidłowo i może obsługiwać żądania, czy też występują problemy, które należy rozwiązać.

  Usługi równoważenia obciążenia platformy Azure, takie jak Azure Front Door, Azure Traffic Manager, Azure Application Gateway i Azure Load Balancer, obsługują sondy kondycji. Sondy kondycji wysyłają żądania kontroli kondycji do aplikacji.

• Przejdź do rejestrowania semantycznego. Uwzględnij informacje ustrukturyzowane o zdarzeniach i akcjach w aplikacji. W przypadku rejestrowania strukturalnego dane dziennika są rejestrowane w spójnym formacie przy użyciu dobrze zdefiniowanego schematu. Ten schemat ułatwia tworzenie automatyzacji, wyszukiwania i analizowania w kolejnych etapach. Uwzględnij określone pola, takie jak znaczniki czasu i kody błędów, aby szybko identyfikować i rozwiązywać problemy.

• Zaimplementuj śledzenie rozproszone. Kiedy żądanie przepływa przez różne komponenty systemu, istotne jest, aby rejestrować dane śledzenia na przekroju granic. Te dane są przydatne do uzyskiwania szczegółowych informacji na temat zachowania aplikacji oraz identyfikowania wąskich gardeł wydajności, błędów i problemów z opóźnieniami. Usługa Azure Monitor obsługuje zbieranie danych opartych na protokole OpenTelemetry za pomocą usługi Application Insights.

Dane

• Śledź czas trwania zapytania, nieudane zapytania i inne istotne metryki. Długotrwałe zapytania mogą wskazywać ograniczenia zasobów i ewentualnie konieczność dostosowania projektu schematu.

  Na tym etapie baza danych działa od jakiegoś czasu. Zwróć uwagę na szybkość wzrostu danych, zwłaszcza w tabelach, które rosną nieoczekiwanie szybko. Te informacje mają kluczowe znaczenie dla planowania przyszłych potrzeb magazynu i wczesnego rozwiązywania problemów z wydajnością.

• Monitorowanie stanu replikacji bazy danych przy użyciu narzędzi i pulpitu nawigacyjnego zapewnianego przez system zarządzania bazami danych. Jeśli na przykład używasz usługi Azure Cosmos DB, użyj szczegółowych informacji usługi Azure Cosmos DB. W przypadku usługi Azure SQL Database lub Azure SQL Managed Instance rozważ użycie obserwatora bazy danych w celu uzyskania szczegółowych informacji diagnostycznych dotyczących baz danych.

  W miarę rozwoju bazy danych problemy ze schematem mogą stać się bardziej widoczne, co wpływa na wydajność. Aby zoptymalizować wydajność zapytań, rozważ dodanie indeksów lub zmodyfikowanie schematu, ponieważ te zmiany mogą mieć wpływ na niezawodność.

Operacji

Poziom 1 koncentruje się na poprzednich warstwach. Na poziomie 2 rozpoczynasz tworzenie operacji wokół systemu monitorowania.

• Zachowaj dzienniki wystarczająco długo, aby uzyskać szczegółowe informacje. Z perspektywy niezawodności skonfiguruj czas przechowywania, aby można było zebrać wystarczającą ilość danych do wykrywania wzorców awarii, rozwiązywania problemów i przeprowadzania analizy głównej przyczyny.

• Monitorowanie procesów tworzenia kopii zapasowych i odzyskiwania. Upewnij się, że kopie zapasowe są pomyślnie przechowywane w lokalizacjach zgodnie z planem i że dane obciążenia są odzyskiwane w rozsądnym przedziale czasu. Monitorowanie tych procesów jest ważne w przypadku ustawiania punktów odniesienia dla metryk celu punktu odzyskiwania (RPO) na nowszych poziomach.

Rozszerz podręcznik radzenia sobie z awariami

Poziom 1 koncentruje się na oczekiwanych awariach platformy. Na Poziomie 2 należy zająć się punktami awarii dotyczącymi składników i operacji w ramach własnego obciążenia. W miarę uruchamiania kodu na platformie punkty interakcji między platformą a aplikacją rosną. Spodziewaj się problemów związanych z błędami w kodzie, nieudanymi wdrożeniami i błędami ludzkimi. Złagodź te problemy, stosując taktyki samozachowawcze i taktyki odzyskiwania.

Rozszerz podręcznik ograniczania ryzyka awarii, aby uwzględnić błędy i problemy z wdrażaniem. Poniższa tabela opiera się na szablonie z poziomu 1:

To ćwiczenie może stać się przytłaczające, jeśli spróbujesz uwzględnić wszelkie możliwe błędy. Aby ułatwić, skoncentruj się na składnikach będących częścią krytycznych przepływów użytkownika. Ten żywy dokument nadal rośnie wraz ze wzrostem obciążenia.

Opracuj podstawowy plan odzyskiwania

Podręcznik ograniczania ryzyka awarii jest podstawą tworzenia podstawowego planu odzyskiwania. Strategie ograniczania ryzyka mogą obejmować implementację wzorca projektu, korekty konfiguracji platformy, zarządzanie zdarzeniami na żywo, zautomatyzowane testy i personel szkoleniowy w celu wykrywania problemów podczas przeglądów kodu.

Zacznij od pełnej strategii degradacji, która obejmuje tymczasowe poprawki, gdy części systemu nie działają prawidłowo. Celem jest dalsze obsługiwanie użytkowników pomimo niepowodzeń przez wyłączenie części niepracujących i dostosowanie środowiska użytkownika. Jeśli na przykład baza danych nie działa, aplikacja może wyłączyć tę funkcję i poinformować klientów, że usługa jest tymczasowo niedostępna przy użyciu kodów stanu HTTP.

Aby zapewnić bezproblemowe obniżenie wydajności, izoluj składniki systemowe, tak aby tylko części, których dotyczy problem, podczas gdy pozostałe składniki nadal działają. Użyj wzorca Bulkhead, aby uzyskać izolację awarii.

Skorzystaj z tej okazji, aby ponownie zapoznać się z wyborami projektowymi, które mogą spowolnić odzyskiwanie. Na przykład skierowanie rekordów systemu nazw domen (DNS) bezpośrednio do aplikacji w usłudze Azure App Service może prowadzić do opóźnień w czasie przywracania z powodu propagacji DNS. Użyj dedykowanej usługi, takiej jak Azure Front Door, jako punktu wejścia, aby ułatwić ponowną konfigurację podczas wykonywania kroków odzyskiwania.

Należy oczekiwać, że ten podstawowy plan przekształci się w pełny plan odzyskiwania po awarii na bardziej dojrzałych poziomach.

√ Tworzenie planów testów

Utwórz plany testów, symulując awarie i problemy zidentyfikowane w podręczniku ograniczania ryzyka. Uzupełnij te środki zaradcze prostymi przypadkami testowymi, aby upewnić się, że działają zgodnie z oczekiwaniami i są możliwe. Sprawdź, czy te funkcje działają prawidłowo, i przeprowadź testy degradacji, aby sprawdzić, jak system działa w przypadku awarii określonych składników. Zachowaj prosty wynik, upewniając się, że test kończy się niepowodzeniem lub powodzeniem.

Użyj narzędzi testowych, takich jak frameworki do tworzenia atrap, aby symulować błędy w żądaniach HTTP, co ułatwia jawniejsze testowanie zasad ponawiania prób. Usługa Azure Chaos Studio udostępnia kompleksowy zestaw testów do symulowania awarii składników i innych problemów, co sprawia, że jest to cenna usługa do eksplorowania. Możesz stopniowo wdrażać program Chaos Studio, gdy zapoznasz się z jego funkcjami.

√ Ocena wpływu operacji skalowania na niezawodność

Aby obsłużyć skoki obciążenia, krytyczne składniki muszą być w stanie wydajnie skalować w poziomie lub skalować w górę. Korzystaj z funkcji skalowania automatycznego zapewnianych przez platformę Azure. Te możliwości dostosowują limity pojemności usługi na podstawie wstępnie zdefiniowanych konfiguracji. Ta korekta umożliwia skalowanie usługi w górę lub w dół zgodnie z potrzebami.

• Zidentyfikuj potencjalne wąskie gardła i poznaj potencjalne zagrożenia. Na przykład wysoka przepływność nie powinna powodować zakłócenia przepływu.

• Omówienie wzorców obciążenia. Statyczne wzorce użycia mogą sprawić, że wąskie gardła będą mniej krytyczne, ale zmiany w sposobach użycia i dynamice zużycia mogą zwiększyć związane z nimi ryzyko.

  Uwaga / Notatka

  Mogą istnieć składniki, które nie mogą skalować w poziomie, takie jak monolityczne bazy danych i starsze aplikacje. Proaktywne monitorowanie krzywej obciążenia w celu umożliwienia ponownego tworzenia architektury w razie potrzeby.

• Zdecyduj o limitach skalowania, które są uzasadnione na podstawie wymagań dotyczących wydajności i niezawodności. W przypadku problemów z wydajnością najczęściej stosuje się stopniowe skalowanie. Jednak obawy dotyczące niezawodności krytycznych przepływów mogą wymagać szybszego skalowania, aby uniknąć awarii. W obu przypadkach unikaj nieskończonego skalowania.

Ryzyko: Podczas rozwiązywania problemów związanych z wydajnością skalowanie może być przydatną strategią ograniczania ryzyka. Jednak skalowanie jest tymczasową poprawką, a nie rozwiązaniem. Zbadaj i rozwiąż podstawowy problem, taki jak wyciek pamięci lub proces ucieczki. W przeciwnym razie grozi Ci ponowne zastosowanie tych samych środków zaradczych w kolejnym punkcie zwrotnym i ponoszenie kosztów na zasoby, których nie potrzebujesz. Zwracając się do głównej przyczyny, można zapewnić długoterminową stabilność i efektywność kosztową.

Ustaw cele niezawodności i cele, aby zespół był odpowiedzialny za procedury odzyskiwania.

Na wczesnych poziomach zespoły koncentrują się na łatwych zwycięstwach i podstawowych możliwościach. Zaczynają od niewielkich ulepszeń, rozwiązując proste problemy, aby zbudować silną podstawę, opierając się głównie na możliwościach niezawodności platformy Azure. W miarę rozwoju zespołów zajmują się bardziej wyzwaniami technicznymi związanymi z własnymi aktywami i procesami.

Na poziomie 3 zespoły powinny integrować analizy biznesowe i umiejętności techniczne na potrzeby planowania odzyskiwania. Określają cele i planują procesy odzyskiwania przy użyciu zaawansowanego monitorowania. Takie podejście pomaga inżynierom niezawodności witryny szybko osiągać cele dotyczące niezawodności.

Kluczowe strategie

√ Formalizowanie możliwości niezawodności jako celów

Cele niezawodności pomagają określić odpowiedzialność dla zespołów ds. obciążeń. Ważne jest, aby wspólnie rozmawiać z uczestnikami projektu biznesowego, aby omówić czasy odzyskiwania i koszty oraz wprowadzić kompromisy zgodne z celami biznesowymi. Zbierz uczestników projektu i przeprowadź tę dyskusję jako warsztaty. Weź pod uwagę następujące kwestie dotyczące programu warsztatowego:

• Wyjaśnij metryki za celami. Zacznij od wyjaśnienia kluczowych metryk używanych do definiowania celów, takich jak cele poziomu usług, cele czasu odzyskiwania (RTO) i cele punktu odzyskiwania (RPO). Pokaż, jak te metryki są zgodne z celami biznesowymi. Skoncentruj się na krytycznych przepływach użytkownika. Na przykład w aplikacji e-commerce czas przywrócenia (RTO) na aktualizację preferencji e-mailowych jest mniej istotny niż użytkownicy realizujący zamówienia.

• Komunikacja kompromisów. Uczestnicy projektu często oczekują więcej niż tego, co można osiągnąć. Wyjaśnij, jak rozszerzenie zakresu wpływa na budżet, wymagania operacyjne i wydajność.

• Proponowanie celów docelowych. W oparciu o doświadczenie architektoniczne i projektowanie obciążeń, zaleca się ustawienie celów takich jak 99,9% dostępności, z RPO i RTO ustawionymi na cztery godziny. Ułatwij dyskusję dla uczestników projektu, aby przekazać opinię i wprowadzić korekty. Upewnij się, że zarówno zainteresowane strony biznesowe, jak i techniczne zabezpieczają się przed nierealistycznymi oczekiwaniami. Podejdź do dyskusji z nastawieniem na współpracę.

• Osiągnąć konsensus lub decyzję. Dążyć do konsensusu, ale jeśli nie jest to możliwe, należy sfinalizować cele w celu zapewnienia postępu.

√ Proaktywne monitorowanie przy użyciu modelu kondycji

Na poziomie 1 dane monitorowania są zbierane ze składników obciążenia, w tym usług i aplikacji platformy. Podstawowa analiza i alerty są ustawione w celu ustalenia wydajności punktu odniesienia i identyfikowania anomalii. Na poziomie 2 nacisk przesuwa się na uzyskiwanie danych obserwowalności z komponentów obciążenia roboczego, takich jak kod aplikacji.

Poziom 3 zwiększa monitorowanie przez dodanie kontekstu biznesowego do krytycznych przepływów i zdefiniowanie stanów w dobrej kondycji, złej kondycji i obniżonej kondycji za pośrednictwem modelowania kondycji. Umowa uczestników projektu jest potrzebna do określenia akceptowalnych kompromisów dotyczących środowiska użytkownika i powinna być używana jako dane wejściowe do definiowania stanów kondycji.

Modelowanie kondycji wymaga dojrzałości operacyjnej i wiedzy w zakresie narzędzi do monitorowania. Twój zespół przegląda nieprzetworzone dane, poziomy wydajności i dzienniki, aby utworzyć niestandardowe metryki i progi definiujące stan kondycji przepływu. Muszą zrozumieć, jak te wartości odnoszą się do ogólnej kondycji systemu. Przekaż jasne definicje i progi uczestnikom projektu.

Zwizualizuj model kondycji na pulpitach nawigacyjnych, aby szybko wskazać problemy z usługami SRE, koncentrując się na niezdrowych lub obniżonych przepływach.

Model kondycji definiuje stan aplikacji i przepływy krytyczne. Green wskazuje, że wszystkie przepływy krytyczne działają zgodnie z oczekiwaniami. Czerwony wskazuje błąd. Żółty pokazuje trendy wskazujące na problemy. Iteracja za pomocą wersji modelu kondycji zapewnia niezawodność i dokładność, ale wymaga znacznego nakładu pracy w przypadku dużych aplikacji.

Zmiana stanu kondycji powinna być skonfigurowana jako alerty. Jednak aby alerty były celowe, należy wziąć pod uwagę krytyczność składnika.

Aby uzyskać więcej informacji, zobacz Well-Architected Framework: Modelowanie kondycji.

√ Ustawianie alertów z możliwością działania

Aby zwiększyć wydajność reagowania, zdefiniuj alerty i podaj wystarczająco dużo informacji na potrzeby szybkiej akcji. Szczegółowe nazwy alertów i opisy mogą pomóc zaoszczędzić czas i nakład pracy podczas rozwiązywania problemów. Starannie skonfiguruj ważność, nazwę i opis ze szczególnym uwzględnieniem poziomów ważności. Nie każde zdarzenie jest awaryjne. Przemyślana ocena poziomów krytyczności i ustalenie kryteriów dla każdego poziomu, na przykład, czy nagły wzrost aktywności CPU z 80% do 90% kwalifikuje się jako sytuacja kryzysowa. Ustaw odpowiednie progi, aby zapewnić efektywne zdefiniowanie alertów.

Skuteczne zarządzanie alertami zapewnia, że alerty powiadamiają odpowiednie osoby w odpowiednim czasie. Częste i zakłócające alerty wskazują na potrzebę dostosowania i mogą stać się nieproduktywne, gdy są ignorowane. Zmniejsz niepotrzebne powiadomienia, ustawiając odpowiednie progi, aby odfiltrować fałszywe alarmy. Identyfikowanie możliwości wyzwalania procedur operacyjnych przez automatyzację.

Utwórz pojedynczą stronę docelową zawierającą informacje niezbędne do efektywnego rozwiązywania problemów z alertami. Takie podejście pozwala zaoszczędzić czas w porównaniu z logowaniem się do witryny Azure Portal i wyszukiwaniem metryk. Jeśli wbudowane funkcje usługi Azure Monitor nie spełniają Twoich potrzeb, rozważ utworzenie niestandardowego pulpitu nawigacyjnego.

√ Przeprowadzanie analizy trybu awarii

We wcześniejszych poziomach utworzono prosty podręcznik ograniczania ryzyka awarii dla poszczególnych składników. Na tym poziomie rozwiń ten podręcznik w formalne ćwiczenie analizy trybu awarii (FMA). Celem tego ćwiczenia jest proaktywne identyfikowanie potencjalnych trybów awarii.

FMA wymaga zidentyfikowania potencjalnych miejsc awarii w ramach obciążeń i zaplanowania działań zaradczych, takich jak autoregeneracja lub odzyskiwanie po awarii (DR). Aby rozpocząć, monitoruj zwiększone współczynniki błędów i wykrywaj wpływ na krytyczne przepływy. Użyj przeszłych doświadczeń i danych testowych, aby zidentyfikować potencjalne awarie i ocenić ich zakres oddziaływania. Określanie priorytetów głównych problemów, takich jak awaria całego regionu.

Ważne jest, aby klasyfikować akcje jako prewencyjne lub reaktywne. Działania zapobiegawcze identyfikują zagrożenia, zanim spowodują awarię, co zmniejsza prawdopodobieństwo lub ważność. Działania reaktywne rozwiązują problemy, aby złagodzić obniżony stan kondycji lub awarię.

W przykładowej aplikacji handlu elektronicznego zespół odpowiedzialny za obciążenia chce zrobić FMA, aby przygotować się na ważne wydarzenie. Jednym z kluczowych przepływów użytkownika jest dodawanie elementów do koszyka. Składniki, które są częścią procesu, to frontend, CartAPI, ProductCatalogAPI, UserProfileAPI, PricingAPI, Azure Cosmos DB i Azure Event Hubs.

FMA jest złożona i może być czasochłonna, więc stopniowo rozwijaj analizę w miarę upływu czasu. Ten proces jest iteracyjny i nadal ewoluuje na późniejszych etapach.

Aby uzyskać więcej informacji, zobacz RE:03 Zalecenia dotyczące wykonywania FMA.

Przygotuj plan odzyskiwania po awarii (DR Plan)

Na poziomie 2 utworzono plan odzyskiwania skoncentrowany na kontrolkach technicznych w celu przywrócenia funkcjonalności systemu. Jednak katastrofa wymaga szerszego podejścia ze względu na katastrofalną stratę lub awarię. Plany DR są oparte na procesach. Obejmują one komunikację, szczegółowe kroki odzyskiwania i potencjalnie obejmują artefakty techniczne, takie jak skrypty.

Najpierw zidentyfikuj typy awarii, które mają być planowane, takie jak awarie regionów, awarie całej platformy Azure, zakłócenia infrastruktury, uszkodzenie bazy danych i ataki ransomware. Następnie opracuj strategie odzyskiwania dla każdego scenariusza i upewnij się, że mechanizmy są na miejscu w celu przywrócenia operacji. Wymagania biznesowe, RTO i RPO powinny wyznaczać kierunek planów odzyskiwania po awarii. Niskie wartości RTO i RPO wymagają jawnych zautomatyzowanych procesów, podczas gdy wyższe wartości RTO i RPO umożliwiają prostsze metody odzyskiwania i ręczną analizę.

Odzyskiwanie po awarii obejmuje głównie następujące działania:

• Powiadom strony odpowiedzialne. Ważne jest, aby mieć jasność co do tego, kogo należy zaangażować i kiedy. Upewnij się, że twój zespół korzysta z odpowiednich procesów, ma odpowiednie uprawnienia i rozumie swoje role w odzyskiwaniu. Niektóre obowiązki, takie jak raportowanie dyrektora generalnego na rynku lub obsługa wymagań regulacyjnych, należy zidentyfikować wcześnie.

  W idealnym przypadku należy mieć oddzielne role odzyskiwania i komunikacji oraz przypisywać różne osoby do każdej roli. Początkowo osoba zajmująca się operacjami IT, która wykryje problem, może obsłużyć obie role. Jednak w miarę eskalacji sytuacji starsze kierownictwo może obsługiwać odzyskiwanie techniczne, gdy specjalista ds. biznesu zarządza komunikacją.

• Podejmowanie decyzji biznesowych. Podczas katastrofy poziomy stresu mogą być wysokie, co sprawia, że niezbędne jest jasne podejmowanie decyzji. Dobrze ustrukturyzowany plan odzyskiwania po awarii wymaga ciągłych dyskusji między zespołem technicznym a interesariuszami biznesowymi w celu zdefiniowania wstępnych opcji decyzyjnych. Rozważ na przykład, czy zasoby obciążenia powinny być uruchamiane w jednym regionie świadczenia usługi Azure z kopiami zapasowymi w innym regionie, czy też zasoby IaC powinny być przygotowane z wyprzedzeniem w celu utworzenia nowych zasobów lub przywrócenia z kopii zapasowej podczas pracy w trybie failover.

  Działania podejmowane zgodnie z planami odbudowy po awarii mogą być destrukcyjne lub mieć znaczące skutki uboczne. Ważne jest, aby zrozumieć opcje, rozważyć ich zalety i wady i określić odpowiedni czas, aby je zastosować. Na przykład oceń, czy konieczne jest odzyskiwanie do innego regionu, jeśli oczekuje się, że region podstawowy będzie działać w akceptowalnym czasie.

• Przywracanie operacji systemowych. Podczas awarii należy skupić się na przywracaniu operacji, a nie na identyfikowaniu przyczyny. W przypadku odzyskiwania technicznego, zwłaszcza w przypadku trybu failover w regionie, należy podjąć decyzję z wyprzedzeniem o podejściach takich jak aktywne-aktywne,aktywne-pasywne, ciepłe wstrzymanie lub rezerwa zimna.

  Przygotuj konkretne kroki odzyskiwania na podstawie wybranego podejścia. Zacznij od określonej listy kroków przywracania operacji. W miarę dojrzewania procesu należy zdefiniować plan DR jako skrypt z minimalną interakcją ręczną. Użyj kontroli wersji i bezpiecznie zapisz skrypt, aby uzyskać łatwy dostęp. Takie podejście wymaga większego nakładu pracy z góry, ale minimalizuje stres podczas rzeczywistego incydentu.

  Aby uzyskać więcej informacji, zobacz więcej w Wdrażanie w trybie aktywno-pasywnym dla DR.

• Przeprowadzanie analizy po zdarzeniu. Zidentyfikuj przyczynę zdarzenia i znajdź sposoby jego zapobiegania w przyszłości. Wprowadź zmiany w celu ulepszenia procesów odzyskiwania. To ćwiczenie może również odkryć nowe strategie. Jeśli na przykład system został przełączony do środowiska pomocniczego, ustal, czy środowisko podstawowe jest nadal potrzebne i jaki powinien być proces powrotu po awarii.

Plan DR to dokument żyjący, który dostosowuje się do zmian w obciążeniu roboczym. Zaktualizuj plan odzyskiwania po awarii, gdy pojawiają się nowe składniki i zagrożenia. Uściślij plan na podstawie informacji uzyskanych z prób lub rzeczywistych katastrof, zbierając realistyczne informacje od operatorów DR.

Kontrolowanie zagrożeń wynikających ze zmian technicznych i operacyjnych oraz określanie priorytetów zarządzania zdarzeniami.

Na poprzednich poziomach zespół ds. obciążenia pracą koncentruje się na tworzeniu funkcji i przygotowaniu systemu do działania. Na poziomie 4 koncentruje się na utrzymaniu niezawodności systemu w środowisku produkcyjnym. Zarządzanie zdarzeniami staje się tak ważne, jak upewnienie się, że wprowadzone zmiany są dokładnie przetestowane i bezpiecznie wdrożone, aby uniknąć niestabilnego systemu.

Ten proces wymaga ulepszeń mechanizmów kontroli operacyjnej, takich jak inwestowanie w dedykowane zespoły w celu zarządzania zdarzeniami niezawodności. Wymaga również zastosowania technicznych mechanizmów, które zwiększą niezawodność systemu, wychodząc poza wzmocnienie krytycznych składników na poprzednich poziomach. Ponieważ system nadal działa w środowisku produkcyjnym, wzrost danych może wymagać przeprojektowania, takich jak partycjonowanie, w celu zapewnienia niezawodnego dostępu i konserwacji.

Kluczowe strategie

√ Niezawodne zarządzanie zmianami

Największe ryzyko związane z niezawodnością występuje podczas zmian, takich jak aktualizacje oprogramowania, korekty konfiguracji lub modyfikacje procesów. Te zdarzenia mają kluczowe znaczenie z punktu widzenia niezawodności. Celem jest zminimalizowanie prawdopodobieństwa wystąpienia problemów, przestojów, przestojów lub utraty danych. Każdy typ zmiany wymaga konkretnych działań w celu efektywnego zarządzania unikatowymi zagrożeniami.

Na poziomie 4 niezawodność przecina się z bezpiecznymi praktykami wdrażania opisanymi w sekcji Doskonałość operacyjna w utrzymaniu stabilnego środowiska podczas zarządzania zmianami. Niezawodne zarządzanie zmianami jest wymagane do osiągnięcia stabilności obciążenia. Weź pod uwagę następujące kluczowe aspekty:

• Reagowanie na aktualizacje platformy. Usługi platformy Azure mają różne mechanizmy aktualizacji usług.

  • Zapoznaj się z procesami konserwacji i zaktualizuj zasady każdej używanej usługi. Dowiedz się, czy usługa obsługuje automatyczne lub ręczne uaktualnienia oraz przedział czasu aktualizacji ręcznych.

  • W przypadku usług, które mają zaplanowane aktualizacje, skutecznie zarządzaj tymi aktualizacjami, planując je w czasie o niskim wpływie. Unikaj automatycznych aktualizacji i odroczyć je do czasu oceny ryzyka. Niektóre usługi umożliwiają kontrolowanie czasu, podczas gdy inne usługi zapewniają okres prolongaty. Na przykład w przypadku usługi Azure Kubernetes Service (AKS) masz 90 dni, zanim aktualizacja stanie się automatyczna. Przetestuj aktualizacje w klastrze nieprodukcyjnym, który dubluje konfigurację produkcyjną, aby zapobiec regresji.

    Stopniowo stosuj aktualizacje. Nawet jeśli testy pokazują, że aktualizacja jest bezpieczna, zastosowanie jej do wszystkich wystąpień jednocześnie może być ryzykowne. Zamiast tego zaktualizuj kilka wystąpień jednocześnie i poczekaj między poszczególnymi zestawami.

  • Regularnie sprawdzaj powiadomienia dotyczące aktualizacji, które mogą być dostępne w dziennikach aktywności lub w innych kanałach specyficznych dla usługi.

  • Monitoruj nagłe lub stopniowe zmiany po zastosowaniu aktualizacji. W idealnej sytuacji model zdrowia powinien powiadomić Cię o tych zmianach.

• Dokładne testowanie za pomocą automatyzacji. Integracja większej liczby testów w potokach kompilacji i wdrażania przy wprowadzaniu zmian. Poszukaj możliwości konwersji procesów ręcznych na zautomatyzowane części linii przetwarzania.

  Wykonaj kompleksowe testowanie przy użyciu kombinacji różnych typów testów na różnych etapach, aby potwierdzić, że zmiany działają zgodnie z oczekiwaniami i nie wpływają na inne części aplikacji. Na przykład testy dodatnie mogą sprawdzić, czy system działa zgodnie z oczekiwaniami. Powinien sprawdzić, czy nie ma żadnych błędów i czy ruch przepływa prawidłowo.

  Podczas planowania aktualizacji zidentyfikuj bramy testowe i typy testów do zastosowania. Większość testów powinna być przeprowadzana na etapie przed wdrożeniem, ale testy dymne powinny być również wykonywane w każdym środowisku przy aktualizacji.

• Postępuj zgodnie z bezpiecznymi praktykami wdrażania. Użyj topologii wdrażania, które obejmują okna weryfikacji i bezpieczne praktyki wdrażania. Zaimplementuj bezpieczne wzorce wdrażania, takie jak kanarkowe i niebiesko-zielone wdrożenia, aby zwiększyć elastyczność i niezawodność.

  Na przykład we wdrożeniach kanarowych mały podzbiór użytkowników otrzymuje najpierw nową wersję. Ten proces umożliwia monitorowanie i walidację przed wdrożeniem do całej bazy użytkowników. Techniki, takie jak flagi funkcji i ciemne uruchomienia, ułatwiają testowanie w środowisku produkcyjnym przed udostępnieniem zmian wszystkim użytkownikom.

• Zaktualizuj plan odzyskiwania po awarii. Regularnie aktualizuj plan DR, aby był adekwatny i skuteczny. Unikaj nieaktualnych instrukcji. Takie podejście zapewnia, że plan odzwierciedla bieżący stan systemu, który jest wdrożony w środowisku produkcyjnym i na którym polegają użytkownicy. Uwzględnij wnioski wyciągnięte z ćwiczeń i rzeczywistych zdarzeń.

Aby uzyskać więcej informacji, zobacz Poziom doskonałości operacyjnej 4

√ Zainwestuj w dedykowany zespół do obsługi zdarzeń

Początkowo zespół programistyczny może być zaangażowany podczas incydentów. Na poziomie 4 zainwestuj w inżynierię niezawodności lokacji (SRE) na potrzeby zarządzania zdarzeniami. SPRO specjalizują się w problemach produkcyjnych i są ekspertami w zakresie wydajności, zarządzania zmianami, monitorowania, reagowania kryzysowego i zarządzania pojemnością. Biegły zespół SRE może znacząco zmniejszyć zależność od zespołu inżynierskiego.

Zapewnij inżynierom niezawodności serwisów narzędzia, informacje i wiedzę niezbędną do samodzielnej obsługi incydentów. To przygotowanie zmniejsza zależność od zespołu inżynieryjnego. Inżynierowie SRE powinni być przeszkoleni z podręczników i modelu zdrowia obciążenia opracowanych na poprzednich poziomach, aby szybko rozpoznawać typowe wzorce i inicjować proces łagodzenia problemów.

Zespół inżynierów powinien mieć czas, aby zastanowić się nad powtarzającymi się problemami i opracowywać strategie długoterminowe, zamiast zajmować się nimi indywidualnie za każdym razem.

√ Automatyzowanie procesów samonaprawiania

W poprzednich poziomach strategie samonaprawiania są projektowane przy użyciu wzorców nadmiarowości i wzorców projektowych. Teraz, gdy twój zespół ma doświadczenie w zakresie rzeczywistego użycia, możesz zintegrować automatyzację, aby wyeliminować typowe wzorce awarii i zmniejszyć zależność od zespołu inżynierów.

Kompromis: Automatyzacja może zająć trochę czasu i być kosztowna do skonfigurowania. Skoncentruj się na automatyzowaniu najbardziej wpływających zadań, takich jak zadania, które występują często lub mogą powodować awarie.

Skonfiguruj działania w oparciu o wyzwalacze i automatyzuj odpowiedzi w czasie, aby stworzyć automatyczny schemat dla SRE. Jednym z podejść jest ulepszenie podręcznika za pomocą skryptów, które implementują kroki ograniczania ryzyka. Zapoznaj się z opcjami natywnymi platformy Azure, takimi jak używanie grup akcji usługi Azure Monitor, aby skonfigurować wyzwalacze, które automatycznie inicjują różne zadania.

Zwiększ odporność na zadania w tle

Większość obciążeń obejmuje składniki, które nie obsługują bezpośrednio przepływów użytkowników, ale odgrywają kluczową rolę w ogólnym przepływie pracy aplikacji. Na przykład w systemie handlu elektronicznego, gdy użytkownik składa zamówienie, system dodaje komunikat do kolejki. Ta akcja wyzwala kilka zadań w tle, takich jak potwierdzenie wiadomości e-mail, finalizacja opłaty za kartę kredytową i powiadomienie magazynu na potrzeby przygotowania wysyłki. Te zadania działają oddzielnie od funkcji obsługujących żądania użytkowników w witrynie internetowej, co zmniejsza obciążenie i zwiększa niezawodność. Systemy bazują również na zadaniach w tle na potrzeby oczyszczania danych, regularnej konserwacji i tworzenia kopii zapasowych.

Po ocenie i ulepszaniu przepływów użytkownika podstawowego należy wziąć pod uwagę zadania w tle. Użyj technik i infrastruktury, które już istnieją, i dodaj ulepszenia dotyczące zadań w tle.

• Stosowanie punktów kontrolnych. Tworzenie punktów kontrolnych to technika zapisywania stanu procesu lub zadania w określonych punktach. Punktowanie kontrolne jest szczególnie przydatne w przypadku długotrwałych zadań lub procesów, które mogą zostać zakłócone z powodu nieoczekiwanych problemów, takich jak awarie sieci lub awarie systemu. Po ponownym uruchomieniu procesu może on kontynuować od ostatniego zapisanego punktu kontrolnego, co minimalizuje wpływ przerw.

• Zachowaj idempotentne procesy. Upewnij się, że procesy w tle są idempotentne, aby w przypadku niepowodzenia zadania inne wystąpienie mogło je przejąć i kontynuować przetwarzanie bez problemów.

• Zapewnij spójność. Uniemożliwiaj systemowi wprowadzanie niespójnego stanu, jeśli zadanie w tle zatrzymuje się podczas przetwarzania. Zarówno tworzenie punktów kontrolnych, jak i idempotentność na poziomie zadania są technikami umożliwiającymi większą spójność w operacjach zadań w tle. Uruchom każde zadanie jako niepodzielną transakcję. W przypadku zadania obejmującego wiele magazynów danych lub usług użyj idempotencji na poziomie zadania lub transakcji wyrównujących, aby upewnić się, że zostanie ukończona.

• Integrowanie zadań w tle z systemem monitorowania i praktykami testowania. Wykrywaj błędy i zapobiegaj niezauważonym przerwom, które mogą powodować konsekwencje funkcjonalne i niefunkcjonalne. System monitorowania powinien przechwytywać dane z tych składników, ustawiać alerty dotyczące zakłóceń i używać wyzwalaczy, aby ponowić próbę lub wznowić proces automatycznie. Traktuj te zasoby jako część obciążenia i przeprowadzaj zautomatyzowane testowanie w taki sam sposób, jak w przypadku składników krytycznych.

Platforma Azure udostępnia kilka usług i funkcji zadań w tle, takich jak Azure Functions i Azure App Service WebJobs. Zapoznaj się z ich najlepszymi rozwiązaniami i limitami podczas implementowania przepływów, które koncentrują się na niezawodności.

Zachowaj odporność w miarę rozwoju architektury obciążenia, co pozwala systemowi wytrzymać nowe i nieprzewidziane zagrożenia.

Na poziomie 5 skupienie się na ulepszaniu niezawodności rozwiązania przesuwa się z dala od implementowania mechanizmów kontroli technicznej. Infrastruktura, aplikacje i operacje powinny być na tyle niezawodne, aby były odporne na awarie i umożliwiały odzyskiwanie w określonym czasie docelowym.

Użyj danych i przyszłych celów biznesowych, aby potwierdzić, że jeśli twoja firma musi pójść dalej, zmiany architektury mogą być konieczne. W miarę rozwoju obciążenia i dodawania nowych funkcji należy dążyć do zminimalizowania przestojów związanych z tymi funkcjami, jednocześnie zmniejszając awarie istniejących funkcji.

Kluczowe strategie

√ Używanie szczegółowych informacji o niezawodności do kierowania ewolucją architektury

Na tym poziomie podejmij decyzje we współpracy z uczestnikami projektu biznesowego. Rozważmy następujący czynniki:

• Przeanalizuj metryki, które wskazują, ile razy system przekracza progi niezawodności w danym okresie i czy jest to akceptowalne. Na przykład w przypadku pięciu poważnych awarii w ciągu jednego roku może spowodować ponowne przeprowadzenie oceny rozwiązań projektowych i operacyjnych systemu.

• Oceń krytyczne znaczenie biznesowe systemu. Na przykład usługa, która obsługuje przepływy pracy o znaczeniu krytycznym, może wymagać przeprojektowania wdrożeń bez przestojów i natychmiastowego przejścia w tryb failover, nawet jeśli zwiększa koszt lub złożoność. Z drugiej strony usługa o ograniczonym wykorzystaniu może korzystać z mniej rygorystycznych celów poziomu SLA.

• Ocena wpływu zmian w innych filarach na niezawodność. Na przykład zwiększone środki bezpieczeństwa mogą wymagać środków poprawy niezawodności dla dodatkowych etapów zabezpieczeń, co może spowodować potencjalne punkty awarii.

• Ocena kosztów operacyjnych utrzymania niezawodności. Jeśli te koszty przekraczają ograniczenia budżetowe, rozważ zmiany architektury, aby zoptymalizować i kontrolować wydatki.

Aby pomóc uczestnikom projektu, inżynierom i menedżerom produktów podejmować świadome decyzje, rozważ wizualizację powyższych punktów danych wraz z dodatkowymi szczegółowymi informacjami. Takie podejście zapewnia pełny obraz niezawodności.

√ Uruchamianie testów kontrolowanych w środowisku produkcyjnym

Na tym poziomie rozważ kontrolowane eksperymenty w środowisku produkcyjnym tylko wtedy, gdy obciążenie wymaga najwyższych gwarancji odporności. Te praktyki testowania są nazywane inżynierią chaosu. Testy sprawdzają, czy system może bezpiecznie odzyskać i kontynuować działanie w niekorzystnych warunkach.

Rozważmy następujące przykładowe przypadki użycia:

• Analiza przepływu zależności: Typowym przypadkiem użycia jest testowanie aplikacji zaprojektowanych jako mikrousługi. Możesz wyłączyć losowe wystąpienia mikrousług, aby upewnić się, że błędy nie są kaskadowe lub zakłócają środowisko użytkownika. To podejście można rozszerzyć na przepływy systemowe, wyłączając określone składniki w celu przeanalizowania sposobu reagowania systemów podrzędnych. Celem jest zidentyfikowanie ścisłego sprzężenia lub ukrytych zależności i przetestowanie sposobu wykonywania planów nadmiarowości systemu.

• Bezproblemowe testowanie degradacji: Oceń, jak system działa z ograniczoną funkcjonalnością podczas awarii. Na przykład można ukryć funkcje niekrytyczne, jeśli aparat rekomendacji ulegnie awarii.

• Symulacja niepowodzeń systemów zewnętrznych: Wyłącz lub ogranicz wywołania aplikacji zewnętrznych, aby sprawdzić funkcjonowanie systemu i czy mechanizmy rezerwowe lub ponowne próby są prawidłowo implementowane.

Inżynieria chaosu to złoty standard testowania odporności. Jednak tę praktykę należy zarezerwować dla dojrzałych systemów i zespołów odpowiedzialnych za obciążenie. Upewnij się, że obowiązują zabezpieczenia, aby ograniczyć promień wybuchu i zapobiec wpływowi użytkownika.

• Przygotuj się poprzez przeprowadzanie symulacji. Rozpocznij w środowiskach nieprodukcyjnych, które symulują rzeczywiste warunki przy użyciu konfiguracji o niższym ryzyku z transakcjami syntetycznymi. Takie podejście ułatwia identyfikowanie luk w procesie, ścieżek błędów ludzkich i wad architektury.

  Gdy testowanie nieprodukcyjne przestaje zwracać cenne informacje, może to być czas na przejście do środowiska produkcyjnego, jeśli masz pewność. Pamiętaj, aby wymienić wszystkie kwestie, ocenić odporność i rozwiązywać wszelkie problemy przed przejściem.

• Ogranicz zakres eksperymentów. Na przykład można zamknąć tylko jedno wystąpienie. Jasno zdefiniuj cel testu. Dowiedz się, co testujesz i dlaczego.

Te testy muszą być zgodne z umowami dotyczącymi poziomu usług przez działanie w ramach wstępnie zdefiniowanych limitów i budżetów błędów. Wybierz odpowiednie przedziały czasowe dla tych eksperymentów. Zazwyczaj wykonywanie ich podczas dnia roboczego gwarantuje, że zespół jest w pełni obsadzony i ma wiele zasobów w celu reagowania na wszelkie zdarzenia, które mogą wystąpić.

Przeprowadzanie ćwiczeń z odzyskiwania po awarii

Inżynieria chaosu testuje odporność kontroli technicznej. Ćwiczenia odzyskiwania po awarii (DR) oceniają odporność mechanizmów kontrolnych procesów. Celem ćwiczeń odzyskiwania po awarii jest zweryfikowanie skuteczności procedur, koordynacji i działań ludzkich przy przywróceniu systemu do działania po poważnych awariach lub katastrofach.

W przypadku obciążeń regulacyjnych wymagania dotyczące zgodności mogą określać częstotliwość ćwiczeń DR w celu zapewnienia dokumentacji wysiłków. W przypadku innych obciążeń zalecane jest regularne przeprowadzanie tych ćwiczeń. Interwał sześciomiesięczny zapewnia dobrą okazję do przechwytywania zmian obciążeń i odpowiednio aktualizowania procedur odzyskiwania po awarii.

Ćwiczenia DR nie mogą być tylko rutynowymi ćwiczeniami. Jeśli przeprowadza się prawidłowo, ćwiczenia DR pomagają szkolić nowych członków zespołu i identyfikować luki w narzędziach, komunikacji i innych zadaniach związanych z ćwiczeniem. Mogą również wyróżniać nowe perspektywy, które w przeciwnym razie mogą być pomijane.

Rozważ następujące kluczowe metody przeprowadzania ćwiczeń disaster recovery, z których każda różni się w zakresie ryzyka i praktyczności.

• W pełni symulowane: Te ćwiczenia są w pełni oparte na tablicy i obejmują przewodniki proceduralne bez wpływu na żadne systemy. Są one odpowiednie do trenowania i weryfikacji początkowej. Nie zapewniają jednak wglądu w rzeczywiste zdarzenia.

• Rzeczywiste ćwiczenia w środowiskach nieprodukcyjnych: Te ćwiczenia umożliwiają weryfikację automatyzacji, skryptów i procesów bez ryzyka biznesowego.

• Rzeczywiste ćwiczenia w środowisku produkcyjnym: Te ćwiczenia zapewniają najwyższy poziom zaufania i realizmu. Przeprowadź te ćwiczenia dopiero po przetestowaniu poprzednich dwóch metod. Dokładne strategie planowania i wycofywania są niezbędne do zminimalizowania ryzyka. Nie kontynuuj, jeśli wystąpi jakiekolwiek prawdopodobieństwo wystąpienia awarii.

Niezależnie od typu testu przywracania po awarii, jasno zdefiniuj scenariusze przywracania obciążeń roboczych. Przeprowadź ćwiczenia tak, jakby były prawdziwymi zdarzeniami. Takie podejście zapewnia, że zespół przestrzega dobrze zrozumianych list kontrolnych. Dokumentowanie i klasyfikowanie wyników w celu ciągłego ulepszania. Przygotowanie odzyskiwania po awarii może obejmować następujące procesy:

• Poznaj systemy zarządzania zdarzeniami i upewnij się, że zespół jest przeszkolony na ścieżkach eskalacji.

• Lista narzędzi komunikacyjnych do współpracy i aktualizacji statusu, w tym alternatyw w przypadku, gdy systemy podstawowe zostaną zakłócone.

• Dostarczaj materiały szkoleniowe dotyczące odpowiednich scenariuszy testowych dla środowiska pracy.

• Śledzenie rozbieżności w celu przechwycenia problemów napotkanych podczas implementacji.

Kompromis: Te ćwiczenia nie są zwykle destrukcyjne, ale zajmują trochę czasu. Aby zmaksymalizować ich skuteczność, skup się na kluczowych aspektach i unikaj niepotrzebnych zadań. Pamiętaj, aby przydzielić czas na tę praktykę w swoim rejestrze zadań.

Podczas tworzenia planów odzyskiwania po awarii lub przeprowadzania prób odzyskiwania po awarii, należy rozważyć uwzględnienie specjalistycznej wiedzy, szczególnie podczas pierwszych kilku prób. Ich wkład dotyczący projektowania w wielu regionach, strategii awaryjnego przełączania i powrotu do normalnego działania oraz usług lub narzędzi może być nieoceniony. Jeśli Twoja organizacja ma zespół centrum doskonałości w chmurze, pamiętaj, aby uwzględnić je w procesie planowania.

√ Oceń twój model danych i segmentuj w razie potrzeby

Dane są dynamiczne i stale ewoluują. W przeciwieństwie do innych składników architektury dane zwykle rosną w miarę interakcji użytkowników z systemem. Monitorowanie wzorców danych w czasie i ocenianie ich wpływu na inne części architektury jest niezbędne. Na tym poziomie należy wziąć pod uwagę techniki upraszczające zarządzanie danymi i zwiększające wydajność w celu zwiększenia ogólnej niezawodności. Partycjonowanie to kluczowa strategia osiągania tych wyników.

Poznaj techniki, takie jak partycjonowanie na gorąco, które dzieli dane na podstawie wzorców dostępu i przechowuje je oddzielnie. Użyj kryteriów, takich jak częstotliwość dostępu lub trafność, aby zdecydować, co należy podzielić na partycje.

Partycjonowanie gorąco-zimne może być łączone z fragmentowaniem, czyli procesem dzielącym dużą bazę danych na mniejsze jednostki nazywane fragmentami. Każdy fragment zawiera część danych i razem tworzą kompletny zestaw danych. Takie podejście umożliwia niezależne zarządzanie danymi.

Kompromis: Równoważenie fragmentów wymaga procesów operacyjnych w celu oceny i potwierdzenia ich dystrybucji. Takie podejście pomaga uniknąć gorących partycji, w których jedna partycja jest nadmiernie używana. Jednak wymaga to również ciągłego wysiłku i zasobów w celu zachowania równowagi.

Podczas wybierania techniki partycjonowania należy wziąć pod uwagę następujące korzyści z niezawodności:

• Zwiększona wydajność: Dystrybuując żądania w wielu partycjach, można zmniejszyć obciążenie poszczególnych magazynów. W przypadku efektywnego wdrażania fragmentowanie umożliwia systemowi przetwarzanie milionów żądań zapisu dziennie. Ta strategia zwiększa wydajność i minimalizuje opóźnienia.

  Partycjonowanie może uprościć skalowanie w poziomie. Na przykład fragmentowanie może podzielić użytkowników lub klientów na zasobniki o równym rozmiarze.

• Ulepszone zarządzanie danymi: Partycjonowanie gorące na zimno umożliwia stosowanie różnych poziomów zarządzania danymi do każdej warstwy magazynowania. Na przykład przenoszenie danych archiwalnych do oddzielnego magazynu pomaga zapobiec spowolnieniu operacji i kopii zapasowych. Podobnie nie wszystkie dane dziennika muszą być przechowywane w relacyjnej bazie danych. Można je przechowywać w innym magazynie danych, podczas gdy aktywne dane robocze pozostają relacyjne.

• Dostosowane zasady niezawodności: Można zastosować różne zasady niezawodności, aby zapewnić, że każda partycja ma odpowiedni poziom odporności i zapobiega powstawaniu wąskich gardeł w każdym magazynie. Gorące partycje mogą być całkowicie redundantne, obejmując nadmiarowość strefową i geograficzną, podczas gdy zimne partycje opierają się na kopiach zapasowych. Dodatkową korzyścią w zakresie niezawodności jest to, że można zmniejszyć zakres wpływu niektórych typów awarii systemowych. Na przykład jeśli awaria wpłynie na jeden fragment, może nie mieć wpływu na inne fragmenty.

Kompromis: Może to być trudne do utrzymania lub modyfikowania partycji z powodu silnych współzależności między różnymi partycjami danych. Te zmiany mogą mieć wpływ na możliwość weryfikowania spójności i integralności danych, zwłaszcza w porównaniu z pojedynczym magazynem danych. Wraz ze wzrostem liczby partycji potrzeba niezawodnych procesów w celu zachowania integralności danych staje się ważniejsza. Bez tych miar niezawodność może zostać naruszona.