Zasady projektowania niezawodności

Awarie i awarie są poważnymi problemami ze wszystkimi obciążeniami. Niezawodne obciążenie musi przetrwać te zdarzenia i stale zapewniać zamierzone funkcje. Musi być odporny , aby mógł wykrywać, wytrzymać i odzyskiwać awarie w akceptowalnym czasie. Musi być również dostępna , aby użytkownicy mogli uzyskiwać dostęp do obciążenia w obiecanym okresie czasu na obiecanym poziomie jakości.

Nie można zakładać, że błędy nie będą występować, zwłaszcza gdy obciążenie jest tworzone do uruchamiania w systemach rozproszonych. Niektóre składniki mogą zakończyć się niepowodzeniem, podczas gdy inne nadal działają. W pewnym momencie może to mieć wpływ na środowisko użytkownika, co narusza cele biznesowe.

Architektury obciążeń powinny mieć pewność niezawodności w kodzie aplikacji, infrastrukturze i operacjach. Opcje projektowania nie powinny zmieniać intencji określonej przez wymagania biznesowe. Takie zmiany należy uznać za znaczące kompromisy.

Zasady projektowania mają na celu zapewnienie wskazówek dotyczących aspektów niezawodności, które należy wziąć pod uwagę w całym cyklu projektowania. Zacznij od zalecanych metod i uzasadnij korzyści dla zestawu wymagań. Po ustawieniu strategii należy prowadzić akcje przy użyciu listy kontrolnej Niezawodność.

Jeśli te zasady nie zostaną zastosowane do projektu, obciążenie najprawdopodobniej nie będzie przygotowane do przewidywania ani obsługi problemów w środowisku produkcyjnym. Wynikiem mogą być zakłócenia w świadczeniu usług, które prowadzą do strat finansowych. W przypadku obciążeń krytycznych zastosowanie tych zasad może zagrozić bezpieczeństwu.

Projektowanie pod kątem wymagań biznesowych

Zbierz wymagania biznesowe, koncentrując się na zamierzonym narzędziu obciążenia.

Wymagania muszą obejmować środowisko użytkownika, dane, przepływy pracy i charakterystyki, które są unikatowe dla obciążenia. Wynik procesu wymagań musi jasno określać oczekiwania. Cele muszą być osiągalne i negocjowane z zespołem, biorąc pod uwagę określoną inwestycję. Muszą one być udokumentowane, aby napędzać wybory technologiczne, implementacje i operacje.

Podejście	Korzyść
Kwantyfikuj sukces, ustawiając cele dotyczące wskaźników dla poszczególnych składników, przepływów systemowych i całego systemu. Czy te cele sprawiają, że przepływy użytkowników są bardziej niezawodne?	Metryki kwantyfikują oczekiwania. Umożliwiają one zrozumienie złożoności i określenie, czy koszty podrzędne tych złożoności mieszczą się w limicie inwestycyjnym. Wartości docelowe wskazują idealny stan. Możesz użyć wartości jako progów testów, które pomagają wykrywać odchylenia od tego stanu i jak długo trwa powrót do stanu docelowego. Wymagania dotyczące zgodności muszą również mieć przewidywalne wyniki dla przepływów w zakresie. Ustalanie priorytetów tych przepływów zwraca uwagę na obszary, które są najbardziej wrażliwe.
Omówienie zobowiązań platformy. Należy wziąć pod uwagę limity, limity przydziału, regiony i ograniczenia pojemności dla usług.	Umowy dotyczące poziomu usług (SLA) różnią się w zależności od usługi. Nie wszystkie usługi i funkcje są objęte tym samym zakresem. Nie wszystkie usługi lub funkcje są dostępne we wszystkich regionach. Większość limitów zasobów subskrypcji jest na region. Zrozumienie zakresu i limitów może pomóc w wykrywaniu dryfu i tworzenia mechanizmów odporności i odzyskiwania.
Określ zależności i ich wpływ na odporność.	Śledzenie infrastruktury, usług, interfejsów API i funkcji zależnych opracowanych przez inne zespoły lub inne firmy pomaga określić, czy obciążenie może działać w przypadku braku tych zależności. Pomaga również zrozumieć błędy kaskadowe i poprawić operacje podrzędne. Deweloperzy mogą implementować odporne wzorce projektowe , aby obsługiwać potencjalne błędy w przypadku korzystania z usług zewnętrznych, które mogą być podatne na błędy.

Projektowanie pod kątem odporności

Obciążenie musi nadal działać z pełną lub ograniczoną funkcjonalnością.

Należy oczekiwać, że wystąpią awarie składników, awarie platformy, obniżenie wydajności, ograniczona dostępność zasobów i inne błędy. Tworzenie odporności w systemie w taki sposób, aby była odporna na uszkodzenia i mogła bezpiecznie ulec pogorszeniu.

Podejście	Korzyść
Rozróżnianie składników znajdujących się na ścieżce krytycznej od składników , które mogą działać w stanie obniżonej wydajności.	Nie wszystkie składniki obciążenia muszą być równie niezawodne. Określenie krytycznej wartości pomaga projektować zgodnie z krytycznością każdego składnika. W przypadku składników, które mogą nieco pogorszyć środowisko użytkownika, nie będą nadmiernie podatne na awarie składników, które mogą powodować kompleksowe problemy. Projekt może być wydajny w przydzielaniu zasobów do krytycznych składników. Można również zaimplementować strategie izolacji błędów, aby w przypadku awarii składnika niekrytycznego lub wprowadzenia stanu obniżonej wydajności można go odizolować, aby zapobiec awariom kaskadowym.
Zidentyfikuj potencjalne punkty awarii w systemie, szczególnie w przypadku krytycznych składników i określ wpływ na przepływy użytkowników.	Możesz analizować przypadki awarii, promień wybuchu i intensywność błędu: pełne lub częściowe przestoje. Ta analiza wpływa na projektowanie możliwości obsługi błędów na poziomie składnika.
Twórz możliwości samozachowawcze przy użyciu wzorców projektowych poprawnie i modularyzując projekt w celu odizolowania błędów.	System będzie mógł zapobiec problemowi wpływającemu na składniki podrzędne. System będzie mógł ograniczyć przejściowe i trwałe awarie, wąskie gardła wydajności i inne problemy, które mogą mieć wpływ na niezawodność. Będzie można również zminimalizować promień wybuchu.
Dodaj możliwość skalowania w poziomie krytycznych składników (aplikacji i infrastruktury), uwzględniając ograniczenia pojemności usług w obsługiwanych regionach.	Obciążenie będzie mogło obsługiwać zmienne skoki i wahania pojemności. Ta funkcja ma kluczowe znaczenie w przypadku nieoczekiwanego obciążenia systemu, takiego jak wzrost prawidłowego użycia. Jeśli obciążenie jest przeznaczone do skalowania w poziomie w wielu regionach, może nawet przezwyciężyć potencjalne tymczasowe ograniczenia pojemności zasobów lub inne problemy wpływające na jeden region.
Tworzenie nadmiarowości w warstwach i odporności na różnych warstwach aplikacji. Dążyć do nadmiarowości w narzędziach fizycznych i natychmiastowej replikacji danych. Celem jest również nadmiarowość w warstwie funkcjonalnej, która obejmuje usługi, operacje i personel.	Nadmiarowość pomaga zminimalizować pojedyncze punkty awarii. Jeśli na przykład występuje składnik, strefowe lub regionalne, nadmiarowe wdrożenie (w trybie aktywny-aktywny lub aktywny-pasywny) umożliwia spełnienie celów czasu pracy. Dodawanie pośredników uniemożliwia bezpośrednią zależność między składnikami i poprawia buforowanie. Obie te korzyści wzmacniają odporność systemu.
Nadmierna aprowizacja w celu natychmiastowego wyeliminowania poszczególnych awarii wystąpień nadmiarowych i buforowania przed uciekającym zużyciem zasobów.	Wyższa inwestycja w nadmierną aprowizowanie zwiększa odporność. System będzie nadal działać w pełnym narzędziu podczas aktywnej awarii nawet przed rozpoczęciem operacji skalowania w celu skorygowania awarii. Podobnie można zmniejszyć ryzyko nieoczekiwanego zużycia zasobów uciekających, twierdząc, że planowany bufor, zyskuje krytyczny czas klasyfikacji, zanim wystąpi awarie systemu lub agresywne skalowanie.

Projektowanie pod kątem odzyskiwania

Obciążenie musi być w stanie przewidywać i odzyskiwać dane po większości awarii o wszystkich rozmiarach, przy minimalnych zakłóceniach środowiska użytkownika i celów biznesowych.

Nawet wysoce odporne systemy wymagają podejść do gotowości na awarie, zarówno w projektach architektury, jak i operacjach obciążeń. W warstwie danych powinny istnieć strategie, które mogą naprawiać stan obciążenia w przypadku uszkodzenia.

Podejście	Korzyść
Mają ustrukturyzowane, przetestowane i udokumentowane plany odzyskiwania dostosowane do wynegocjowanych celów odzyskiwania. Plany muszą obejmować wszystkie składniki oprócz całego systemu.	Dobrze zdefiniowany proces prowadzi do szybkiego odzyskiwania , które może zapobiec negatywnemu wpływowi na finanse i reputację firmy. Przeprowadzanie regularnych próbnego odzyskiwania testuje proces odzyskiwania składników systemu, danych i trybu failover oraz kroków powrotu po awarii, aby uniknąć nieporozumień, gdy czas i integralność danych są kluczowymi miarami sukcesu.
Upewnij się, że możesz naprawić dane wszystkich składników stanowych w ramach celów odzyskiwania.	Kopie zapasowe są niezbędne do powrotu systemu do stanu roboczego przy użyciu zaufanego punktu odzyskiwania, takiego jak ostatni znany dobry stan. Niezmienne i transakcyjnie spójne kopie zapasowe zapewniają, że nie można zmienić danych i że przywrócone dane nie są uszkodzone.
Implementowanie zautomatyzowanych funkcji samonaprawiania w projekcie.	Ta automatyzacja zmniejsza ryzyko związane z czynnikami zewnętrznymi, takimi jak interwencja człowieka, i skraca cykl naprawy przerwania.
Zastąp składniki bezstanowe niezmiennymi jednostkami efemerycznym.	Tworzenie efemerycznych jednostek, które można uruchamiać i niszczyć na żądanie, zapewnia powtarzalność i spójność. Modele wdrażania równoległego umożliwiają przejście do nowych jednostek przyrostowych, minimalizując zakłócenia.

Projektuj pod kątem operacji

Shift w lewo w operacjach, aby przewidzieć warunki awarii.

Błędy testów są na wczesnym etapie i często w cyklu projektowania oraz określają wpływ wydajności na niezawodność. Ze względu na analizę głównych przyczyn i postmortems musisz mieć wspólną widoczność między zespołami ze stanem zależności i trwającymi awariami. Szczegółowe informacje, diagnostyka i alerty z obserwowanych systemów mają podstawowe znaczenie dla efektywnego zarządzania zdarzeniami i ciągłego ulepszania.

Podejście	Korzyść
Tworzenie obserwowalnych systemów , które mogą skorelować dane telemetryczne.	Monitorowanie i diagnostyka są kluczowymi operacjami. Jeśli coś nie powiedzie się, musisz wiedzieć, że nie powiodło się, gdy się nie powiodło i dlaczego się nie powiodło. Wgląd na poziomie składnika jest fundamentalny, ale zagregowana wgląd w składniki i skorelowane przepływy użytkowników zapewnia całościowy widok stanu kondycji. Te dane są wymagane w celu umożliwienia inżynierom niezawodności lokacji nad priorytetem działań naprawczych.
Przewidywanie potencjalnych awarii i nietypowych zachowań. Uwidocznij aktywne błędy niezawodności przy użyciu alertów z priorytetem i z możliwością działania. Zainwestuj w niezawodne procesy i infrastrukturę, która prowadzi do szybszego klasyfikacji.	Inżynierowie niezawodności lokacji mogą natychmiast otrzymywać powiadomienia, aby zapobiec trwającym zdarzeniu w witrynie i aktywnie ograniczyć potencjalne awarie identyfikowane przez alerty predykcyjne, zanim staną się zdarzeniami na żywo.
Symulowanie błędów i uruchamianie testów w środowiskach produkcyjnych i przedprodukcyjnych.	Korzystne jest doświadczenie awarii w środowisku produkcyjnym, dzięki czemu można ustawić realistyczne oczekiwania dotyczące odzyskiwania. Pozwala to na podejmowanie decyzji projektowych, które bezpiecznie reagują na błędy. Ponadto umożliwia testowanie progów ustawionych dla metryk biznesowych.
Twórz składniki z myślą o automatyzacji i automatyzuj tak samo, jak to tylko możliwe.	Automatyzacja minimalizuje potencjał błędów ludzkich, zapewniając spójność testowania, wdrażania i operacji.
Uwzględnianie rutynowych operacji i ich wpływ na stabilność systemu.	Obciążenie może podlegać trwającym operacjom, na przykład poprawkom aplikacji, inspekcjom zabezpieczeń i zgodności, uaktualnieniom składników i procesom tworzenia kopii zapasowych. Przeanalizowanie tych zmian zapewnia stabilność systemu.
Ciągłe uczenie się na podstawie zdarzeń w środowisku produkcyjnym.	Na podstawie zdarzeń można określić wpływ i nadzoru w projekcie i operacjach, które mogą być niezauważone w przedprodukcji. Ostatecznie będziesz mieć możliwość wprowadzania ulepszeń na podstawie rzeczywistych zdarzeń.

Zachowaj prostotę

Unikaj nadmiernego projektowania architektury, kodu aplikacji i operacji.

Często jest to to, co usuwasz, a nie to, co dodajesz, co prowadzi do najbardziej niezawodnych rozwiązań. Prostota zmniejsza obszar powierzchni w celu sterowania, minimalizując nieefektywność i potencjalne błędy konfiguracji lub nieoczekiwane interakcje. Z drugiej strony nadmierne uproszczenie może powodować pojedyncze punkty awarii. Zachowaj zrównoważone podejście.

Podejście	Korzyść
Dodaj składniki do architektury tylko wtedy, gdy ułatwiają one osiąganie docelowych wartości biznesowych. Zachowaj chylenie ścieżki krytycznej.	Projektowanie pod kątem wymagań biznesowych może prowadzić do prostego rozwiązania , które jest łatwe do zaimplementowania i zarządzania. Unikaj zbyt wielu krytycznych składników, ponieważ każdy z nich jest istotnym punktem awarii.
Ustanów standardy w implementacji kodu, wdrażaniu i procesach oraz udokumentowaniu ich. Identyfikowanie możliwości wymuszania tych standardów przy użyciu zautomatyzowanych walidacji.	Standardy zapewniają spójność i minimalizują błędy ludzkie. Podejścia takie jak standardowe konwencje nazewnictwa i przewodniki dotyczące stylu kodu mogą ułatwić utrzymanie jakości i ułatwianie identyfikacji zasobów podczas rozwiązywania problemów.
Oceń, czy podejścia teoretyczne przekładają się na pragmatyczny projekt , który ma zastosowanie do przypadków użycia.	Kod aplikacji, który jest zbyt szczegółowy, może prowadzić do niepotrzebnej współzależności, dodatkowych operacji i trudnej konserwacji.
Opracowywanie wystarczającej ilości kodu.	Będziesz mieć możliwość zapobiegania problemom, które są wynikiem nieefektywnych implementacji, takich jak nieoczekiwane użycie zasobów, błędy użytkownika lub przepływu danych oraz błędy kodu. Z drugiej strony problemy z niezawodnością powinny prowadzić do przeglądów kodu w celu zapewnienia, że kod jest wystarczająco odporny, aby obsłużyć problemy.
Korzystaj z funkcji udostępnianych przez platformę i wstępnie utworzonych zasobów, które mogą pomóc w efektywnym osiąganiu celów biznesowych.	Takie podejście minimalizuje czas programowania. Umożliwia również poleganie na wypróbowanych i przetestowanych rozwiązaniach , które były używane z podobnymi obciążeniami.

Następne kroki

Lista kontrolna dotycząca niezawodności