Udostępnij za pośrednictwem

Zalecenia dotyczące projektowania strategii ograniczania niepowodzeń wdrażania

  • Artykuł

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

OE:12 Zaimplementuj strategię ograniczania błędów wdrażania, która rozwiązuje nieoczekiwane problemy z wdrażaniem w ramach szybkiego odzyskiwania. Połącz wiele podejść, takich jak wycofywanie, wyłączanie funkcji lub korzystanie z natywnych możliwości wzorca wdrażania.

W tym przewodniku opisano zalecenia dotyczące projektowania standardowej strategii efektywnej obsługi błędów wdrażania. Podobnie jak inne problemy z obciążeniami, błędy wdrażania są nieuniknioną częścią cyklu życia obciążenia. Dzięki temu myślenia można aktywnie stosować dobrze zaprojektowaną, celową strategię radzenia sobie z błędami wdrażania. Taka strategia umożliwia zespołowi ds. obciążeń efektywne eliminowanie awarii z jak najmniejszym wpływem na użytkowników końcowych.

Brak takiego planu może prowadzić do chaotycznego i potencjalnie szkodliwego reagowania na problemy, co może znacząco wpłynąć na spójność zespołu i organizacji, zaufanie klientów i finanse.

Kluczowe strategie projektowania

Czasami, pomimo dojrzałości praktyk programistycznych, występują problemy z wdrażaniem. Korzystanie z bezpiecznych praktyk wdrażania i obsługa niezawodnego łańcucha dostaw obciążeń może pomóc zminimalizować częstotliwość wdrożeń, które zakończyły się niepowodzeniem. Należy jednak również zaprojektować ustandaryzowaną strategię obsługi wdrożeń, które zakończyły się niepowodzeniem w przypadku ich wystąpienia.

W przypadku korzystania z progresywnego modelu wdrażania ekspozycji jako standardowej praktyki:

  • Masz odpowiednią podstawę do zminimalizowania wpływu na klientów lub użytkowników wewnętrznych, gdy wdrożenia kończą się niepowodzeniem.
  • Możesz skutecznie ograniczyć problemy.

Strategia ograniczania ryzyka niepowodzeń wdrażania składa się z pięciu szerokich faz:

  1. Wykrywanie: Aby odpowiedzieć na nieudane wdrożenie, należy najpierw wykryć błąd. Wykrywanie może mieć kilka formularzy, takich jak nieudane testy weryfikacyjne kompilacji, problemy zgłaszane przez użytkownika lub alerty generowane przez platformę monitorowania.

  2. Decyzja: Musisz zdecydować, jaka jest najlepsza strategia ograniczania ryzyka dla określonego typu błędu.

  3. Środki zaradcze: Należy wykonać zidentyfikowaną akcję zaradcze. Środki zaradcze mogą mieć formę rezerwowego, wycofywania, wycofywania, wycofywania do przodu lub używania konfiguracji środowiska uruchomieniowego w celu obejścia funkcji naruszającej.

  4. Komunikacja: Uczestnicy projektu i użytkownicy końcowi, których dotyczy problem, muszą być świadomi stanu w miarę wykrywania i pracy nad problemem zgodnie z wymaganiami planu reagowania awaryjnego.

  5. Postmortem: Postmortems bez winy zapewniają zespołowi ds. obciążeń możliwości identyfikowania obszarów poprawy i tworzenia planów stosowania szkoleń.

W poniższych sekcjach przedstawiono szczegółowe zalecenia dotyczące tych faz. W tych sekcjach założono, że po wdrożeniu zmian w co najmniej jednej grupie użytkowników lub systemów wykryto problem, ale przed zaktualizowaniem wszystkich grup w planie wdrożenia.

Wykrywanie

Aby szybko identyfikować problemy z wdrożeniami, potrzebujesz niezawodnych rozwiązań testowania i możliwości obserwacji w odniesieniu do wdrożeń. Aby szybko wykrywać anomalie, możesz uzupełnić monitorowanie obciążeń i alerty, wykonując następujące czynności:

  • Użyj narzędzia do zarządzania wydajnością aplikacji.
  • Włącz rejestrowanie za pomocą instrumentacji.

Testy weryfikacyjne kompilacji i inne testy jakości powinny odbywać się w każdej fazie wdrożenia. Pomyślne testy w jednej grupie wdrożenia nie powinny mieć wpływu na decyzje dotyczące testowania w kolejnych grupach.

Można zaimplementować telemetrię, która koreluje problemy użytkowników z fazą wdrażania. Następnie możesz szybko określić, z którą grupą wdrożenia jest skojarzony określony użytkownik. Takie podejście jest szczególnie ważne w przypadku wdrożeń progresywnych ekspozycji, ponieważ w danym momencie wdrożenia może być uruchomionych wiele konfiguracji w całej bazie użytkowników.

Powinno być gotowe do natychmiastowego reagowania na problemy zgłaszane przez użytkownika. Zawsze, gdy jest to praktyczne, wdróż fazę wdrażania w godzinach pracy, gdy masz dostępny pełny zespół pomocy technicznej. Upewnij się, że personel pomocy technicznej jest przeszkolony w zakresie eskalowania problemów z wdrażaniem w celu właściwego routingu. Eskalacje powinny być zgodne z planem reagowania awaryjnego obciążenia.

Decyzja

Podjęcie decyzji o odpowiedniej strategii ograniczania ryzyka dla danego problemu z wdrożeniem obejmuje uwzględnienie wielu czynników, w tym:

  • Typ używanego modelu progresywnego narażenia. Można na przykład użyć modelu niebieski-zielony lub modelu kanarowego.

    Jeśli używasz modelu niebieski-zielony, powrót z powrotem jest bardziej praktyczny niż wycofywanie. Możesz łatwo przenieść ruch z powrotem do stosu, który uruchamia konfigurację, która nie jest aktualizowana. Następnie możesz rozwiązać problem w problematycznym środowisku i spróbować ponownie przeprowadzić wdrożenie w odpowiednim czasie.

  • Metody, które masz do dyspozycji w celu pomijania problemu. Przykłady obejmują użycie flag funkcji, zmiennych środowiskowych lub dowolnej innej właściwości konfiguracji środowiska uruchomieniowego, którą można włączać i wyłączać.

    Czasami można łatwo obejść problem, wyłączając flagę funkcji lub przełączając ustawienie. W takim przypadku możesz wykonać następujące elementy:

    • Kontynuuj wdrażanie.
    • Unikaj powrotu.
    • Wycofaj się podczas naprawiania kodu, który jest obraźliwy.

  • Poziom nakładu pracy wymagany do zaimplementowania poprawki w kodzie.

    Jeśli poziom nakładu pracy w celu naprawienia kodu jest niski, wdrażanie poprawki na gorąco jest właściwym wyborem dla niektórych scenariuszy.

  • Poziom krytyczny dla obciążenia, którego dotyczy problem.

    Obciążenia krytyczne dla działania firmy powinny być zawsze wdrażane w sposób równoległy, taki jak w modelu niebieskim zielonym, w celu osiągnięcia wdrożeń bez przestojów. W rezultacie powrót jest preferowaną strategią ograniczania ryzyka dla tego typu obciążeń.

  • Typ infrastruktury używanej przez obciążenie — modyfikowalny lub niezmienny.

    Jeśli obciążenie jest przeznaczone do używania modyfikowalnej infrastruktury, wdrażanie w przyszłości może mieć sens, ponieważ obejmuje aktualizację infrastruktury. Z drugiej strony wycofywanie lub powrót może mieć sens w przypadku korzystania z niezmienialnej infrastruktury.

Niezależnie od wybranych wyborów, należy uwzględnić odpowiednie zatwierdzenia w procesie podejmowania decyzji i skodyfikować je w drzewie decyzyjnym.

Ograniczanie ryzyka

  • Wycofywanie: w scenariuszu wycofywania przywracasz zaktualizowane systemy do stanu ostatniej znanej dobrej konfiguracji.

    Ważne jest, aby cały zespół ds. obciążeń zgodził się na znaczenie ostatniego znanego dobra. To wyrażenie odwołuje się do ostatniego stanu obciążenia, które było w dobrej kondycji przed rozpoczęciem wdrażania, co nie musi być poprzednią wersją aplikacji.

    Wycofywanie może być złożone, szczególnie w odniesieniu do zmian danych. Zmiany schematu mogą wprowadzać ryzykowne wycofywanie. Ich bezpieczne wdrożenie może wymagać znacznego planowania. Ogólnie rzecz biorąc, aktualizacje schematu powinny być addytywne. Nie powinny one być zmianami zastępczymi — rekordy nie powinny być zastępowane nowymi rekordami. Zamiast tego starsze rekordy powinny być przestarzałe i powinny współistnieć z nowymi rekordami, dopóki nie będzie można bezpiecznie usunąć przestarzałych rekordów.

  • Rezerwa: W scenariuszu rezerwowym zaktualizowane systemy są usuwane z routingu ruchu produkcyjnego. Cały ruch jest kierowany do stosu, który nie jest aktualizowany. Ta strategia niskiego ryzyka umożliwia rozwiązanie problemów w kodzie bez wprowadzania dalszych zakłóceń.

    W przypadku wdrożeń kanarowych powrót może nie być prosty lub nawet możliwy, w zależności od infrastruktury i projektu aplikacji. Jeśli musisz wykonać skalowanie w celu obsługi obciążenia w systemach, które nie są aktualizowane, przed powrotem wykonaj to skalowanie.

  • Pomiń funkcję powodującą przestępstwo: jeśli możesz pominąć problem przy użyciu flag funkcji lub innego typu właściwości konfiguracji środowiska uruchomieniowego, możesz zdecydować, że kontynuowanie wdrażania jest właściwą strategią dla danego problemu.

    Należy wyraźnie zrozumieć kompromis z pominięciem funkcji i powinien być w stanie przekazać ten kompromis uczestnikom projektu. Uczestnicy projektu powinni zatwierdzić plan naprzód. Uczestnicy projektu muszą określić czas, który można tolerować w stanie obniżonej wydajności. Należy również rozważyć to określenie względem oszacowania czasu potrzebnego do naprawienia kodu naruszającego błąd i wdrożenia go.

  • Wdrożenie awaryjne (poprawka dynamiczna): Jeśli możesz rozwiązać problem w połowie wdrożenia, najbardziej praktyczną strategią ograniczania ryzyka może być poprawka gorąca.

    Podobnie jak w przypadku każdego innego kodu, gorące poprawki muszą przejść przez bezpieczne praktyki wdrażania. Jednak z gorącą poprawką oś czasu jest znacznie przyspieszona. W środowiskach należy użyć strategii podwyższania poziomu kodu. Należy również sprawdzić kod poprawki na wszystkich bramkach jakości. Ale może być konieczne radykalne skrócenie czasu pieczenia i może być konieczne zmodyfikowanie testów, aby je przyspieszyć. Upewnij się, że można uruchamiać pełne testy na zaktualizowanym kodzie tak szybko, jak to możliwe po wdrożeniu. Automatyzacja testowania kontroli jakości w wysokim stopniu pomaga w wydajnym testowaniu w tych scenariuszach.

Kompromisy:

  • Możliwość powrotu zwykle oznacza, że potrzebna jest wystarczająca pojemność infrastruktury do obsługi dwóch wersji konfiguracji obciążenia w tym samym czasie. Zespoły ds. obciążeń muszą również mieć możliwość obsługi dwóch wersji w środowisku produkcyjnym w tym samym czasie.
  • Możliwość skutecznego wycofywania może obejmować refaktoryzację elementów obciążenia. Na przykład może być konieczne oddzielenie funkcji lub zmiana modelu danych.

Komunikacja

Ważne jest, aby jasno zdefiniować obowiązki komunikacyjne, aby zminimalizować chaos podczas incydentów. Te obowiązki powinny określać, w jaki sposób zespół ds. obciążeń angażuje się w zespoły pomocy technicznej, osoby biorące udział w projekcie i personel zespołu reagowania awaryjnego, na przykład kierownik ds. reagowania awaryjnego.

Standaryzacja cykli, zgodnie z którą zespół ds. obciążeń zapewnia aktualizacje stanu. Upewnij się, że uczestnicy projektu znają ten standard, aby wiedzieć, kiedy należy oczekiwać aktualizacji.

Jeśli zespół ds. obciążeń musi komunikować się bezpośrednio z użytkownikami końcowymi, wyjaśnij typ informacji i poziom szczegółowości, które są odpowiednie do udostępniania użytkownikom. Poinformuj również zespół ds. obciążeń o wszelkich innych wymaganiach, które mają zastosowanie do tych przypadków.

Postmortem

Postmortems powinny być zgodne ze wszystkimi nieudanymi wdrożeniami bez wyjątku. Każde nieudane wdrożenie jest okazją do nauki. Postmortems może pomóc w zidentyfikowaniu słabych stron procesów wdrażania i programowania. Możesz również zidentyfikować błędy konfiguracji w infrastrukturze, między innymi.

Postmortems zawsze powinny być bez winy, aby osoby zaangażowane w incydent czuły się bezpiecznie, gdy dzielą się swoimi perspektywami na to, co można poprawić. Liderzy postmortem powinni postępować zgodnie z planami wdrażania zidentyfikowanych ulepszeń i dodawania tych planów do listy prac obciążeń.

Zagadnienia i ogólne zalecenia

Upewnij się, że potok wdrażania może akceptować różne wersje jako parametry, aby można było łatwo wdrożyć konfiguracje o ostatniej znanej dobrej kondycji.

Zachowaj spójność dzięki płaszczyznom zarządzania i danych podczas wycofywania lub wycofywania. Klucze, wpisy tajne, dane stanu bazy danych i konfiguracje, które są specyficzne dla zasobów i zasad, muszą być w zakresie i uwzględniane. Na przykład należy zwrócić uwagę na projekt skalowania infrastruktury w ostatnim znanym dobrym wdrożeniu. Ustal, czy chcesz dostosować konfigurację podczas ponownego wdrażania kodu.

Preferuj małe, częste zmiany w rzadkich, dużych zmianach, tak aby różnica między nowymi i ostatnimi znanymi dobrymi wdrożeniami jest mała.

Przeprowadź analizę trybu awarii (FMA) na potokach ciągłej integracji i ciągłego dostarczania (CI/CD), aby ułatwić identyfikowanie problemów, które mogą komplikować środki zaradcze. Podobnie jak w przypadku obciążenia jako całości, potoki można analizować w celu zidentyfikowania obszarów, które mogą być problematyczne podczas próby zastosowania danego typu ograniczania ryzyka.

Korzystanie z funkcji automatycznego wycofywania w sposób rozsądny:

  • Niektóre narzędzia ciągłej integracji/ciągłego wdrażania, takie jak Usługa Azure DevOps, mają wbudowaną funkcję automatycznego wycofywania. Rozważ użycie tej funkcji, jeśli zapewnia ona wymierną wartość.
  • Należy zastosować funkcję automatycznego wycofywania dopiero po dokładnym i regularnym przetestowaniu potoku. Upewnij się, że potok jest wystarczająco dojrzały, aby wprowadzić dodatkowe problemy w przypadku wyzwolenia automatycznego wycofywania.
  • Należy ufać, że automatyzacja wdraża tylko niezbędne zmiany i że jest wyzwalana tylko wtedy, gdy jest to konieczne. Starannie projektuj wyzwalacze, aby spełnić te wymagania.

Podczas wycofywania używaj możliwości zapewnianych przez platformę. Na przykład kopie zapasowe i przywracanie do punktu w czasie mogą pomóc w przechowywaniu i wycofywaniu danych. Jeśli natomiast używasz maszyn wirtualnych do hostowania aplikacji, warto przywrócić środowisko do punktu kontrolnego, który znajduje się bezpośrednio przed zdarzeniem.

Często testuj całą strategię ograniczania niepowodzeń wdrażania. Podobnie jak plany reagowania awaryjnego i plany odzyskiwania po awarii, plan niepowodzenia wdrożenia jest pomyślny tylko wtedy, gdy twój zespół jest na nim szkolony i regularnie go praktykuje. Testowanie iniekcji błędów i inżynierii chaosu może być skutecznymi technikami testowania strategii ograniczania ryzyka wdrożenia.

Kompromis: członkowie zespołu pomocy technicznej muszą być w stanie wykonywać swoje normalne obowiązki, a także wspierać sytuacje kryzysowe. Może być konieczne zwiększenie liczby szefów w celu zapewnienia, że zespół pomocy technicznej jest prawidłowo obsadzony i może wykonywać wszystkie wymagane obowiązki. Dokładnie przetestuj wdrożenia podczas wdrażania w niższych środowiskach deweloperskich. Ta praktyka pomaga wykrywać błędy i błędy konfiguracji przed przejściem do środowiska produkcyjnego.

Ułatwienia dla platformy Azure

  • Usługa Azure Pipelines udostępnia usługi kompilacji i wydawania na potrzeby obsługi ciągłej integracji/ciągłego wdrażania aplikacji.

  • Azure Test Plans to oparte na przeglądarce rozwiązanie do zarządzania testami, które jest łatwe w użyciu. To rozwiązanie oferuje możliwości wymagane do zaplanowanego testowania ręcznego, testowania akceptacyjnego użytkownika i testowania eksploracyjnego. Azure Test Plans umożliwia również zbieranie opinii od uczestników projektu.

  • Usługa Azure Monitor to kompleksowe rozwiązanie do monitorowania służące do zbierania, analizowania i reagowania na dane monitorowania z chmury i środowisk lokalnych. Monitor zawiera niezawodną platformę zgłaszania alertów. Można skonfigurować ten system na potrzeby automatycznych powiadomień i innych akcji, takich jak autoskalowanie i inne mechanizmy samonaprawiania.

  • Application Insights to rozszerzenie monitora, które zapewnia funkcje monitorowania wydajności aplikacji (APM).

  • Azure Logic Apps to oparta na chmurze platforma do uruchamiania zautomatyzowanych przepływów pracy, które integrują aplikacje, dane, usługi i systemy. Za pomocą usługi Logic Apps możesz utworzyć nową wersję aplikacji przy każdej aktualizacji. Platforma Azure utrzymuje historię wersji i może przywrócić lub podwyższyć poziom poprzedniej wersji.

  • Wiele usług baz danych platformy Azure udostępnia funkcje przywracania do punktu w czasie, które mogą pomóc w powrocie:

  • Azure Chaos Studio (wersja zapoznawcza ) to usługa zarządzana, która korzysta z inżynierii chaosu, która pomaga mierzyć, interpretować i ulepszać aplikację w chmurze oraz odporność usług.

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna doskonałości operacyjnej