Zalecenia dotyczące projektowania strategii testowania niezawodności
Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej niezawodności Well-Architected Reliability:
| RE:06 | Przetestuj środowiska testowe pod kątem dostępności i stosowania zasad projektowania chaosu w środowiskach testowych i produkcyjnych. Zastosowanie testowania gwarantuje, że strategie implementacji tego programu są skuteczne przez przeprowadzenie aktywnego testowania i symulowanego testowania obciążenia. |
|---|
W tym przewodniku opisano zalecenia dotyczące projektowania strategii testowania niezawodności służącej do sprawdzania poprawności i optymalizacji niezawodności prac. Testy niezawodności skupiają się na tym, że pracowitość i dostępność obciążenia, a w szczególności przepływy krytyczne identyfikowane podczas projektowania rozwiązania. Zawiera ogólne wskazówki i wskazówki dotyczące testowania specyficzne dla projektowania i projektowania chaosu.
Definicje
| Termin | Definicja |
|---|---|
| Dostępność | Ilość czasu, przez który obciążenia związanego z aplikacją jest uruchomiona w stanie prawidłowego bez znaczących przestojów. |
| Inżynieria chaosu | Praktyką jest podsyłanie aplikacji i usług do tematyki i niepowodzeń w świecie rzeczywistym. Celem projektowania chaosu jest tworzenie i sprawdzanie poprawności danych w celu nierozpoznania warunków i braku zależności. |
| Awaria | Wprowadzenie błędu do systemu w celu przetestowania niesnasytowania systemu. |
| Odzyskanie | Jej synonimem odporności. |
| Odporność | Możliwość kontrolowania i odzyskiwania danych w przypadku obciążenia aplikacji w trybach niepowodzenia. |
Kluczowe strategie projektowania
Testowanie jest niezbędne, aby upewnić się, że obciążenia spełnia jego cele niezawodności i nie można obsługiwać błędów. Awaria to typ testów, które celowo wprowadza w systemie testy lub obciążenie systemu do scenariuszy ze świata rzeczywistego. Korzystając z technologii projektowania i przetwarzania chaosu, można w sposób aktywny wykrywać i poprawiać problemy, zanim będą one wpływały na środowisko produkcyjne. Ta sekcja zawiera ogólne wskazówki dotyczące testowania, projektowania chaosu i testowania prac nad pracą.
Ogólne wskazówki dotyczące testowania
Regularnie przeprowadzaj testy w celu sprawdzenia poprawności istniejących progów, celów i założenia. Jeśli w obciążeniach wystąpi duża zmiana, należy regularnie testować. Wykonaj większość testów w środowiskach testowania i przemieszczania. Jest również konieczne uruchomienie podzbioru testów w systemie produkcyjnym.
Zautomatyzowanie testowania pozwala zagwarantować spójne zakres testów i powtarzalność. Zautomatyzuj typowe zadania testowe i zintegruj je z procesami tworzenia. Ręczne testowanie oprogramowania jest fikcyjne i niesłyszące, można jednak przeprowadzić ręczne testy przeprowadzane w celu wychwytowego. W przypadku spraw, w których należy opracować zautomatyzowane testy, należy użyć testowania ręcznego w celu określenia zakresu testów, które mają na celu opracowanie.
Opracowanie metody testowania opartego na lewej zmianie w celu przeprowadzenia testów dostępności i testy dostępności na wczesnym etapie cyklu projektowego.
Zaadaptuj prosty format dokumentacji, tak aby każdy mógł zrozumieć proces i wyniki zwykłych testów.
Można udostępnić udokumentowane wyniki odpowiednim zespołom, zespołom operacyjnym, kierownictwu technologii, interesariuszom biznesowym i interesariuszom ds. odzyskiwania danych. W wyniku tych wyników należy poinformować o precyzacjach celów niezawodności, takich jak cele dotyczące poziomu usług (SLO), umowy dotyczące poziomu usług (SLA), cele dotyczące czasu naprawy (RTO) oraz cele punktów naprawy (RPO).
Utwórz zwykły okres testowania kopii zapasowych. Przywróć dane w izolowanych systemach, aby upewnić się, że kopie zapasowe są prawidłowe i że przywracania są funkcjonalne.
Należy dokumentować metryki czasu odzyskiwania danych i udostępniać je interesariuszom odzyskiwania danych, aby upewnić się, że są odpowiednie oczekiwania dotyczące odzyskiwania danych.
Procedury testowania wdrożenia standardowego pomagają zapewnić, że proces wdrażania jest zautomatyzowany, przewidywalny i wydajny.
Przetestuj możliwość ustawienia obciążenia w celu awarii. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi przesyłania danych.
Przetestuj sposób przetwarzania przez obciążenia błędów w usługach zależnych lub innych zależnościach, używając różnych zależności.
Przetestuj plan odzyskiwania danych w celu reagowania na awarie i inne duże zdarzenia.
Przetestuj możliwość ustawienia obciążenia i zminimalizuj awarię składników, korzystając z tego narzędzia.
Korzyści z planowanych i nieplanowanych przestojów
Podczas pracy w trybie offline z powodu planowanej konserwacji lub nieplanowanej przestoju istnieje unikatowa szansa przeprowadzenia testowania i lepszego zrozumienia obciążenia. W poniższych sekcjach przedstawiono zalecenia dla każdego scenariusza.
Planowane prace konserwacyjne
Jeśli zaplanowano okna konserwacyjne dla aktualizacji lub aplikacji, można przetestować składniki i przepływy, które nie są związane z pracami konserwacyjnymi. Wykonaj testy bez potencjalnego ryzyka nieoczekiwanego obciążenia lub podjęcia go w trybie offline. Jeśli w okresie konserwacji jest wystarczająca ilość czasu, można również przetestować składniki i przepływy związane z konserwacją po zakończeniu prac konserwacyjnych.
Nieplanowana przestoje
Użyj każdego zdarzenia z awarią jako szansy sprzedaży, aby dowiedzieć się więcej o obciążeniach i poprawić jego wydajność, wykonać następujące kroki uporządkowane według priorytetu:
Pobierz obciążenie pracą z powrotem do trybu online dla użytkowników. Może być konieczne obejście problemu, rozwiązanie problemu lub zainicjowanie procesów odzyskiwania.
Należy określić główną przyczynę awarii i rozwiązać ją. Jeśli można naprawić przyczynę główną podczas naprawienia błędu, należy dokumentować przyczynę główną i działania podjęte w celu rozwiązania tego problemu. Jeśli problem wymaga późniejszego wykonania kolejnego okna konserwacji, upewnij się, że środki zaradcze poradzą sobie z oczekiwanym obciążeniem, dokładnie je testując. Należy się upewnić, że ustawiono wystarczające monitorowanie na tyle, aby można było je pokryć.
Jeśli ma to zastosowanie, należy zwrócić uwagę na te same problemy lub braki w konfiguracji, które mogą mieć wpływ na podobne problemy, na wszystkie składniki w obciążeniach. Za pomocą tej szansy sprzedaży można w sposób aktywny adresować te składniki. Należy zapoznać się z historię zdarzeń w celu wykrycia wzorców podobnych problemów w obrębie całego obciążenia.
Wyniki badań mogą poprawić strategię testowania. Należy sprawdzić, czy ta sama przyczyna i podobne problemy zostały pomyślnie rozwiązane, testując ten sam błąd.
Wskazówki dotyczące projektowania i chaosu
W testach środowiska testowego w sposób zgodny z zasadami projektowania chaosu zaznacz możliwość reagowania prac na błędy składników. Wykonaj testy przedproduktowe i produkcyjne w środowiskach przedproduktowych i produkcyjnych. Zastosowanie informacji poznanych z wykonywania analizy trybu niepowodzenia pozwala zagwarantować, że testuje się tylko testowe dane, które mają priorytet, oraz upewnić się, że strategie dotyczące migracji powinny rozwiązać problem.
Kluczowe wskazówki dotyczące projektowania chaosu:
Bądź aktywny. Nie należy czekać na niepowodzenia. Próbuj przewidujeć niepowodzenia, przeprowadzenie chaosu w celu wykrywania i poprawiania problemów, zanim wpłynie one na środowisko produkcyjne.
Obejmij niepowodzeniem. Zaakceptować niepowodzenia systemu i w ten sposób poznać informacje na temat jego awarii. Niepowodzenia są naturalną częścią złożonych systemów i używają ich jako szansy sprzedaży w celu wykorzystania informacji i poprawienia niezawodności systemu.
Naruszanie systemu. Celowo wsadu lub obciążenia systemu w celu przetestowania jego awarii. Poważne awarie ze świata rzeczywistego i zakłócenia w celu przetestowania i usprawnienia funkcji odzyskiwania danych w obciążeniach.
Tworzenie odporności. Użyj środowiska inżynieryjnego chaosu, aby poprawić możliwość zapobiegania awarii i odzyskiwania ich do potrzeb.
Projektowanie chaosu jest integralną częścią zespołu obsługi obciążenia i bieżącej praktyk, nie jest to krótkoterminowy wysiłek taktyczny w odpowiedzi na jednokrotną awarię. Postępuj zgodnie z tą standardową metodą podczas projektowania chaosu:
Zaczynanie od hipotezy. Każdy eksperyment powinien mieć konkretny cel, na przykład przetestowanie możliwości przepływu, aby spowodować utratę konkretnego składnika.
Zmierz zachowanie plan bazowy. Należy zagwarantować, że spójne metryki niezawodności i wydajności dotyczące przepływu i składników są związane z eksperymentem, który ma być porównywany ze stanem, który można porównywać podczas wykonywania eksperymentu.
Nadaj ekstremowi i jego przechyłki. W tym eksperymentie należy celowo zwrócić uwagę na określone składniki, które można szybko odzyskać. Należy się kierować oczekiwaniami na efekt, który spowoduje, że awaria pozwoli na kontrolowanie wielkich igorów eksperymentu.
Monitoruj wynikowe zachowanie. Zbierania danych telemetrycznymi dotyczących poszczególnych składników przepływu oraz zachowania przepływu, które jest właściwe w przypadku eksperymentu, aby prawidłowo zrozumieć efekty działania strumienia. Porównaj zbieranie metryk z metrykami bazowymi, aby uzyskać pełny obraz wyników gromadzenia danych.
Dokumentować proces i przechowania. Na podstawie szczegółowych informacji o przechowaniach i harmonogramach prac będą podejmowane przyszłe decyzje o projekcie obciążenia, co pozwoli rozwiązać ujawnione w czasie zadania.
Określenie wyniku i działanie na nie. Planować kroki przetwarzania, które można dodać do backlogu prac jako udoskonalenia. Upewnij się, że plany ulepszeń projektu zostały przejrzene i przetestowane w środowiskach nieprodukcjowych według tych samych procesów co w innych wdrożeniach.
Okresowo sprawdzaj proces, opcje architektury i kod, aby szybko wykrywać błędy techniczne, integrować nowe technologie i dostosowywać się do zmieniających się wymagań.
Podczas postępowania w wichrowego i przedmieniowe należy:
Sprawdź, czy monitorowanie jest już dostępne, i skonfigurowanie alertów.
Sprawdź poprawność procesu przypisywania bezpośrednio odpowiedzialnej osoby (DRI) do właściciela zdarzenia.
Upewnij się, że dokumentacja i procesy przetwarzania są aktualne.
Zintegruj następujące zalecenia i rozważania w celu zoptymalizowania strategii testowania chaosu:
Wyzwanie związane z założeniami systemu. Testując, można spróbować poprawić awarię obciążenia i strategii projektowania prac. Należy poszukać szans sprzedaży w celu pojmowania danych składników i przepływów, które zostały założone, że są wiarygodne na podstawie wcześniejszych doświadczeń. Mogą one być wiarygodne w nowym obciążeniach.
Sprawdź poprawność zmiany. Bez dokładnego testowania, w tym testowania testów testowych, może wystąpić niekompletny obraz prac po w wprowadzonych zmianach. Na przykład mogą zostać wprowadzili nowe zależności, które nie są od razu widoczne.
Bufory umowy SLA. Należy ograniczyć testowanie chaosu, aby zachować się w ramach swoich umów SLA i uniknąć potencjalnych niekorzystnych skutków testowania, których nie można by było uniknąć. Wartości docelowe przepływu i odzyskiwania składników ułatwiają zdefiniowanie zakresu testów.
Ustalić budżet błędu jako inwestycję w chaosie i kontroli. Budżet błędu stanowi różnicę między osiąganiem 100% wartości SLO a osiąganiem uzgodnionego budżetu nie-SLO.
Zatrzymaj eksperyment, jeśli wykracza on poza zakres. Nieznane wyniki są oczekiwanym skutkiem chaosu. Należy osiągnąć równowagi między zbierania istotnych danych wynikowych i wpływania na jak mało możliwych użytkowników produkcyjnych.
Należy ściśle współpracować z zespołami projektami w celu zapewnienia zgodności z błędami. Użyj wcześniejszych zdarzeń lub problemów jako przewodnika. Należy sprawdzić zależności i oceniać wyniki po usunięciu tych zależności.
Zidentyfikuj i dokumentuj wcześniej niewykrytych wcześniej zależności między różnymi składnikami w ramach obciążenia, które są ujawniane w czasie testowania chaosu.
Planu naprawy można dostosowywać tak, aby uwzględnić zależności wykryte podczas testowania chaosu.
Użyj wyników analizy i testów jako podstawy nowych eksperymentów i testów. W sytuacji nieoczekiwanych zachowań nowe testy mogą bezpośrednio ukierunkować te zachowania i dać im możliwość projektowania strategii postępowania w przypadku ich projektowania.
Kompromis: Testowanie wtrysku błędów w produkcji może być uciążliwe i może potencjalnie powodować przestoje. Należy dopilnować, aby w zdumieniu interesariuszy o tej możliwości zaprowadzono zabezpieczenia, aby zakończyć proces eksperymentów i wycofywania, aby szybko odwrócić błędy, które wprowadzili.
Ułatwienia Power Platform
Możesz użyć wyników statycznych w Power Automate celu zwrócenia stałego wyniku w celu przetestowania obciążenia.
Power Apps Test Engine (wersja zapoznawcza) to składnik interfejsu wiersza Power Platform polecenia, którego można użyć do testowania autonomicznych aplikacji Power Apps kanwy.
Azure Test Plans to łatwe w użyciu, oparte na przeglądarce rozwiązanie do zarządzania testami, które zapewnia wszystkie możliwości wymagane do planowanego testowania ręcznego, testowania akceptacyjnego użytkowników, testowania eksploracyjnego i zbierania opinii od uczestników projektu.
Jeśli Twoje obciążenie obejmuje zasoby platformy Azure, możesz użyć usługi zarządzanej Azure Chaos Studio, która używa projektowania chaosu w celu pomocy w oceny, zrozumieniu i ulepszyć aplikację w chmurze oraz wydajność systemu.
Jeśli obciążenie obejmuje drugiego pilota Microsoft Copilot Studio , możesz użyć zestawu Power CAT Copilot Studio do skonfigurowania drugiego pilota i testów. Przeprowadzając indywidualne testy na interfejsach Copilot Studio API (Direct Line), odpowiedzi drugiego pilota są oceniane pod kątem oczekiwanych wyników.
Lista kontrolna niezawodności
Zapoznaj się z kompletną zestawem zaleceń.