Udostępnij przez

Zasady projektu — Niezawodność

Awarie i usterki są poważnymi problemami we wszystkich zadaniach roboczych. Niezawodne obciążenie musi przetrwać te zdarzenia i stale zapewniać zamierzone funkcje. Musi być odporny , aby można było wykrywać i wytrzymać błędy podczas ciągłego działania. Należy go odzyskać , aby w przypadku przekroczenia zakłóceń środki odporności można przywrócić obciążenie w ramach uzgodnionych celów odzyskiwania. Musi być również dostępne aby użytkownicy mogli uzyskać dostęp do obciążenia w obiecanym czasie i obiecanej jakości.

Nie można zakładać, że awarie 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. Wybory projektowe 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 podejmij działania przy użyciu listy kontrolnej niezawodności.

Jeśli nie zastosujesz tych zasad do projektu, obciążenie najprawdopodobniej nie będzie przygotowane do przewidywania ani obsługi problemów w środowisku produkcyjnym. W wyniku mogą wystąpić zakłócenia w działaniu usługi, które mogą spowodować utratę klientów. Nieprzestrzeganie tych zasad w przypadku obciążeń o krytycznym znaczeniu może zagrozić bezpieczeństwu.

Projektowanie pod kątem wymagań biznesowych

Ikona celu Uzyskaj przejrzystość co do zakresu pracy, wzrostu liczby użytkowników, a co najważniejsze, obietnic, które zespół złożył zewnętrznym klientom i wewnętrznym interesariuszom.

Projektowanie nie jest zgadywaniem na podstawie niezdefiniowanych bądź niejasnych wyników. Niezawodność wymaga celowego działania, które osiąga dopasowanie do akceptowalnego środowiska użytkownika, ograniczeń projektowych i tego, jak wygląda sukces i jak jest mierzony.

Określ jasne, osiągalne i udokumentowane cele, wynegocjowane z zainteresowanymi stronami biznesowymi i zakorzenione w realistycznych inwestycjach i prognozowaniu. Te wymagania będą bezpośrednio informować o Twoich wyborach architektonicznych, od strategii odporności do narzędzi obserwowalności i planów skalowania.

Metoda Korzyść
Skoncentruj się na zbieraniu informacji potrzebnych do zdefiniowania zakresu i głębokości rozwiązania. Wyjaśnienie ograniczeń mających wpływ na cele biznesowe. Zacznij od pytań wysokiego poziomu, takich jak:

- Jaki poziom odporności, odzyskiwania, obserwacji i prostoty jest wymagany?
— Czy istnieją zdefiniowane ograniczenia związane z kosztami, zgodnością, lokalizacją geograficzną lub opóźnieniem?

Na podstawie tych informacji udokumentować, co jest wystarczająco dobre i proste do osiągnięcia.		 Zrozumienie celów i granic uniemożliwi odgadnięcie. W przeciwnym razie być może utkniesz w pętli projektowej iteracyjnej, co spowoduje zmarnowanie wysiłków i niepotrzebnych kosztów.
Prowadzenie podejmowania decyzji przez przekształcanie celów biznesowych we wspólne zrozumienie dylematów architektonicznych w kontekście rzeczywistych ograniczeń. Prezentuj opcje, które mają wpływ:

- Koszt finansowy
— Złożoność inżynieryjna
- Zagadnienia dotyczące zabezpieczeń
- Obciążenie operacyjne		 Pomoże to uczestnikom projektu zrozumieć koszty, złożoność i konsekwencje operacyjne swoich zapytań oraz kierować je do realistycznych, dopasowanych wyników.
Należy priorytetowo traktować definiowanie wyników niezawodności dla każdego krytycznego przepływu użytkownika zamiast ogólnych mierników, takich jak czas dostępności.

Zidentyfikuj możliwości i przepływy użytkowników przez system oraz dla każdego z nich oceń swoją wartość biznesową, wzorce użycia i wymagania dotyczące odporności. Dążenie do konsensusu na poziomie przepływu w celu zapewnienia, że decyzje projektowe pozostają zgodne z celami biznesowymi.		 Ta rozmowa pomaga przesunąć interesariuszy od niewykonalnych oświadczeń, takich jak "witryna musi być zawsze dostępna", w kierunku praktycznych, osiągalnych oczekiwań związanych z rzeczywistymi funkcjami i wynikami. Te wyniki pomagają ustalić, co jest rozwiązywane z technologią i co można rozwiązać z dodatkowymi planami ciągłości działania.
Zakotwicz decyzje projektowe wokół horyzontów czasowych.

Zdefiniuj oczekiwania dotyczące użycia z realistycznymi prognozami. Na przykład jakie jest oczekiwane obciążenie użytkownika podczas uruchamiania? Oczekuje się, że wzrost użytkowników będzie liniowy, wykładniczy lub niepewny.		 Te informacje pomogą Ci zaprojektować architekturę, która będzie obsługiwać krótkoterminowe potrzeby w zakresie niezawodności, unikając decyzji projektowych, które będą wymagały znacznej pracy w celu obsługi przyszłych horyzontów. Takie podejście wpływa na sposób myślenia o elastyczności, przepływach pracy opartych na zdarzeniach i umożliwia podejmowanie strategicznych decyzji dotyczących tego, jaki dług techniczny należy zaciągnąć lub jakiego unikać.
Uwzględnij zależności, które mogą ograniczać autonomię projektu, takie jak ograniczenia organizacyjne.

Należy pamiętać o scentralizowanej infrastrukturze, mandatach zabezpieczeń, zasadach routingu sieciowego lub decyzjach dotyczących platformy, które mają bezpośredni wpływ na to, co można obiecać pod względem odporności, dostępności i odzyskiwania.		 Zrozumienie zależności od usług spoza kontroli pomaga zaprojektować realistyczne oczekiwania dotyczące niezawodności. Gwarantuje, że Twoje cele RTO/RPO i SLO są osiągalne oraz jasno komunikowane, co pozwala unikać obietnic bez pokrycia i ograniczać niespodzianki.

Projektowanie pod kątem odporności

Ikona celu Obciążenie robocze 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. Zbuduj odporność w systemie, aby był odporny na uszkodzenia i mógł umiarkowanie się pogarszać.

Metoda 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 krytyczności pomaga zaprojektować zgodnie z krytycznością każdego składnika. Nie będziesz mieć nadmiernej odporności składników, które mogą nieco pogorszyć środowisko użytkownika, w przeciwieństwie do składników, które mogą powodować kompleksowe problemy w przypadku awarii.

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 wejść w stan obniżonej wydajności, można go odizolować, aby zapobiec awariom kaskadowym.
Zidentyfikuj potencjalne punkty awarii w systemie, szczególnie w przypadku składników krytycznych, i określ wpływ na przepływy użytkowników. Możesz analizować przypadki niepowodzeń, zasięg awarii i intensywność awarii: pełne lub częściowe przestoje. Ta analiza ma wpływ na projektowanie możliwości obsługi błędów na poziomie składnika.
Rozwijaj zdolności do samopodtrzymywania się poprzez poprawne stosowanie wzorców projektowych i modularizację projektu w celu izolacji 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), biorąc pod uwagę ograniczenia pojemności usług w obsługiwanych regionach. Obciążenie będzie mogło radzić sobie ze zmiennymi skokami zapotrzebowania i wahaniami. Ta funkcja ma kluczowe znaczenie w przypadku nieoczekiwanego obciążenia systemu, takiego jak wzrost uzasadnionego 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.
Budowanie nadmiarowości w warstwach i odporności na różnych poziomach aplikacji.

Celem jest redundancja w infrastrukturze fizycznej i natychmiastowa replikacja danych. Celem jest również dążenie do wprowadzenia nadmiarowości w warstwie funkcjonalnej, która obejmuje usługi, operacje i personel.		 Nadmiarowość pomaga zminimalizować pojedyncze punkty awarii. Jeśli na przykład występuje awaria komponentu, strefowa lub regionalna, redundantne wdrożenie (w trybie aktywny-aktywny lub aktywny-pasywny) umożliwia osiąganie docelowego 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 niepowodzeń wystąpień nadmiarowych i buforowania przed zużyciem zasobów uciekanych. Większa inwestycja w nadmiarowe zasoby zwiększa odporność.

System będzie nadal działać z pełną wydajnością podczas aktywnej awarii, nawet zanim operacje skalowania będą mogły się rozpocząć w celu skorygowania awarii. Podobnie można zmniejszyć ryzyko nieoczekiwanego niekontrolowanego zużycia zasobów, zajmując planowany bufor i zdobywając kluczowy czas na podjęcie działań, zanim wystąpią awarie systemu lub agresywne skalowanie.

Projektowanie pod kątem odzyskiwania

Ikona celu 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ścia do gotowości po awarii zarówno w przypadku operacji projektowania architektury, jak i obciążeń. W warstwie danych powinny istnieć strategie, które mogą naprawiać stan obciążenia w przypadku uszkodzenia.

Metoda Korzyść
Mają ustrukturyzowane, przetestowane i udokumentowane plany odzyskiwania zgodne z wynegocjowanymi celami 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ób odzyskiwania sprawdza proces przywrócenia składników systemu, danych oraz procedury przełączania awaryjnego i odtwarzania, aby uniknąć zakłóceń, gdy czas i integralność danych są kluczowymi miarami sukcesu.
Upewnij się, że możesz naprawić dane wszystkich składników stanowych zgodnie z celami odzyskiwania. Kopie zapasowe są niezbędne do przywrócenia systemu do stanu operacyjnego 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.
Zaimplementuj automatyczne funkcje samonaprawiania w projekcie. Ta automatyzacja zmniejsza ryzyko związane z czynnikami zewnętrznymi, takimi jak interwencja człowieka, i skraca cykl rozwiązywania problemów.
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 obok siebie umożliwiają stopniowe przejście do nowych jednostek, minimalizując zakłócenia.

Projektowanie operacji

Ikona celu Przesuń w lewo w operacjach, aby przewidzieć warunki awarii.

Testuj błędy wcześnie i często w cyklu rozwoju oraz określ wpływ wydajności na niezawodność. Ze względu na analizę głównych przyczyn i postmortems musisz mieć współużytkowany wgląd w zespoły, stan zależności i bieżące awarie. Szczegółowe informacje, diagnostyka i alerty z obserwowanych systemów mają podstawowe znaczenie dla efektywnego zarządzania zdarzeniami i ciągłego ulepszania.

Metoda Korzyść
Twórz obserwowalne systemy , które mogą skorelować dane telemetryczne. Monitorowanie i diagnostyka są kluczowymi operacjami. Jeśli coś się nie powiedzie, musisz wiedzieć, że nie powiodło się, gdy zakończyła się niepowodzeniem i dlaczego zakończyła się niepowodzeniem. Obserwowanie na poziomie składnika jest podstawowe, ale zagregowana możliwość obserwowania składników i skorelowanych przepływów użytkownika zapewnia całościowy widok stanu kondycji. Te dane są wymagane, aby umożliwić inżynierom niezawodności lokacji ustalanie priorytetów w celu skorygowania.
Przewidywanie potencjalnych awarii i nietypowych zachowań. Uwidocznij aktywne błędy niezawodności przy użyciu alertów z priorytetami i z możliwością działania.

Zainwestuj w niezawodne procesy i infrastrukturę, która prowadzi do szybszego klasyfikacji.		 Inżynierowie niezawodności strony mogą być natychmiast powiadamiani, aby złagodzić trwające incydenty na żywo i proaktywnie łagodzić potencjalne awarie identyfikowane przez alerty predykcyjne, zanim staną się incydentami 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. Dzięki temu można dokonać wyborów 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 dużo, jak potrafisz. Automatyzacja minimalizuje potencjał błędu ludzkiego, zapewniając spójność testowania, wdrażania i operacji.
Uwzględnij rutynowe operacje 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. Badanie tych zmian zapewnia stabilność systemu.
Ciągłe uczenie się na podstawie zdarzeń w środowisku produkcyjnym. Na podstawie incydentów można określić wpływ i przeoczenia w projektowaniu i działaniach, które mogą pozostać niezauważone w przedprodukcji. Ostatecznie będziesz mieć możliwość wprowadzania ulepszeń na podstawie rzeczywistych zdarzeń.

Zachowaj prostotę

Ikona Cel Unikaj nadmiernej inżynierii projektu architektury, kodu aplikacji i operacji.

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

Metoda Korzyść
Dodaj składniki do architektury tylko wtedy, gdy ułatwiają one osiągnięcie 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 składników krytycznych, ponieważ każdy z nich jest istotnym punktem awarii.
Ustanów standardy implementacji kodu, wdrażania i procesów oraz dokumentuj je. Identyfikowanie możliwości wymuszania tych standardów przy użyciu zautomatyzowanych walidacji. Standardy zapewniają spójność i minimalizują błędy ludzkie. Metody, takie jak standardowe konwencje nazewnictwa i przewodniki dotyczące stylu kodu, mogą pomóc w utrzymaniu jakości i ułatwieniu 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 poradzić sobie z problemami.
Korzystaj z funkcji udostępnianych przez platformę i wstępnie utworzonych zasobów, które mogą pomóc w efektywnym spełnianiu celów biznesowych. Takie podejście minimalizuje czas programowania. Umożliwia również poleganie na wypróbowanych i przetestowanych rozwiązaniach , które zostały użyte z podobnymi obciążeniami.

Dalsze kroki

Lista kontrolna dotycząca niezawodności

  • Last updated on