Przesunięcie w prawo do testowania w środowisku produkcyjnym

  • Artykuł

Przesunięcie w prawo to praktyka przenoszenia niektórych testów w dalszej części procesu DevOps do testowania w środowisku produkcyjnym. Testowanie w środowisku produkcyjnym używa rzeczywistych wdrożeń do weryfikowania i mierzenia zachowania i wydajności aplikacji w środowisku produkcyjnym.

Jednym ze sposobów, w jaki zespoły DevOps mogą poprawić szybkość, jest strategia testowania z przesunięciem w lewo . Przesunięcie w lewo wypycha większość testów wcześniej w potoku DevOps, aby skrócić czas, przez jaki nowy kod dociera do środowiska produkcyjnego i działa niezawodnie.

Jednak mimo że wiele rodzajów testów, takich jak testy jednostkowe, może łatwo przesunąć się w lewo, niektóre klasy testów nie mogą być uruchamiane bez wdrażania części lub całego rozwiązania. Wdrożenie w usłudze QA lub przejściowej może symulować porównywalne środowisko, ale nie ma pełnego zamiennika środowiska produkcyjnego. Zespoły uważają, że w środowisku produkcyjnym muszą wystąpić pewne typy testów.

Testowanie w środowisku produkcyjnym zapewnia:

  • Pełna szerokość i różnorodność środowiska produkcyjnego.
  • Rzeczywiste obciążenie ruchu klientów.
  • Profile i zachowania w miarę rozwoju zapotrzebowania produkcyjnego w miarę upływu czasu.

Środowisko produkcyjne ciągle się zmienia. Nawet jeśli aplikacja nie ulegnie zmianie, infrastruktura, na podstawie których stale się zmienia. Testowanie w środowisku produkcyjnym weryfikuje kondycję i jakość danego wdrożenia produkcyjnego oraz stale zmieniające się środowisko produkcyjne.

Zmiana prawa do testowania w środowisku produkcyjnym jest szczególnie ważna w następujących scenariuszach:

Wdrożenia mikrousług

Rozwiązania oparte na mikrousługach mogą mieć dużą liczbę mikrousług, które są opracowywane, wdrażane i zarządzane niezależnie. Zmiana prawa do testowania jest szczególnie ważna w przypadku tych projektów, ponieważ różne wersje i konfiguracje mogą na wiele sposobów uzyskiwać dostęp do środowiska produkcyjnego. Niezależnie od pokrycia przedprodukcyjnego testu konieczne jest przetestowanie zgodności w środowisku produkcyjnym.

Zapewnianie jakości po wdrożeniu

Wydawanie do środowiska produkcyjnego to tylko połowa dostarczania oprogramowania. Druga połowa zapewnia jakość na dużą skalę przy użyciu rzeczywistego obciążenia w środowisku produkcyjnym. Ponieważ środowisko ciągle się zmienia, zespół nigdy nie wykonuje testów w środowisku produkcyjnym.

Dane testowe z produkcji to dosłownie wyniki testów z rzeczywistego obciążenia klienta. Testowanie w środowisku produkcyjnym obejmuje monitorowanie, testowanie trybu failover i iniekcję błędów. Ten test śledzi błędy, wyjątki, metryki wydajności i zdarzenia zabezpieczeń. Testowa telemetria pomaga również wykrywać anomalie.

Pierścienie wdrażania

Aby chronić środowisko produkcyjne, zespoły mogą wdrażać zmiany w progresywny i kontrolowany sposób przy użyciu wdrożeń opartych na pierścieniach i flag funkcji. Na przykład lepiej jest złapać usterkę, która uniemożliwia kupującym ukończenie zakupu, gdy mniej niż 1% klientów znajduje się na tym pierścieniu wdrażania, niż po zmianie wszystkich klientów jednocześnie. Wartość funkcji z wykrytymi awariami musi przekraczać straty netto tych niepowodzeń, mierzone w znaczący sposób dla danej firmy.

Pierwszy pierścień powinien być najmniejszym rozmiarem wymaganym do uruchomienia standardowego pakietu integracji. Testy mogą być podobne do tych, które zostały już uruchomione wcześniej w potoku w innych środowiskach, ale testowanie sprawdza, czy zachowanie jest takie samo w środowisku produkcyjnym. Ten pierścień identyfikuje oczywiste błędy, takie jak błędy konfiguracji, zanim będą miały wpływ na klientów.

Po zweryfikowaniu początkowego pierścienia następny pierścień może poszerzyć, aby uwzględnić podzbiór rzeczywistych użytkowników na potrzeby przebiegu testu. Jeśli wszystko wygląda dobrze, wdrożenie może przejść przez kolejne pierścienie i testy, dopóki wszyscy nie będą z niego korzystać. Pełne wdrożenie nie oznacza, że testowanie się skończyło. Śledzenie danych telemetrycznych jest niezwykle ważne w przypadku testowania w środowisku produkcyjnym.

Wstrzykiwanie błędów

Zespoły często używają iniekcji błędów i inżynierii chaosu, aby zobaczyć, jak system działa w warunkach awarii. Te rozwiązania pomagają:

  • Sprawdź, czy zaimplementowane mechanizmy odporności działają faktycznie.
  • Sprawdź, czy awaria w jednym podsystemie znajduje się w tym podsystemie i nie powoduje kaskadowej awarii.
  • Udowodnij, że prace naprawcze dla poprzedniego zdarzenia mają pożądany efekt, bez konieczności oczekiwania na wystąpienie innego zdarzenia.
  • Twórz bardziej realistyczne ćwiczenia szkoleniowe dla inżynierów witryn na żywo, aby mogli lepiej przygotować się do radzenia sobie ze zdarzeniami.

Dobrym rozwiązaniem jest zautomatyzowanie eksperymentów polegających na wstrzyknięciu błędów, ponieważ są to kosztowne testy, które muszą być uruchamiane w stale zmieniających się systemach.

Inżynieria chaosu może być skutecznym narzędziem, ale powinna być ograniczona do środowisk kanarowych , które mają niewielki lub żaden wpływ na klienta.

Testowanie trybu failover

Jedną z form iniekcji błędów jest testowanie trybu failover w celu zapewnienia ciągłości działania i odzyskiwania po awarii (BCDR). Zespoły powinny mieć plany trybu failover dla wszystkich usług i podsystemów. Plany powinny obejmować:

  • Jasne wyjaśnienie wpływu działania usługi na dół.
  • Mapa wszystkich zależności pod względem platformy, technologii i osób opracowującej plany BCDR.
  • Formalna dokumentacja procedur odzyskiwania po awarii.
  • Cykl regularnego wykonywania prób odzyskiwania po awarii.

Testowanie błędów wyłącznika

Mechanizm wyłącznika odcina dany składnik z większego systemu, zwykle w celu zapobiegania awariom w tym składniku rozprzestrzeniania się poza granicami. Aby przetestować następujące scenariusze, można celowo wyzwalać wyłączniki:

  • Czy rezerwowy działa po otwarciu wyłącznika. Rezerwa może pracować z testami jednostkowymi, ale jedynym sposobem, aby sprawdzić, czy będzie działać zgodnie z oczekiwaniami w środowisku produkcyjnym, jest wstrzyknięcie błędu w celu jego wyzwolenia.

  • Czy wyłącznik ma odpowiedni próg poufności do otwarcia, gdy jest to konieczne. Iniekcja błędów może wymusić opóźnienie lub rozłączyć zależności, aby obserwować czas reakcji wyłącznika. Ważne jest, aby sprawdzić nie tylko, czy występuje prawidłowe zachowanie, ale że dzieje się to wystarczająco szybko.

Przykład: Testowanie wyłącznika pamięci podręcznej Redis Cache

Pamięć podręczna Redis cache zwiększa wydajność produktu, przyspieszając dostęp do często używanych danych. Rozważmy scenariusz, który przyjmuje niekrytyczną zależność od usługi Redis. Jeśli usługa Redis ulegnie awarii, system powinien nadal działać, ponieważ może wrócić do używania oryginalnego źródła danych dla żądań. Aby potwierdzić, że awaria usługi Redis wyzwala wyłącznik i że rezerwowy działa w środowisku produkcyjnym, okresowo uruchamiaj testy pod kątem tych zachowań.

Na poniższym diagramie przedstawiono testy zachowania rezerwowego wyłącznika Redis. Celem jest upewnienie się, że po otwarciu wyłącznika wywołania ostatecznie przechodzą do języka SQL.

Diagram showing tests for the Redis circuit breaker and fallback behavior.

Na powyższym diagramie przedstawiono trzy ATs z wyłącznikami przed wywołaniami usługi Redis. Jeden test wymusza otwarcie wyłącznika przez zmianę konfiguracji, a następnie obserwowanie, czy wywołania przechodzą do języka SQL. Następnie inny test sprawdza odwrotną zmianę konfiguracji, zamykając wyłącznik, aby potwierdzić, że wywołania zwracają się z powrotem do usługi Redis.

Ten test sprawdza, czy zachowanie rezerwowe działa po otwarciu wyłącznika, ale nie sprawdza, czy konfiguracja wyłącznika otwiera wyłącznik, gdy powinien. Testowanie tego zachowania wymaga symulowania rzeczywistych awarii.

Agent błędów może wprowadzać błędy w wywołaniach przechodzących do usługi Redis. Na poniższym diagramie przedstawiono testowanie z wstrzyknięciem błędów.

Diagram showing Redis circuit breaker testing with fault injection.

  1. Wstrzykiwacz błędów blokuje żądania redis.
  2. Wyłącznik zostanie otwarty, a test może sprawdzić, czy rezerwowy działa.
  3. Błąd jest usuwany, a wyłącznik wysyła żądanie testowe do usługi Redis.
  4. Jeśli żądanie zakończy się pomyślnie, wywołania powróć do usługi Redis.

Dalsze kroki mogą przetestować czułość wyłącznika, niezależnie od tego, czy próg jest zbyt wysoki, czy zbyt niski, oraz czy inne przekroczenia limitu czasu systemu zakłócają zachowanie wyłącznika.

W tym przykładzie, jeśli wyłącznik nie zostanie otwarty lub zamknięty zgodnie z oczekiwaniami, może to spowodować zdarzenie lokacji na żywo (LSI). Bez testowania iniekcji błędów problem może nie zostać wykryty, ponieważ trudno jest wykonać tego typu testy w środowisku laboratoryjnym.

Następne kroki