Rekomendacje dotyczące projektowania strategii ograniczania ryzyka awarii wdrożenia
Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej doskonałości operacyjnej Well-Architected:
| OE:11 | Zaimplementowanie strategii ograniczania ryzyka dla awarii wdrożenia, która rozwiązuje nieoczekiwane problemy związane z szybkimi odzyskiwaniem danych w trakcie wdrażania. Łącz różne podejścia, takie jak wycofywanie, wyłączanie funkcji lub używanie macierzystej funkcji wzorca wdrażania. |
|---|
W tym przewodniku opisano zalecenia dotyczące projektowania standardowych strategii efektywnej obsługi niepowodzeń wdrażania. Podobnie jak inne problemy z obciążeniem, niepowodzenia wdrożenia są nieuniknioną częścią cyklu życia obciążenia. Ten sposób postępowania pozwala działać w sposób aktywny dzięki dobrze zaprojektowanej i celowej strategii postępowania z niepowodzeniami wdrażania. Taka strategia umożliwia zespołowi ds. obciążeń skuteczne ograniczanie awarii przy jak najmniejszym wpływie na użytkowników.
Brak takiego planu może spowodować potencjalne odpowiedzi na problemy, które mogą znacznie wpłynąć na dane zespół i organizacyjne, zaufanie klienta i finanse.
Kluczowe strategie projektowania
Czasami pomimo dojrzałości praktyk projektowych występują problemy z wdrożeniem. Korzystanie z funkcji bezpiecznego wdrażania i obsługa niezawodnych obciążenia sieciowego umożliwia zminimalizowanie częstotliwości nieudanych wdrożeń. Należy również zaprojektować ustandaryzowaną strategię obsługi nieudanych wdrożeń w momencie ich wystąpienia.
Strategia ograniczania ryzyka niepowodzenia wdrożenia składa się z pięciu szerokich etapów:
- Wykrywanie: Aby zareagować na nieudane wdrożenie, należy najpierw wykryć błąd. Wykrywanie może przybierać różne formy, takie jak nieudane testy dymu, raporty użytkowników lub alerty generowane przez platformę monitorowania.
- Decyzja: Musisz zdecydować, jaka jest najlepsza strategia ograniczania ryzyka dla określonego typu awarii.
- Środki zaradcze: należy wykonać zidentyfikowaną akcję zaradczą. Ograniczenie ryzyka może być formą reakcji na awarię, wycofania lub przejścia do kolejnej wersji.
- Komunikacja: Interesariusze i użytkownicy, których dotyczy problem, muszą być informowani o stanie w miarę wykrywania problemu i pracy nad nim, zgodnie z planem odpowiedzi w sytuacjach awaryjnych.
- Analizy post-mortem: analizy post-mortem bez obwiniania dają zespołowi ds. obciążenia pracą możliwość zidentyfikowania obszarów wymagających poprawy i stworzenia planów zastosowania wyciągniętej wiedzy.
W poniższych sekcjach przedstawiono szczegółowe rekomendacje dla tych faz.
Wykrywanie
Aby szybko identyfikować problemy z wdrożeniami, potrzebne są solidne praktyki testowania i monitorowania związane z wdrożeniami. Aby ułatwić szybkie wykrywanie anomalii, można uzupełnić monitorowanie obciążeń i alerty przy użyciu narzędzia do zarządzania wydajnością aplikacji i rejestrowania za pomocą instrumentacji.
Testy jakości i inne testy jakości powinny odbywać się na każdym etapie realizacji. Pomyślne testy w jednej grupie wdrożeń nie powinny mieć wpływu na decyzje o przetestowaniu w kolejnych grupach.
Można zaimplementować dane telemetryczne, które korelują problemy użytkowników z etapem wdrażania. Następnie można szybko określić, z którą grupą zbiorczą jest skojarzony dany użytkownik. Ta metoda jest szczególnie istotna w przypadku wdrożeń stopniowo uruchomionych w różnych środowiskach, ponieważ w danym momencie we wdrożeniu może być uruchomionych wiele konfiguracji w całej bazie użytkowników.
Użytkownik powinien być gotowy do natychmiastowego odpowiadania na problemy zgłaszane przez użytkowników. W miarę możliwości należy wdrożyć etap wdrożenia w godzinach pracy, o ile jest dostępny pełny zespół pomocy technicznej. Upewnij się, że personel pomocy technicznej jest przeszkolony w zakresie eskalacji problemów z wdrażaniem w celu zapewnienia prawidłowego routingu. Eskalacja powinna być wyrównana z planem odpowiedzi w obciążeniach.
Decyzja
Podjęcie decyzji o odpowiedniej strategii ograniczania ryzyka w przypadku problemu z wdrożeniem wymaga rozważenia takich czynników, jak:
Typ modelu stopniowo postępującego ujawniania, który jest już używany. Można na przykład użyć modelu niebieski-zielony lub modelu canary. W przypadku użycia modelu niebieski-zielony powrót jest bardziej praktyczny niż cofnięcie. Można łatwo przywrócić ruch z powrotem do stosu, w który uruchomiono konfiguracja, która nie została zaktualizowana. Można następnie rozwiązać problem w środowisku projektowym i w odpowiednim czasie spróbować ponownie wdrożenie.
Dostępne metody pominięcia problemu. Przykładami mogą być używanie funkcji, zmiennych środowiska lub dowolnej innej 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 flagi funkcji lub włączając ustawienie. W tym przypadku może być możliwe:
- Kontynuowanie wycofania.
- Unikanie wycofywania.
- Wycofanie w czasie, gdy poprawiany jest kod źródłowy.
Poziom nakładów pracy wymagany do zaimplementowania poprawki w kodzie. Jeśli poziom wysiłku związanego z naprawieniem kodu jest niski, wdrożenie poprawki jest właściwym wyborem w niektórych scenariuszach.
Poziom krytyczności danego obciążenia. W celu osiągnięcia zerowych przestojów wdrożeń zawsze należy wdrożyć obciążenia krytyczne dla działalności w sposób sąsiadujący, tak jak w modelu niebieski-zielony. W związku z tym powrót do takiego zadania jest preferowaną strategią na potrzeby różnych typów prac.
Ograniczanie ryzyka
Oto kilka typowych strategii ograniczenia ryzyka:
Wycofywanie: W scenariuszu wycofywania należy przywrócić zaktualizowane systemy do ostatniego znanego dobrego stanu konfiguracji.
Ważne jest, aby cały zespół ds. obciążenia pracą zgadzał się co do znaczenia "ostatniego znanego dobra". To wyrażenie odnosi się do ostatniego stanu obciążenia, które było w dobrej kondycji przed rozpoczęciem wdrożenia, co niekoniecznie jest poprzednią wersją aplikacji.
Wycofywanie może być złożone, szczególnie gdy dotyczy zmian danych. Zmiany schematu mogą być ryzykowne. Bezpieczne wdrożenie tych działań może wymagać zaplanowania. Aktualizacje schematu należy stosować jako zalecenia ogólne. Rekordów nie należy zastępować nowymi rekordami. Zamiast tego starsze rekordy powinny być przestarzałe i powinny współistnieć z nowymi rekordami, dopóki nie zostanie bezpieczne usunięcie przestarzałych rekordów.
Rezerwowy: W scenariuszu rezerwowym zaktualizowane systemy są usuwane z routingu ruchu produkcyjnego. Cały ruch jest kierowany do niezaktualizowanego stosu. Ta strategia niskiego ryzyka umożliwia rozwiązania problemów w kodzie bez wprowadzania dalszych zakłóceń.
W przypadku wdrożeń canary powrót do programu może nie być prosty lub nawet możliwy, w zależności od infrastruktury i projektowania aplikacji. Jeśli konieczne jest wykonanie skalowania w celu obsługi niezaktualizowanych systemów, należy je skalować przed wycofaniem.
Pomiń obraźliwą funkcję: Jeśli możesz ominąć 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 problemu.
Należy dokładnie poznać sposób obejścia tej funkcji i należy mieć możliwość komunikowania się z interesariuszami. Interesariusze powinni zatwierdzić plan działań. Interesariusze muszą określić czas, jaki można zrównoważać w przypadku stanu pogorszonego. Muszą także ustalić to ustalenie w stosunku do szacowanego czasu potrzebnego do naprawienia błędu i wdrożenia tego kodu.
Wdrożenie awaryjne (poprawka): Jeśli możesz rozwiązać problem w trakcie wdrażania, poprawka może być najbardziej praktyczną strategią ograniczania ryzyka.
Podobnie jak w przypadku każdego innego kodu, poprawki muszą przejść przez bezpieczne praktyki wdrażania. Ale dzięki poprawce oś czasu jest znacznie przyspieszona. W środowiskach tych należy stosować strategię promocji kodu. Musisz także sprawdzić kod poprawki we wszystkich bramkach jakości. Może się jednak okazać konieczne skrócenie czasu oczekiwania i zmodyfikowanie testów w celu przyspieszenia ich działania. Upewnij się, że można uruchomić pełne testy zaktualizowanego kodu możliwie jak najszybciej po wdrożeniu. Automatyzacja testowania zapewnienia jakości w wysokim stopniu ułatwia wydajne testowanie w tych scenariuszach.
Komunikacja
Ważne jest, aby jasno zdefiniować obowiązki komunikacyjne, aby zminimalizować chaos podczas zdarzeń. Te obowiązki powinny określać sposób kontaktu zespołu obsługi klienta z zespołami pomocy technicznej, interesariuszami i personelem zespołu odpowiedzi, na przykład z menedżerem odpowiedzi na sytuację awaryjną.
Należy ustandaryzować czas następujący po stronie zespołu prac przy udostępnianiu aktualizacji stanu. Należy upewnić się, że interesariusze mają świadomość tego standardu, aby wiedzieć, kiedy oczekują na aktualizacje.
Jeśli zespół ds. obciążenia musi komunikować się bezpośrednio z użytkownikami, wyjaśnij typ informacji i poziom szczegółowości, które są odpowiednie do udostępniania. Ponadto należy przekazać zespołowi prac wszelkie inne wymagania dotyczące tych spraw.
Post mortem
Analizy końcowe powinny uwzględniać wszystkie nieudane wdrożenia bez wyjątku. Każde wdrożenie, które zakończyło się niepowodzeniem, jest szansą na naukę. Analizy post-mortem mogą pomóc w zidentyfikowaniu słabych punktów w procesach wdrażania i programowania oraz błędnych konfiguracji w infrastrukturze.
Analizy post mortem powinny być zawsze bez przypisywania winy, aby osoby biorące udział w zdarzeniu były bezpieczne, gdy dzielą się swoimi perspektywami na to, co można poprawić. Liderzy ds. analiz post-mortem powinni kolejne czynności z planami wdrożenia zidentyfikowanych ulepszeń i dodania tych planów do listy zadań związanych z obciążeniem.
Rozważania i zalecenia ogólne
Upewnij się, że potok wdrożenia może zaakceptować różne wersje jako parametry, aby można było łatwo wdrożyć znane już konfiguracje.
Zapewnianie spójności z zarządzaniem i danymi w przypadku cofnięcia lub przejścia do przodu. Klucze, wpisy tajne, dane stanu bazy danych i konfiguracje specyficzne dla zasobów i zasad, muszą być w zakresie i uwzględnione. Zwróć na przykład uwagę na projekt skalowalności infrastruktury w znanym ostatnim dobrym wdrożeniu. Należy określić, czy należy dostosować konfigurację podczas ponownego konfigurowania kodu.
Preferuj małe, częste zmiany zamiast rzadkich, dużych zmian, tak aby różnica między nowymi a ostatnimi znanymi dobrymi wdrożeniami była niewielka.
Przeprowadź analizę trybu awarii w potokach ciągłej integracji i ciągłego dostarczania (CI/CD), aby ułatwić identyfikowanie problemów, które mogą komplikować działania 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 środków zaradczych.
Użyj zautomatyzowanej funkcji wycofywania w sposób automatyczny:
- Niektóre narzędzia CI/CD, takie jak Azure DevOps, mają wbudowane funkcje automatycznego wycofywania. Rozważ użycie tej funkcji, jeśli będzie miała dla Ciebie wartość.
- Funkcję automatycznego wycofywania należy wycofać tylko po przetestowaniu potoku dokładnie i regularnie. Upewnij się, że potok jest na tyle dużo, aby wprowadzić dodatkowe problemy, jeśli zostanie wyzwolone automatyczne wycofywanie.
- Należy mieć zaufanie, że automatyzacja wdraża tylko niezbędne zmiany i że jest wyzwalana tylko w razie potrzeby. Zaprojektuj wyzwalane bardzo starannie, aby spełnić te wymagania.
Podczas wycofywania użyj funkcji dostarczonych z platformy. Na przykład kopie zapasowe i przywracanie do określonego punktu w czasie mogą pomóc w przywracaniu pamięci masowej i danych. Jeśli używasz maszyn wirtualnych do hostowania aplikacji, pomocne może być przywrócenie środowiska do punktu kontrolnego bezpośrednio przed zdarzeniem.
Często przetestuj strategię ograniczania ryzyka dla awarii całego wdrożenia. Podobnie jak plany odpowiedzi na awarie i plany odzyskiwania danych, plan niepowodzenia wdrożenia jest pomyślny tylko wtedy, gdy zespół jest w nim przeszkolony i regularnie go praktykuje. Inżynieria chaosu i testowanie wstrzykiwania błędów mogą być skutecznymi technikami testowania strategii ograniczania ryzyka wdrożenia.
Ułatwienia Power Platform
Potoki mają Power Platform na celu demokratyzację zarządzania cyklem życia aplikacji (ALM) dla Power Platform klientów i klientów Dynamics 365 poprzez wprowadzenie do usługi funkcji automatyzacji ALM oraz ciągłej integracji i ciągłego dostarczania (CI/CD).
Microsoft Power Platform Narzędzia do kompilacji mogą Azure DevOps służyć do automatyzowania typowych zadań kompilacji i wdrażania związanych z aplikacjami opartymi na Power Platform bazie.
Akcje GitHub umożliwiają Power Platform deweloperom tworzenie zautomatyzowanych przepływów pracy cyklu życia tworzenia oprogramowania. Za pomocą akcji GitHub dla platformy Microsoft Power Platform można tworzyć przepływy pracy w swoim repozytorium, aby tworzyć, testować, pakowania, wydawać i wdrażać aplikacje; wykonywać automatyzację; oraz zarządzać botami i innymi składnikami zbudowanymi na platformie Microsoft Power Platform.
Akcelerator ALM to narzędzie typu open source, które składa się z zestawu aplikacji, skryptów i potoków zaprojektowanych w celu zautomatyzowania procesu ciągłej integracji/ciągłego dostarczania.
Automatyzowanie testów za pomocą usługi Azure Pipelines.
Użyj zestawu Copilot Studio Power CAT , aby skonfigurować drugiego pilota i testy. Przeprowadzając indywidualne testy na interfejsach Copilot Studio API (Direct Line), odpowiedzi drugiego pilota są oceniane pod kątem oczekiwanych wyników.
Zmienne środowiskowe w rozwiązaniach przechowują klucze parametrów i wartości, które następnie służą jako dane wejściowe dla innych obiektów aplikacji. Dzielenie parametrów od obiektów zużywających dane pozwala na zmianę wartości w tym samym środowisku lub migrowanie rozwiązań do innych środowisk.
Power Platform Środowiska udostępniają funkcję przywracania do określonego punktu w czasie, która może pomóc w wycofaniu.
Power Platform integruje się z programem Application Insights, będącego częścią ekosystemu Azure Monitor. Używaj tej integracji do wykonywania następujących czynności:
Odbieranie telemetrii z diagnostyki i wydajności przechwyconej przez platformę Dataverse w Application Insights. Można subskrybować, aby otrzymywać dane telemetryczne dotyczące operacji wykonywanych przez aplikacje w bazie danych i Dataverse w aplikacjach opartych na modelach. Ta telemetria zawiera informacje, których można użyć do diagnozowania i rozwiązywania problemów związanych z błędami i wydajnością.
Połącz aplikacje kanwy z Application Insights. Tych analiz można użyć do diagnozowania problemów i zrozumienia, jak użytkownicy korzystają z aplikacji. Możesz zbierać informacje, które pomogą Ci podejmować lepsze decyzje biznesowe i poprawić jakość swoich aplikacji.
Skonfiguruj Power Automate telemetrię , do której ma przepływać Application Insights, na przykład w celu monitorowania wykonań przepływu w chmurze i tworzenia alertów dotyczących niepowodzeń uruchamiania przepływu w chmurze.
Przechwytywanie danych telemetrycznych z Microsoft Copilot Studio drugiego pilota do użycia na platformie Azure Application Insights. Za pomocą tej telemetrii można monitorować zarejestrowane komunikaty i zdarzenia wysyłane do i z drugiego pilota, tematy wyzwalane podczas konwersacji użytkowników oraz niestandardowe zdarzenia telemetrii, które mogą być wysyłane z tematów.
Lista kontrolna doskonałości operacyjnej
Zapoznaj się z kompletną zestawem zaleceń.