Temat DevOps jest teraz na czasie. Pipeline ciągłej integracji i dostarczania wdrażają wszyscy, którzy się tym interesują. Jednak większość nie zawsze zwraca wystarczającą uwagę na zapewnienie niezawodności systemów informacyjnych na różnych etapach CI/CD Pipeline. W tym artykule chciałbym opowiedzieć o swoim doświadczeniu w automatyzacji kontroli jakości oprogramowania i realizacji możliwych scenariuszy jego „samosanacji”.
Pracuję jako inżynier w dziale zarządzania usługami IT w firmie . Moją specjalnością jest wdrażanie różnych systemów monitorowania wydajności i dostępności aplikacji. Często rozmawiam z zamawiającymi z różnych segmentów rynku na temat aktualnych zagadnień związanych z monitorowaniem jakości ich usług IT. Głównym celem jest minimalizacja czasu cyklu wydania i zwiększenie częstotliwości ich wydawania. To oczywiście wszystko brzmi dobrze: więcej wydań – więcej nowych funkcji – więcej zadowolonych użytkowników – więcej zysków. Ale w rzeczywistości nie zawsze tak to wygląda. Przy bardzo wysokim tempie wdrożeń pojawia się pytanie o jakość naszych wydań. Nawet przy całkowicie zautomatyzowanym pipeline jednym z największych problemów jest przejście usług z testów do produkcji, które nie wpływa na czas niezawodnej pracy i interakcję użytkowników z aplikacją.
Po wielu rozmowach z zamawiającymi mogę powiedzieć, że kontrola jakości wydań, problem niezawodności aplikacji i możliwość jej „samosanacji” (np. powrót do stabilnej wersji) na różnych etapach pipeline CI/CD są jednymi z najbardziej interesujących i aktualnych tematów.
Ostatnio sam pracowałem po stronie zamawiającego – w departamencie utrzymania oprogramowania aplikacyjnego banku online. W architekturze naszej aplikacji użyto dużej liczby własnych mikroserwisów. Najsmutniejsze jest to, że nie wszyscy programiści radzili sobie z wysokim tempem rozwoju, jakość niektórych mikroserwisów cierpiała, co rodziło śmieszne przydomki dla nich i ich twórców. Pojawiały się legendy o tym, z jakich materiałów te produkty są wytwarzane.
„Postawienie zadania”
Wysoka częstotliwość wydań i duża liczba mikroserwisów wprowadza trudności w zrozumieniu działania aplikacji jako całości, zarówno na etapie testowania, jak i eksploatacji. Zmiany zachodzą nieustannie i kontrolowanie ich bez dobrych narzędzi monitorujących jest bardzo trudne. Często po nocnym wydaniu rano programiści siedzą jak na beczce prochu i czekają, aby nic się nie zepsuło, choć na etapie testowania wszystkie kontrole były udane.
Jest jeszcze jeden aspekt. Na etapie testowania sprawdzana jest funkcjonalność oprogramowania: wykonywanie podstawowych funkcji aplikacji i brak błędów. Oceny jakości wydajności są często niedostateczne lub nie uwzględniają wszystkich aspektów działania aplikacji oraz warstwy integracyjnej. Niektóre metryki mogą nie być w ogóle sprawdzane. W efekcie, w przypadku awarii w środowisku produkcyjnym, dział wsparcia technicznego dowiaduje się o tym dopiero, gdy rzeczywiści użytkownicy zaczynają zgłaszać problemy. Chcemy zminimalizować wpływ niskiej jakości oprogramowania na końcowych użytkowników.
Jednym z rozwiązań jest wprowadzenie procesów weryfikacji jakości oprogramowania na różnych etapach CI/CD Pipeline, dodawanie różnych scenariuszy odzyskiwania systemu w przypadku awarii. Pamiętajmy także, że mamy DevOps. Biznes oczekuje jak najszybszego uzyskania nowego produktu. Dlatego wszystkie nasze kontrole i scenariusze muszą być zautomatyzowane.
Zadanie dzieli się na dwie części:
- kontrola jakości buildów na etapie testowania (zautomatyzowanie procesu wykrywania wadliwych buildów);
- kontrola jakości oprogramowania w środowisku produkcyjnym (mechanizmy automatycznego wykrywania problemów oraz potencjalne scenariusze ich samoodtwarzania).
Narzędzie do monitorowania i zbierania metryk
Aby zrealizować postawione zadania, potrzebny jest system monitorowania, zdolny do wykrywania problemów i przekazywania ich do systemów automatyzacji na różnych etapach konwejera CI/CD. Ponadto korzystne będzie, jeśli ten system dostarczy użyteczne metryki dla różnych zespołów: rozwoju, testowania, eksploatacji. A jeszcze lepiej, jeśli także dla biznesu.
Aby zbierać metryki, można wykorzystać różnorodne systemy (Prometheus, ELK Stack, Zabbix itp.), ale moim zdaniem rozwiązania klasy APM najlepiej nadają się do takich zadań (), które mogą znacznie ułatwić życie.
W ramach mojej pracy w serwisie wsparcia rozpocząłem podobny projekt, korzystając z rozwiązania klasy APM firmy Dynatrace. Obecnie, pracując w integratorze, dobrze znam rynek systemów monitorowania. Moim subiektywnym zdaniem: Dynatrace najlepiej nadaje się do rozwiązywania takich problemów.
Rozwiązanie Dynatrace zapewnia poziome odwzorowanie każdej operacji użytkownika z głębokim poziomem szczegółowości aż do poziomu wykonania kodu. Można śledzić całą chainę interakcji między różnymi usługami informacyjnymi: od poziomów frontendowych aplikacji webowych i mobilnych, przez serwery aplikacji backendowych, po szynę integracyjną aż do konkretnego wywołania w bazie danych.
. Automatyczne budowanie wszystkich zależności między komponentami systemu
. Automatyczne definiowanie i budowanie ścieżki przejścia operacji serwisu
Pamiętajmy również, że musimy zintegrować się z różnymi narzędziami do automatyzacji. Rozwiązanie to ma wygodne API, które pozwala na przesyłanie i odbieranie różnych metryk oraz zdarzeń.
Przejdźmy teraz do bardziej szczegółowego omówienia, jak rozwiązywać postawione zadania z pomocą systemu Dynatrace.
Zadanie 1. Automatyzacja kontroli jakości buildów na etapie testowania
Pierwszym zadaniem jest jak najwcześniejsze wykrycie problemów na etapie dostarczania aplikacji. Tylko „dobre” buildy kodu powinny trafiać do środowiska produkcyjnego. Dlatego w Twoim pipeline na etapie testowania muszą być uwzględnione dodatkowe monitory do sprawdzania jakości twoich serwisów.
Rozważmy krok po kroku, jak zrealizować i zautomatyzować ten proces:
Na rysunku przedstawiono strumień zautomatyzowanych kroków weryfikacji jakości oprogramowania:
- wdrożenie systemu monitorowania (instalacja agentów);
- określenie zdarzeń oceny jakości twojego oprogramowania (metryki i wartości progowe) oraz przekazywanie ich do systemu monitorowania;
- generowanie obciążenia i testów wydajności;
- zbieranie danych o wydajności i dostępności w systemie monitorowania;
- przesyłanie danych o testach opartych na zdarzeniach oceny jakości oprogramowania z systemu monitorowania do systemu CI/CD. Automatyczna analiza kompilacji.
Krok 1. Wdrażanie systemu monitorowania
Na początku należy zainstalować agentów w swoim środowisku testowym. Rozwiązanie Dynatrace ma tę przyjemną cechę – używa uniwersalnego agenta OneAgent, który jest instalowany na instancji OS (Windows, Linux, AIX), automatycznie wykrywa Twoje usługi i zaczyna zbierać dane monitorujące na ich temat. Nie musisz osobno konfigurować agenta dla każdego procesu. Podobna sytuacja dotyczy platform chmurowych i kontenerowych. Przy tym proces instalacji agentów można również zautomatyzować. Dynatrace doskonale wpisuje się w koncepcję „infrastruktura jako kod” (): są już gotowe skrypty i instrukcje dla wszystkich popularnych platform. Wbudowujesz agenta w konfigurację swojej usługi, a przy jej wdrożeniu od razu otrzymujesz nową usługę z już działającym agentem.
Krok 2. Określenie zdarzeń oceny jakości Twojego oprogramowania
Teraz należy określić listę usług i operacji biznesowych. Ważne jest, aby uwzględnić te operacje użytkowników, które są krytyczne biznesowo dla Twojej usługi. Zalecam skonsultowanie się z analitykami biznesowymi i systemowymi.
Następnie należy określić, jakie metryki chcesz uwzględnić w weryfikacji dla każdego z poziomów. Na przykład mogą to być czasy realizacji (z podziałem na średnią, medianę, percentyle itp.), błędy (logiczne, serwisowe, infrastrukturalne itp.) oraz różne metryki infrastrukturalne (memory heap, garbage collector, thread count itp.).
W celu automatyzacji i ułatwienia użycia przez zespół DevOps pojawia się koncepcja „Monitoring jako kod”. Co przez to rozumiem – programista/tester może napisać prosty plik JSON, który określa wskaźniki weryfikacji jakości oprogramowania.
Przyjrzyjmy się przykładzie takiego pliku JSON. Jako pary klucz/wartość wykorzystuje się obiekty z API Dynatrace (opis API można sprawdzić tutaj ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}Plik jest tablicą definicji szeregów czasowych (timeseries):
- timeseriesId – monitorowana metryka, na przykład czas odpowiedzi, liczba błędów, zużycie pamięci itp.;
- aggregation — poziom agregacji metryk, w naszym przypadku avg, ale możesz użyć dowolnego, który Ci odpowiada (avg, min, max, sum, count, percentile);
- tags – tag obiektu w systemie monitorowania lub możesz podać konkretny identyfikator obiektu;
- severe i warning – te wskaźniki regulują progi naszych metryk, jeśli wartość testów przekracza próg severe, nasza kompilacja jest oznaczana jako nieudana.
Na następnym rysunku przedstawiono przykład zastosowania takich progów.
Krok 3. Generowanie obciążenia
Po określeniu poziomów jakości naszego serwisu, konieczne jest wygenerowanie testowego obciążenia. Możesz wykorzystać dowolne narzędzia do testowania, które Ci odpowiadają, na przykład Jmeter, Selenium, Neotys, Gatling itp.
System monitorowania Dynatrace pozwala na przechwytywanie różnych metadanych z Twoich testów i rozpoznawanie, który test należy do jakiej pętli wydania i jakiego serwisu. Zaleca się dodawanie dodatkowych nagłówków do zapytań HTTP testu.
Na następnym rysunku przedstawiono przykład, w którym za pomocą dodatkowego nagłówka X-Dynatrace-Test oznaczamy, że ten test dotyczy operacji dodawania produktu do koszyka.
Podczas uruchamiania każdego testu obciążeniowego wysyłasz dodatkowe informacje kontekstowe do Dynatrace za pomocą API zdarzeń z serwera CI/CD. Dzięki temu system może rozróżniać różne testy między sobą.
. Zdarzenie w systemie monitorowania o rozpoczęciu testu obciążeniowego
Krok 4-5. Zbieranie danych o wydajności i przekazywanie danych do systemu CI/CD
Wraz z generowanym testem do systemu monitorowania przesyłane jest zdarzenie o konieczności zbierania danych dotyczących wskaźników jakości serwisu. Określany jest również nasz plik JSON, w którym zdefiniowane są kluczowe metryki.
Wydarzenie dotyczące potrzeby weryfikacji jakości oprogramowania, tworzone na serwerze CI/CD w celu przesłania do systemu monitoringu
W naszym przykładzie wydarzenie związane z weryfikacją jakości nazywa się perfSigDynatraceReport (Performance_Signature) – jest gotowym do integracji z Jenkins, który został opracowany przez zespół T-Systems Multimedia Solutions. W każdym wydarzeniu związanym z uruchomieniem weryfikacji zawarte są informacje o usłudze, numerze kompilacji oraz czasie testowania. Wtyczka zbiera wartości wydajności podczas kompilacji, ocenia je i porównuje wyniki z poprzednimi kompilacjami oraz wymaganiami niefunkcjonalnymi.
Wydarzenie w systemie monitoringu dotyczące rozpoczęcia weryfikacji jakości kompilacji.
Po zakończeniu testu wszystkie metryki oceny jakości oprogramowania są przesyłane z powrotem do systemu ciągłej integracji, na przykład Jenkins, który generuje raport na podstawie wyników.
Wynik statystyk dotyczących kompilacji na serwerze CI/CD.
Dla każdej pojedynczej kompilacji widzimy statystyki dla każdej z ustalonych przez nas metryk w trakcie całego testu. Zobaczymy również, czy wystąpiły naruszenia określonych wartości progowych (warning i severe-thresholds). Na podstawie zbiorczych wskaźników cała kompilacja jest oznaczana jako stabilna, niestabilna lub nieudana. Dla wygody można również dodać do raportu wskaźniki porównawcze aktualnej kompilacji z poprzednią.
Przegląd szczegółowych statystyk dotyczących kompilacji na serwerze CI/CD.
Szczegółowe porównanie dwóch kompilacji
W razie potrzeby można przejść do interfejsu Dynatrace i tam dokładniej przejrzeć statystyki dotyczące każdej z kompilacji i porównać je ze sobą.
Porównanie statystyk dotyczących kompilacji w Dynatrace.
Wnioski
W rezultacie otrzymujemy usługę „monitoring jako usługa”, zautomatyzowaną w procesie ciągłej integracji. Programista lub tester musi jedynie określić listę metryk w pliku JSON, a wszystko inne odbywa się automatycznie. Otrzymujemy przejrzystą kontrolę jakości wydań: wszystkie powiadomienia dotyczące wydajności, zużycia zasobów lub regresji architektonicznych.
Zadanie 2. Automatyzacja kontroli jakości oprogramowania w środowisku produkcyjnym
Tak więc rozwiązaliśmy problem, jak zautomatyzować proces monitoringu na etapie testowania w Pipeline. W ten sposób minimalizujemy procent niskiej jakości kompilacji, które trafiają do środowiska produkcyjnego.
Co zrobić, jeśli złośliwe oprogramowanie jednak trafi do produkcji, lub po prostu coś zawiedzie? Marzyliśmy o tym, aby istniały mechanizmy automatycznego wykrywania problemów oraz system, który w miarę możliwości samodzielnie przywracałby swoją funkcjonalność, przynajmniej w nocy.
W związku z tym musimy, wzorując się na poprzedniej sekcji, przewidzieć automatyczne kontrole jakości oprogramowania w środowisku produkcyjnym oraz opracować scenariusze automatycznego przywracania systemu.
Auto-korekcja jako kod
W większości firm już istnieje obszerną baza wiedzy na temat różnych typów powszechnych problemów oraz lista działań naprawczych, takich jak ponowne uruchamianie procesów, oczyszczanie zasobów, przywracanie wersji, przywracanie nieprawidłowych zmian w konfiguracji, zwiększenie lub zmniejszenie liczby komponentów w klastrze, przełączanie na niebieską lub zieloną trasę itd.
Mimo że te przypadki użycia są znane od lat wielu zespołom, z którymi się kontaktuję, tylko nieliczni zastanawiali się nad ich automatyzacją i zainwestowali środki w ten proces.
Rozważając, w realizacji procesów samonaprawy aplikacji nie ma nic nadzwyczajnego; wystarczy przekształcić znane scenariusze działań administratorów w scenariusze kodu (koncepcja „auto-korekcja jako kod”), które wcześniej napisaliście na potrzeby każdej konkretnej sytuacji. Scenariusze automatycznego naprawiania powinny być ukierunkowane na usunięcie przyczyny problemu. To wy ustalacie właściwe działania reagowania na incydent.
Jako wyzwalacz do uruchomienia scenariusza może służyć dowolna metryka z waszego systemu monitorowania, ważne jest, aby te metryki dokładnie określały, że coś jest nie tak, aby uniknąć fałszywych alarmów w środowisku produkcyjnym.
Możecie korzystać z dowolnego systemu lub zestawu systemów: Prometheus, ELK Stack, Zabbix itd. Jednak zamierzam podać kilka przykładów w oparciu o rozwiązanie APM (znów użyję Dynatrace jako przykład), które również pomoże ułatwić wam życie.
Przede wszystkim, to narzędzie oferuje wszystko, co dotyczy funkcjonalności z perspektywy działania aplikacji. Rozwiązanie dostarcza setki metryk na różnych poziomach, które możecie użyć jako wyzwalacze:
- poziom użytkowników (przeglądarki, aplikacje mobilne, urządzenia IoT, zachowanie użytkowników, konwersja itd.);
- poziom usług i operacji (wydajność, dostępność, błędy itd.);
- poziom infrastruktury aplikacji (metryki OS gospodarza, JMX, MQ, serwer www itd.);
- poziom platform (wirtualizacja, chmura, kontenery itd.).
Poziomy monitorowania w Dynatrace.
Po drugie, jak już wcześniej wspomniałem, Dynatrace ma otwarte API, które umożliwia wygodną integrację z różnymi systemami zewnętrznymi. Na przykład, wysyłanie powiadomień do systemu automatyzacji przy przekroczeniu kontrolnych parametrów.
Poniżej przedstawiono przykład integracji z Ansible.
Oto kilka przykładów automatyzacji, jakie można zrealizować. To tylko część przypadków, ich lista w Twoim środowisku może być ograniczona jedynie Twoją wyobraźnią i możliwościami narzędzi monitorowania.
1. Zły deploy – przywrócenie wersji
Nawet jeśli wszystko dokładnie sprawdzamy w środowisku testowym, zawsze istnieje ryzyko, że nowa wersja może zniszczyć Twoją aplikację w środowisku produkcyjnym. Czynnik ludzki pozostaje bez zmian.
Na następnym rysunku widzimy, że następuje nagły wzrost czasu wykonywania operacji w usłudze. Początek tego wzrostu zbiegł się z czasem wdrożenia aplikacji. Całą tę informację jako zdarzenia przesyłamy do systemu automatyzacji. Jeśli dostępność usługi nie zostanie przywrócona po upływie ustalonego przez nas czasu, automatycznie wywoływany jest skrypt, który przywraca wersję do poprzedniej.
Degradacja wydajności operacji po wdrożeniu.
2. Obciążenie zasobów na poziomie 100% – dodanie węzła do routingu
W następnym przykładzie system monitorowania identyfikuje, że na jednym z komponentów obciążenie CPU wynosi 100%.
Obciążenie CPU 100%
W związku z tym zdarzeniem istnieje kilka różnych scenariuszy. Na przykład, system monitorowania dodatkowo sprawdza, czy brak zasobów jest związany ze wzrostem obciążenia usługi. Jeśli tak, to wykonywany jest skrypt, który automatycznie dodaje węzeł do routingu, przywracając tym samym ogólną funkcjonalność systemu.
Skalowanie po incydencie
3. Brak miejsca na dysku twardym – czyszczenie dysku
Myślę, że te procesy są już automatyzowane przez wielu. Dzięki APM można również monitorować wolne miejsce na systemie dyskowym. W przypadku braku miejsca lub wolnej pracy dysku wywołujemy skrypt do czyszczenia lub dodajemy miejsce.
Obciążenie dysku 100%
4. Niska aktywność użytkowników lub niska konwersja – przełączanie między niebieską a zieloną gałęzią
Często spotykam klientów korzystających z dwóch konturów (blue-green deploy) dla aplikacji w środowisku produkcyjnym. Pozwala to szybko przełączać się między gałęziami podczas dostarczania nowych wydań. Często po wdrożeniu mogą wystąpić kardynalne zmiany, które nie są od razu zauważalne. Przy tym degradacja wydajności i dostępności może być niezauważalna. Aby szybko reagować na takie zmiany, lepiej jest korzystać z różnych metryk, które odzwierciedlają zachowania użytkowników (liczba sesji i działań użytkowników, konwersja, wskaźnik odrzuceń). Na następnym rysunku pokazano przykład, w którym przy spadku konwersji następuje przełączenie między gałęziami oprogramowania.
Spadek konwersji po przełączeniu między gałęziami oprogramowania.
Mechanizmy automatycznego wykrywania problemów
Na koniec podam jeszcze jeden przykład, za co najbardziej lubię Dynatrace.
W części mojej opowieści o automatyzacji weryfikacji jakości buildów w środowisku testowym wszystkie progi ustalaliśmy ręcznie. Dla środowiska testowego jest to normalne, tester sam określa wskaźniki przed każdą weryfikacją w zależności od obciążenia. W środowisku produkcyjnym pożądane jest, aby problemy były wykrywane automatycznie, biorąc pod uwagę różne mechanizmy baseline.
Dynatrace ma interesujące wbudowane narzędzia sztucznej inteligencji, które na podstawie mechanizmów wykrywania anomalii w metrykach (baselining) oraz budowania mapy interakcji między wszystkimi komponentami, porównując i korelując zdarzenia ze sobą, identyfikują anomalie w działaniu Twojej usługi i dostarczają szczegółowe informacje o każdym problemie oraz jego przyczynie.
Dzięki automatycznej analizie zależności między komponentami, Dynatrace określa nie tylko to, czy problematyczna usługa jest główną przyczyną, ale również jej zależności od innych usług. W zamieszczonym poniżej przykładzie Dynatrace automatycznie śledzi i ocenia wydajność każdej usługi w ramach realizacji transakcji, identyfikując usługę Golang jako główną przyczynę.
Przykład identyfikacji przyczyny awarii.
Na następnym rysunku przedstawiono proces monitorowania problemów z Twoją aplikacją od momentu wystąpienia incydentu.
Wizualizacja pojawiającego się problemu z wyświetleniem wszystkich komponentów i zdarzeń w ich ramach.
System monitorowania zebrał pełną chronologię zdarzeń dotyczących wystąpienia problemu. W oknie pod wykresem czasowym widzimy wszystkie kluczowe zdarzenia na każdym z komponentów. Na podstawie tych zdarzeń możesz ustalić procedury automatycznego naprawiania w postaci skryptów kodu.
Dodatkowo polecam zintegrować system monitorowania z Service Desk lub systemem zgłaszania błędów. W przypadku wystąpienia problemu, programiści szybko otrzymują pełne informacje do analizy na poziomie kodu w środowisku produkcyjnym.
Podsumowanie
W rezultacie otrzymaliśmy pipeline CI/CD z wbudowanymi zautomatyzowanymi kontrolami jakości oprogramowania w Pipeline. Minimalizujemy liczbę wadliwych kompilacji, zwiększamy niezawodność systemu jako całości, a jeśli mimo to wydajność systemu zostaje zakłócona, uruchamiamy mechanizmy jego przywracania.
W automatyzację monitorowania jakości oprogramowania naprawdę warto inwestować, nie zawsze jest to szybki proces, ale z czasem przyniesie owoce. Polecam po rozwiązaniu nowego incydentu w środowisku produkcyjnym natychmiast pomyśleć o dodaniu monitorów do kontroli w środowisku testowym, aby uniknąć wprowadzenia złej kompilacji do produkcji, a także przygotować skrypt do automatycznego naprawiania tych problemów.
Mam nadzieję, że moje przykłady pomogą Ci w Twoich przedsięwzięciach. Ciekawi mnie również zobaczyć Twoje przykłady używanych metryk do realizacji samonaprawy systemów.
Źródło: habr.com
