Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Gdy testy to za mało,
Continuous Monitoring
Quality Meetup, 2017
Piotr Marczydło
The Team
23mln
realnych
użytkowników
7 mln
zapytań na
minutę
150mln
PV dziennie
350
specjalistów
40
zespołów
> 500
wdrożeń
dziennie
„Monitoring provides
a good approximation
of the health of
a system” – SRE book@Google
Monitoring & Observability
Kluczem do sukcesu jest to aby
monitoringodpowiadał na pytania
„Co” i „dlaczego”
Web Speed
Web Speed
1. Porównanie wersji (A/B Test)
2. Badanie trendu
3. Ciężar strony i liczba requestów
4. *Visual Complete i Prog...
Real User Monitoring
1. Każdy użytkownik
2. Navigation Timing API
Real User Monitoring
1. Wersje OS
2. Przeglądarki
3. ISP
4. Prędkość łącza
5. Urządzenia mobilne
Real User Monitoring
14
Analityka
1. Google Analitics
2. Gemius - Ranking.pl
3. Logi
Historia jednego requestu
Historia jednego requestu
Performance
1. Narzędzia
2. Usługi
Performance
1. Front
2. API/Kolejek/DB
3. Workery
4. Lokalizacje
5. CDN?
Performance Platform
1. Liczba testów
2. Statusy
3. Obciążenie
4. Komponenty
„If a human operator needs to touch your
system during normal operations, you have
a bug.”
~Carla Geisser, Google SRE
Development & Build
Deployment & Ops
CI/CD enviroment & uptime
1. Dostępność SDK
2. Liczba VM
3. Czas Commit to Build
4. Czas Builda i status
5. Rozmiar kolejk...
AWS S3 = 99,95% uptime =~21,5min
Dziękuję za uwagę
Piotr.Marczydlo@dreamlab.pl
Linki/Bibliografia:
Monitoring and Observability
https://medium.com/@copyconstruct/monitoring-and-observability-8417d1952e...
[Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring
[Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring
[Quality Meetup #13] Piotr Marczydło - Gdy testy to za mało – Continuous Monitoring
Nächste SlideShare
Wird geladen in …5
×

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

273 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

[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

×