Zalecenia dotyczące bezpiecznych praktyk wdrażania

  • Artykuł

Dotyczy tej rekomendacji dotyczącej listy kontrolnej doskonałości operacyjnej platformy Azure Well-Architected Framework:

OE:11 Jasno zdefiniuj bezpieczne praktyki wdrażania obciążenia. Podkreśl ideały małych, przyrostowych, wysokiej jakości metod wydawania. Użyj nowoczesnych wzorców wdrażania i postępowych technik ekspozycji, aby kontrolować ryzyko. Należy uwzględnić rutynowe wdrożenia i poprawki lub poprawki.

W tym przewodniku opisano zalecenia dotyczące korzystania z bezpiecznych praktyk wdrażania (SDP). Bezpieczne procesy wdrażania i procedury definiują sposób bezpiecznego wprowadzania i wdrażania zmian w obciążeniu. Wdrożenie protokołu SDP wymaga przemyślenia wdrożeń za pomocą rozwiązania do zarządzania ryzykiem. Możesz 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

Podczas wdrażania bezpiecznych praktyk wdrażania należy pamiętać o czterech ważnych wytycznych:

  • 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ść.

  • Progresywna ekspozycja: można zminimalizować potencjalny promień wybuchu problemów spowodowanych wdrożeniem, stosując model wdrażania progresywnego narażenia.

  • 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.

Bezpieczeństwo i spójność

Niezależnie od tego, czy wdrażasz aktualizację kodu aplikacji, infrastrukturę jako kod (IaC), flagę funkcji lub aktualizację konfiguracji, wprowadzasz ryzyko dla obciążenia. Nie ma wdrożeń niskiego ryzyka w środowisku produkcyjnym. Każde wdrożenie musi być zgodne ze standardowym wzorcem i powinno być zautomatyzowane w celu wymuszania spójności i zminimalizowania 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. Traktowanie każdego wdrożenia jako możliwego ryzyka i poddanie każdego wdrożenia do tego samego poziomu 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 występują problemy i częste wdrożenia pomagają zespołowi w budowaniu zaufania do procesu wdrażania. Ważne jest również, aby nauczyć się z produkcji, przeglądając procesy obciążeń podczas napotkania anomalii podczas wdrażania. W projekcie infrastruktury lub wdrożeniu mogą znajdować się słabe strony. W przypadku wystąpienia problemów podczas wdrożeń upewnij się, że bez winy postmortemy są częścią procesu SDP w celu przechwycenia lekcji dotyczących zdarzenia.

Wdrażanie progresywnego narażenia

Gdy wystąpią problemy z wdrażaniem, celem jest jak najszybsze ich złapanie, aby zminimalizować wpływ na użytkowników końcowych. W celu osiągnięcia tego celu zaimplementuj stopniowo model wdrażania, znany również jako model progresywnego narażenia. Wdrożenia kanaarne są typowym przykładem progresywnej ekspozycji. W tym modelu wdrażania niewielka grupa użytkowników wewnętrznych lub zewnętrznych otrzymuje pierwszą nową funkcję. Gdy pierwsza grupa uruchomi nową wersję bez problemu, ta 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 niebieskie-zielone. W tym modelu wdrażane są dwa identyczne zestawy lub pule infrastruktury obciążeń. Obie pule są w stanie obsłużyć 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 jest aktualizowana przy użyciu nowej funkcji i wewnętrznie przetestowana. Po przeprowadzeniu testów wewnętrznych podzbiór ruchu produkcyjnego jest kierowany z niebieskiej puli do zielonej puli. Podobnie jak wdrożenia kanarków, wdrożenie jest postępowe, 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 jest 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 używa wzorca projektu Sygnatury wdrożenia , wdrażając na jednej sygnaturze naraz.

W obu tych modelach czas między poszczególnymi fazami wdrażania powinien być wystarczająco długi, aby umożliwić monitorowanie metryk kondycji obciążenia. Należy podać wiele czasu pieczenia, czas między grupami wdrażania, aby zapewnić, że użytkownicy z różnych regionów lub użytkowników wykonujących 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 wdrożenia, aby można było uwzględnić różne strefy czasowe i wzorce użycia w ciągu dnia.

Modele kondycji

Opracowywanie niezawodnego modelu kondycji w ramach strategii platformy obserwacji i niezawodności. Model kondycji powinien zapewnić szczegółowy wgląd w składniki i ogólną kondycję obciążenia. W trakcie wdrażania, jeśli otrzymasz alert dotyczący zmiany kondycji odnoszącej się do użytkownika końcowego, wdrożenie powinno zostać natychmiast zatrzymane, a dochodzenie w sprawie przyczyny alertu powinno pomóc w ustaleniu następnego przebiegu akcji. Jeśli nie ma żadnych problemów zgłoszonych przez użytkowników końcowych i 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.

Wykrywanie problemó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ść efektów natychmiast po odebraniu alertu. Odzyskiwanie z problemu 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 minimalizując problem w inny sposób.

  • 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 sposobu radzenia sobie ze zmianami danych zgodnie z projektem majątku danych dla obciążenia. Podobnie należy uważnie obsługiwać stopniowe wdrażanie, aby upewnić się, że protokół SDP nie jest zaniedbany i że poprawka lub inne zminimalizowane nakłady pracy są wykonywane bezpiecznie.

Ogólne zalecenia dotyczące protokołu SDP

  • Zaimplementuj przechowywanie wersji w artefaktach kompilacji, aby upewnić się, że możesz wycofać i wycofać się w razie potrzeby.

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

  • Automatyzuj jak najwięcej protokołu SDP. Aby uzyskać szczegółowe wskazówki dotyczące automatyzacji procesów IaC i ciągłej integracji aplikacji i ciągłego dostarczania (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łączyć lub wyłączyć nowe funkcje lub zmiany w środowisku produkcyjnym. Flagi funkcji mogą pomóc w kontrolowaniu ekspozycji nowego kodu i szybkim wycofaniu wdrożenia w razie wystąpienia problemów.

  • 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, która ma 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 dla poprawki lub problemów awaryjnych, takich jak naruszenie zabezpieczeń lub narażenie na luki w zabezpieczeniach. Na przykład protokoły SDP awaryjne mogą obejmować następujące elementy:

  • Przyspieszanie etapu podwyższania poziomu i zatwierdzania.

  • Testowanie 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ć 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, oraz kryteria, które muszą zostać spełnione w celu zatwierdzenia przyspieszenia. Wyrównuj protokoły SDP awaryjne z planem reagowania awaryjnego , aby zapewnić obsługę wszystkich sytuacji nadzwyczajnych zgodnie z tymi samymi protokołami.

Zagadnienia do 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. Korzystanie z automatyzacji, IaC tylko w przypadku zmian infrastruktury, spójności w strategiach rozgałęziania, używania flag funkcji i wielu 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 dla platformy Azure

Przykład

Zobacz niebieski-zielony przewodnik dotyczący architektury klastrów 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ń.

Lista kontrolna doskonałości operacyjnej