Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring

271 views

Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

[Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring

  1. 1. Gdy testy to za mało, Continuous Monitoring Quality Meetup, 2017 Piotr Marczydło
  2. 2. The Team
  3. 3. 23mln realnych użytkowników 7 mln zapytań na minutę 150mln PV dziennie
  4. 4. 350 specjalistów 40 zespołów > 500 wdrożeń dziennie
  5. 5. „Monitoring provides a good approximation of the health of a system” – SRE book@Google
  6. 6. Monitoring & Observability Kluczem do sukcesu jest to aby monitoringodpowiadał na pytania „Co” i „dlaczego”
  7. 7. Web Speed
  8. 8. 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
  9. 9. Real User Monitoring 1. Każdy użytkownik 2. Navigation Timing API
  10. 10. Real User Monitoring 1. Wersje OS 2. Przeglądarki 3. ISP 4. Prędkość łącza 5. Urządzenia mobilne
  11. 11. Real User Monitoring
  12. 12. 14 Analityka 1. Google Analitics 2. Gemius - Ranking.pl 3. Logi
  13. 13. Historia jednego requestu
  14. 14. Historia jednego requestu
  15. 15. Performance 1. Narzędzia 2. Usługi
  16. 16. Performance 1. Front 2. API/Kolejek/DB 3. Workery 4. Lokalizacje 5. CDN?
  17. 17. Performance Platform 1. Liczba testów 2. Statusy 3. Obciążenie 4. Komponenty
  18. 18. „If a human operator needs to touch your system during normal operations, you have a bug.” ~Carla Geisser, Google SRE
  19. 19. Development & Build
  20. 20. Deployment & Ops
  21. 21. 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
  22. 22. AWS S3 = 99,95% uptime =~21,5min
  23. 23. Dziękuję za uwagę Piotr.Marczydlo@dreamlab.pl
  24. 24. 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

×