Udostępnij za pośrednictwem

Zalecenia dotyczące projektowania łańcucha dostaw dla obciążeń

  • Artykuł

Dotyczy tego zalecenia z listy kontrolnej dotyczącej doskonałości operacyjnej platformy Azure Well-Architected Framework:

OE:06 Utwórz łańcuch dostaw obciążenia, który napędza proponowane zmiany za pośrednictwem przewidywalnych, zautomatyzowanych potoków. Potoki testują i promują te zmiany w środowiskach. Zoptymalizuj łańcuch dostaw, aby zapewnić niezawodne, bezpieczne, ekonomiczne i wydajne obciążenie.

W tym przewodniku opisano zalecenia dotyczące projektowania łańcucha dostaw obciążeń opartego na potokach ciągłej integracji i ciągłego dostarczania (CI/CD). Opracuj łańcuch dostaw, aby zapewnić przewidywalną, ustandaryzowaną metodę utrzymania obciążenia. Potoki ciągłej integracji/ciągłego wdrażania są przejawem łańcucha dostaw, ale należy mieć jeden łańcuch dostaw. Ponadto może istnieć kilka potoków, które są zgodne z tymi samymi procesami i korzystać z tych samych narzędzi.

Uwzględnij łańcuch dostaw, aby chronić obciążenie przed uszkodzeniem, które mogą wystąpić, gdy nie będziesz prawidłowo zarządzać zmianami obciążenia. Zawsze należy pamiętać o stanie obciążenia, więc nie masz ryzyka wystąpienia nieprzewidywalnego zachowania. To ryzyko składa się, jeśli musisz poświęcić krytyczny czas na odzyskanie nierozliczonej zmiany w przypadku wystąpienia problemów. Aby zminimalizować te zagrożenia, zasyfikuj procesy i narzędzia, które definiują łańcuch dostaw, i upewnij się, że zespół ds. obciążeń w pełni zobowiązuje się do ich użycia.

Definicja

Termin Definicja
Łańcuch dostaw W przypadku obciążeń w chmurze łańcuch dostaw to ustandaryzowany zestaw narzędzi i procesów, których używasz do wpływania na infrastrukturę i zmianę aplikacji w środowiskach.

Kluczowe strategie projektowania

Uwaga

Zalecenia w tym przewodniku dotyczą środowisk obciążeń w łańcuchu podwyższania poziomu kodu. Piaskownica lub inne środowiska eksploracyjne i sprawdzające koncepcje wymagają mniej rygoru i struktury.

Poniższe zalecenia mogą pomóc w zdefiniowaniu podstawowych zestawów łańcucha dostaw.

Wymuszanie rygorystycznych zasad wdrożeń opartych na szablonach

Wprowadź proponowane zmiany obciążenia za pomocą procesów i narzędzi łańcucha dostaw. Wymuszanie rygorystycznych zasad zautomatyzowanych wdrożeń opartych na szablonach. Ta metoda pomaga zapewnić, że konfiguracja obciążenia we wszystkich środowiskach jest ustandaryzowana, dobrze zdefiniowana i ściśle kontrolowana. W przypadku środowisk w łańcuchu podwyższania poziomu kodu nie wykonuj aktualizacji przy użyciu procesów ręcznych ani interakcji człowieka z płaszczyzną sterowania platformy w chmurze, na przykład portalem lub interfejsem API. Uwzględnij wszystkie zmiany w środowisku za pośrednictwem potoku, postępując zgodnie z zdefiniowanymi praktykami wdrażania. Aby ułatwić wymuszanie tych zasad, należy rozważyć ograniczenie dostępu tylko do odczytu jako domyślne i użycie bramy autoryzacji dostępu w celu umożliwienia dostępu do zapisu.

Ważnym aspektem tego zestawu jest to, że wszystkie zmiany są proponowane do momentu ich wdrożenia w środowisku produkcyjnym. Dzięki zautomatyzowanym testom, na przykład integracji i testowaniu weryfikacyjnego kompilacji, możesz zezwolić łańcuchowi dostaw na automatyczne odrzucanie zmian.

Wdrażanie powtarzalnej i niezmiennej infrastruktury jako kodu

Wdrażanie powtarzalnej i niezmiennej infrastruktury jako kodu (IaC). IaC to zarządzanie infrastrukturą w modelu opisowym, który używa systemu przechowywania wersji, który dubluje kod źródłowy. Podczas tworzenia aplikacji ten sam kod źródłowy powinien generować ten sam plik binarny za każdym razem, gdy jest kompilowany. W podobny sposób model IaC generuje to samo środowisko przy każdym zastosowaniu.

Uwzględnij IaC, aby upewnić się, że twój zespół jest zgodny ze standardowym, dobrze ugruntowanym procesem. Niektóre organizacje wyznaczają pojedynczą lub małą grupę osób do wdrażania i konfigurowania infrastruktury. Podczas implementowania w pełni zautomatyzowanego procesu wdrożenia infrastruktury wymagają mniejszego zarządzania od użytkowników indywidualnych. Odpowiedzialność jest przekazywana do procesu automatyzacji i narzędzi. Członkowie zespołu mogą inicjować wdrożenia infrastruktury w celu zachowania spójności i jakości.

Zaprojektuj obciążenie jako logiczną grupę składników, które można połączyć w jeden szablon, aby wdrożenia mogły być łatwe i powtarzalne. Te pakiety można traktować jako sygnatury lub jednostki skali. Aby uzyskać więcej informacji, zobacz Wzorzec sygnatur wdrożenia. Jeśli musisz wdrożyć obciążenie w celu skalowania w poziomie do innego regionu lub strefy w tym samym regionie, wdróż sygnaturę przy użyciu potoku. W zależności od sposobu projektowania sygnatur można wdrożyć podzestaw obciążenia zamiast całego obciążenia. Uwzględnij składniki sieciowe w potokach IaC, aby upewnić się, że sygnatury wdrażania będą automatycznie łączyć się z istniejącymi zasobami.

Aby zoptymalizować potok IaC pod kątem spójności i wydajności, zaprojektuj niezmienną infrastrukturę zamiast modyfikowalnej infrastruktury. Zaimplementuj niezmienną infrastrukturę, aby upewnić się, że wszystkie systemy w zakresie są zastępowane zaktualizowaną konfiguracją jednocześnie i identycznie z każdym wdrożeniem.

Użyj tego samego zestawu artefaktów wdrażania we wszystkich środowiskach

Użyj jednego zestawu zasobów kodu i artefaktów we wszystkich środowiskach i potokach. Typowym punktem bólu dla organizacji jest to, że środowiska nieprodukcyjne różnią się od środowisk produkcyjnych. Ręczne tworzenie środowisk produkcyjnych i nieprodukcyjnych może spowodować niezgodność konfiguracji między środowiskami. Ta niezgodność spowalnia testowanie i zwiększa prawdopodobieństwo, że zmiany mogą zaszkodzić systemowi produkcyjnemu. Podejście IaC minimalizuje te problemy. W przypadku korzystania z automatyzacji IaC można użyć tych samych plików konfiguracji infrastruktury dla wszystkich środowisk do tworzenia niemal identycznych środowisk. Parametry można dodawać do plików konfiguracji infrastruktury i dostosowywać je, aby spełniały wymagania poszczególnych środowisk.

W celu kontrolowania kosztów zwykle występuje wariancja między środowiskami produkcyjnymi i nieprodukcyjnymi. Często nie potrzebujesz tego samego stopnia nadmiarowości i wydajności w środowiskach nieprodukcyjnych, co w środowisku produkcyjnym. Liczba i jednostka SKU zasobów mogą się różnić między środowiskami. Upewnij się, że kontrolujesz i rozumiesz wariancję przy użyciu ustandaryzowanych parametrów, aby ułatwić zachowanie przewidywalności podczas wprowadzania zmian.

Odzwierciedlanie struktury organizacyjnej w łańcuchu dostaw

Odzwierciedlić strukturę organizacyjną w projektach łańcucha dostaw i potoków. Twoja organizacja może być silosowana wśród zespołów. Każdy zespół może zarządzać częścią łańcucha dostaw. Na przykład wiele organizacji ma zespoły, które zarządzają domenami infrastruktury, takimi jak sieci, dane i zasoby obliczeniowe. Te zespoły są oddzielone od zespołów programistycznych, które zarządzają programowaniem aplikacji, testowaniem i wdrożeniami. W niektórych organizacjach zespoły programistyczne i zespoły infrastruktury są dołączane do zespołów DevOps, które wspólnie zarządzają wszystkimi wdrożeniami infrastruktury i aplikacji. Istnieje wiele sposobów organizowania zespołów zaangażowanych w łańcuch dostaw. Łańcuch dostaw opiera się na wszystkich zespołach, które bezproblemowo współpracują ze sobą. Upewnij się, że wszystkie zespoły przestrzegają standardowych procesów i używają standardowych narzędzi w celu zapewnienia jak największej wydajności łańcucha dostaw.

Łańcuch dostaw może polegać na dostawcach innych firm, jeśli udostępniasz części cyklu życia obciążenia. Ci dostawcy mają tak samo kluczowe znaczenie dla sukcesu łańcucha dostaw, jak zasoby wewnętrzne. Upewnij się, że istnieje wzajemne porozumienie we wszystkich zespołach dotyczących używanych procesów i narzędzi.

Wybieranie właściwej metody wdrażania

Standaryzacja metody wdrażania. Porozmawiaj z właścicielem produktu o akceptowalnej liczbie przestojów produkcyjnych dla obciążenia. W zależności od tego, ile, jeśli istnieje, przestój jest akceptowalny, możesz wybrać metodę wdrażania odpowiednią dla wymagań. W idealnym przypadku należy wykonać wdrożenia w oknie obsługi, aby zmniejszyć złożoność i ryzyko. Jeśli przestój nie jest akceptowalny, zastosuj metodę wdrażania niebiesko-zieloną.

Użyj progresywnego podejścia do ekspozycji, aby zmniejszyć ryzyko wprowadzenia niewykrytych usterek do klientów. Znana również jako wdrożenia kanary, ta metoda jest wdrażana w kontrolowanych grupach użytkowników w sekwencji stopniowej. Przechwytuje problemy, zanim wpłyną one na więcej użytkowników. Początkowa grupa wdrażania może być podsekcją klientów, którzy wiedzą o strategii wdrażania. Ta podsekcja klientów może tolerować pewne nieoczekiwane zachowanie i przekazywać opinie. Może to być grupa użytkowników wewnętrznych, która pomaga zawierać promień błędów podczas wprowadzania.

Podczas definiowania metody wdrażania należy przyjąć standardowe zasady wdrażania tylko najmniejszej możliwej zmiany w każdym wdrożeniu. W zależności od czynników, takich jak krytyczne znaczenie obciążenia i złożoności składników, należy określić najmniejszą realną zmianę. Jeśli używasz niezmiennej infrastruktury, najmniejszą realną zmianą jest zwykle wdrożenie zasobów z najnowszą konfiguracją w celu zastąpienia zasobów z uruchomioną poprzednią wersją. Jeśli używasz infrastruktury modyfikowalnej, możesz zdecydować, że najmniejsza realna zmiana to tylko jedna aktualizacja grupy zasobów w zakresie.

Postępuj zgodnie z podejściem warstwowym

Postępuj zgodnie z podejściem warstwowym, aby odzwierciedlić różne cykle życia. Warstwy podstawowe powinny pozostać statyczne w większości cyklu życia obciążenia, a warstwy aplikacji często się zmieniają. Aby uwzględnić te różnice, należy mieć różne potoki, aby wprowadzić zmiany w każdej warstwie.

Strefa docelowa znajduje się w najniższej warstwie. Strefa docelowa to logiczne grupowanie podstawowych elementów, takich jak subskrypcje, grupy zarządzania, grupy zasobów, funkcje ładu i topologia sieci. Strefa docelowa umożliwia łatwe wdrażanie obciążenia i zarządzanie nim oraz zapewnia centralne zespoły operacyjne lub zespoły platform z powtarzalnym podejściem do konfiguracji środowiska. Aby zapewnić spójne środowiska, wszystkie strefy docelowe platformy Azure zapewniają zestaw typowych obszarów projektowych, architekturę referencyjną, implementację referencyjną i proces modyfikowania wdrożenia zgodnie z wymaganiami projektowymi. Zasady projektowania strefy docelowej platformy Azure zawierają zalecane rozwiązania na podstawie ładu opartego na zasadach wraz z demokratyzacją subskrypcji. Strefa docelowa powinna wymagać minimalnych zmian w trakcie cyklu życia obciążenia. Aby zobaczyć przykład strefy docelowej, zobacz Co to jest strefa docelowa platformy Azure. Ta architektura koncepcyjna zawiera zestaw opinii zalecanych dla platformy Azure.

Podstawowa infrastruktura i funkcje, takie jak kontrolery sieci przychodzącej i wychodzącej, równoważenie obciążenia, rozwiązania do routingu sieciowego, zarządzanie systemem DNS i serwery podstawowe, powinny również wymagać rzadko istotnych zmian. Mogą jednak wymagać częstych aktualizacji konfiguracji.

Warstwa aplikacji i danych wymaga częstych aktualizacji konfiguracji i częstych zmian infrastruktury. Te składniki powinny mieć najbardziej dynamiczne potoki.

Dołączanie kompleksowych typów testów

Planowanie całościowej strategii testowania. Podstawową zasadą niezawodności systemu jest zasada przesunięcia w lewo . Tworzenie i wdrażanie aplikacji to proces, który jest przedstawiony jako seria kroków przechodzących od lewej do prawej. Nie należy ograniczać testowania do końca procesu. Jak najwięcej, przenieś testowanie na początek lub po lewej stronie. Błędy są tańsze do naprawy, gdy je złapać wcześnie. Mogą być kosztowne lub niemożliwe do naprawienia w dalszej części cyklu życia aplikacji.

Przetestuj cały kod, w tym kod aplikacji, szablony infrastruktury i skrypty konfiguracji. Środowisko uruchamiające aplikacje powinno być kontrolowane w wersji i wdrażane za pomocą tych samych mechanizmów co kod aplikacji. Środowisko można przetestować i zweryfikować przy użyciu tych samych paradygmatów testowania, które są już używane przez zespoły na potrzeby kodu aplikacji.

Jeśli to możliwe, użyj zautomatyzowanego testowania, aby zapewnić spójność. Uwzględnij następujące typy testów w projekcie łańcucha dostaw.

  • Testowanie jednostkowe: testy jednostkowe są zwykle uruchamiane w ramach procedury ciągłej integracji. Testy jednostkowe powinny być obszerne i szybkie. Najlepiej pokryć 100 procent kodu i uruchomić go w czasie poniżej 30 sekund.

    Zaimplementuj testowanie jednostkowe, aby sprawdzić, czy składnia i funkcjonalność poszczególnych modułów kodu działają tak, jak powinny, na przykład tworząc zdefiniowane dane wyjściowe dla znanych danych wejściowych. Możesz również użyć testów jednostkowych, aby sprawdzić, czy zasoby IaC są prawidłowe.

    Stosowanie testów jednostkowych do wszystkich zasobów kodu, w tym szablonów i skryptów.

  • Testowanie weryfikacyjne kompilacji: Testy weryfikacyjne kompilacji sprawdzają, czy obciążenie może być wstane w środowisku testowym i działa zgodnie z oczekiwaniami. Testy weryfikacyjne kompilacji nie weryfikują współdziałania składników.

    Testy weryfikacyjne kompilacji sprawdzają, czy metodologia wdrażania infrastruktury i aplikacji działa, oraz czy system reaguje zgodnie z oczekiwaniami po zakończeniu procesu.

  • Testowanie integracji: Testy integracji zapewniają, że składniki aplikacji działają indywidualnie, a następnie określają, czy składniki mogą współdziałać ze sobą tak, jak powinny.

    Uruchomienie dużego zestawu testów integracji może zająć dużo czasu. Dlatego najlepiej jest uwzględnić zasadę zmiany w lewo i przeprowadzić testy na wczesnym etapie cyklu tworzenia oprogramowania. Zarezerwuj testy integracji dla scenariuszy, których nie można przetestować przy użyciu testu weryfikacyjnego kompilacji lub testu jednostkowego.

    W razie potrzeby można uruchamiać długotrwałe procesy testowe w regularnych odstępach czasu. Regularny interwał zapewnia dobry kompromis i wykrywa problemy ze współdziałaniem między składnikami aplikacji nie później niż jeden dzień po ich wprowadzeniu.

    Niektóre scenariusze testowania korzystają z ręcznych przebiegów. Użyj testowania ręcznego, gdy musisz wprowadzić elementy interakcyjności człowieka do testów.

  • Testowanie akceptacyjne: w zależności od kontekstu można ręcznie przeprowadzić testowanie akceptacyjne. Może być częściowo lub w pełni zautomatyzowany. Testy akceptacyjne określają, czy system oprogramowania spełnia wymagania.

    Głównym celem tego testu jest ocena zgodności systemu z wymaganiami biznesowymi i określenie, czy system spełnia wymagane kryteria dostarczania użytkownikom końcowym.

Implementowanie bram jakości w procesach podwyższania poziomu kodu

Zaimplementuj bramy jakości w całym procesie podwyższania poziomu kodu za pośrednictwem testowania. Wdróż kod w niższych środowiskach, takich jak programowanie i testowanie, oraz w wyższych środowiskach, takich jak środowisko przejściowe i produkcyjne. W miarę przechodzenia wdrożenia przez bramy jakości upewnij się, że spełnia ona cele dotyczące jakości przed przejściem do środowiska produkcyjnego. Wymagania biznesowe określają, czym są bramy jakości. Należy również wziąć pod uwagę podstawowe zasady dobrze zaprojektowanej struktury: bezpieczeństwo, niezawodność i wydajność.

Integruj również przepływy pracy zatwierdzania z bramami jakości. Jasno zdefiniuj i zautomatyzuj przepływy pracy zatwierdzania, jeśli jest to konieczne. Zdefiniuj kryteria akceptacji jakości w automatyzacji, aby umożliwić efektywne i bezpieczne przechodzenie przez bramy.

Ułatwienia platformy Azure

Azure DevOps to zbiór usług, które ułatwiają tworzenie wspólnej, wydajnej i spójnej praktyki programistycznej.

Usługa Azure Pipelines udostępnia usługi kompilacji i wydania do obsługi ciągłej integracji/ciągłego wdrażania w aplikacjach.

Funkcja GitHub Actions dla platformy Azure integruje się z platformą Azure , aby uprościć wdrożenia. Użyj funkcji GitHub Actions, aby zautomatyzować procesy ciągłej integracji/ciągłego wdrażania. Możesz tworzyć przepływy pracy, które kompilują i testują każde żądanie ściągnięcia do repozytorium lub wdrażają scalone żądania ściągnięcia w środowisku produkcyjnym.

W przypadku wdrożeń IaC można używać programu Terraform, Bicep i usługi Azure Resource Manager. W zależności od wymagań i znajomości narzędzi przez zespół można użyć co najmniej jednego z tych narzędzi na potrzeby wdrożeń i zarządzania zasobami.

Przykład

Przykład pokazujący, jak za pomocą usługi Azure Pipelines utworzyć potok ciągłej integracji/ciągłego wdrażania, zobacz Architektura punktu odniesienia usługi Azure Pipelines.

Lista kontrolna doskonałości operacji

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna doskonałości operacyjnej