Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
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
Próxima SlideShare
Cargando en…5
×

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

253 visualizaciones

Publicado el

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.

Publicado en: Software
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

[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

×