Teraz temat DevOps jest modny. Ciągła integracja i potok dostaw wszyscy to realizują. Jednak większość nie zawsze przykłada należytą uwagę do zapewnienia niezawodności systemów informatycznych na różnych etapach rurociągu CI/CD. W tym artykule chciałbym opowiedzieć o swoim doświadczeniu w automatyzacji kontroli jakości oprogramowania i wdrażaniu możliwych scenariuszy jego „samonaprawy”.
Pracuję jako inżynier w dziale zarządzania usługami IT firmy . Moją podstawową specjalizacją jest wdrażanie różnorodnych systemów monitorowania wydajności i dostępności aplikacji. Często komunikuję się z klientami IT z różnych segmentów rynku w zakresie bieżących zagadnień związanych z monitorowaniem jakości ich usług IT. Głównym celem jest zminimalizowanie czasu cyklu wydawniczego i zwiększenie częstotliwości wydań. To oczywiście wszystko dobrze: więcej wydań - więcej nowych funkcji - więcej zadowolonych użytkowników - więcej zysków. Ale w rzeczywistości nie zawsze wszystko układa się dobrze. Przy bardzo wysokim wskaźniku wdrożeń od razu pojawia się pytanie o jakość naszych wydań. Nawet w przypadku w pełni zautomatyzowanego potoku jednym z największych wyzwań jest przeniesienie usług z testowania do produkcji bez wpływu na czas pracy aplikacji i wygodę użytkownika.
Na podstawie wyników licznych rozmów z klientami mogę stwierdzić, że dopuszczono kontrolę jakości, problem niezawodności aplikacji i możliwości jej „samonaprawy” (np. powrotu do wersji stabilnej) na różnych etapach CI /CD rurociąg to jedne z najbardziej ekscytujących i istotnych tematów.
Ostatnio sam pracowałem po stronie klienta - w serwisie wsparcia oprogramowania aplikacji bankowości internetowej. Architektura naszej aplikacji wykorzystywała dużą liczbę samodzielnie napisanych mikroserwisów. Najsmutniejsze jest to, że nie wszyscy programiści byli w stanie poradzić sobie z wysokim tempem rozwoju, ucierpiała na tym jakość niektórych mikroserwisów, przez co nadano im i ich twórcom zabawne przezwiska. Krążyły opowieści o tym, z jakich materiałów wykonano te produkty.
„Sformułowanie problemu”
Wysoka częstotliwość wydań i duża liczba mikroserwisów sprawiają, że trudno jest zrozumieć działanie aplikacji jako całości, zarówno na etapie testowania, jak i na etapie operacyjnym. Zmiany następują nieustannie i bardzo trudno jest je kontrolować bez dobrych narzędzi monitorujących. Często po nocnej premierze z rana programiści siedzą jak na beczce z prochem i czekają, aż nic się nie stłucze, choć na etapie testów wszystkie kontrole wypadły pomyślnie.
Jest jeszcze jeden punkt. Na etapie testów sprawdzana jest funkcjonalność oprogramowania: realizacja głównych funkcji aplikacji oraz brak błędów. Brakuje jakościowych ocen wydajności lub nie uwzględniają one wszystkich aspektów aplikacji i warstwy integracyjnej. Niektóre wskaźniki mogą w ogóle nie zostać sprawdzone. Dzięki temu, gdy w środowisku produkcyjnym wystąpi awaria, dział wsparcia technicznego dowiaduje się o tym dopiero wtedy, gdy prawdziwi użytkownicy zaczną narzekać. Chciałbym zminimalizować wpływ oprogramowania niskiej jakości na użytkowników końcowych.
Jednym z rozwiązań jest wdrożenie procesów sprawdzających jakość oprogramowania na różnych etapach CI/CD Pipeline oraz dodanie różnych scenariuszy przywracania systemu w przypadku awarii. Pamiętamy też, że mamy DevOps. Firmy oczekują otrzymania nowego produktu tak szybko, jak to możliwe. Dlatego wszystkie nasze kontrole i skrypty muszą być zautomatyzowane.
Zadanie podzielone jest na dwa komponenty:
- kontrola jakości złożeń na etapie testów (w celu zautomatyzowania procesu wychwytywania złożeń o niskiej jakości);
- kontrola jakości oprogramowania w środowisku produkcyjnym (mechanizmy automatycznego wykrywania problemów i możliwych scenariuszy ich samonaprawy).
Narzędzie do monitorowania i zbierania metryk
Aby osiągnąć założone cele, niezbędny jest system monitorowania, który będzie w stanie wykryć problemy i przenieść je do systemów automatyki na różnych etapach rurociągu CI/CD. Pozytywem będzie również to, że system ten będzie dostarczał przydatnych wskaźników dla różnych zespołów: rozwoju, testowania, działania. I jest to absolutnie cudowne, jeśli jest to również biznesowe.
Do zbierania metryk można wykorzystać zestaw różnych systemów (Prometheus, ELK Stack, Zabbix itp.), jednak moim zdaniem do tych zadań najlepiej nadają się rozwiązania klasy APM (), co może znacznie ułatwić Ci życie.
W ramach pracy w serwisie wsparcia rozpocząłem realizację podobnego projektu z wykorzystaniem rozwiązania klasy APM firmy Dynatrace. Teraz pracując dla integratora dość dobrze znam rynek systemów monitoringu. Moja subiektywna opinia: Dynatrace najlepiej nadaje się do rozwiązywania takich problemów.
Dynatrace zapewnia poziomy widok każdej operacji użytkownika na poziomie szczegółowym aż do poziomu wykonania kodu. Można prześledzić cały łańcuch interakcji pomiędzy różnymi usługami informacyjnymi: od poziomu front-end aplikacji webowych i mobilnych, serwerów aplikacji back-end, szyny integracyjnej aż po konkretne wywołanie do bazy danych.
. Automatyczna konstrukcja wszystkich zależności pomiędzy komponentami systemu
. Automatyczne wykrywanie i budowa ścieżki działania usługi
Pamiętamy też, że musimy integrować się z różnymi narzędziami automatyzującymi. Tutaj rozwiązanie posiada wygodne API, które umożliwia wysyłanie i odbieranie różnych metryk i zdarzeń.
Następnie przejdźmy do bardziej szczegółowego spojrzenia na to, jak rozwiązać te problemy za pomocą systemu Dynatrace.
Zadanie 1. Automatyzacja kontroli jakości złożeń na etapie testów
Pierwszym wyzwaniem jest znalezienie problemów na jak najwcześniejszym etapie procesu dostarczania aplikacji. Tylko „dobre” kompilacje kodu powinny trafić do produkcji. Aby to osiągnąć, Twój rurociąg na etapie testów powinien zostać wyposażony w dodatkowe monitory sprawdzające jakość Twoich usług.
Przyjrzyjmy się krok po kroku, jak to wdrożyć i zautomatyzować ten proces:
Rysunek przedstawia przebieg etapów zautomatyzowanego testowania jakości oprogramowania:
- wdrożenie systemu monitoringu (instalacja agentów);
- identyfikacja zdarzeń w celu oceny jakości Twojego oprogramowania (metryki i wartości progowe) i przekazanie ich do systemu monitorowania;
- generowanie testów obciążeniowych i wydajnościowych;
- zbieranie danych o wydajności i dostępności w systemie monitorowania;
- transfer danych testowych na podstawie zdarzeń oceny jakości oprogramowania z systemu monitorowania do systemu CI/CD. Automatyczna analiza złożeń.
Krok 1. Wdrożenie systemu monitorowania
Najpierw musisz zainstalować agenty w środowisku testowym. Jednocześnie rozwiązanie Dynatrace ma ciekawą funkcję - wykorzystuje uniwersalnego agenta OneAgent, który jest instalowany na instancji systemu operacyjnego (Windows, Linux, AIX), automatycznie wykrywa Twoje usługi i zaczyna zbierać o nich dane monitorujące. Nie ma potrzeby konfigurowania oddzielnego agenta dla każdego procesu. Podobnie będzie w przypadku platform chmurowych i kontenerowych. Jednocześnie możesz także zautomatyzować proces instalacji agenta. Dynatrace doskonale wpisuje się w koncepcję „infrastruktury jako kodu” (): Istnieją gotowe skrypty i instrukcje dla wszystkich popularnych platform. Osadzasz agenta w konfiguracji swojej usługi, a po jego wdrożeniu od razu otrzymujesz nową usługę z już działającym agentem.
Krok 2: Zdefiniuj zdarzenia związane z jakością oprogramowania
Teraz musisz zdecydować o liście usług i operacji biznesowych. Ważne jest, aby wziąć pod uwagę dokładnie te działania użytkowników, które są krytyczne biznesowo dla Twojej usługi. Tutaj polecam konsultacje z analitykami biznesowymi i systemowymi.
Następnie musisz określić, które wskaźniki chcesz uwzględnić w recenzji dla każdego poziomu. Może to być na przykład czas wykonania (podzielony na średni, medianę, percentyle itp.), błędy (logiczne, usługi, infrastruktura itp.) i różne metryki infrastruktury (sterta pamięci, moduł zbierający elementy bezużyteczne, liczba wątków itp.).
Dla automatyzacji i łatwości obsługi przez zespół DevOps pojawia się koncepcja „Monitoringu jako kodu”. Mam przez to na myśli to, że programista/tester może napisać prosty plik JSON, który definiuje metryki zapewnienia jakości oprogramowania.
Spójrzmy na przykład takiego pliku JSON. Obiekty z API Dynatrace wykorzystywane są jako pary klucz/wartość (opis API znajdziesz 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:
- timeseriesId – sprawdzana metryka, np. czas odpowiedzi, liczba błędów, wykorzystana pamięć itp.;
- agregacja - poziom agregacji metryk, w naszym przypadku avg, ale możesz użyć dowolnego, jakiego potrzebujesz (avg, min, max, sum, count, percentyl);
- tagi – znacznik obiektu w systemie monitorowania lub możesz podać konkretny identyfikator obiektu;
- poważny i ostrzegawczy – te wskaźniki regulują wartości progowe naszych metryk; jeśli wartość testowa przekroczy próg poważny, wówczas nasza kompilacja zostanie oznaczona jako nieudana.
Poniższy rysunek przedstawia przykład zastosowania takich progów.
Krok 3: Generowanie obciążenia
Kiedy już określimy poziom jakości naszej usługi, musimy wygenerować obciążenie testowe. Możesz użyć dowolnego narzędzia testowego, z którym czujesz się komfortowo, takiego jak Jmeter, Selenium, Neotys, Gatling itp.
System monitorowania Dynatrace umożliwia przechwytywanie różnych metadanych z testów i rozpoznawanie, które testy należą do jakiego cyklu wydawniczego i jakiej usługi. Zalecane jest dodanie dodatkowych nagłówków do żądań testowych HTTP.
Poniższy rysunek przedstawia przykład, w którym korzystając z dodatkowego nagłówka X-Dynatrace-Test wskazujemy, że test ten dotyczy sprawdzenia działania dodania towaru do koszyka.
Po uruchomieniu każdego testu obciążenia wysyłasz dodatkowe informacje kontekstowe do Dynatrace za pomocą interfejsu API zdarzeń z serwera CI/CD. W ten sposób system może rozróżniać różne testy.
. Zdarzenie w systemie monitorującym o rozpoczęciu testów obciążeniowych
Krok 4-5. Zbieraj dane dotyczące wydajności i przesyłaj je do systemu CI/CD
Wraz z wygenerowanym testem do systemu monitoringu przekazywane jest zdarzenie o konieczności zebrania danych na temat sprawdzania wskaźników jakości usług. Określa także nasz plik JSON, który definiuje kluczowe metryki.
Zdarzenie o konieczności sprawdzenia jakości oprogramowania wygenerowanego na serwerze CI/CD w celu przesłania go do systemu monitorującego
W naszym przykładzie wywoływane jest zdarzenie kontroli jakości raport perfSigDynatrace (Wydajność_sygnatury) - to jest gotowe do integracji z Jenkinsem, który został opracowany przez chłopaków z T-Systems Multimedia Solutions. Każde zdarzenie uruchomienia testu zawiera informacje o usłudze, numerze kompilacji i czasie testowania. Wtyczka zbiera wartości wydajności w czasie kompilacji, ocenia je i porównuje wynik z poprzednimi kompilacjami i wymaganiami niefunkcjonalnymi.
Zdarzenie w systemie monitorowania dotyczące rozpoczęcia kontroli jakości kompilacji.
Po zakończeniu testu wszystkie metryki służące do oceny jakości oprogramowania są przenoszone z powrotem do systemu ciągłej integracji, np. Jenkins, który generuje raport z wyników.
Wynik statystyk złożeń na serwerze CI/CD.
Dla każdej indywidualnej kompilacji widzimy statystyki dla każdego wskaźnika, który ustawiliśmy podczas całego testu. Widzimy również, czy wystąpiły naruszenia określonych wartości progowych (ostrzeżenie i poważne Thrashhold). Na podstawie zagregowanych wskaźników cała kompilacja jest oznaczana jako stabilna, niestabilna lub nieudana. Dla wygody możesz także dodać do raportu wskaźniki porównujące obecną kompilację z poprzednią.
Wyświetl szczegółowe statystyki dotyczące zestawów na serwerze CI/CD.
Szczegółowe porównanie dwóch zespołów
Jeśli zajdzie taka potrzeba, możesz przejść do interfejsu Dynatrace i tam możesz wyświetlić bardziej szczegółowo statystyki każdego ze swoich buildów i porównać je ze sobą.
Porównanie statystyk kompilacji w Dynatrace.
odkrycia
W rezultacie otrzymujemy usługę „monitoringu jako usługi”, zautomatyzowaną w procesie ciągłej integracji. Programista lub tester musi jedynie zdefiniować listę metryk w pliku JSON, a cała reszta dzieje się automatycznie. Otrzymujemy przejrzystą kontrolę jakości wydań: wszystkie powiadomienia o wydajności, zużyciu zasobów czy regresjach architektonicznych.
Zadanie 2. Automatyzacja kontroli jakości oprogramowania w środowisku produkcyjnym
Rozwiązaliśmy więc problem automatyzacji procesu monitorowania na etapie testów w Pipeline. W ten sposób minimalizujemy odsetek podzespołów niskiej jakości, które trafiają do środowiska produkcyjnego.
Ale co zrobić, jeśli złe oprogramowanie zostanie sprzedane lub coś po prostu się zepsuje. W przypadku utopii chcieliśmy, aby mechanizmy automatycznie wykrywały problemy i, jeśli to możliwe, sam system przywracał swoją funkcjonalność, przynajmniej w nocy.
W tym celu należy, analogicznie do poprzedniego punktu, zapewnić automatyczne kontrole jakości oprogramowania w środowisku produkcyjnym i oprzeć je na scenariuszach samonaprawy systemu.
Autokorekta jako kod
Większość firm posiada już zgromadzoną bazę wiedzy na temat różnego rodzaju typowych problemów oraz listę działań pozwalających je naprawić, na przykład ponowne uruchomienie procesów, oczyszczenie zasobów, przywrócenie wersji, przywrócenie nieprawidłowych zmian w konfiguracji, zwiększenie lub zmniejszenie liczby komponentów w klaster, przełączanie niebieskiego lub zielonego konturu itp.
Chociaż wiele zespołów, z którymi rozmawiam, zna te przypadki użycia od lat, niewiele z nich pomyślało o ich automatyzacji lub zainwestowało w nie.
Jeśli się nad tym zastanowić, nie ma nic zbyt skomplikowanego we wdrażaniu procesów samonaprawy wydajności aplikacji, trzeba przedstawić znane już scenariusze pracy administratorów w formie skryptów kodu (koncepcja „auto-fix as code”) , które napisałeś wcześniej dla każdego konkretnego przypadku. Skrypty automatycznej naprawy powinny mieć na celu wyeliminowanie pierwotnej przyczyny problemu. Sam określasz właściwe działania w odpowiedzi na incydent.
Dowolna metryka z Twojego systemu monitorowania może działać jako wyzwalacz do uruchomienia skryptu. Najważniejsze jest to, że te metryki dokładnie określają, że wszystko jest źle, ponieważ nie chciałbyś otrzymywać fałszywych alarmów w produktywnym środowisku.
Możesz użyć dowolnego systemu lub zestawu systemów: Prometheus, ELK Stack, Zabbix itp. Podam jednak kilka przykładów opartych na rozwiązaniu APM (znowu Dynatrace będzie przykładem), które również ułatwią Ci życie.
Po pierwsze, jest tam wszystko, co dotyczy wydajności, jeśli chodzi o działanie aplikacji. Rozwiązanie udostępnia setki wskaźników na różnych poziomach, które można wykorzystać jako wyzwalacze:
- poziom użytkownika (przeglądarki, aplikacje mobilne, urządzenia IoT, zachowania użytkowników, konwersja itp.);
- poziom usług i operacji (wydajność, dostępność, błędy itp.);
- poziom infrastruktury aplikacji (metryki systemu operacyjnego hosta, JMX, MQ, serwer WWW itp.);
- poziomie platformy (wirtualizacja, chmura, kontener itp.).
Monitorowanie poziomów w Dynatrace.
Po drugie, tak jak mówiłem wcześniej, Dynatrace posiada otwarte API, co bardzo ułatwia integrację z różnymi systemami firm trzecich. Np. wysłanie powiadomienia do systemu automatyki w przypadku przekroczenia parametrów kontrolnych.
Poniżej znajduje się przykład interakcji z Ansible.
Poniżej podam kilka przykładów jakiego rodzaju automatyzacji można dokonać. To tylko część przypadków, ich lista w Twoim otoczeniu może być ograniczona jedynie Twoją wyobraźnią i możliwościami Twoich narzędzi monitorujących.
1. Złe wdrożenie – wycofanie wersji
Nawet jeśli wszystko bardzo dobrze przetestujemy w środowisku testowym, nadal istnieje ryzyko, że nowa wersja może zabić Twoją aplikację w środowisku produkcyjnym. Ten sam czynnik ludzki nie został anulowany.
Na poniższym rysunku widzimy, że następuje gwałtowny skok czasu wykonywania operacji w serwisie. Początek tego skoku zbiega się z momentem wdrożenia do aplikacji. Wszystkie te informacje przekazujemy jako zdarzenia do systemu automatyki. Jeśli po ustalonym przez nas czasie działanie usługi nie wróci do normy, automatycznie zostanie wywołany skrypt, który przywróci wersję do starej.
Pogorszenie wydajności operacyjnej po wdrożeniu.
2. Ładowanie zasobów na 100% - dodaj węzeł do routingu
W poniższym przykładzie system monitorowania ustalił, że jeden ze składników doświadcza 100% obciążenia procesora.
Obciążenie procesora 100%
Możliwych jest kilka różnych scenariuszy tego wydarzenia. Przykładowo system monitoringu sprawdza dodatkowo, czy brak zasobów nie ma związku ze wzrostem obciążenia usługi. Jeśli tak, wykonywany jest skrypt, który automatycznie dodaje węzeł do routingu, przywracając w ten sposób funkcjonalność systemu jako całości.
Skalowanie po incydencie
3. Brak miejsca na dysku twardym - czyszczenie dysku
Myślę, że wiele osób zautomatyzowało już te procesy. Za pomocą APM można także monitorować ilość wolnego miejsca w podsystemie dyskowym. Jeśli nie ma miejsca lub dysk działa wolno, wywołujemy skrypt, który go wyczyści lub doda miejsce.
Obciążenie dysku 100%
4. Niska aktywność użytkowników lub niska konwersja - przełączanie pomiędzy oddziałami niebieskim i zielonym
Często widzę klientów korzystających z dwóch pętli (wdrożenie niebiesko-zielone) dla aplikacji w środowisku produkcyjnym. Dzięki temu możesz szybko przełączać się między oddziałami podczas dostarczania nowych wydań. Często po wdrożeniu mogą wystąpić dramatyczne zmiany, które nie są natychmiast zauważalne. W takim przypadku może nie zostać zaobserwowane pogorszenie wydajności i dostępności. Aby szybko reagować na takie zmiany, lepiej zastosować różne wskaźniki odzwierciedlające zachowania użytkowników (liczba sesji i działań użytkownika, konwersja, współczynnik odrzuceń). Poniższy rysunek przedstawia przykład, w którym w przypadku spadku współczynników konwersji następuje przełączanie pomiędzy gałęziami oprogramowania.
Współczynnik konwersji spada po przełączaniu się między gałęziami oprogramowania.
Mechanizmy automatycznego wykrywania problemów
Na koniec podam jeszcze jeden przykład, dlaczego najbardziej lubię Dynatrace.
W części mojej opowieści o automatyzacji kontroli jakości złożeń w środowisku testowym, wszystkie wartości progowe ustaliliśmy ręcznie. Jest to normalne w środowisku testowym, tester sam określa wskaźniki przed każdym testem w zależności od obciążenia. W środowisku produkcyjnym pożądane jest, aby problemy były wykrywane automatycznie, z uwzględnieniem różnych mechanizmów bazowych.
Dynatrace posiada ciekawe wbudowane narzędzia sztucznej inteligencji, które bazując na mechanizmach wyznaczania metryki anomalnej (baselineing) i budowaniu mapy interakcji pomiędzy wszystkimi komponentami, porównując i korelując ze sobą zdarzenia, wykrywają anomalie w działaniu Twojej usługi i dostarczają szczegółowych informacji informacje o każdym problemie i jego pierwotnej przyczynie.
Automatycznie analizując zależności między komponentami, Dynatrace określa nie tylko, czy przyczyną problemu jest problematyczna usługa, ale także jej zależność od innych usług. W poniższym przykładzie Dynatrace automatycznie monitoruje i ocenia kondycję każdej usługi w ramach realizacji transakcji, identyfikując usługę Golang jako główną przyczynę.
Przykład określenia pierwotnej przyczyny awarii.
Poniższy rysunek przedstawia proces monitorowania problemów z aplikacją od początku zdarzenia.
Wizualizacja pojawiającego się problemu z wyświetleniem wszystkich komponentów i zdarzeń na nich
System monitoringu zebrał pełną chronologię zdarzeń związanych z zaistniałym problemem. W oknie poniżej osi czasu widzimy wszystkie najważniejsze wydarzenia na każdym z komponentów. Na podstawie tych zdarzeń można ustawić procedury automatycznej korekty w postaci skryptów kodu.
Dodatkowo radzę zintegrować system monitoringu z Service Desk lub modułem śledzenia błędów. Gdy pojawia się problem, programiści szybko otrzymują pełną informację, aby móc go przeanalizować na poziomie kodu w środowisku produkcyjnym.
wniosek
W rezultacie otrzymaliśmy potok CI/CD z wbudowanymi automatycznymi kontrolami jakości oprogramowania w Pipeline. Minimalizujemy liczbę złożeń niskiej jakości, zwiększamy niezawodność całego systemu, a jeśli nasz system nadal zawiedzie, uruchamiamy mechanizmy umożliwiające jego przywrócenie.
Na pewno warto włożyć wysiłek w automatyzację monitorowania jakości oprogramowania – nie zawsze jest to proces szybki, ale z czasem przyniesie efekty. Zalecam, aby po rozwiązaniu nowego incydentu w środowisku produkcyjnym od razu zastanowić się, które monitory dodać do kontroli w środowisku testowym, aby uniknąć przedostania się złego buildu do produkcji, a także stworzyć skrypt, który automatycznie naprawi te problemy.
Mam nadzieję, że moje przykłady pomogą Ci w Twoich wysiłkach. Będę również zainteresowany zobaczeniem przykładów metryk wykorzystywanych do wdrażania systemów samoleczenia.
Źródło: www.habr.com