Les incidents arrivent. Le travail, c’est de décider quoi faire ensuite, et quoi ne pas aggraver.
Dernière relecture: mars 2026
La gestion des incidents, c’est répondre à un comportement inattendu sur des environnements Linux et Unix en production, de manière à stabiliser le système et préserver les options futures.
Il ne s’agit pas de réagir le plus vite possible. Il s’agit de garder le contrôle avec une information incomplète, peu fiable et parfois contradictoire.
Les incidents tombent rarement isolément. Ils impliquent des pannes qui interagissent: saturation de ressources, timeouts en cascade, problèmes de dépendances et hypothèses fausses qui s’accumulent sous pression.
La première priorité: empêcher la situation d’empirer. Ça peut passer par isoler des composants, désactiver l’automatisation, réduire la charge ou revenir délibérément sur des changements récents. Une dégradation partielle vaut souvent mieux qu’une panne incontrôlée.
Une fois stable, l’attention bascule sur ce qui a cassé et pourquoi. Reconstituer les événements à partir des journaux, métriques et changements récents, en validant les hypothèses contre le comportement observé.
Les actions correctives sont choisies pour restaurer un état prévisible sans introduire de risque nouveau. Les corrections définitives, refactorisations ou améliorations sont souvent reportées au moment où le système est calme et les décisions peuvent être prises délibérément.
La gestion d’incident ne peut pas être entièrement automatisée. Décider de revenir en arrière, basculer, restaurer à partir d’une sauvegarde, reconstruire ou attendre demande du contexte et de l’expérience. Beaucoup de pannes graves sont aggravées par des actions bien intentionnées prises trop tôt.
Pendant un incident, la communication est factuelle, mesurée, et concentrée sur ce qui est connu et ce qui ne l’est pas.
Après résolution, les incidents sont documentés: ce qui s’est passé, ce qui a été fait, quelles hypothèses ont lâché, ce qui doit changer. Cette documentation alimente la supervision, les sauvegardes, le PRA et la conception des systèmes.
La gestion d’incident n’est pas une promesse de disponibilité. La réponse dépend des accès préalables, de la familiarité avec le système et des engagements en cours.
Pour un petit nombre de clients en forfait long terme, un canal de contact dédié peut être convenu explicitement pour des incidents rares de gravité élevée. Ce canal existe pour soutenir la stabilisation court terme lors d’incidents exceptionnels. Il n’implique pas une disponibilité continue, ni des temps de réponse garantis, ni une priorité sur le travail non critique.
Toute autre communication continue par les canaux standards. Ces frontières sont écrites en amont. Aucune obligation de répondre n’existe sans accord préalable. Un usage abusif de ce canal peut entraîner son retrait.
Une gestion d’incident efficace repose sur le travail fait bien avant l’incident: supervision conçue pour faire remonter de vrais signaux, sauvegardes que l’on peut effectivement restaurer, et une conception système prudente.
L’essentiel de l’effort de réponse est réduit par des décisions prises des mois plus tôt. C’est là que se fait le vrai travail.
Pour les structures qui ne sont pas en exploitation opérationnelle actuellement, l’intervention d’urgence fournit une stabilisation court terme pendant des pannes actives ou une instabilité sévère.
La gestion d’incident implique de travailler directement sur des systèmes en production dans des conditions incertaines, où comprendre l’état actuel compte plus que le choix des outils.
La saturation de ressources s’analyse avec les utilitaires système standards, qui permettent d’évaluer en temps réel la pression CPU, mémoire et I/O. Les pannes disque, dont les systèmes de fichiers pleins et la croissance inattendue, sont investiguées par inspection directe de l’usage des systèmes de fichiers et de l’activité des processus.
Les soucis réseau et les coupures de services sont examinés au niveau socket et paquet, plutôt que déduits indirectement par des systèmes externes. Les journaux sont lus dans leur forme originale pour reconstruire les chronologies, valider les hypothèses et comprendre le comportement réel du système.
Les outils incluent top, vmstat, lsof,
tcpdump et journalctl, mais l’accent est mis sur
l’interprétation, pas sur l’outillage. Les actions sont prises délibérément, sur
preuves et non sur hypothèse.
La gestion d’incident est plus efficace quand elle fait partie de la responsabilité opérationnelle long terme, plutôt que d’être un service isolé ou seulement d’urgence. Les pratiques amont qui réduisent l’effort réel de réponse aux incidents sont la supervision, la gestion des sauvegardes et le PRA.
Discuter de votre infrastructure → Exploitation opérationnelle