Zasady projektowania obciążenia o krytycznym znaczeniu
Metodologia projektowania krytycznego dla misji jest poparta pięcioma kluczowymi zasadami projektowania, które służą jako kompas dla kolejnych decyzji projektowych w krytycznych obszarach projektowych. Zdecydowanie zalecamy zapoznanie się z tymi zasadami, aby lepiej zrozumieć ich wpływ i kompromisy związane z niezgodnością.
Ważne
Ten artykuł jest częścią serii obciążeń o znaczeniu krytycznym dla platformy Azure Well-Architected . Jeśli nie znasz tej serii, zalecamy rozpoczęcie od tego, co to jest obciążenie o znaczeniu krytycznym?
Te zasady projektowania o krytycznym znaczeniu rezonują i rozszerzają filary jakości platformy Azure Well-Architected Framework — niezawodność, zabezpieczenia, optymalizacja kosztów, doskonałość operacyjna i wydajność.
Niezawodność
Maksymalna niezawodność — podstawowe dążenie do najbardziej niezawodnego rozwiązania, zapewniając prawidłowe zrozumienie kompromisów.
| Zasada projektowania | Zagadnienia do rozważenia |
|---|---|
| Projekt aktywny/aktywny | Aby zmaksymalizować dostępność i osiągnąć regionalną odporność na uszkodzenia, składniki rozwiązania powinny być dystrybuowane w wielu Strefy dostępności i regionach świadczenia usługi Azure przy użyciu aktywnego/aktywnego modelu wdrażania, jeśli to możliwe. |
| Redukcja promieni wybuchu i izolacja błędów | Niepowodzenie nie jest możliwe, aby uniknąć w wysoce rozproszonym środowisku chmury wielodostępnej, takiej jak platforma Azure. Przewidując awarie i skorelowany wpływ, od poszczególnych składników do całych regionów platformy Azure, rozwiązanie można projektować i opracowywać w sposób odporny. |
| Obserwowanie kondycji aplikacji | Zanim problemy wpływające na niezawodność aplikacji mogą zostać rozwiązane, należy najpierw je wykryć i zrozumieć. Monitorując działanie aplikacji względem znanego stanu dobrej kondycji, można wykryć lub nawet przewidzieć problemy z niezawodnością, co pozwala na szybkie podjęcie działań naprawczych. |
| Automatyzacja dysków | Jedną z głównych przyczyn przestoju aplikacji jest błąd ludzki, niezależnie od tego, czy jest to spowodowane wdrożeniem wystarczająco przetestowanego oprogramowania, czy błędną konfiguracją. Aby zminimalizować możliwość i wpływ błędów ludzkich, należy dążyć do automatyzacji we wszystkich aspektach rozwiązania w chmurze w celu zwiększenia niezawodności; zautomatyzowane testowanie, wdrażanie i zarządzanie. |
| Projektuj pod kątem samonaprawiania | Samonaprawianie opisuje zdolność systemu do automatycznego radzenia sobie z awariami za pośrednictwem wstępnie zdefiniowanych protokołów korygowania połączonych z trybami awarii w rozwiązaniu. Jest to zaawansowana koncepcja, która wymaga wysokiego poziomu dojrzałości systemu z monitorowaniem i automatyzacją, ale powinna być aspiracją od początku, aby zmaksymalizować niezawodność. |
| Unikanie złożoności | Unikaj niepotrzebnej złożoności podczas projektowania rozwiązania i wszystkich procesów operacyjnych w celu zwiększenia wydajności niezawodności i zarządzania, minimalizując prawdopodobieństwo awarii. |
Efektywność wydajności
Zrównoważona wydajność i skalowalność — projektowanie pod kątem skalowalności w ramach kompleksowego rozwiązania bez wąskich gardeł wydajności.
| Zasada projektowania | Zagadnienia do rozważenia |
|---|---|
| Projektowanie pod kątem skalowania w poziomie | Skalowanie w poziomie to koncepcja, która koncentruje się na zdolności systemu do reagowania na zapotrzebowanie poprzez poziomy wzrost. Oznacza to, że wraz ze wzrostem ruchu więcej jednostek zasobów jest dodawanych równolegle zamiast zwiększać rozmiar istniejących zasobów. System może obsługiwać oczekiwany i nieoczekiwany wzrost ruchu przez jednostki skalowania ma zasadnicze znaczenie dla ogólnej wydajności i niezawodności przez dalsze zmniejszenie wpływu awarii pojedynczego zasobu. |
| Automatyzacja dla hiperskala | Operacje skalowania w całym rozwiązaniu powinny być w pełni zautomatyzowane, aby zminimalizować wpływ wydajności i dostępności na nieoczekiwany lub oczekiwany wzrost ruchu, zapewniając czas potrzebny na przeprowadzenie operacji skalowania i jest zgodny z modelem kondycji aplikacji. |
| Ciągła walidacja i testowanie | Automatyczne testowanie powinno odbywać się w procesach ciągłej integracji/ciągłego wdrażania w celu ciągłej weryfikacji dla każdej zmiany aplikacji. Testowanie obciążenia względem planu bazowego wydajności z zsynchronizowanym eksperymentem chaosu powinno zostać uwzględnione w celu zweryfikowania istniejących progów, celów i założeń, a także ułatwienia szybkiego identyfikowania zagrożeń związanych z odpornością i dostępnością. Takie testy powinny być przeprowadzane w środowiskach przejściowych i testowych, ale także opcjonalnie w środowiskach deweloperskich. Korzystne może być również uruchomienie podzestawu testów w środowisku produkcyjnym, szczególnie w połączeniu z niebieskim/zielonym modelem wdrażania w celu zweryfikowania nowych sygnatur wdrożenia przed odebraniem ruchu produkcyjnego. |
| Zmniejszanie nakładu pracy dzięki zarządzanym usługom obliczeniowym | Korzystanie z zarządzanych usług obliczeniowych i architektur konteneryzowanych znacznie zmniejsza bieżące koszty administracyjne i operacyjne projektowania, obsługi i skalowania aplikacji przez przeniesienie wdrożenia infrastruktury i konserwacji do zarządzanego dostawcy usług. |
| Wydajność punktu odniesienia i identyfikowanie wąskich gardeł | Testowanie wydajnościowe ze szczegółowymi danymi telemetrycznymi z każdego składnika systemu umożliwia identyfikację wąskich gardeł w systemie, w tym składników, które muszą być skalowane w odniesieniu do innych składników, a te informacje należy uwzględnić w modelu pojemności. |
| Pojemność modelu | Model pojemności umożliwia planowanie poziomów skalowania zasobów dla danego profilu obciążenia i dodatkowo uwidacznia sposób działania składników systemowych względem siebie nawzajem, co umożliwia planowanie alokacji pojemności w całej systemie. |
Doskonałość operacyjna
Operacje według projektu — zaprojektowane do ostatniej pracy z niezawodnym i asertywnym zarządzaniem operacyjnym.
| Zasada projektowania | Zagadnienia do rozważenia |
|---|---|
| Luźno połączone składniki | Luźne sprzężenie umożliwia niezależne i na żądanie testowanie, wdrożenia i aktualizacje składników aplikacji przy jednoczesnym zminimalizowaniu zależności między zespołami na potrzeby pomocy technicznej, usług, zasobów lub zatwierdzeń. |
| Automatyzowanie procesów kompilacji i wydawania | W pełni zautomatyzowane procesy kompilacji i wydawania zmniejszają tarcie i zwiększają szybkość wdrażania aktualizacji, zapewniając powtarzalność i spójność w różnych środowiskach. Automatyzacja skraca pętlę opinii od deweloperów wypychających zmiany w celu uzyskania szczegółowych informacji na temat jakości kodu, pokrycia testów, odporności, zabezpieczeń i wydajności, co zwiększa produktywność deweloperów. |
| Elastyczność dewelopera | Automatyzacja ciągłej integracji i ciągłego wdrażania (CI/CD) umożliwia korzystanie z krótkożytnych środowisk programistycznych z cyklami życia powiązanymi z skojarzoną gałęzią funkcji, która promuje elastyczność deweloperów i umożliwia weryfikację jak najszybciej w ramach cyklu inżynieryjnego w celu zminimalizowania kosztów inżynierii usterek. |
| Kwantyfikowanie kondycji operacyjnej | Pełna instrumentacja diagnostyczna wszystkich składników i zasobów umożliwia ciągłą obserwację dzienników, metryk i śladów, ale także ułatwia modelowanie kondycji w celu określenia kondycji aplikacji w kontekście wymagań dotyczących dostępności i wydajności. |
| Próba odzyskania i niepowodzenia praktyki | Ciągłość działania (BC) i odzyskiwanie po awarii (DR) są niezbędne i ćwiczenia praktyczne są niezbędne i powinny być przeprowadzane często, ponieważ nauki mogą iteracyjne ulepszać plany i procedury w celu zmaksymalizowania odporności w przypadku nieplanowanego przestoju. |
| Obsługa ciągłego ulepszania operacyjnego | Ustalanie priorytetów rutynowych ulepszeń środowiska systemu i użytkownika przy użyciu modelu kondycji w celu zrozumienia i mierzenia wydajności operacyjnej za pomocą mechanizmów opinii, aby umożliwić zespołom aplikacji zrozumienie i rozwiązywanie luk w iteracyjny sposób. |
Zabezpieczenia
Zawsze bezpieczne — zaprojektowanie kompleksowego zabezpieczeń w celu utrzymania stabilności aplikacji i zapewnienia dostępności.
| Zasada projektowania | Zagadnienia do rozważenia |
|---|---|
| Monitorowanie zabezpieczeń całego rozwiązania i planowanie reagowania na zdarzenia | Skorelowanie zdarzeń zabezpieczeń i inspekcji w celu modelowania kondycji aplikacji i identyfikowania aktywnych zagrożeń. Ustanów zautomatyzowane i ręczne procedury reagowania na zdarzenia przy użyciu narzędzi do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM) na potrzeby śledzenia. |
| Modelowanie i testowanie pod kątem potencjalnych zagrożeń | Upewnij się, że odpowiednie zabezpieczanie zasobów i ustanawianie procedur w celu identyfikowania i ograniczania znanych zagrożeń przy użyciu testów penetracyjnych w celu zweryfikowania ograniczania ryzyka, a także statycznej analizy kodu i skanowania kodu. |
| Identyfikowanie i ochrona punktów końcowych | Monitoruj i chroń integralność sieci wewnętrznych i zewnętrznych punktów końcowych za pomocą funkcji zabezpieczeń i urządzeń, takich jak zapory lub zapory aplikacji internetowej. Użyj standardowych metod ochrony przed typowymi wektorami ataków, takimi jak ataki DDoS (Distributed Denial-Of-Service), takie jak SlowLoris. |
| Ochrona przed lukami w zabezpieczeniach na poziomie kodu | Identyfikowanie i eliminowanie luk w zabezpieczeniach na poziomie kodu, takich jak wykonywanie skryptów między lokacjami lub wstrzyknięcie kodu, oraz dołączanie poprawek zabezpieczeń do cykli życia operacyjnego dla wszystkich części bazy kodu, w tym zależności. |
| Automatyzowanie i używanie najniższych uprawnień | Napędzaj automatyzację, aby zminimalizować potrzebę interakcji człowieka i zaimplementować najmniejsze uprawnienia zarówno na płaszczyźnie aplikacji, jak i sterowania, aby chronić przed eksfiltracją danych i złośliwymi scenariuszami aktorów. |
| Klasyfikowanie i szyfrowanie danych | Klasyfikowanie danych zgodnie z ryzykiem i stosowanie standardowego szyfrowania w branży magazynowanych i przesyłanych, zapewniając, że klucze i certyfikaty są przechowywane bezpiecznie i prawidłowo zarządzane. |
Optymalizacja kosztów
Istnieją oczywiste kompromisy związane z wprowadzeniem większej niezawodności, które powinny być starannie brane pod uwagę w kontekście wymagań dotyczących obciążeń.
Maksymalizacja niezawodności może mieć wpływ na całkowity koszt finansowy rozwiązania. Na przykład duplikowanie zasobów i rozkład zasobów między regionami w celu osiągnięcia wysokiej dostępności ma wyraźne konsekwencje związane z kosztami. Aby uniknąć nadmiarowych kosztów, nie należy nadmiernie projektować ani nadmiernie aprowizować poza odpowiednimi wymaganiami biznesowymi.
Ponadto istnieją dodatkowe koszty związane z inwestycjami inżynieryjnymi w podstawowe pojęcia dotyczące niezawodności, takie jak wykorzystanie infrastruktury jako kodu, automatyzacji wdrażania i inżynierii chaosu. Wiąże się to z kosztami zarówno czasu, jak i wysiłku, które można zainwestować w inne miejsce w celu dostarczania nowych funkcji i funkcji aplikacji.
Projekt natywny dla chmury
Usługi zarządzane natywne dla platformy Azure — usługi zarządzane natywne dla platformy Azure są priorytetowe ze względu na niższe koszty administracyjne i operacyjne, a także ścisłą integrację z spójną konfiguracją i instrumentacją w stosie aplikacji.
Dopasowanie planu — dołączanie nowych i ulepszonych możliwości usług platformy Azure, ponieważ stają się ogólnie dostępne (GA), aby pozostać blisko wiodącej krawędzi platformy Azure.
Uściślij możliwości w wersji zapoznawczej i zniweluj znane luki — chociaż ogólnie dostępne usługi są priorytetowe dla możliwości obsługi, wersje zapoznawcze usług platformy Azure są aktywnie eksplorowane pod kątem szybkiego włączenia, zapewniając grupom produktów platformy Azure opinie techniczne i umożliwiające podejmowanie działań w celu rozwiązania luk.
Wyrównanie strefy docelowej platformy Azure — możliwe do wdrożenia w strefie docelowej platformy Azure i dostosowane do metodologii projektowania strefy docelowej platformy Azure, ale także w pełni funkcjonalne i możliwe do wdrożenia w środowisku bez strefy docelowej.
Następny krok
Zapoznaj się z problemami krzyżowymi związanymi z obciążeniami o znaczeniu krytycznym.