RUN, MCO, incidents et performance

C'est ton point fort. Huit ans d'astreinte et de N2/N3, c'est ce qui te sépare des profils sortis de formation. Ne le survole pas en entretien : prépare des histoires précises.

Vocabulaire

• RUN : faire tourner ce qui existe, par opposition au BUILD (construire du nouveau).
• MCO (maintien en condition opérationnelle) : garder les systèmes disponibles, à jour et performants. Patching, montées de version, supervision, capacité, sauvegardes.
• MCS (maintien en condition de sécurité) : la même chose côté sécurité. Correctifs, revues d'accès, suivi des vulnérabilités.
• Astreinte : disponibilité hors heures ouvrées pour intervenir sur incident.

ITIL en trois notions

	Incident	Problème	Changement
Objectif	Rétablir le service au plus vite	Trouver et supprimer la cause racine	Modifier le SI de façon maîtrisée
Exemple	Kafka ne répond plus, on bascule et on redémarre	Pourquoi Kafka tombe chaque semaine ? Disque trop petit pour la rétention	Agrandir les disques mardi à 22 h, avec retour arrière prévu

Les changements passent souvent en CAB (comité de validation des changements). Un changement standard (pré-approuvé, faible risque) n'y passe pas.

Priorisation

Priorité = impact (combien d'utilisateurs ou de services touchés) × urgence (à quelle vitesse ça empire).

Priorité	Exemple	Prise en charge typique
P1	Prod indisponible, chaîne de production usine à l'arrêt	Immédiate, cellule de crise
P2	Fonction majeure dégradée, contournement difficile	Moins d'1 h
P3	Gêne limitée, contournement existe	Dans la journée
P4	Demande mineure, cosmétique	Planifiée

Gérer un incident

1. Détecter : alerte de supervision, idéalement avant que l'utilisateur appelle.
2. Qualifier : quoi, qui est touché, depuis quand, quelle priorité.
3. Communiquer : prévenir tôt, donner des nouvelles régulièrement même sans avancée. Un seul canal, un responsable de l'incident (incident commander) qui coordonne.
4. Rétablir : rollback, bascule, redémarrage, ajout de capacité. On restaure le service avant de comprendre. On garde des traces (logs, dumps) avant de redémarrer si possible.
5. Résoudre : corriger durablement.
6. Postmortem : pour tout incident significatif.

Le postmortem sans recherche de coupable (blameless)

On cherche ce qui dans le système a permis l'erreur, pas qui l'a commise. Sinon les gens cachent les erreurs et on n'apprend rien.

Contenu :

• Chronologie précise (détection, actions, rétablissement).
• Impact (durée, utilisateurs, données).
• Cause racine. La méthode des 5 pourquoi aide : on remonte de cause en cause.
• Ce qui a bien marché, ce qui a mal marché.
• Actions avec un responsable et une date. Sans ça, le postmortem ne sert à rien.

Indicateurs

• SLI (indicateur) : ce qu'on mesure. « Pourcentage de requêtes HTTP réussies en moins de 300 ms. »
• SLO (objectif) : la cible interne. « 99,9 % sur 30 jours. »
• SLA (accord) : l'engagement contractuel envers un client, avec pénalités. Toujours moins strict que le SLO, pour garder une marge.
• Error budget : ce que le SLO autorise à rater. 99,9 % sur 30 jours = environ 43 minutes d'indisponibilité. Si le budget est consommé, on gèle les mises en prod risquées et on travaille la fiabilité.

Disponibilité	Indispo par an	Par mois
99 %	3,65 jours	7,3 h
99,9 %	8,8 h	43 min
99,99 %	53 min	4,3 min

• MTTD : temps moyen de détection.
• MTTR : temps moyen de rétablissement.
• MTBF : temps moyen entre deux pannes.

Supervision

Les quatre signaux dorés (Google SRE) pour un service :

1. Latence : temps de réponse (regarder les percentiles p95, p99, pas la moyenne).
2. Trafic : requêtes par seconde, messages par seconde.
3. Erreurs : taux de 5xx, d'échecs.
4. Saturation : à quel point la ressource est pleine (CPU, files, connexions).

Bonnes pratiques d'alerte :

• Alerter sur les symptômes vus par l'utilisateur (le service répond mal) plutôt que sur chaque cause possible (CPU à 80 %).
• Chaque alerte doit demander une action. Une alerte qu'on ignore habitue à ignorer les alertes.
• Chaque alerte renvoie vers un runbook.

Outils : Prometheus et Grafana (ton projet Penpot), Loki pour les logs, Cloud Monitoring sur GCP, Datadog, Dynatrace, Zabbix, Centreon (fréquent dans les grandes entreprises françaises).

Runbooks

Une procédure écrite pour une situation donnée : symptômes, vérifications, actions, retour arrière, qui prévenir. Tu en as rédigé 11 pour un client : c'est un argument à citer.

Optimisation des performances

1. Mesurer avant de toucher. Une optimisation sans mesure est une supposition.
2. Trouver le goulot : CPU, mémoire, I/O disque, réseau, base de données, verrou applicatif.
3. Changer une chose à la fois, remesurer.
4. Leviers courants : cache, index de base de données, taille des pools de connexions, réglages JVM (heap, garbage collector) pour Kafka et ActiveMQ, scaling horizontal, rétention ajustée.

Capacity planning

Suivre la tendance (disque, débit, CPU), projeter la date de saturation, anticiper l'achat ou l'agrandissement. « Le disque des brokers sera plein dans 6 semaines au rythme actuel » vaut mieux qu'une alerte à 95 %.

Sauvegardes et PRA

• RPO (Recovery Point Objective) : combien de données on accepte de perdre. RPO de 1 h = sauvegarde au moins toutes les heures.
• RTO (Recovery Time Objective) : en combien de temps on doit être reparti.
• PRA (plan de reprise d'activité) : redémarrer après un sinistre. PCA (plan de continuité) : ne jamais s'arrêter, via la redondance.
• Tester les restaurations régulièrement.

Préparer tes histoires (méthode STAR)

• Situation : le contexte.
• Tâche : ton rôle, ce qu'on attendait de toi.
• Action : ce que tu as fait, concrètement.
• Résultat : chiffré si possible (durée de coupure, clients concernés, récurrence évitée).

Prépare au moins trois histoires de ton expérience Faircom :

1. Un incident critique géré en astreinte.
2. Un problème récurrent dont tu as trouvé la cause racine.
3. Une amélioration que tu as proposée et mise en place (automatisation, procédure, supervision).

Questions d'entretien à préparer

• Différence entre incident et problème ?
• Raconte un incident critique que tu as géré.
• C'est quoi un SLO, un error budget ?
• 99,9 % de disponibilité, ça fait combien d'indisponibilité par mois ?
• Comment évites-tu la fatigue d'alerte ?
• RPO et RTO, quelle différence ?
• Ce que tu fais dans les 10 premières minutes d'un incident P1 ?