Wdrażanie i testowanie obciążeń o znaczeniu krytycznym na platformie Azure

Nieudane wdrożenia i błędne wydania są typowymi przyczynami awarii aplikacji. Podejście do wdrażania i testowania odgrywa kluczową rolę w ogólnej niezawodności aplikacji o znaczeniu krytycznym.

Wdrażanie i testowanie powinno stanowić podstawę dla wszystkich operacji aplikacji i infrastruktury w celu zapewnienia spójnych wyników dla obciążeń o znaczeniu krytycznym. Przygotuj się do wdrożenia co tydzień, codziennie lub częściej. Zaprojektuj potoki ciągłej integracji i ciągłego wdrażania (CI/CD), aby obsługiwać te cele.

Strategia powinna zostać zaimplementowana:

• Rygorystyczne testy wersji wstępnej. Aktualizacje nie powinny wprowadzać wad, luk w zabezpieczeniach ani innych czynników, które mogą zagrozić kondycji aplikacji.

• Przezroczyste wdrożenia. W dowolnym momencie powinno być możliwe wprowadzanie aktualizacji bez wpływu na użytkowników. Użytkownicy powinni mieć możliwość kontynuowania interakcji z aplikacją bez przerwy.

• Operacje o wysokiej dostępności. Procesy wdrażania i testowania oraz narzędzia muszą być wysoce dostępne, aby zapewnić ogólną niezawodność aplikacji.

• Spójne procesy wdrażania. Te same artefakty i procesy aplikacji powinny być używane do wdrażania infrastruktury i kodu aplikacji w różnych środowiskach. Kompleksowa automatyzacja jest obowiązkowa. Należy unikać interwencji ręcznych, ponieważ mogą one powodować ryzyko związane z niezawodnością.

Ten obszar projektowania zawiera zalecenia dotyczące optymalizowania procesów wdrażania i testowania w celu zminimalizowania przestojów i utrzymania kondycji i dostępności aplikacji.

Ważne

Ten artykuł jest częścią serii obciążeń Azure Well-Architected Framework o znaczeniu krytycznym. Jeśli nie znasz tej serii, zalecamy rozpoczęcie od tematu Co to jest obciążenie o krytycznym znaczeniu?

Wdrażanie bez przestojów

Obejrzyj poniższy film wideo, aby zapoznać się z omówieniem wdrożenia bez przestojów.

Osiągnięcie wdrożeń bez przestojów jest podstawowym celem aplikacji o krytycznym znaczeniu. Aplikacja musi być dostępna przez cały dzień, codziennie nawet wtedy, gdy nowe wersje są wdrażane w godzinach pracy. Zainwestuj swoje wysiłki z góry, aby zdefiniować i zaplanować procesy wdrażania, aby podjąć kluczowe decyzje projektowe, takie jak traktowanie zasobów jako efemerycznych.

Aby osiągnąć wdrożenie bez przestojów, wdróż nową infrastrukturę obok istniejącej infrastruktury, przetestuj ją dokładnie, przełącz ruch użytkowników końcowych, a następnie zlikwiduj poprzednią infrastrukturę. Inne rozwiązania, takie jak architektura jednostki skalowania, są również kluczowe.

Implementacje referencyjne Mission-Critical Online i Azure Mission-Critical Connected ilustrują to podejście wdrażania, jak pokazano na poniższym diagramie:

Środowiska aplikacji

Zapoznaj się z poniższym filmem wideo, aby zapoznać się z omówieniem zaleceń dotyczących środowisk aplikacji.

Do weryfikowania i etapu operacji wdrażania potrzebne są różne typy środowisk. Typy mają różne możliwości i cykle życia. Niektóre środowiska mogą odzwierciedlać środowisko produkcyjne i długotrwałe, a inne mogą być krótkotrwałe i mieć mniej możliwości niż środowisko produkcyjne. Skonfigurowanie tych środowisk na wczesnym etapie cyklu programowania pomaga zapewnić elastyczność, rozdzielenie zasobów produkcyjnych i przedprodukcyjnych oraz dokładne testowanie operacji przed wydaniem do środowiska produkcyjnego. Wszystkie środowiska powinny odzwierciedlać środowisko produkcyjne jak najwięcej, chociaż w razie potrzeby można zastosować uproszczenia do niższych środowisk. Na tym diagramie przedstawiono architekturę o znaczeniu krytycznym:

Istnieją pewne typowe zagadnienia:

• Składniki nie powinny być współużytkowane w środowiskach. Możliwe wyjątki to podrzędne urządzenia zabezpieczeń, takie jak zapory i lokalizacje źródłowe dla syntetycznych danych testowych.

• Wszystkie środowiska powinny używać artefaktów infrastruktury jako kodu (IaC), takich jak terraform lub szablony usługi Azure Resource Manager (ARM).

Środowiska projektowe

Obejrzyj poniższy film wideo, aby uzyskać informacje o efemerycznych środowiskach deweloperskich i automatycznej weryfikacji funkcji.

Uwagi dotyczące projektowania

• Możliwości. Niższe wymagania dotyczące niezawodności, pojemności i zabezpieczeń są akceptowalne dla środowisk deweloperskich.

• Cykl życia. Środowiska programistyczne powinny być tworzone zgodnie z wymaganiami i istnieć przez krótki czas. Krótsze cykle życia ułatwiają zapobieganie dryfowaniu konfiguracji z bazy kodu i obniżaniu kosztów. Ponadto środowiska deweloperskie często współdzielą cykl życia gałęzi funkcji.

• Gęstość. Zespoły potrzebują wielu środowisk do obsługi opracowywania funkcji równoległych. Mogą współistnieć w ramach jednej subskrypcji.

Zalecenia dotyczące projektowania

• Zachowaj środowisko w dedykowanej subskrypcji z kontekstem ustawionym na potrzeby programowania.

• Użyj zautomatyzowanego procesu, aby wdrożyć kod z gałęzi funkcji do środowiska deweloperskiego.

Środowiska testowe lub przejściowe

Te środowiska są używane do testowania i walidacji. Wiele cykli testowych jest wykonywanych w celu zapewnienia wolnego od błędów wdrożenia w środowisku produkcyjnym. Odpowiednie testy dla obciążenia o krytycznym znaczeniu opisano w sekcji Ciągła walidacja i testowanie .

Uwagi dotyczące projektowania

• Możliwości. Te środowiska powinny odzwierciedlać środowisko produkcyjne pod kątem niezawodności, pojemności i zabezpieczeń. W przypadku braku obciążenia produkcyjnego użyj syntetycznego obciążenia użytkownika, aby zapewnić realistyczne metryki i cenne dane wejściowe modelowania kondycji.

• Cykl życia. Te środowiska są krótkotrwałe. Należy je zniszczyć po zakończeniu walidacji testów.

• Gęstość. W jednej subskrypcji można uruchamiać wiele niezależnych środowisk. Należy również rozważyć użycie wielu środowisk, z których każda należy wziąć pod uwagę w dedykowanej subskrypcji.

Uwaga

Aplikacje o znaczeniu krytycznym powinny być poddawane rygorystycznym testom.

Możesz wykonywać różne funkcje testowe w jednym środowisku, a w niektórych przypadkach konieczne będzie wykonanie tych czynności. Na przykład w przypadku testowania chaosu w celu zapewnienia znaczących wyników należy najpierw umieścić aplikację pod obciążeniem, aby zrozumieć, jak aplikacja reaguje na wstrzyknięte błędy. Dlatego testowanie chaosu i testowanie obciążenia są zwykle wykonywane równolegle.

Zalecenia dotyczące projektowania

• Upewnij się, że co najmniej jedno środowisko przejściowe w pełni odzwierciedla środowisko produkcyjne, aby umożliwić testowanie i walidację przypominającą środowisko produkcyjne. Pojemność w tym środowisku może być elastyczna w oparciu o wykonywanie działań testowych.

• Generowanie syntetycznego obciążenia użytkownika w celu zapewnienia realistycznego przypadku testowego dla zmian w jednym ze środowisk.

  Uwaga

  Implementacja referencyjna aplikacji Mission Critical Online zawiera przykład generatora obciążenia użytkownika.

• Zdefiniuj liczbę środowisk przejściowych i ich celów w ramach cyklu tworzenia i wydawania.

Środowiska produkcyjne

Uwagi dotyczące projektowania

• Możliwości. Wymagane są najwyższe poziomy niezawodności, pojemności i funkcjonalności zabezpieczeń aplikacji.

• Cykl życia. Mimo że cykl życia obciążenia i infrastruktury pozostają takie same, wszystkie dane, w tym monitorowanie i rejestrowanie, wymagają specjalnego zarządzania. Na przykład zarządzanie jest wymagane do tworzenia kopii zapasowych i odzyskiwania.

• Gęstość. W przypadku niektórych aplikacji warto rozważyć użycie różnych środowisk produkcyjnych do obsługi różnych klientów, użytkowników lub funkcji biznesowych.

Zalecenia dotyczące projektowania

Mają wyraźną granicę ładu dla środowiska produkcyjnego i niższego. Umieść każdy typ środowiska w dedykowanej subskrypcji, aby osiągnąć ten cel. Ta segmentacja zapewnia, że wykorzystanie zasobów w niższych środowiskach nie ma wpływu na limity przydziału produkcyjnego. Dedykowane subskrypcje ustawiają również granice dostępu.

Efemeryczne wdrożenia niebieskie/zielone

Niebieski/zielony model wdrażania wymaga co najmniej dwóch identycznych wdrożeń. Niebieskie wdrożenie jest aktywne, które obsługuje ruch użytkowników w środowisku produkcyjnym. Zielone wdrożenie to nowe, które jest przygotowane i przetestowane pod kątem odbierania ruchu. Po zakończeniu i przetestowaniu zielonego wdrożenia ruch jest stopniowo kierowany z niebieskiego do zielonego. Jeśli transfer obciążenia zakończy się pomyślnie, wdrożenie zielone stanie się nowym aktywnym wdrożeniem. Stare niebieskie wdrożenie można następnie zlikwidować za pośrednictwem procesu etapowego. Jeśli jednak występują problemy w nowym wdrożeniu, może zostać przerwany, a ruch może pozostać w starym niebieskim wdrożeniu lub zostać przekierowany do niego.

Usługa Azure Mission-Critical zaleca podejście do wdrażania niebieskiego/zielonego, w którym infrastruktura i aplikacje są wdrażane razem w ramach sygnatury wdrożenia. Dlatego wprowadzenie zmiany infrastruktury lub aplikacji zawsze powoduje zielone wdrożenie, które zawiera obie warstwy. Takie podejście umożliwia pełne przetestowanie i zweryfikowanie wpływu zmiany na kompleksową infrastrukturę i aplikację przed przekierowaniem ruchu użytkowników do niej. Takie podejście zwiększa zaufanie do wydawania zmian i umożliwia uaktualnianie bez przestojów, ponieważ można zweryfikować zgodność z zależnościami podrzędnymi, takimi jak platforma Azure, dostawcy zasobów i moduły IaC.

Uwagi dotyczące projektowania

• Możliwości technologiczne. Korzystaj z wbudowanych funkcji wdrażania w usługach platformy Azure. Na przykład usługa aplikacja systemu Azure udostępnia dodatkowe miejsca wdrożenia, które można zamienić po wdrożeniu. Za pomocą usługi Azure Kubernetes Service (AKS) można użyć oddzielnego wdrożenia zasobnika w każdym węźle i zaktualizować definicję usługi.

• Czas trwania wdrożenia. Ukończenie wdrożenia może potrwać dłużej, ponieważ sygnatura zawiera infrastrukturę i aplikację, a nie tylko zmieniony składnik. Jest to jednak akceptowalne, ponieważ ryzyko braku pracy wszystkich składników zgodnie z oczekiwaniami zastępuje obawy dotyczące czasu.

• Wpływ na koszty. Istnieje dodatkowy koszt z powodu dwóch wdrożeń równoległych, które muszą współistnieć do momentu ukończenia wdrożenia.

• Przenoszenie ruchu. Po zweryfikowaniu nowego wdrożenia ruch musi zostać przeniesiony ze środowiska niebieskiego do zielonego. To przejście wymaga orkiestracji ruchu użytkownika między środowiskami. Przejście powinno być w pełni zautomatyzowane.

• Cykl życia. Sygnatury wdrożenia o znaczeniu krytycznym należy traktować jako efemeryczny. Użycie sygnatur krótkotrwałych tworzy nowy początek za każdym razem, zanim zasoby zostaną aprowidowane.

Zalecenia dotyczące projektowania

• Przyjęcie podejścia do wdrażania niebieskiego/zielonego w celu wydania wszystkich zmian produkcyjnych. Wdróż całą infrastrukturę i aplikację za każdym razem, dla dowolnego typu zmiany, aby osiągnąć spójny stan i zero przestojów. Mimo że można ponownie używać środowisk, nie zalecamy używania ich w przypadku obciążeń o znaczeniu krytycznym. Traktuj każdą regionalną sygnaturę wdrożenia jako efemeryczny z cyklem życia powiązanym z pojedynczą wersją.

• Użyj globalnego modułu równoważenia obciążenia, takiego jak usługa Azure Front Door, aby zorganizować automatyczne przejście ruchu użytkowników między niebieskimi i zielonymi środowiskami.

• Aby przenieść ruch, dodaj zielony punkt końcowy zaplecza, który używa małego ruchu do wagi woluminu, na przykład 10 procent. Po sprawdzeniu, czy ruch przy zielonym wdrożeniu działa i zapewnia oczekiwaną kondycję aplikacji, stopniowo zwiększa ruch. W ten sposób zastosuj krótki okres ramp-up, aby złapać błędy, które mogą nie być natychmiast widoczne.

  Po przejściu całego ruchu usuń niebieski zaplecze z istniejących połączeń. Na przykład usuń zaplecze z globalnej usługi modułu równoważenia obciążenia, opróżnianie kolejek i odłącz inne skojarzenia. Dzięki temu można zoptymalizować koszt utrzymania pomocniczej infrastruktury produkcyjnej i zapewnić, że nowe środowiska są wolne od dryfu konfiguracji.

  W tym momencie zlikwidowanie starego i teraz nieaktywnego niebieskiego środowiska. W przypadku następnego wdrożenia powtórz proces z niebieskim i zielonym odwróconym.

Wdrożenie w zakresie subskrypcji

W zależności od wymagań dotyczących skalowania aplikacji może być konieczne użycie wielu subskrypcji produkcyjnych, aby służyć jako jednostki skalowania.

Obejrzyj poniższy film wideo, aby zapoznać się z zaleceniami dotyczącymi określania zakresu subskrypcji dla aplikacji o znaczeniu krytycznym.

Uwagi dotyczące projektowania

• Skalowalność. W przypadku scenariuszy aplikacji o dużej skali ze znaczącymi ilościami ruchu należy zaprojektować rozwiązanie do skalowania w wielu subskrypcjach platformy Azure, aby limity skalowania pojedynczej subskrypcji nie ograniczały skalowalności.

  Ważne

  Użycie wielu subskrypcji wymaga dodatkowej złożoności ciągłej integracji/ciągłego wdrażania, która musi być odpowiednio zarządzana. W związku z tym zalecamy używanie wielu subskrypcji tylko w skrajnych scenariuszach skalowania, w których limity pojedynczej subskrypcji mogą stać się ograniczeniem.

• Granice środowiska. Wdrażanie środowisk produkcyjnych, programistycznych i testowych w oddzielnych subskrypcjach. Dzięki temu niższe środowiska nie przyczyniają się do limitów skalowania. Zmniejsza to również ryzyko zanieczyszczenia środowiska produkcyjnego przez zmniejszenie ryzyka aktualizacji środowiska, zapewniając jasne zarządzanie i granicę tożsamości.

• Ład. Jeśli potrzebujesz wielu subskrypcji produkcyjnych, rozważ użycie dedykowanej grupy zarządzania aplikacjami w celu uproszczenia przypisywania zasad za pośrednictwem granicy agregacji zasad.

Zalecenia dotyczące projektowania

• Wdróż każdą regionalną sygnaturę wdrożenia w dedykowanej subskrypcji, aby upewnić się, że limity subskrypcji mają zastosowanie tylko w kontekście pojedynczej sygnatury wdrożenia, a nie całej aplikacji. W razie potrzeby można rozważyć użycie wielu sygnatur wdrożenia w jednym regionie, ale należy wdrożyć je w niezależnych subskrypcjach.

• Umieść globalne zasoby udostępnione w dedykowanej subskrypcji, aby umożliwić spójne wdrożenie subskrypcji regionalnej. Unikaj używania wyspecjalizowanego wdrożenia dla regionu podstawowego.

Ciągła walidacja i testowanie

Testowanie to krytyczne działanie, które pozwala w pełni zweryfikować kondycję kodu i infrastruktury aplikacji. W szczególności testowanie umożliwia spełnienie standardów niezawodności, wydajności, dostępności, zabezpieczeń, jakości i skali. Testowanie musi być dobrze zdefiniowane i stosowane w ramach strategii projektowania aplikacji i metodyki DevOps. Testowanie jest kluczowym problemem podczas lokalnego procesu dewelopera ( pętli wewnętrznej) i w ramach pełnego cyklu życia metodyki DevOps ( pętli zewnętrznej), który jest po uruchomieniu kodu na ścieżce z procesów potoku wydania w kierunku środowiska produkcyjnego.

Zapoznaj się z poniższym filmem wideo, aby zapoznać się z omówieniem ciągłej weryfikacji i testowania.

Ta sekcja koncentruje się na testowaniu pętli zewnętrznej. Opisuje on różne typy testów.

Test	opis
Testowanie jednostek	Potwierdza, że logika biznesowa aplikacji działa zgodnie z oczekiwaniami. Weryfikuje ogólny efekt zmian kodu.
Testowanie weryfikacyjne kompilacji	Określa, czy składniki infrastruktury i aplikacji są dostępne i działają zgodnie z oczekiwaniami. Zazwyczaj testowana jest tylko jedna sesja użytkownika wirtualnego. Wynikiem powinno być to, że system reaguje z oczekiwanymi wartościami i zachowaniem. Typowe scenariusze testowania kompilacji obejmują dotarcie do punktu końcowego HTTPS aplikacji internetowej, wykonywanie zapytań względem bazy danych i symulowanie przepływu użytkownika w aplikacji.
Testowanie interfejsu użytkownika	Sprawdza, czy interfejsy użytkownika aplikacji są wdrażane, a interakcje interfejsu użytkownika działają zgodnie z oczekiwaniami. Aby zwiększyć automatyzację, należy użyć narzędzi automatyzacji interfejsu użytkownika. Podczas testu interfejsu użytkownika skrypt powinien naśladować realistyczny scenariusz użytkownika i wykonać serię kroków w celu wykonania akcji i osiągnięcia zamierzonego wyniku.
Testowanie obciążenia	Weryfikuje skalowalność i operację aplikacji przez szybkie i/lub stopniowe zwiększanie obciążenia do momentu osiągnięcia wstępnie określonego progu. Testy obciążeniowe są zwykle projektowane wokół określonego przepływu użytkownika w celu sprawdzenia, czy wymagania aplikacji są spełnione w ramach zdefiniowanego obciążenia.
Testy obciążeniowe	Stosuje działania, które przeciążą istniejące zasoby, aby określić limity rozwiązań i zweryfikować możliwość bezpiecznego odzyskiwania systemu. Głównym celem jest zidentyfikowanie potencjalnych wąskich gardeł wydajności i limitów skalowania. Z drugiej strony przeprowadź skalowanie w dół zasobów obliczeniowych systemu i monitoruj jego zachowanie pod obciążeniem i ustal, czy może odzyskać.
Testowanie wydajności	Łączy aspekty testowania obciążenia i obciążenia, aby zweryfikować wydajność pod obciążeniem i ustanowić zachowania porównawcze dla operacji aplikacji.
Testowanie chaosu	Wprowadza sztuczne awarie do systemu, aby ocenić, jak reaguje i weryfikuje skuteczność środków odporności, procedur operacyjnych i środków zaradczych. Zamknięcie składników infrastruktury, celowe obniżenie wydajności i wprowadzenie błędów aplikacji to przykłady testów, które mogą służyć do sprawdzania, czy aplikacja będzie reagować zgodnie z oczekiwaniami w przypadku rzeczywistego wystąpienia scenariuszy.
Testy penetracyjne	Gwarantuje, że aplikacja i jej środowisko spełniają wymagania oczekiwanego stanu zabezpieczeń. Celem jest zidentyfikowanie luk w zabezpieczeniach. Testowanie zabezpieczeń może obejmować kompleksowe łańcuchy dostaw oprogramowania i zależności pakietów z skanowaniem i monitorowaniem znanych typowych luk w zabezpieczeniach i ekspozycji (CVE).

Uwagi dotyczące projektowania

• Automatyzacja. Testowanie automatyczne jest niezbędne do weryfikowania zmian aplikacji lub infrastruktury w odpowiednim czasie i powtarzalnym.

• Kolejność testowania. Kolejność przeprowadzania testów jest krytyczną kwestią ze względu na różne zależności, takie jak potrzeba uruchomienia środowiska aplikacji. Czas trwania testu wpływa również na kolejność. Testy z krótszym czasem wykonywania powinny być uruchamiane wcześniej w cyklu, gdy jest to możliwe, aby zwiększyć wydajność testowania.

• Limity skalowalności. Usługi platformy Azure mają różne miękkie i twarde limity. Rozważ użycie testowania obciążenia, aby określić, czy ryzyko związane z systemem przekracza je podczas oczekiwanego obciążenia produkcyjnego. Testowanie obciążenia może być również przydatne do ustawiania odpowiednich progów skalowania automatycznego. W przypadku usług, które nie obsługują skalowania automatycznego, testowanie obciążenia może pomóc w dostosowaniu zautomatyzowanych procedur operacyjnych.

  Brak możliwości składników systemu, takich jak aktywne/pasywne składniki sieci lub bazy danych, do odpowiedniego skalowania może być restrykcyjny. Testy stresu mogą pomóc w zidentyfikowaniu ograniczeń.

• Analiza trybu awarii. Wprowadzenie błędów do aplikacji i podstawowej infrastruktury oraz ocena efektu jest niezbędne do oceny mechanizmów nadmiarowości rozwiązania. Podczas tej analizy zidentyfikuj ryzyko, wpływ i zakres wpływu (częściową lub pełną awarię). Aby zapoznać się z przykładową analizą utworzoną na potrzeby implementacji referencyjnej usługi Mission Critical Online , zobacz Czynniki ryzyka awarii poszczególnych składników.

• Monitorowanie. Należy przechwytywać i analizować wyniki testów indywidualnie, a także agregować je w celu oceny trendów w czasie. Należy stale oceniać wyniki testów pod kątem dokładności i pokrycia.

Zalecenia dotyczące projektowania

Obejrzyj poniższy film wideo, aby zobaczyć, jak można zintegrować testowanie odporności z potokami ciągłej integracji/ciągłego wdrażania usługi Azure DevOps.

• Zapewnij spójność, automatyzując wszystkie testy dotyczące składników infrastruktury i aplikacji. Integruj testy w potokach ciągłej integracji/ciągłego wdrażania, aby organizować i uruchamiać je tam, gdzie ma to zastosowanie. Aby uzyskać informacje o opcjach technologii, zobacz Narzędzia DevOps.

• Traktuj wszystkie artefakty testowe jako kod. Powinny one być utrzymywane i kontrolowane wersje wraz z innymi artefaktami kodu aplikacji.

• Dopasuj umowę SLA infrastruktury testowej do umowy SLA na potrzeby cykli wdrażania i testowania.

• Uruchom testy weryfikacyjne kompilacji w ramach każdego wdrożenia. Uruchamiaj również obszerne testy obciążeniowe wraz z testami obciążenia i chaosem, aby sprawdzić, czy wydajność i obsługa aplikacji są utrzymywane.

  • Użyj profilów obciążenia, które odzwierciedlają rzeczywiste wzorce szczytowego użycia.
  • Uruchamiaj eksperymenty chaosu i testy iniekcji błędów w tym samym czasie co testy obciążeniowe.

  Napiwek

  Azure Chaos Studio to natywny zestaw narzędzi do eksperymentowania w chaosie. Narzędzia ułatwiają przeprowadzanie eksperymentów chaosu i wprowadzanie błędów w usługach i składnikach aplikacji platformy Azure.

  Usługa Chaos Studio udostępnia wbudowane eksperymenty chaosu dla typowych scenariuszy błędów i obsługuje eksperymenty niestandardowe przeznaczone dla infrastruktury i składników aplikacji.

• Jeśli interakcje z bazą danych, takie jak tworzenie rekordów, są wymagane w przypadku testów obciążeniowych lub weryfikacyjnych, należy użyć kont testowych, które mają ograniczone uprawnienia i udostępnić dane testowe z zawartości rzeczywistej użytkownika.

• Skanuj i monitoruj całościowy łańcuch dostaw oprogramowania i zależności pakietów dla znanych CVE.

  • Użyj narzędzia Dependabot dla repozytoriów GitHub, aby upewnić się, że repozytorium jest automatycznie aktualne wraz z najnowszymi wersjami pakietów i aplikacji, od których zależy.

Infrastruktura jako wdrożenia kodu

Infrastruktura jako kod (IaC) traktuje definicje infrastruktury jako kod źródłowy kontrolowany wraz z innymi artefaktami aplikacji. Użycie IaC promuje spójność kodu w środowiskach, eliminuje ryzyko błędu ludzkiego podczas zautomatyzowanych wdrożeń i zapewnia możliwość śledzenia i wycofywania. W przypadku wdrożeń niebieski/zielony konieczne jest użycie rozwiązania IaC z w pełni zautomatyzowanymi wdrożeniami.

Repozytorium IaC o znaczeniu krytycznym ma dwie odrębne definicje mapowane na zasoby globalne i regionalne. Aby uzyskać informacje o tych typach zasobów, zobacz wzorzec architektury podstawowej.

Uwagi dotyczące projektowania

• Powtarzalna infrastruktura. Wdróż obciążenia o znaczeniu krytycznym w sposób, który za każdym razem generuje to samo środowisko. IaC powinna być podstawowym modelem.

• Automatyzacja. Wszystkie wdrożenia muszą być w pełni zautomatyzowane. Procesy ludzkie są podatne na błędy.

Zalecenia dotyczące projektowania

• Zastosuj IaC, upewniając się, że wszystkie zasoby platformy Azure są zdefiniowane w szablonach deklaratywnych i przechowywane w repozytorium kontroli źródła. Szablony są wdrażane, a zasoby są aprowizowane automatycznie z kontroli źródła za pośrednictwem potoków ciągłej integracji/ciągłego wdrażania. Nie zalecamy używania skryptów imperatywnych.

• Uniemożliwianie ręcznego wykonywania operacji we wszystkich środowiskach. Jedynym wyjątkiem są w pełni niezależne środowiska deweloperskie.

Narzędzia DevOps

Efektywne korzystanie z narzędzi wdrażania ma kluczowe znaczenie dla ogólnej niezawodności, ponieważ procesy DevOps wpływają na ogólną funkcję i projekt aplikacji. Na przykład operacje trybu failover i skalowania mogą zależeć od automatyzacji udostępnianej przez narzędzia DevOps. Zespoły inżynieryjne muszą zrozumieć wpływ niedostępności usługi wdrażania w odniesieniu do ogólnego obciążenia. Narzędzia wdrażania muszą być niezawodne i wysoce dostępne.

Firma Microsoft udostępnia dwa natywne zestawy narzędzi platformy Azure: GitHub Actions i Azure Pipelines, które mogą skutecznie wdrażać aplikację o znaczeniu krytycznym i zarządzać nią.

Uwagi dotyczące projektowania

• Możliwości technologiczne. Możliwości usług GitHub i Azure DevOps nakładają się na siebie. Możesz ich używać razem, aby uzyskać najlepsze z obu tych elementów. Typowym podejściem jest przechowywanie repozytoriów kodu w usłudze GitHub.com lub GitHub AE podczas wdrażania przy użyciu usługi Azure Pipelines.

  Należy pamiętać o złożoności dodanej podczas korzystania z wielu technologii. Ocena rozbudowanego zestawu funkcji pod kątem ogólnej niezawodności.

• Dostępność regionalna. Jeśli chodzi o maksymalną niezawodność, zależność od pojedynczego regionu świadczenia usługi Azure reprezentuje ryzyko operacyjne.

  Załóżmy na przykład, że ruch jest rozłożony na dwa regiony: Region 1 i Region 2. Region 2 hostuje wystąpienie narzędzi usługi Azure DevOps. Załóżmy, że wystąpiła awaria w regionie 2, a wystąpienie nie jest dostępne. Region 1 automatycznie obsługuje cały ruch i musi wdrożyć dodatkowe jednostki skalowania, aby zapewnić dobre środowisko pracy w trybie failover. Nie będzie jednak możliwe ze względu na zależność usługi Azure DevOps w regionie 2.

• Replikacja danych. Dane, w tym metadane, potoki i kod źródłowy, powinny być replikowane w różnych regionach.

Zalecenia dotyczące projektowania

• Obie technologie są hostowane w jednym regionie świadczenia usługi Azure, co może sprawić, że strategia odzyskiwania po awarii będzie restrykcyjna.

  Funkcja GitHub Actions jest dobrze odpowiednia dla zadań kompilacji (ciągłej integracji), ale może brakować funkcji złożonych zadań wdrażania (ciągłe wdrażanie). Biorąc pod uwagę bogaty zestaw funkcji usługi Azure DevOps, zalecamy jej wdrożenie o znaczeniu krytycznym. Należy jednak dokonać wyboru po ocenie kompromisów.

• Definiowanie umowy SLA dotyczącej dostępności na potrzeby narzędzi wdrażania i zapewnienie zgodności z szerszymi wymaganiami dotyczącymi niezawodności aplikacji.

• W przypadku scenariuszy obejmujących wiele regionów, które korzystają z konfiguracji wdrożenia aktywnego/pasywnego lub aktywnego/aktywnego, upewnij się, że aranżacja trybu failover i operacje skalowania mogą nadal działać, nawet jeśli podstawowy region hostujący zestawy narzędzi wdrażania staną się niedostępne.

Strategia rozgałęzień

Istnieje wiele prawidłowych metod rozgałęziania. Należy wybrać strategię zapewniającą maksymalną niezawodność. Dobra strategia umożliwia programowanie równoległe, zapewnia wyraźną ścieżkę od programowania do środowiska produkcyjnego i obsługuje szybkie wersje.

Uwagi dotyczące projektowania

• Zminimalizuj dostęp. Deweloperzy powinni wykonywać swoją pracę w gałęziach feature/* i fix/* . Te gałęzie stają się punktami wejścia dla zmian. Ograniczenia oparte na rolach powinny być stosowane do gałęzi w ramach strategii rozgałęziania. Na przykład zezwalaj administratorom na tworzenie gałęzi wydania lub wymuszanie konwencji nazewnictwa dla gałęzi.

• Przyspieszony proces w nagłych wypadkach. Strategia rozgałęziania powinna umożliwiać scalanie main poprawek tak szybko, jak tylko w praktyce. Dzięki temu przyszłe wersje zawierają poprawkę i uniknąć cyklu problemu. Ten proces należy używać tylko w przypadku drobnych zmian, które dotyczą pilnych problemów i używać ich z powściągliwością.

Zalecenia dotyczące projektowania

• Określanie priorytetów użycia usługi GitHub na potrzeby kontroli źródła.

  Ważne

  Utwórz strategię rozgałęziania, która zawiera szczegóły dotyczące funkcji i wydań co najmniej, oraz użyj zasad i uprawnień gałęzi, aby upewnić się, że strategia jest odpowiednio wymuszana.

• Wyzwól zautomatyzowany proces testowania, aby zweryfikować zmiany kodu przed ich zaakceptowaniem. Członkowie zespołu muszą również przejrzeć zmiany.

• main Traktuj gałąź jako stale przenoszoną i stabilną gałąź, która jest używana głównie do testowania integracji.

  • Upewnij się, że zmiany są wprowadzane main tylko za pośrednictwem żądania ściągnięcia. Użyj zasad gałęzi, aby zakazać bezpośrednich zatwierdzeń.
  • Za każdym razem, gdy żądanie ściągnięcia jest scalane z mainusługą , powinno automatycznie uruchamiać wdrożenie w środowisku integracji.
  • Gałąź main powinna być uważana za stabilną. Należy bezpiecznie utworzyć wydanie w main dowolnym momencie.

• Użyj dedykowanych release/* gałęzi utworzonych na podstawie main gałęzi i używanych do wdrażania w środowiskach produkcyjnych. release/* gałęzie powinny pozostać w repozytorium i mogą służyć do stosowania poprawek wydania.

• Dokumentowanie procesu poprawek i używanie go tylko w razie potrzeby. Utwórz poprawki w fix/* gałęzi w celu późniejszego scalenia z gałęzią wydania i wdrożeniem w środowisku produkcyjnym.

Sztuczna inteligencja dla metodyki DevOps

Metodologie AIOps można stosować w potokach ciągłej integracji/ciągłego wdrażania, aby uzupełnić tradycyjne podejścia do testowania. Dzięki temu można wykryć potencjalne regresje lub degradacje i umożliwia zatrzymanie wdrożeń, aby zapobiec potencjalnym negatywnym wpływom.

Uwagi dotyczące projektowania

• Ilość danych telemetrycznych. Potoki ciągłej integracji/ciągłego wdrażania i procesy DevOps emitują szeroką gamę danych telemetrycznych dla modeli uczenia maszynowego. Dane telemetryczne wahają się od wyników testów i wyników wdrażania do danych operacyjnych dotyczących składników testowych z złożonych etapów wdrażania.

• Skalowalność. Tradycyjne metody przetwarzania danych, takie jak wyodrębnianie, przekształcanie, ładowanie (ETL) może nie być w stanie skalować przepływności, aby nadążyć za wzrostem danych telemetrycznych wdrożenia i danych z obserwacji aplikacji. Możesz użyć nowoczesnych podejść analitycznych, które nie wymagają etL i przenoszenia danych, takich jak wirtualizacja danych, aby umożliwić ciągłą analizę modeli AIOps.

• Zmiany wdrożenia. Zmiany we wdrożeniu muszą być przechowywane w celu zautomatyzowanej analizy i korelacji wyników wdrożenia.

Zalecenia dotyczące projektowania

• Zdefiniuj dane procesu DevOps w celu zebrania i sposobu ich analizowania. Dane telemetryczne, takie jak metryki wykonywania testów i dane szeregów czasowych zmian w każdym wdrożeniu, są ważne.

  • Uwidacznianie danych dotyczących obserwacji aplikacji z środowisk przejściowych, testowych i produkcyjnych na potrzeby analizy i korelacji w modelach AIOps.

• Wdrażanie przepływu pracy metodyki MLOps.

• Opracowywanie modeli analitycznych obsługujących kontekst i świadomość zależności w celu zapewnienia przewidywań za pomocą zautomatyzowanej inżynierii cech w celu rozwiązania zmian schematu i zachowania.

• Operacjonalizacja modeli przez rejestrowanie i wdrażanie najlepiej wytrenowanych modeli w potokach wdrażania.

Następny krok

Zapoznaj się z zagadnieniami dotyczącymi zabezpieczeń.

Bezpieczeństwo