You Build It, You Run it, l'observabilité pour les devs

En tant que développeur et développeuse il est fréquent de penser que notre travail s'arrête à la mise en production. L'observabilité est souvent mise de côté, on attend une remontée client pour corriger le problème alors que l'on peut être pro-actif avec de l'observabilité. Mais qu'est-ce que l'observabilité?

Est-ce vraiment aux équipe de devs de s'en occuper ? Est-ce aux équipe de devs d'intervenir en cas d'incendie, euh, d'incident ! Comment définir un périmètre d'intervention ?

D'ailleurs comment être alerté.e qu'il y a un souci en production, comment savoir si vous devez ou non intervenir, comment organiser vos équipes pour être le plus efficace possible, comment former vos équipes de dev à l'observabilité, comment éviter de perdre du temps en cas d'incident ? Dans ce genre de situation, les process peuvent vous faire gagner beaucoup de temps pour revenir à un état normal.

Chez Yousign, l'observabilité est quelque chose de très important. Nous avons une "license to run", cette license nous donne le droit d'être "runner", mais c'est quoi un "runner" ?

Rapidement, un runner est une personne dont le rôle est de s'assurer que le scope de fonctionnalité de sa squad est pleinement opérationnel: il protège, alerte et secourt en cas de soucis.

Je vous propose un retour d'expérience pour découvrir le rôle du runner, quels outils peuvent vous aider, comment définir les alertes à mettre en place, comment former vos équipes, comment être pro actif et que faire en cas d'incident...

Comments

Comments are closed.