[Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring
•Télécharger en tant que PPSX, PDF•
0 j'aime•467 vues
Praca Inżyniera Jakości Oprogramowania kojarzy się głównie z testowaniem, jednak wraz z rozwojem produktu testy przestają wystarczać. Aby wyjść naprzeciw oczekiwaniom klientów i rozwiązywać ich problemy, należy zrobić krok naprzód – tak właśnie postąpił zespół Piotra. Aby na bieżąco tropić błędy w aplikacjach, wykorzystali podejście Continuous Monitoring. W czasie prelekcji Piotr przedstawił wyniki pracy zespołu Quality Assurance, który przeprowadza taki monitoring: co i w jaki sposób jest mierzone oraz jak wykorzystywane są zebrane dane. Pokazał też kilka krytycznych błędów, które udało się wykryć właśnie dzięki stałemu monitorowaniu serwisów.
Recommandé
Recommandé
Contenu connexe
Similaire à [Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring
Similaire à [Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring (20)
Plus de Future Processing
Plus de Future Processing (20)
[Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring
- 1. Gdy testy to za mało, Continuous Monitoring Quality Meetup, 2017 Piotr Marczydło
- 2. The Team
- 7. „Monitoring provides a good approximation of the health of a system” – SRE book@Google
- 8. Monitoring & Observability Kluczem do sukcesu jest to aby monitoringodpowiadał na pytania „Co” i „dlaczego”
- 9. Web Speed
- 10. Web Speed 1. Porównanie wersji (A/B Test) 2. Badanie trendu 3. Ciężar strony i liczba requestów 4. *Visual Complete i Progress
- 11. Real User Monitoring 1. Każdy użytkownik 2. Navigation Timing API
- 12. Real User Monitoring 1. Wersje OS 2. Przeglądarki 3. ISP 4. Prędkość łącza 5. Urządzenia mobilne
- 14. 14 Analityka 1. Google Analitics 2. Gemius - Ranking.pl 3. Logi
- 18. Performance 1. Front 2. API/Kolejek/DB 3. Workery 4. Lokalizacje 5. CDN?
- 19. Performance Platform 1. Liczba testów 2. Statusy 3. Obciążenie 4. Komponenty
- 20. „If a human operator needs to touch your system during normal operations, you have a bug.” ~Carla Geisser, Google SRE
- 22. Deployment & Ops
- 23. CI/CD enviroment & uptime 1. Dostępność SDK 2. Liczba VM 3. Czas Commit to Build 4. Czas Builda i status 5. Rozmiar kolejki 6. Dysk
- 24. AWS S3 = 99,95% uptime =~21,5min
- 27. Linki/Bibliografia: Monitoring and Observability https://medium.com/@copyconstruct/monitoring-and-observability-8417d1952e1c Google SRE book https://landing.google.com/sre/book/index.html AWS S3 sla https://aws.amazon.com/s3/sla/ WebPageTest https://github.com/WPO-Foundation AWS Status Page https://status.aws.amazon.com DevOps Automation Cookbook - Michael Duffy
Notes de l'éditeur
- Cześć nazywam się Piotr Marczydło i pracuję w Dreamlabie gdzie w pewnym momencie zdałem sobie sprawę, że testy czy to manualne czy automatyczne to za mało aby zachować najwyższą jakość. W kulturze DevOps i procesie ciągłej integracji wdrożenie nie sa eventem tylko codziennością Dlatego przez długi czas zastanawiałem się jak możemy wykorzystać nasze narzędzia, żeby lepiej poprawiać jakość. Na Quality Excites dużo mówiliśmy o TestOps, a monitoring jest tego częścią. Monitorować można wszystko np. czystość powietrza – tak jestem z krakowa
- Gdy ponad 3 lata temu przyszedłem do firmy testowaliśmy ręcznie i sporadycznie pisaliśmy testy selenium W 4 osoby nie było szansy zapewnić jakości w skali w której pracujemy. Dlatego aktualnie budujemy własne narzędzia, monitoring, raporty, frameworki testowe i zarządzamy procesem CI/CD
- Jeżeli w pewnym momencie będzie wam się wydawać, że tytuł prezentacji był clickbaitem to nie dlatego, że Dreamlab robi między innymi takie serwisy jak Fakt, Onet, nk i inne wchodzące w skład grupy onet-RAS Nigdy nie miałem głowy do nazw
- Poza polską w 5 krajach europy
- Jeżeli jeżeli mówimy o skali to: 23 miliony RU 150 mln PV dziennie Co przekłada się na 7 mln requestów na minutę 4.5 miliarda na dobę
- Za tym wszystkim stoją ludzie 40 zespołów w 3 biurach – w Krakowie, Wrocławiu i Warszawie Pracuje u nas Ponad 350 specjalistów Nasze zespoły przeprowadzają ponad 500 wdrożeń dziennie
- Wracając do monitoringu, ważne jest żeby zrozumieć, że monitoring nie zagwarantuje braku awarii, ale w dość dobrym przybliżeniu zobrazuje nam jaki jest status systemu. Da nam możliwość analizy długoterminowej takich jak rozrost DB czy PV Porównania np. po wdrożeniu nowej wersji czy liczba req spadła, czy może wzrósł czas ładowania strony Alerty gdy coś się może zepsuć albo już się zepsuło i ktoś powinien na to spojrzeć Pozwala zbudować dashboard który będzie odpowiadał na podstawowe pytania nt serwisu Osobiście jestem zwolennikiem 2 rodzajów dashboardów nazwijmy je codzienny i wdrożeniowy
- Do niedawna Monitoring był domeną Opsów czyli Administratorów. Jednak dlaczego nie spróbować tego w QA. Jak to powinno wyglądać Jednak samo monitorowanie to nie wszystko kluczem do sukcesu jest aby dostarczał odpowiedzi na pytania „Co” i „dlaczego” Dla przykładu taki monitoring 500 na stronie onet.pl nie mówi o niczym? Mamy tam powiedzmy 200 requestów per 1 pv i któryś z nich zwraca 500 dla 100mln pv dziennie – nie wiemy nic Co innego monitoring konkretnego api pod spodem. Pomogą nam w tym: Tracing requestów np. przy użyciu zipkina – który pozwoli nam zidentyfikować wadliwe requesty i ich ścieżkę w systemie Logi – customowe informacje dla dogłębnej analizy problemy Metryki per komponent Wizualizacja czyli wspomniane dashboardy które zobrazują nam stan systemu i alarmy które poinformują nas o degradacji
- Wracając na nasze podwórko. Sytuacja w której większość dostaje białej gorączki, nadmiernej potliwości i krzyczy „Boże dlaczego ja?” – strona ładuje się długo i nasi użytkownicy to zgłaszają. Co możemy zrobić jako testerzy? Odpalić jedno z kilku narzędzi i zmierzyć. Ale co gdy takiej sytuacji nie można łatwo odtworzyć, zacząć ciągle monitorować. Użyliśmy WPT bo można postawić własną instancję, a od jakiegoś czasu nie wymaga windowsa aby uruchomić test
- To był nasz pierwszy ciągły monitoring gdzie: Wersje serwisów czy to przy testach AB czy też Prod i Int - było to możliwe właśnie dzięki prywatnej instancji która jest uruchomiona w naszej sieci wewnętrznej Czasami nie widać na pierwszy rzut oka jak kolejne wdrożenia wpływają na prędkość ładowania Zbieraliśmy dane nonstop, a następnie generowaliśmy raport zmian trendu czasu ładowania Tak samo dla ciężaru strony i liczby requestów, czasami jeden bloczek reklamowy potrafi stworzyć bardzo duże problemy Wyróżniłem 2 moim zdaniem ciekawe metryki: - Visual complete która najprościej mówiąc jest czasem załadowania strony od pierwszego piksela Visual progres jest histogramem procentu załadowania się do czasu czyli pokaże nam w której sekundzie jak jaka część strony była załadowana W kontekście reklam ma to duże znaczenie
- Jednak samo testowanie prędkości to nie wszystko chcemy mieć informacje jak to wygląda u naszych użytkowników Bo przecież są w różnych sieciach na różnych prędkościach, przeglądarkach i systemach operacyjnych W dawnych czasach internetu pewna firma rozwiązała to w taki sposób, że kupiła 200 RaspPi podłączyła w różnych miejscach w Polsce aby mierzyć ładowanie ich portalu Potem pojawiło się NTA i zamiast 200 próbników mamy 23mil NTA to standard a do niego można dołożyć swoje własne „logi” i wszystko to opakować w RUM
- RUM dostarczy nam informacji które pozwolą nam na zdefiniowanie Wersji OS na których testujemy mobile/desktop Najpopularniejszych przeglądarek i rozdzielczości Dostawców internetu i prędkości łącza - to np. przydatna informacja przy testach ładowania strony Te dokładne informacjami kto gdzie i co klika możemy wykorzystać np. artykuł jest najbardziej popularny, a dalej wyciągnąć url i podstawić do testu selenium
- Dla przykładu to jeden z wykresów najpopularniejszych przeglądarek u nas na wszystkich portalach Takie dane są bardzo pomocne przy zgłaszaniu błędów Ponad rok temu wdrażaliśmy portal który miał poważny błąd na jednym telefonie, PO nie interesowała naprawa, Wpadliśmy na pomysł, żeby policzyć ile konkretnie użytkowników go używa, a było to ponad 5% udziału w rynku Gość był nietechniczny, ale podanie argumentów gdzie 5% było konkretnymi $$ sprawiło, ze szybko znalazł się czas na naprawę. Od tego czasu automatycznie codziennie aktualizuje się nam % użycia
- Takie dane poza wspomnianymi firmami możecie wyciągnąć z Google Analitics portalu ranking.pl czyli Gemiusa gdzie znajdziecie ogólne statystyki dla kilku krajów Oraz własnego rozwiązania czy to w postaci logów Rum pozwala na dogłębną analizę działania serwisów i jego użytkowników i w ten sposób dopasowania testów
- To teraz będzie ciekawy case Jak już wspominałem raportujemy czasy ładowania i trendy Pewnego razu przyszedł do nas kierownik projektów z pytaniem dlaczego wykresy się rozjeżdżają i na jednym średnia to ~5s a na drugim ponad 12 Problemów nie było widać z sieci firmowej
- Długie czasy generowane były tylko z instancji WPT, która była wpięta do zewnętrznej sieci Neostradą Jednak w samym web page test też nie było widać co powoduje problem tylko wielką dziurę, ale sugestywne były piki w ruchu sieciowym Dopiero po zalogowani na server i uruchomienie w przeglądarce i sprawdzeniu w inspektorze okazało się, że jeden bloczek reklamowy problem miał z ładowaniem, a raczej był blokowany Co ciekawe tylko i wyłączenie na sieci orange. Sprawa została zgłoszona i naprawiona. Mimo, że wygląda banalanie, zostawiona sama sobie mogła by wygenerować dużo problemów przy rozliczeniach Czasami wystarczy spojrzeć z innej perspektywy, żeby znaleźć błąd. Tak jak w tym wypadku, narzędzie kompletnie nie do tego przeznaczone miało swój udział w znalezieniu awarii.
- Skoro mierzymy prędkoś ładowania to kolejnym krokiem było mierzenie wydajności Bo co się stanie gdy wejdzie na naszą stronę 100, 200 czy 1000 os Jak na to zareaguję aplikacje czy też bazy danych A czy przy takim godzinnym ruchu, czy czasy odpowiedzi naszych serwisów nie będą rosły Na te i inne pytania, znaleźć odpowiedzi pozwoli takie darmowe narzędzia jak jmeter czy gatling Ogólnodostępne i zarazem płatne usługi takie jak blazemeter i loader.io My postawiliśmy na jmeter z uwagi na potrzebne nam funkcjonalności oraz możliwość dystrubułowania testów
- Wydajność jaką mierzymy to Ładowanie frontu z requestami Api – prędkość odpowiedzi api oraz rodzaje odpowiedzi Przetwarzania kolejek Baz danych – działanie Oraz przetwarzanie różnych workerów Lokalizacje to wymaga zdefiniowania gdzie znajdują się nasi klienci i dobranie do tego lokalizacji testów, jednej lub kilku Bo jaki sens ma 10ms czasu odpowiedzi z polski jeżeli nasi kliencie są w Niemczech CDN czyli continuous delivery network np. cloudflare, ta technologia pozwala nam na serwowanie stron bliżej klienta. Dlaczego o tym mówię w kontekście testów?
- Robimy bardzo dużo testów wydajnościowych i chcieliśmy uprościć proces ich wykonywania więc stworzyliśmy swoją własną platformę Testowanie z laptopa odpadało bo po prostu nie były w stanie wygenerować potrzebnej ilości requestów, dostępu do infrastruktury nie mogliśmy dać ponieważ po tuningu była w stanie wygenerować przytłaczający ruch. Pozwala nam ona też monitorować działanie serwisów, wszystkie wyniki zbieramy i prezentujemy w raportach Takie dane jak liczba testów per domena, statusy testów w czasie, najlepszy wynik oraz jakie komponenty były testowane
- Jak wspomniałem na początku zarządzamy środowiskiem CI/CD, ale chcąc pójść krok dalej zastanawialiśmy jak poprawić proces developmentu, a głównie zapanować nad awariami spowodowanymi błędnym wdrożeniem Pierwszym krokiem było stworzenie referencyjnego planu buildu i deployu tak aby osiągnąć stabilność, a sukces czy porażka nie zalezały od jakiś wydumanych skryptów developera Następnie zdefiniowaliśmy modelu dojrzałości jako KPI, a następnie zmierzenia produktów wg. punktów. Mierzymy się w takich obszarach jak Proces, zarządzanie jakością, monitoring, build i deploy Co ważne każdy z tych punktów musiało się dać zmieżyć
- Więc skoro da się mierzyć to co? Chcemy wiedzieć czy nasi developerzy mają poprawnie skonfigurowane środowiska np. wymagane PR I jak szybko wdrażają Czy ich buildy zawierają wszystkie komponenty jak testy czy analiza kodu oraz czy długość buildu nie odbiega od trendu Czy i ile testów uruchamiają oraz jakie są statystyki sukcesu Czy branch Master jest zawsze działający - przechodzą testy
- Dalej czy mam procedurę wdrożeniową, jak jest przeprowadzany deploy ręcznie/automatycznie Czy deploye kończą się powodzeniem i są uruchamiane testy e2e po wdrożeniu Czy proces jest odwracalny i potrafię zrobić rollback oraz ile on trwa Czy zespół monitoruje trendy buildów, deployemntów i testów Jak wygląda automatyzacja w ramach chatOps oraz notyfikacje Koniec końców czy Produck owner zna proces i jest informowany o statusie testów i deploymentów Na te wszystkie pytania odpowiadamy stałym monitoringiem procesu bo to pozwala nam na definiowanie kolejnych kroków i walkę z problemami, a także zapewnia transparentność na linii dev i biznes
- Nie wszystkie błędy wynikają z procesu za który odpowiedzialny jest zespół, a środowisko CI jest za duże żeby monitorować każdą VM, produkt czy Build Plan. Dlatego określiliśmy krytyczne funkcjonalności które mówią nam, że środowisko działa z perspektywy użytkownika. I w ten sposób powstała lista Dostępność SDK każdej wspieranej technologii – to daje nam informacje, że konfiguracja VM jest poprawnie wdrożona, ponieważ są one uruchamiane na w chmurze która się rotuje Odpowiednia liczba VM per OS - brak środowiska oznacza zmniejszoną dostępność Czas Commit to Build – potwierdza działanie linków, triggerów oraz odpowiednią wydajność środowiska Czas Builda i jego status – potwierdza działanie wszystkich komponentów pobocznych jak analiza kodu czy testy a nie spodziewane wydłużenie czasu builda może oznaczać utratę wydajności Rozmiar kolejki – dzięki czemu wiemy czy dostarczamy odpowiednią dostępność Wolne miejsce na dysku To wszystko mierzymy testami syntetycznymi, z poza infrastruktury CI tak aby stabilność środowiska nie wpływały na wykonanie testu. W ten sposób postawiliśmy krok w kierunku walki o wysoki uptime i spełnianie SLA
- O samym procesie czy też idei service level agreement trzeba by było mówić przez kolejną godzinę, ale w kontekście monitoringu i stabilności jest o bardzo ciekawa i rozwijająca sprawa. Pewnie widzieliście kiedyś dashboard uptime AWS Dla przykładu taki Amazon S3 zakłada 99.95% dostępności w miesiącu czyli tylko 21,5min może być nie dostępny, jeżeli dołożymy do tego jeżeli dobrze pamiętam deploy co 7s to robi wrażenie Mierzenie uptime i dążenie do utrzymania SLA motywuje do bardzo dużej poprawy stabilności oraz wdrożenia wielu procedur i mechanizmów zabezpieczających na wypadek awarii lub informujących wystarczająco wcześniej aby temu zapobiec
- Monitoring nie zastąpi testowania, jednak ułatwi nam pracę i tak jak potrafimy przeprowadzić wiele rodzajów testów, tak samo warto myśleć o monitoringu, bo nie ma jednego rozwiązania. Automatyzacja to klucz do sukcesu w coraz bardziej dynamicznym świecie IT, a monitoring dobrze zobrazuje status systemu. Stałe dostarczanie informacji pozwoli nam wyniesienie naszej pracy na kolejny poziom i dostarczenie najwyższej jakości