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 kluczowym znaczeniu.

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 wdrażanie 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 służyć 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ń o znaczeniu krytycznym dla platformy Azure Well-Architected Framework . Jeśli nie znasz tej serii, zalecamy rozpoczęcie od tematu Co to jest obciążenie o znaczeniu krytycznym?.

Wdrożenie 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 dla aplikacji o znaczeniu krytycznym. 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 to, czy traktować zasoby jako efemeryczny.

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

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

Środowiska aplikacji

Obejrzyj poniższy film 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 tworzenia 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 w możliwie największym stopniu, chociaż w razie potrzeby można zastosować uproszczenia do niższych środowisk. Ten diagram przedstawia 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 deweloperskie

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

Zagadnienia 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 potrzebami i istnieć przez krótki czas. Krótsze cykle życia pomagają zapobiec dryfowaniu konfiguracji z bazy kodu i obniżeniu kosztów. Ponadto środowiska programistyczne 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 wdrożenia bez usterek w środowisku produkcyjnym. Odpowiednie testy dla obciążenia o znaczeniu krytycznym zostały opisane w sekcji Ciągła walidacja i testowanie .

Zagadnienia 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 w ramach 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 trzeba będzie to zrobić. 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 wprowadzone 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 na podstawie wykonywania działań testowych.

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

  Uwaga

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

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

Środowiska produkcyjne

Zagadnienia dotyczące projektowania

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

• Cykl życia. Chociaż 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 środowisk produkcyjnych i niższych. 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 wpływa na przydziały produkcyjne. Dedykowane subskrypcje ustawiają również granice dostępu.

Wdrożenia efemeryczne 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, zielone wdrożenie 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 z nowym wdrożeniem, 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 wdrożenie 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 do niego ruchu użytkowników. 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.

Zagadnienia dotyczące projektowania

• Możliwości technologiczne. Korzystaj z wbudowanych funkcji wdrażania w usługach platformy Azure. Na przykład Azure App Service udostępnia pomocnicze miejsca wdrożenia, które można zamienić po wdrożeniu. Za pomocą 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 dopuszczalne, ponieważ ryzyko, że wszystkie składniki nie działają zgodnie z oczekiwaniami, przesłaniają obawy dotyczące czasu.

• Wpływ na koszty. Istnieje dodatkowy koszt ze względu na dwa wdrożenia równoległe, które muszą współistnieć, dopóki wdrożenie nie zostanie ukończone.

• Przejście ruchu. Po zweryfikowaniu nowego wdrożenia ruch musi zostać przeniesiony z niebieskiego środowiska do zielonego. To przejście wymaga orkiestracji ruchu użytkowników 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ótkoterminowych tworzy nowy początek za każdym razem, zanim zasoby zostaną aprowidowane.

Zalecenia dotyczące projektowania

• Zastosuj podejście do wdrażania niebieskiego/zielonego, aby zwolnić wszystkie zmiany produkcyjne. Wdróż całą infrastrukturę i aplikację za każdym razem, dla dowolnego typu zmiany, aby osiągnąć spójny stan i zerowy przestój. Chociaż 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 pojedynczym wydaniem.

• Użyj globalnego modułu równoważenia obciążenia, takiego jak usługa Azure Front Door, do organizowania automatycznego przenoszenia 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ększaj ruch. W ten sposób należy zastosować krótki okres ramp-up, aby złapać błędy, które mogą nie być od razu widoczne.

  Po przeniesieniu całego ruchu usuń niebieski zaplecze z istniejących połączeń. Na przykład usuń zaplecze z globalnej usługi równoważenia obciążenia, kolejki opróżniania 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.

Zapoznaj się z poniższym filmem wideo, aby zapoznać się z omówieniem zaleceń dotyczących określania zakresu subskrypcji dla aplikacji o znaczeniu krytycznym.

Zagadnienia dotyczące projektowania

• Skalowalność. W przypadku scenariuszy aplikacji o dużej skali ze znacznymi ilościami ruchu zaprojektuj 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óre muszą być odpowiednio zarządzane. 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 aktualizacje o niższym środowisku dzięki zapewnieniu jasnej granicy zarządzania i 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ą sygnaturę wdrożenia regionalnego 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 je wdrożyć w niezależnych subskrypcjach.

• Umieść globalne zasoby udostępnione w dedykowanej subskrypcji, aby umożliwić spójne wdrażanie 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 aplikacji i infrastruktury. W szczególności testowanie pozwala spełnić standardy dotyczące 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 kompletnego cyklu życia metodyki DevOps ( pętli zewnętrznej), który występuje, gdy kod rozpoczyna się na ścieżce od procesów potoku wydania w kierunku środowiska produkcyjnego.

Obejrzyj poniższy film wideo, aby zapoznać się z omówieniem ciągłej weryfikacji i testowania.

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

Testowanie	Opis
Testowanie jednostek	Potwierdza, że logika biznesowa aplikacji działa zgodnie z oczekiwaniami. Weryfikuje ogólny efekt zmian w kodzie.
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 weryfikacyjnego 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ążeniowe	Weryfikuje skalowalność i operację aplikacji, szybko zwiększając obciążenie i/lub stopniowo aż do 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 warunków skrajnych	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 skaluj w dół zasoby obliczeniowe systemu i monitoruj jego zachowanie pod obciążeniem i określ, czy można go odzyskać.
Testowanie wydajności	Łączy aspekty testów obciążenia i testów warunków skrajnych, aby zweryfikować wydajność pod obciążeniem i ustanowić zachowania testów porównawczych dla operacji aplikacji.
Testowanie chaosu	Wprowadza sztuczne awarie do systemu, aby ocenić, w jaki sposób reaguje i weryfikować skuteczność miar odporności, procedur operacyjnych i środków zaradczych. Zamykanie składników infrastruktury, obniżanie wydajności i wprowadzanie błędów aplikacji to przykłady testów, których można użyć do sprawdzenia, 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ńcuch dostaw oprogramowania i zależności pakietów oraz skanowanie i monitorowanie znanych typowych luk w zabezpieczeniach i ekspozycji (CVE).

Zagadnienia 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 system może je przekroczyć 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 systemowych, takich jak składniki sieci aktywne/pasywne lub bazy danych, do odpowiedniego skalowania może być restrykcyjny. Testowanie warunków skrajnych może pomóc w zidentyfikowaniu ograniczeń.

• Analiza trybu awarii. Wprowadzenie błędów do aplikacji i podstawowej infrastruktury oraz ocena efektu jest niezbędna 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 Ryzyko awarii poszczególnych składników.

• Monitorowanie. Wyniki testów należy przechwytywać i analizować 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 DevOps tools (Narzędzia DevOps).

• Traktuj wszystkie artefakty testowe jako kod. Należy je utrzymywać i kontrolować wersję 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ż rozbudowane testy obciążeniowe wraz z testami obciążenia i chaosem, aby sprawdzić, czy wydajność i funkcjonalność 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.

  Porada

  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 platformy Azure i składnikach aplikacji.

  Program 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 bazy danych, takie jak tworzenie rekordów, są wymagane do testów obciążeniowych lub weryfikacyjnych kompilacji, należy użyć kont testowych, które mają ograniczone uprawnienia i udostępnić dane testowe z rzeczywistej zawartości 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 przez wersję wraz z innymi artefaktami aplikacji. Użycie technologii IaC promuje spójność kodu w środowiskach, eliminuje ryzyko błędu ludzkiego podczas zautomatyzowanych wdrożeń oraz zapewnia możliwość śledzenia i wycofywania. W przypadku wdrożeń niebieskich/zielonych użycie uczenia maszynowego z w pełni zautomatyzowanymi wdrożeniami jest konieczne.

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.

Zagadnienia dotyczące projektowania

• Powtarzalna infrastruktura. Wdrażanie obciążeń 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ą automatycznie aprowidowane 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żliwiaj ręczne wykonywanie operacji we wszystkich środowiskach. Jedynym wyjątkiem są w pełni niezależne środowiska deweloperskie.

Narzędzia DevOps

Skuteczne 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ą.

Zagadnienia dotyczące projektowania

• Możliwości technologiczne. Możliwości usług GitHub i Azure DevOps nakładają się na siebie. Można ich używać razem, aby uzyskać najlepsze z obu. 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, która jest dodawana w przypadku korzystania z wielu technologii. Ocena zaawansowanego zestawu funkcji pod kątem ogólnej niezawodności.

• Dostępność regionalna. Jeśli chodzi o maksymalną niezawodność, zależność od jednego regionu platformy 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 jest niedostę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 między regionami.

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.

  GitHub Actions dobrze nadaje się do 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 użycie go w przypadku wdrożeń o znaczeniu krytycznym. Należy jednak dokonać wyboru po ocenie kompromisów.

• Zdefiniuj umowę SLA dotyczącą dostępności dla narzędzi wdrażania i zapewnij zgodność z szerszymi wymaganiami dotyczącymi niezawodności aplikacji.

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

Strategia rozgałęziania

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.

Zagadnienia 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 wydań lub wymuszanie konwencji nazewnictwa dla gałęzi.

• Przyspieszony proces w nagłych wypadkach. Strategia rozgałęziania powinna umożliwiać scalanie poprawek z głównymi , gdy tylko będzie to praktyczne. 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żywają 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 będzie zawierać szczegóły dotyczące funkcji i wydań jako minimum, 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.

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

  • Upewnij się, że zmiany są wprowadzane tylko do głównych za pośrednictwem żądania ściągnięcia. Użyj zasad gałęzi, aby zabronić bezpośrednich zatwierdzeń.
  • Za każdym razem, gdy żądanie ściągnięcia jest scalane z głównym, powinno automatycznie rozpoczynać wdrażanie w środowisku integracji.
  • Gałąź główna powinna być uważana za stabilną. Należy bezpiecznie utworzyć wydanie na podstawie głównej wersji w danym momencie.

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

• Udotwórz proces poprawek i używaj go tylko wtedy, gdy jest to konieczne. Utwórz poprawki w gałęzi fix/* w celu późniejszego scalenia z gałęzią wydania i wdrożeniem w środowisku produkcyjnym.

Sztuczna inteligencja dla metodyki DevOps

Metodologie AIOps można zastosować 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 pozwala na wcześniejsze zatrzymanie wdrożeń, aby zapobiec potencjalnym negatywnym wpływom.

Zagadnienia 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 po dane operacyjne dotyczące 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, Extract, Transform, Load) mogą nie być w stanie skalować przepływności, aby nadążyć za rozwojem danych telemetrycznych wdrożenia i danych z obserwacją aplikacji. Możesz użyć nowoczesnych metod 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 automatycznej analizy i korelacji z wynikami wdrożenia.

Zalecenia dotyczące projektowania

• Zdefiniuj dane procesu DevOps, aby zbierać i jak je analizować. 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 zależność w celu zapewnienia przewidywań za pomocą zautomatyzowanej inżynierii cech w celu rozwiązania zmian schematu i zachowania.

• Operacjonalizowanie modeli przez zarejestrowanie i wdrożenie najlepiej wytrenowanych modeli w potokach wdrażania.

Następny krok

Zapoznaj się z zagadnieniami dotyczącymi zabezpieczeń.

Bezpieczeństwo