Udostępnij za pośrednictwem


Zalecenia dotyczące bezpiecznych praktyk wdrażania

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

OE:11 Jasno zdefiniuj bezpieczne praktyki wdrażania obciążenia. Podkreślenie ideałów małych, przyrostowych metod wydawania z bramą jakości. Użyj nowoczesnych wzorców wdrażania i progresywnych technik ekspozycji, aby kontrolować ryzyko. Uwzględnij rutynowe wdrożenia i wdrożenia awaryjne lub poprawki.

W tym przewodniku opisano zalecenia dotyczące używania bezpiecznych praktyk wdrażania (SDP). Bezpieczne procesy wdrażania i procedury definiują sposób bezpiecznego wprowadzania i wdrażania zmian w obciążeniu. Zaimplementowanie protokołu SDP wymaga przemyślenia wdrożeń w celu zarządzania ryzykiem. Można zminimalizować ryzyko błędu ludzkiego we wdrożeniach i ograniczyć skutki problematycznych wdrożeń dla użytkowników, implementując protokół SDP.

Kluczowe strategie projektowania

Istnieją cztery ważne wytyczne, które należy wziąć pod uwagę podczas implementowania bezpiecznych praktyk wdrażania:

  • Bezpieczeństwo i spójność: Wszystkie zmiany w obciążeniu produkcyjnym są z natury ryzykowne i muszą być wprowadzane z naciskiem na bezpieczeństwo i spójność.

  • Progresywne narażenie: można zminimalizować potencjalny promień wybuchu problemów spowodowanych wdrożeniem, przyjmując progresywny model wdrażania ekspozycji.

  • Modele kondycji: Wdrożenia muszą przejść testy kondycji przed rozpoczęciem każdej fazy progresywnej ekspozycji.

  • Wykrywanie problemów: po wykryciu problemów wdrożenie powinno zostać natychmiast zatrzymane i zainicjowane odzyskiwanie.

W poniższych sekcjach przedstawiono szczegółowe zalecenia dotyczące każdego z tych punktów.

Zapewnianie bezpieczeństwa i spójności wdrożeń

Niezależnie od tego, czy wdrażasz aktualizację kodu aplikacji, infrastrukturę jako kod (IaC), flagę funkcji lub aktualizację konfiguracji, wprowadzasz ryzyko związane z obciążeniem. W środowisku produkcyjnym nie ma wdrożeń o niskim ryzyku . Każde wdrożenie musi być zgodne ze standardowym wzorcem i powinno być zautomatyzowane w celu wymuszania spójności i minimalizowania ryzyka błędu ludzkiego. Ważne jest, aby łańcuch dostaw obciążeń i potoki wdrażania były niezawodne, bezpieczne i mają jasno zdefiniowane standardy wdrażania. Traktuj każde wdrożenie jako możliwe ryzyko i poddaj każde wdrożenie na tym samym poziomie zarządzania ryzykiem. Pomimo ryzyka należy nadal wdrażać regularne zmiany w obciążeniu. Nie można wdrożyć regularnych aktualizacji wprowadza inne zagrożenia, takie jak luki w zabezpieczeniach, które należy rozwiązać za pośrednictwem wdrożeń. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące projektowania łańcucha dostaw obciążeń.

Częste małe wdrożenia są preferowane w rzadkich dużych wdrożeniach. Małe zmiany są łatwiejsze do rozwiązania, gdy pojawiają się problemy, a częste wdrożenia pomagają zespołowi w budowaniu zaufania do procesu wdrażania. Ważne jest również, aby nauczyć się z środowiska produkcyjnego, przeglądając procesy obciążenia w przypadku wystąpienia anomalii podczas wdrażania. Możesz znaleźć słabe strony projektu infrastruktury lub wdrożenia. Jeśli występują problemy podczas wdrożeń, upewnij się, że bez winy postmortemy są częścią procesu SDP w celu przechwytywania lekcji dotyczących zdarzenia.

Wdrażanie progresywnego modelu ekspozycji

W przypadku wystąpienia problemów z wdrażaniem celem jest jak najszybsze przechwycenie ich w celu zminimalizowania wpływu na użytkowników końcowych. Aby osiągnąć ten cel, zaimplementuj model wdrażania stopniowego wdrażania, znany również jako progresywny model ekspozycji. Wdrożenia kanary są typowym przykładem progresywnej ekspozycji. W tym modelu wdrażania niewielka grupa użytkowników wewnętrznych lub zewnętrznych otrzymuje najpierw nową funkcję. Gdy pierwsza grupa uruchomi nową wersję bez problemu, funkcja zostanie wdrożona w kolejnych większych grupach, dopóki cała populacja użytkowników nie uruchomi nowej wersji. Flagi funkcji są zwykle używane do włączania nowej wersji dla użytkowników docelowych we wdrożeniach kanarowych.

Innym typowym modelem wdrażania jest podejście niebiesko-zielone. W tym modelu wdrażane są dwa identyczne zestawy lub pule infrastruktury obciążenia. Obie pule mogą obsługiwać pełne obciążenie produkcyjne. Pierwsza (niebieska) pula uruchamia bieżącą wersję wdrożenia, w której znajdują się wszyscy użytkownicy. Druga (zielona) pula zostanie zaktualizowana o nową funkcję i przetestowana wewnętrznie. Po przeprowadzeniu testów wewnętrznych podzbiór ruchu produkcyjnego jest kierowany z niebieskiej puli do zielonej puli. Podobnie jak wdrożenia kanarowe, wdrożenie jest progresywne, ponieważ przesuwasz więcej ruchu do zielonej puli w kolejnych większych falach wdrażania. Po zakończeniu wdrażania pula aktualizacji stanie się niebieską pulą, a zielona pula będzie gotowa do następnego wdrożenia. Obie pule są logicznie oddzielone od siebie, aby chronić przed awariami. Możesz wdrożyć odmianę modelu niebieski-zielony w obciążeniu, które korzysta ze wzorca projektu Sygnatury wdrożenia, wdrażając pojedynczo jeden znacznik.

W obu tych modelach czas między poszczególnymi fazami wdrożenia powinien być wystarczająco długi, aby umożliwić monitorowanie metryk kondycji obciążenia. Należy podać wiele czasu pieczenia, czas między grupami wprowadzania, aby zapewnić użytkownikom z różnych regionów lub użytkowników, którzy wykonują różne zadania, mają czas na użycie obciążenia w normalnej pojemności. Czasy pieczenia powinny być mierzone w godzinach i dniach, a nie w minutach. Czas pieczenia powinien również wzrosnąć dla każdej grupy wprowadzania, aby można było uwzględnić różne strefy czasowe i wzorce użycia w ciągu dnia.

Opracowywanie niezawodnych modeli kondycji obciążeń

Opracowywanie niezawodnego modelu kondycji w ramach strategii platformy i niezawodności obserwacji. Model kondycji powinien zapewnić szczegółowy wgląd w składniki i ogólną kondycję obciążenia. Jeśli podczas wdrażania otrzymasz alert dotyczący zmiany kondycji odnoszącej się do użytkownika końcowego, wdrożenie powinno zostać natychmiast zatrzymane, a badanie przyczyny alertu powinno pomóc w ustaleniu następnego przebiegu akcji. Jeśli użytkownicy końcowi nie zgłaszają problemów, a wszystkie wskaźniki kondycji pozostają zielone przez cały czas pieczenia, wdrożenie powinno być kontynuowane. Pamiętaj, aby uwzględnić metryki użycia w modelu kondycji, aby upewnić się, że brak problemów zgłaszanych przez użytkownika i negatywne sygnały kondycji nie ukrywają problemu. Aby uzyskać więcej informacji, zobacz Tworzenie modelu kondycji.

Implementowanie mechanizmów wykrywania błędów

Gdy wdrożenie powoduje problem w jednej z grup wdrażania, wdrożenie musi zostać natychmiast zatrzymane. Należy zbadać przyczynę problemu i ważność skutków natychmiast po otrzymaniu alertu. Odzyskiwanie po problemie może obejmować:

  • Wycofywanie wdrożenia przez cofnięcie zmian wprowadzonych we wdrożeniu i przywrócenie ostatniej znanej konfiguracji roboczej.

  • Stopniowe wdrażanie przez rozwiązanie problemu w trakcie wdrażania. Problemy można rozwiązać w połowie wdrożenia, stosując poprawkę lub w inny sposób minimalizując problem.

  • Wdrażanie nowej infrastruktury przy użyciu ostatniej znanej konfiguracji roboczej.

Wycofywanie zmian, zwłaszcza bazy danych, schematu lub innych zmian składników stanowych, może być złożone. Wytyczne dotyczące protokołu SDP powinny zawierać jasne instrukcje dotyczące radzenia sobie ze zmianami danych zgodnie z projektem majątku danych dla obciążenia. Podobnie należy ostrożnie obsługiwać wycofywanie, aby upewnić się, że protokół SDP nie jest zaniedbywany i że poprawka lub inne działania minimalizujące są wykonywane bezpiecznie.

Ustanawianie protokołów dla wdrożeń awaryjnych

  • Zaimplementuj przechowywanie wersji w artefaktach kompilacji, aby mieć pewność, że w razie potrzeby można wycofać i przeprowadzić wycofywanie.

  • Użyj przepływu wydania lub struktury rozgałęziania opartej na magistrali, która wymusza ściśle zsynchronizowaną współpracę między zespołem deweloperów, zamiast struktury rozgałęziania opartej na środowisku lub gitflow.

  • Automatyzuj jak najwięcej protokołu SDP. Aby uzyskać szczegółowe wskazówki dotyczące automatyzowania procesów ciągłej integracji i ciągłego dostarczania aplikacji (CI/CD), zobacz Zalecenia dotyczące implementowania automatyzacji.

  • Skorzystaj z praktyk ciągłej integracji, aby regularnie integrować zmiany kodu z repozytoriami. Praktyki ciągłej integracji mogą pomóc zidentyfikować konflikty integracji i zmniejszyć prawdopodobieństwo dużych, ryzykownych scaleń. Aby uzyskać więcej informacji, zobacz Przewodnik ciągłej integracji.

  • Użyj flag funkcji, aby selektywnie włączać lub wyłączać nowe funkcje lub zmiany w środowisku produkcyjnym. Flagi funkcji mogą pomóc w kontrolowaniu ujawnienia nowego kodu i szybkim wycofaniu wdrożenia, jeśli wystąpią problemy.

  • Wdróż zmiany w środowiskach przejściowych, które odzwierciedlają środowisko produkcyjne. Środowiska praktyczne umożliwiają testowanie zmian w kontrolowanym ustawieniu przed wdrożeniem w środowisku na żywo.

  • Ustanów kontrole przed wdrożeniem, w tym przegląd kodu, skanowania zabezpieczeń i kontrole zgodności, aby zapewnić bezpieczeństwo wdrożeń zmian.

  • Zaimplementuj wyłączniki, aby automatycznie zatrzymać ruch do usługi, w której występują problemy. Może to pomóc w zapobieganiu dalszemu pogorszeniu systemu.

Protokoły SDP awaryjne

Ustanów protokoły preskrypcyjne, które definiują sposób dostosowania protokołu SDP do poprawki lub problemów awaryjnych, takich jak naruszenie zabezpieczeń lub narażenie na luki w zabezpieczeniach. Na przykład awaryjne protokoły SDP mogą obejmować:

  • Przyspieszanie etapu podwyższania poziomu i zatwierdzania.

  • Testowanie weryfikacyjne kompilacji i przyspieszanie testowania integracji.

  • Skrócenie czasu pieczenia.

W niektórych przypadkach sytuacja kryzysowa może ograniczyć jakość i bramy testowe, ale bramy powinny być nadal uruchamiane tak szybko, jak to możliwe, jak ćwiczenia poza pasmem. Upewnij się, że zdefiniowano, kto może zatwierdzić przyspieszenie SDP w nagłych wypadkach i kryteria, które muszą zostać spełnione, aby przyspieszenie zostało zatwierdzone. Dopasuj protokoły SDP awaryjne do planu reagowania awaryjnego, aby zapewnić obsługę wszystkich sytuacji nadzwyczajnych zgodnie z tymi samymi protokołami.

Kwestie wymagające rozważenia

Tworzenie i utrzymywanie bezpiecznych praktyk wdrażania jest złożone. Sukces w pełnym wdrożeniu niezawodnych standardów zależy od dojrzałości praktyk w wielu obszarach tworzenia oprogramowania. Użycie automatyzacji, tylko do infrastruktury IaC, spójność w strategiach rozgałęziania, korzystanie z flag funkcji i wiele innych rozwiązań może pomóc w zapewnieniu bezpiecznego wdrażania. Skorzystaj z tego przewodnika, aby zoptymalizować obciążenie i poinformować o planach poprawy w miarę rozwoju praktyk.

Ułatwienia platformy Azure

  • Usługi Azure Pipelines i GitHub Actions obsługują wdrożenia wieloetapowe przy użyciu bram zatwierdzania, które mogą pomóc w zaprojektowaniu progresywnego wdrożenia ekspozycji na potrzeby wdrożeń.

  • Użyj miejsc przejściowych usługi aplikacja systemu Azure, aby łatwo zamienić się między wersjami kodu. Miejsca przejściowe są przydatne do testowania w środowiskach przejściowych i mogą być używane w przypadku wdrożeń niebiesko-zielonych.

  • Przechowuj flagi funkcji aplikacji internetowej i zarządzaj nimi w konfiguracji aplikacja systemu Azure. Za pomocą tej usługi można tworzyć, zmieniać i wdrażać funkcje w ujednoliconej płaszczyźnie zarządzania.

  • Wdrażanie aplikacji obciążeń na maszynie wirtualnej przy użyciu aplikacji maszyn wirtualnych.

  • Użyj modułów równoważenia obciążenia platformy Azure, aby zaimplementować strategie wdrażania i uwidocznić kondycję aplikacji obciążeń przy użyciu zasobów natywnych.

  • Użyj rozszerzenia Application Health, aby raportować kondycję aplikacji z poziomu wystąpienia zestawu skalowania maszyn wirtualnych. Rozszerzenie sonduje lokalny punkt końcowy aplikacji i aktualizuje stan kondycji na podstawie odpowiedzi TCP/HTTP odebranych z aplikacji.

  • Użyj usługi Azure Logic Apps , aby utworzyć nową wersję aplikacji za każdym razem, gdy zostanie ona zaktualizowana. Platforma Azure utrzymuje historię wersji aplikacji i może przywrócić lub podwyższyć poziom do dowolnej poprzedniej wersji.

  • Wiele usług azure Database zapewnia funkcję przywracania do punktu w czasie, która może pomóc w wycofaniu. Usługi, które obsługują przywracanie do punktu w czasie, obejmują:

Przykład

Zapoznaj się z niebieskim zielonym wdrożeniem klastrów usługi Azure Kubernetes Service (AKS), aby zapoznać się z przykładem korzystania z tego modelu wdrażania.

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.