Come individuare problemi e malfunzionamenti nei software prima che siano i clienti a segnalare il problema

1. Valerio Barbera
Founder & C.T.O.
Identificare
problemi tecnici
nelle applicazioni
prima di creare
disagi ai clienti

2. Workshop
Topics
● Punti deboli lato sviluppo
● Perché monitorare
● Quando e in quali situazioni
● Quale tool usare in base
all’obiettivo
● Infrastructure VS Code driven
● Build VS Buy debate

3. Il modo più comune per i team di sviluppo
software per sapere se un’applicazione sta
funzionando correttamente oppure no, è
sempre…
3
Il Problema

4. La telefonata del
cliente arrabbiato
perché il software
non funziona.
4

5. Why monitoring matter

6. Quali sono le
conseguenze
di ricevere segnalazioni di errori
e problemi direttamente dai
clienti?
6

7. 7
Perdita di produttività
● Il team di sviluppo deve
sospendere le attività in corso;
● Le segnalazioni dei clienti
hanno la massima priorità;
● Il team perde ore o giorni per
identificare problemi e
soluzioni.

8. Tempo per
individuare
il problema
Tempo per
Sviluppare la
soluzione
8
Disservizi ai clienti
I clienti rimangono bloccati in attesa che il team di sviluppo impieghi:

9. A causa delle attese
derivate dai disservizi
i clienti
Sollecitano!
9

10. 10
Perdita di commesse
I disservizi si traducono in:
● Perdita di commesse
● Penali
● Alto turn-over dei contratti
● Perdita di competitività

11. Customers don’t report bugs
They just stop using our application

12. The right tool for the right
problem

13. Generic Logs

14. Logs
They aren’t designed to store metrics and analytics.

15. Uptime
Monitoring

16. Uptime
Can’t help you to know what’s happening inside your code.

17. Error Tracking

18. Error Tracking
Missing a lot of context information.
● System load & Concurrency
● Memory and CPU consumption
● Performance

19. Server
Monitoring

20. Server Monitoring
Cloud providers offer server monitoring for free.
AWS CloudWatch Google Cloud Platform

21. Application
Monitoring

22. Application monitoring
● Difficult and Expensive
● Dedicated team
● Time to learn and maintain

23. Infrastructure
Driven
monitoring
Code
Driven
monitoring

24. Infrastructure-driven monitoring
● Work overload for developers
● Developers lose their autonomy
● Out of software development life cycle
● Looking at the application from the outside

25. Code-driven monitoring
● Sync with CI/CD processes
● Looking at the application from the inside
● Developers can configure and customize

26. Make Buy
Is it better to BUILD an internal monitoring environment,
or BUY a prepackaged solution?

27. Make your competitive advantage
Buy the rest

28. Cost
Obvious up-front costs:
● Time to choose and learn the
right stack;
● Engineering effort to install
and configure all
components;
● Operational costs (servers
and infrastructure).
Hidden costs:
● On-going support (install and
configure new releases,
patches, etc);
● Pulling your developers
away from the project;
● Opportunity Costs.

29. Internal resources
Aside from the time and money there are the logistics
of building a new internal team to build new things.
Will you hire full-time staff, or contract it out?

30. Continuity & Knowledge Transfer
“How much time will this take someone to maintain after they build it?”
“Who will maintain this after them, and who after them?”
“How will each new person learn the intricacies of the system?”

31. Control & Compatibility
Building provides more control but all of that control comes with additional
responsibility, and most of it isn’t very glamorous.
Developer Experience Support & Maintenance

33. Simple Code Execution Monitoring,
built for developers
support@inspector.dev