Udostępnij za pośrednictwem

Zalecenia dotyczące projektowania strategii ograniczania błędów 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 ryzyka niepowodzeń wdrażania, która rozwiązuje nieoczekiwane problemy z szybkim odzyskiwaniem. 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 niepowodzeń 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 niepowodzeniami wdrażania. Taka strategia umożliwia zespołowi ds. obciążeń efektywne eliminowanie niepowodzeń przy możliwie najmniejszym wpływie na użytkowników końcowych.

Brak takiego planu może prowadzić do chaotycznych i potencjalnie szkodliwych odpowiedzi 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 rozwiązań wdrażania i obsługa niezawodnego łańcucha dostaw obciążenia 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 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 rozwiązać 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 form, 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 lub używania konfiguracji środowiska uruchomieniowego w celu obejścia funkcji przestępczej.

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

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

Poniższe sekcje zawierają 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.

Projektowanie mechanizmów wykrywania błędów

Aby szybko zidentyfikować problemy z wdrożeniami, potrzebujesz niezawodnych rozwiązań dotyczących testowania i obserwacji w odniesieniu do wdrożeń. Aby szybko wykrywać anomalie, możesz uzupełnić monitorowanie i alerty obciążenia, 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 wdrażania nie powinny mieć wpływu na decyzje dotyczące testowania w kolejnych grupach.

Można zaimplementować telemetrię, która koreluje problemy użytkownika z fazą wdrażania. Następnie możesz szybko określić, z którą grupą wprowadzania 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 sposobu eskalacji problemów z wdrażaniem w celu odpowiedniego routingu. Eskalacje powinny być zgodne z planem reagowania awaryjnego obciążenia.

Podejmowanie decyzji w sprawie strategii ograniczania ryzyka

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żesz na przykład użyć modelu niebiesko-zielonego 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 innego typu właściwości konfiguracji środowiska uruchomieniowego, które można włączać i wyłączać.

    Czasami można łatwo pominąć problem, wyłączając flagę funkcji lub przełączając ustawienie. W takim przypadku może być możliwe:

    • Kontynuuj wdrażanie.
    • Unikaj powrotu.
    • Wycofaj się, gdy naprawisz kod powodujący wykroczenie.

  • 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 gorącej jest właściwym wyborem dla niektórych scenariuszy.

  • Poziom krytycznego 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 infrastruktury modyfikowalnej, może mieć sens, ponieważ obejmuje aktualizowanie 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.

Implementowanie strategii ograniczania 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 odnosi się do ostatniego stanu obciążenia, które było w dobrej kondycji przed rozpoczęciem wdrażania, co niekoniecznie jest poprzednią wersją aplikacji.

    Wycofywanie może być złożone, szczególnie w przypadku 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.

  • Rezerwowy: 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 systemów, które nie zostały zaktualizowane, przed powrotem wykonaj skalowanie.

  • Pomiń funkcję powodującą wykroczenie: 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 przypadku działania w stanie obniżonej wydajności. Muszą 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 gorąca): jeśli możesz rozwiązać problem w połowie wdrożenia, poprawka gorąca może być najbardziej praktyczną strategią ograniczania ryzyka.

    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 gorąco na wszystkich bramach 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 w 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.
  • Efektywne wycofywanie może obejmować refaktoryzację elementów obciążenia. Na przykład może być konieczne oddzielenie funkcji lub zmiana modelu danych.

Standaryzacja aktualizacji stanu podczas zdarzenia

Ważne jest, aby jasno zdefiniować obowiązki komunikacyjne, aby zminimalizować chaos podczas incydentów. Te obowiązki powinny ustalić, 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 kryzysowego, na przykład kierownik ds. reagowania kryzysowego.

Standaryzacja rytmu wykonywanego przez zespół ds. obciążeń w celu zapewnienia aktualizacji 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ółów, 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.

Przeprowadzanie pośmiertnych zdarzeń

Polecenia 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 w procesach wdrażania i programowania. Możesz również zidentyfikować błędy konfiguracji w infrastrukturze, między innymi wiele innych możliwości.

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 wdrożenia zidentyfikowanych ulepszeń i dodania tych planów do listy prac obciążeń.

Operacjonalizacja procesów ograniczania ryzyka

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

Zachowaj spójność dzięki płaszczyznom zarządzania i danych podczas wycofywania lub wycofywania. Klucze, wpisy tajne, dane stanu bazy danych i konfiguracje specyficzne dla zasobów i zasad muszą być w zakresie i są uwzględniane. Na przykład zwróć 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 wdrożeniami jest mała.

Przeprowadź analizę trybu awarii (FMA) w 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.

Używaj funkcji automatycznego wycofywania w rozsądny sposób:

  • Niektóre narzędzia ciągłej integracji/ciągłego wdrażania, takie jak Azure DevOps, mają wbudowaną funkcję automatycznego wycofywania. Rozważ użycie tej funkcji, jeśli zapewnia ona konkretną wartość.
  • Należy wdrożyć 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. Dokładnie zaprojektuj wyzwalacze, aby spełnić te wymagania.

Korzystanie z funkcji udostępnianych przez platformę podczas wycofywania. Na przykład kopie zapasowe i przywracanie do punktu w czasie mogą pomóc w usuwaniu magazynu i wycofywania danych. Lub jeśli używasz maszyn wirtualnych do hostowania aplikacji, pomocne może być przywrócenie środowiska do punktu kontrolnego, który znajduje się bezpośrednio przed zdarzeniem.

Często przetestuj całą strategię ograniczania ryzyka niepowodzeń wdrażania. Podobnie jak plany reagowania awaryjnego i plany odzyskiwania po awarii, plan niepowodzenia wdrożenia jest pomyślny tylko wtedy, gdy zespół jest na nim przeszkolony i regularnie je 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ć normalne obowiązki, a także wspierać sytuacje awaryjne. Może być konieczne zwiększenie liczby szefów, aby upewnić się, że zespół pomocy technicznej jest właściwie 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 platformy Azure

  • Usługa Azure Pipelines udostępnia usługi kompilacji i wydania do 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żytkowników i testowania eksploracyjnego. Plany testów platformy Azure umożliwiają 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 ze środowisk w chmurze i środowiskach lokalnych. Monitor zawiera niezawodną platformę 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żna utworzyć nową wersję aplikacji za każdym razem, gdy zostanie ona zaktualizowana. Platforma Azure utrzymuje historię wersji i może przywrócić lub podwyższyć poziom poprzedniej wersji.

  • Wiele usług bazy danych platformy Azure udostępnia funkcje przywracania do punktu w czasie, które mogą pomóc w przypadku konieczności wycofania:

  • Azure Chaos Studio (wersja zapoznawcza) to zarządzana usługa, która używa inżynierii chaosu w celu ułatwienia mierzenia, zrozumienia i poprawy odporności aplikacji i usług w chmurze.

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna doskonałości operacyjnej