Découvrez-le avec les anecdotes vécues à travers les années par une startup devenue maintenant PME. Nous verrons quels sont les différents niveaux de monitoring qu'il est possible de mettre en place, selon vos besoins, ainsi que quelques tactiques et conseils pour rendre le on-call facile et vivable pour les développeurs.
Le on-call n'est pas un fardeau et bien mené, il peut même être le moteur principal de la future qualité de vos projets!
3. ◇ Fondée en 2010 (4 employés)
◇ J’étais le 51ème en 2013
◇ 250 employés en 2021
◇ Suite d’outils pour les concessionnaires automobiles
■ CMS, module complet de vente en ligne, CRM, etc.
◇ 725 clients
◇ 1093 websites
◇ Certification avec une dizaine de manufacturiers
◇ Partenariat avec Kijiji Autos lancé en 2020
■ 4000 nouveaux clients
4. Combien coûte une panne ?
?
Source : “Calculating the cost of downtime” from Atlassian
5. $34,722 / min.
Pendant 12 heures, pour Apple (2015)
(The Mac Observer)
$107,142 / min.
Pendant 14 heures, pour Facebook (2019)
(CNN)
$500,000 / min.
Pendant 5 heures, pour Delta Airlines (2016)
(CNN)
6. $427 / min.
Petites entreprises (1-100 employé(e)s)
(IDC)
$9000 / min.
Moyennes (100-500) et grandes entreprises (500+)
(Ponemon Institute (2016))
$5600 / min.
Moyennes (100-500) et grandes entreprises (500+)
(Gartner (2014))
8. Culture DevOps
◇ Devenue la norme
■ Sprints
■ CI / CD, rolling updates
■ Applications “containerized”
■ Serveurs dans le cloud (AWS, GCP, Azure, etc.)
◇ On code, (teste), livre plus vite, tout le temps
◇ Plus de changements = plus de risques
9. Culture DevOps
◇ Mais le management s’attend à ce que :
■ La qualité augmente
■ Les coûts diminuent
◇ Et le client paie pour une haute disponibilité (“99.99 %”)
10. On comprend mieux les
enjeux du on-call
Qui repose forcément sur un bon monitoring
11. Il faut donc monitorer
◇ Notre infrastructure, nos projets
◇ Par où commencer ? Comment tout couvrir ?
◇ Allez-y par étape, par niveau
◇ Nous allons en définir 4
■ Du plus basique au plus personnalisé
■ L’efficacité de chaque niveau repose sur le précédent
12. 4 niveaux de monitoring
Disponibilité
Diagram featured by
http:/
/slidemodel.com
Niv 1 : Disponibilité
Vous devez être au courant le
premier d’une panne (websites,
APIs, prestataire, etc.)
Niv 3 : Votre application
Application Performance Monitoring :
◇ Requêtes / seconde
◇ Temps de réponse
◇ % de calls en erreur
◇ Trace
Logs (mine d’or, alerting cas connu)
Niv 4 : Votre business
Vos KPI (détails à suivre)
Ressources
Niv 2 : Vos ressources
Pour vos applications et serveurs :
◇ CPU (% utilisation, load)
◇ Mémoire (% utilisation)
◇ Disque (IOPS, espace restant)
Et vos dépendances (DB, cache, queuing)
Application
Business
13. ◇ Il est plus facile de détecter un problème et faire le lien dans le temps :
■ Mauvais déploiement ?
■ Panne d’un prestataire ?
■ Problème avec une dépendance ?
■ Trafic anormal (attaque ? soldes ?)
Niv. 3 : Votre application
Monitoring : comment?
14. ◇ Personnalisé : il représente vos KPI (Key Performance Indicators)
■ Vos objectifs concrets, mesurables, non techniques
■ Traduisent l’activité de vos clients, exemple:
○ compteurs de commandes
○ création de comptes
○ authentifications
○ appels
◇ Alerte / notification si drop par rapport à la moyenne
Niv. 4 : votre business
Monitoring : comment?
15. ◇ Pour protéger vos KPI, surveillez le trafic lié
◇ Synthetic Monitoring
■ l’outil simule le trafic d’un client
■ alerte si le résultat attendu n’est pas bon
■ surveillance en tout temps
◇ Real User Monitoring (RUM)
■ l’outil surveille l’activité en direct de vos clients
Niv. 4 : votre business
Monitoring : comment?
17. Quels outils ?
◇ Niveau 1 : Disponibilité
■ UptimeRobot, StatusCake
◇ Niveau 2 : Vos ressources
■ Nagios, Datadog, Zabbix
◇ Niveau 3 : Votre application
■ Datadog, NewRelic, Dynatrace, Raygun
■ Logs : Datadog, Sentry, LogEntries, ELK + Grafana
◇ Niveau 4 : Votre business
■ Datadog, Grafana, Klipfolio, Pingdom
Monitoring : comment?
18. ◇ Liste non exhaustive
■ Essayez
■ Gardez le plus intuitif pour vous
◇ Datadog est un bon point de départ
■ Couvre les 4 niveaux
■ Repère pour vous les pattern suspects (Watchdog)
■ Dashboards sur vos métriques préférées
Quels outils ?
Monitoring : comment?
19. ◇ En cas de problème...
◇ Lorsqu’un problème va arriver...
◇ Comment s’assurer que le retour à la normale soit le plus rapide ?
◇ Le monitoring en place va lancer l’alerte au plus tôt
◇ Il faut maintenant notifier au plus vite la bonne personne !
La finalité
Monitoring : comment?
20. On-call : la clé du succès
Définition Préparation Accompagnement
21. On-call : définir le plan
◇ Il est important de le faire en équipe (meilleure adhésion)
◇ Et préciser le minimum :
■ Quelques volontaires pour commencer
■ Des attentes claires
■ Choisir un bon outil d’Incident Management
■ Un type de compensation
On-call : le rendre vivable (définition)
22. Trouver des volontaires
◇ “Qui veut être on-call ?”
■ Silence souvent assourdissant 😅
■ Ça sonne négatif (plus de travail, moins de sommeil)
■ Peur de l’inconnu
◇ Rassurer dés l’approche
On-call : le rendre vivable (définition)
23. ◇ “Qui veut faire partie de l’équipe on-call avec onboarding
et compensation à la clé ?”
■ Non livré à moi-même
■ Entraide
■ Le temps que je donne est valorisé
Trouver des volontaires
On-call : le rendre vivable (définition)
24. ◇ Idéalement “you code it, you own it”
■ C’est le plus efficace
■ Mais pas si évident
■ Aptitudes particulières
○ Gestion du stress, communication, instinct
◇ Dialoguer et respecter le choix
Trouver des volontaires
On-call : le rendre vivable (définition)
25. ◇ Assumer l’urgence
◇ Régler le problème
◇ Ou escalader à une autre personne (qui et comment ?)
Des attentes claires
On-call : le rendre vivable (définition)
26. Un outil complet
◇ Qui offre les fonctionnalités basiques couvrant nos besoins ici
◇ Intégration native avec vos outils de monitoring
◇ Quelques uns à essayer :
■ PagerDuty est la référence et le plus connu
■ OpsGenie si vous utilisez beaucoup la suite Atlassian
■ Splunk On-Call (anciennement VictorOps)
On-call : le rendre vivable (définition)
27. Offrir une compensation
◇ C’est nécessaire et bien normal
◇ Des heures supplémentaires
■ À rattraper
■ Ou payées
◇ À voir avec votre management
On-call : le rendre vivable (définition)
28. ◇ Mais vous ne voulez pas décevoir les gens avec un lancement raté
■ Trop d’alertes, de “bruit”
■ Réveil inutile la nuit pour quelque chose
○ Qui pouvait attendre
○ Ou sur lequel je n’ai pas le contrôle
Le plan on-call est défini
On-call : le rendre vivable (définition)
29. On-call : la clé du succès
Définition Préparation Accompagnement
31. ◇ Couleur rouge 🔴 ou priorité 1
■ Quelque chose est down ou va l’être bientôt
■ Impact pour le client (ou vos collègues)
■ Cela doit escalader jusqu’à ce que quelqu’un réponde
■ Je peux faire quelque chose
◇ Exemples
■ DB principale saturée (% utilisation CPU)
■ Un serveur ne répond plus
■ Impossible de valider une commande
Urgence : niveau High
On-call : le rendre vivable (préparation)
32. ◇ Couleur jaune 🟡 ou priorité 2
■ Avertissement qui peut être regardé plus tard en
heures ouvrées (quitte à y devenir High)
■ Pas d’impact pour le client
■ Pas besoin d’escalader
◇ Exemples
■ 80% disk space
■ Une app restart de façon isolée (déjà trop tard)
Urgence : niveau Low
On-call : le rendre vivable (préparation)
33. ◇ On commence simple pour faciliter le onboarding
■ Plutôt que 🔴 🟡 🟡
■ Plutôt que urgence 1, 2, 3, 4 ,5
◇ “C’est grave ou pas ?”
◇ On pourra l’affiner plus tard, avec plus de maturité
Urgence : deux niveaux
On-call : le rendre vivable (préparation)
35. Notes pour chaque alerte
◇ Courtes et claires
◇ Texte dans l’alerte ou lien vers votre outil de doc
■ Quels sont les impacts ?
■ Que dois-je regarder ?
■ Où et comment me connecter ?
○ Lister carrément les commandes
■ Qui joindre au besoin et comment ?
On-call : le rendre vivable (préparation)
37. Planning
◇ Choisir une bonne rotation qui corresponde à tout le monde :
■ Heures ouvrées / off hours
■ “Follow the sun” (on suit les timezones, le meilleur)
■ 1 jour entier
■ On déconseille la semaine entière on-call
◇ Le but est d’éviter la fatigue
On-call : le rendre vivable (préparation)
39. Tester le volume d’alertes
◇ Envoyer toutes les alertes dans un channel Slack
◇ On veut juger le volume de notifications
◇ Et commencer une “Morning Routine”
■ Pour être efficace et s’améliorer continuellement
■ La clé est la constance
◇ Prenez le temps (fixe : 30 minutes) chaque jour de...
On-call : le rendre vivable (préparation)
40. 🏋 Morning Routine 🏋 1/3
◇ Challenger chaque alerte reçue durant les dernières 24h 🌵
■ Utile ?
■ Bon niveau d’urgence ? (High ou Low)
■ Bonne équipe ou personne prévenue ?
■ Notes claires ?
◇ Faites les ajustements nécessaires dans votre outil
On-call : le rendre vivable (préparation)
41. 🏋 Morning Routine 🏋 2/3
◇ Voyez-vous un pattern ? 🔍
■ Même alerte tous les jours à même heure
■ Dans les courbes de vos dashboards
■ Ouvrir un ticket (label “morning-routine”) pour les suivre
○ High => Low le temps de la résolution
On-call : le rendre vivable (préparation)
42. ◇ Gérer les alertes Low en cours 🧐
■ Elles représentent des menaces futures
◇ Monitorer vos routines si vous en avez ⚙
■ Départ comme prévu, durée habituelle
■ Cronitor, Dead Man’s Snitch
◇ Satisfaction du ✅ en début de journée 🧘
🏋 Morning Routine 🏋 3/3
On-call : le rendre vivable (préparation)
43. On-call : la clé du succès
Définition Préparation Accompagnement
44. Onboarding
◇ Être transparent, ne pas cacher la vérité
■ “Oui tu peux être réveillé(e) la nuit, dérangé(e) pendant un repas, un film”
◇ Mais rassurer
■ “Tu ne seras jamais seul(e)”
■ “On challenge chaque alerte” (Morning Routine)
■ “On challenge chaque panne grave” (blameless postmortem)
◇ Shadowing encouragé sur les alertes en journée
On-call : le rendre vivable (accompagnement)
45. Point matériel
◇ Laptop
■ Accès VPN fonctionnel, tous les câbles, partage de connexion
◇ Cellulaire
■ Des notifications personnalisées selon l’urgence, exemple :
○ High : push => SMS => appel => escalade (15 min.)
○ Low : email
■ Tester pour la nuit le combo :
○ Mode vibreur
○ Mode “Ne pas déranger” correctement configuré
On-call : le rendre vivable (accompagnement)
47. Cultiver l’esprit d’entraide
◇ Rappeler :
■ De ne jamais hésiter à escalader, demander de l’aide
■ Être là aussi quand quelqu’un a besoin de nous
◇ Encourager les changements de créneaux (imprévus de la vie)
■ Aussi quand on déploie quelque chose de sensible
◇ Veiller sur l’équilibre travail - vie privée des autres
■ Time off le lendemain si grave incident la nuit
On-call : le rendre vivable (accompagnement)
48. Dédramatiser
◇ Ça peut arriver d’échapper une alerte
◇ Ne pas se convaincre qu’un problème va forcément arriver
◇ Restez positif pendant une panne
■ On peut se faire quelques blagues pendant
◇ Ça ne veut pas dire que rien n’est grave !
■ Mais de l’énergie négative n'amènera aucune plus-value
On-call : le rendre vivable (accompagnement)
49. ◇ On crée un cercle vertueux
■ On réduit le bruit, on règle les problèmes récurrents
■ Chaque alerte est challengée (Morning Routine)
■ Chaque incident grave est analysée (blameless postmortem)
◇ Être on-call fait de nous un meilleur dev. et donne confiance en soi
◇ L’équipe génère moins de bugs, la qualité augmente
◇ Moins d’alertes, moins de stress
■ Stress qui était pourtant la crainte du départ !
■ La peur de l’inconnu
La finalité de tout cela...
On-call : le rendre vivable (accompagnement)
51. Partage d’expérience
◇ Premier page reçu en septembre 2015 sur PagerDuty
◇ 5 personnes + 1 manager
◇ 3 niveaux d’escalade (15 minutes entre chaque)
■ Niveau 1 : personne on call
■ Niveau 2 : son backup
■ Niveau 3 : le manager
◇ Minutes travaillées off-hour
■ Arrondies à l’heure et notées dans une spreadsheet
■ À rattraper plus tard
52. ◇ Chaque semaine de travail
■ Même jour en niveau 1, autre jour en niveau 2
■ Même nuit en niveau 1, autre nuit en niveau 2
◇ Les fins de semaine
■ Niveau 1 toutes les 5 fins de semaine
■ Niveau 2 toutes les autres 5 fins de semaine
◇ Le niveau 3 est toujours la même personne
Un
exemple de
planning
Usbig
image.
56. Instances disparues
Dans AWS Beanstalk =>
clone environment
Les réveils à 3AM
BD principale saturée
Stop de la routine d’import
mal optimisée
IOPS dans le tapis
Donner plus de ressources à
un agent qui restartait en
boucle
Panne prestataire (appels)
Load balancer différement le traffic
Ça ira au matin
Nom de domaine non
renouvelé par le client
(passé à Low depuis)
Down-up
Restart isolé de l’app (passé
à Low depuis)
Avertissements simples
80% espace disque (passé à
Low depuis)
57. Aller plus loin
◇ Monitoring de votre staging / preproduction
■ Mêmes surveillances que la production mais adaptées
■ Détecter le plus en amont une éventuelle régression
◇ Rouler un audit de sécurité (infra, scan Git repositories)
◇ Chaos engineering
58. Conclusion / Takeaways
◇ Un bon programme on-call améliore la qualité et réduit donc le stress
◇ Offrez vous 4 niveaux de monitoring complets et personnalisés
◇ Cultiver l’entraide et la positivité en permanence
■ Impliquer l’équipe on-call (nouvelles features)
■ Veiller à l’équilibre fragile (désintérêt si rien n’est corrigé)
◇ Faites votre “Morning Routine” en rotation : le suivi constant est la clé !
59. Merci!
N’hésitez pas à partager vos expériences on-call :
◇ #oncallselfie
◇ @lboix #confoo
◇ https://www.linkedin.com/in/lucienboix/
Des questions?
60. Crédits
Merci également à toutes les personnes qui ont réalisé et
offert gratuitement les éléments utilisés dans cette
présentation :
◇ Template par SlidesCarnival