{"id":22468,"date":"2021-12-08T16:15:38","date_gmt":"2021-12-08T16:15:38","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/?p=22468"},"modified":"2026-06-15T15:43:58","modified_gmt":"2026-06-15T15:43:58","slug":"sre-incident-management-overview-techniques-and-tools","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/sre-incident-management-overview-techniques-and-tools\/","title":{"rendered":"SRE Incident Management: Overview, Techniques, and Tools"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In the world of a site reliability engineer (SRE)<\/a>, failure is not only an option, but also expected. Les syst\u00e8mes, les applications Web, les serveurs, les p\u00e9riph\u00e9riques, etc., sont tous sujets \u00e0 des probl\u00e8mes de performances et \u00e0 des pannes inattendues \u00e0 un moment donn\u00e9. C\u2019est un fait in\u00e9vitable. Ces \u00e9checs inattendus peuvent entra\u00eener d\u2019\u00e9normes pertes de revenus, la confiance des clients et, selon l\u2019industrie, peut-\u00eatre des amendes. Heureusement, la gestion des incidents SRE est l\u2019une des pratiques de base utilis\u00e9es pour limiter les perturbations caus\u00e9es par des probl\u00e8mes inattendus. Dans un autre article, nous avons parl\u00e9 de l\u2019ing\u00e9nierie du chaos<\/a> et de la fa\u00e7on dont les \u00e9quipes SRE recherchent et testent de mani\u00e8re proactive les \u00e9checs pour \u00e9viter que le pire ne se produise. Cependant, comme nous le sommes tous conscients, les probl\u00e8mes peuvent passer entre les mailles du filet. L\u2019objectif est d\u2019\u00e9viter que ces incidents ne se deviennent des d\u00e9faillances en cascade \u00e0 grande \u00e9chelle. Les \u00e9quipes SRE et DevOps peuvent utiliser ces incidents pour mieux reconstruire et am\u00e9liorer leurs syst\u00e8mes et services.<\/p>\n

<\/p>\n

Qu\u2019est-ce qu\u2019un incident?<\/h2>\n

Avant d\u2019approfondir ce sujet, nous devons d\u2019abord discuter de ce qu\u2019est un incident. O\u00f9 se situe la ligne de d\u00e9marcation entre quelque chose qui n\u00e9cessite une action imm\u00e9diate et quelque chose qui peut faire l\u2019objet d\u2019une enqu\u00eate plus tard? Si chaque probl\u00e8me \u00e9tait class\u00e9 comme urgent, personne n\u2019obtiendrait de solution. Dans le contexte de la TI (technologie de l\u2019information), un incident est simplement un \u00e9v\u00e9nement ou un probl\u00e8me qui perturbe le fonctionnement normal ou la qualit\u00e9 du service. Cela n\u2019a pas entra\u00een\u00e9 d\u2019\u00e9chec, mais s\u2019il n\u2019est pas contr\u00f4l\u00e9, il a la possibilit\u00e9 d\u2019avoir un impact plus important sur vos services et vos op\u00e9rations. Et ils se produisent g\u00e9n\u00e9ralement \u00e0 2h00 du matin pendant que vous dormez b\u00e9atement et que vous \u00eates r\u00e9veill\u00e9 par le son de votre t\u00e9l\u00e9phone qui s\u2019\u00e9teint. Nous plaisantons bien s\u00fbr, mais vous savez que quelque chose ne va pas si cela se produit si t\u00f4t le matin. Rien de bon ne se passe \u00e0 2h00 du .m., surtout quand on parle de l\u2019industrie informatique.<\/p>\n

<\/p>\n

Qu\u2019est-ce que la gestion des incidents ?<\/h2>\n

Maintenant que nous avons parl\u00e9 de ce qu\u2019est un incident, la gestion des incidents est le processus par lequel les \u00e9quipes r\u00e9solvent ces \u00e9v\u00e9nements et ram\u00e8nent les syst\u00e8mes et les services \u00e0 un fonctionnement normal. Il convient \u00e9galement de noter que la gestion des incidents n\u2019est qu\u2019un \u00e9l\u00e9ment d\u2019un concept plus large connu sous le nom de gestion des services informatiques, ou ITSM. ITSM d\u00e9finit la fa\u00e7on dont les \u00e9quipes con\u00e7oivent, cr\u00e9ent et fournissent leurs services. C\u2019est bien plus qu\u2019un simple support informatique. L\u2019ITSM est la politique, les processus et la structure qui sous-tendent le cycle de vie des services informatiques. L\u2019ITSM est l\u2019une des pratiques de la Biblioth\u00e8que de l\u2019infrastructure des technologies de l\u2019information, ou ITIL.<\/p>\n

ITIL fournit le cadre et les lignes directrices pour la cr\u00e9ation de solutions ITSM. Vous connaissez peut-\u00eatre d\u00e9j\u00e0 d\u2019autres frameworks, tels que Business Process Framework (eTOM), Control Objectives for Information and Related Technologies (COBIT), FitSM, ISO\/IEC 20000 et Microsoft Operations Framework (MOF).<\/p>\n

<\/p>\n

Le cadre de gestion des services informatiques (ITSM)<\/h3>\n

Si nous prenons un peu de recul et que nous nous concentrons un peu sur les \u00e9l\u00e9ments du cadre ITSM, il y a six autres composants qui composent la \u00abroue\u00bb ITSM avec la gestion des incidents. Bien que nous n\u2019entrons pas dans les d\u00e9tails \u00e0 ce sujet, il est important de comprendre comment tous ces \u00e9l\u00e9ments s\u2019int\u00e8grent avec la gestion des incidents.<\/p>\n

<\/p>\n

Catalogue de services<\/h4>\n

Le catalogue de services informatiques est g\u00e9n\u00e9ralement une base de donn\u00e9es ou une ressource qu\u2019une organisation cr\u00e9e pour fournir aux utilisateurs des informations sur leurs services et offres op\u00e9rationnels. Ces catalogues de services fournissent des informations utiles sur les services actuels et pr\u00e9vus, ainsi que sur les prix, le processus d\u2019achat, les points de contact et d\u2019autres livrables.<\/p>\n

<\/p>\n

Centre de services<\/h4>\n

Le centre de services peut \u00eatre consid\u00e9r\u00e9 comme le point de contact entre le fournisseur de services et les utilisateurs, tels que les employ\u00e9s internes, les parties prenantes ou les clients. C\u2019est le \u00abhub\u00bb central o\u00f9 les utilisateurs se rendent pour obtenir de l\u2019aide et des services. Selon la d\u00e9finition ITIL, le centre de services peut prendre la forme d\u2019une r\u00e9solution d\u2019incident ou de demandes de service, mais quoi qu\u2019il en soit, l\u2019objectif principal du centre de services est de fournir un service rapide et efficace.<\/p>\n

<\/p>\n

Gestion des probl\u00e8mes<\/h4>\n

Lorsque nous parlons de gestion des incidents, une \u00e9quipe SRE peut \u00eatre en mesure de r\u00e9soudre rapidement un incident, mais le probl\u00e8me sous-jacent peut toujours exister et persister pendant un certain temps encore. La gestion des probl\u00e8mes est le processus par lequel les causes profondes des incidents sont d\u00e9finitivement corrig\u00e9es, ce qui am\u00e9liore les performances \u00e0 long terme et les d\u00e9ploiements de services futurs.<\/p>\n

<\/p>\n

Gestion du changement<\/h4>\n

Tout type de changement, qu\u2019il s\u2019agisse de nouveaux d\u00e9ploiements de services ou de changements personnels, il y a toujours un \u00e9l\u00e9ment de risque. La gestion du changement est le processus qui consiste \u00e0 d\u00e9terminer comment les changements affecteront le d\u00e9ploiement du service et\/ou \u00e0 prendre en compte les effets sur l\u2019entreprise elle-m\u00eame. La gestion du changement est \u00e9galement parfois regroup\u00e9e avec la gestion des versions.<\/p>\n

<\/p>\n

Gestion d\u2019actifs<\/h4>\n

Vous ne pouvez pas tout virtualiser… encore. Les services logiciels n\u00e9cessitent toujours des p\u00e9riph\u00e9riques physiques et du mat\u00e9riel pour fonctionner. Et les organisations doivent suivre, g\u00e9rer et continuellement mettre \u00e0 jour ces appareils pour s\u2019assurer que leurs services peuvent fonctionner correctement. La gestion des actifs est \u00e9galement appel\u00e9e gestion des actifs informatiques, ou ITAM.<\/p>\n

<\/p>\n

Gestion des connaissances, des politiques et des proc\u00e9dures<\/h4>\n

L\u2019objectif de la gestion des connaissances est de r\u00e9duire la redondance en termes de collecte, d\u2019examen et de partage d\u2019informations au sein d\u2019une organisation. Cela permet d\u2019am\u00e9liorer l\u2019efficacit\u00e9 et de garantir que les informations sont coh\u00e9rentes, \u00e0 jour et disponibles.<\/p>\n

<\/p>\n

Lifecyle de gestion des incidents : processus et \u00e9tapes<\/h2>\n

La r\u00e9ponse d\u2019une organisation \u00e0 un incident, qu\u2019il s\u2019agisse de temps d\u2019arr\u00eat, de failles de s\u00e9curit\u00e9 ou de cyberattaques, ou m\u00eame de latence prolong\u00e9e et d\u2019erreurs r\u00e9p\u00e9t\u00e9es, est essentielle au succ\u00e8s continu de l\u2019entreprise et \u00e0 la confiance du client ou de l\u2019utilisateur final. Les SRE doivent g\u00e9rer des syst\u00e8mes distribu\u00e9s complexes. Bien que les avantages de ces syst\u00e8mes soient qu\u2019ils sont plus fiables, \u00e9volutifs et tol\u00e9rants aux pannes, cela les rend \u00e9galement extr\u00eamement complexes, ce qui peut entra\u00eener des temps de correction plus longs, car les probl\u00e8mes sont plus difficiles \u00e0 d\u00e9tecter et \u00e0 identifier. Les meilleures \u00e9quipes de gestion des incidents SRE adh\u00e8rent \u00e0 un processus strict de gestion et de correction des incidents. Bien que les \u00e9tapes et les processus r\u00e9els puissent varier d\u2019une organisation \u00e0 l\u2019autre, la plupart suivent le m\u00eame chemin de base. Examinons le processus et les \u00e9tapes de la gestion des incidents SRE.<\/p>\n

<\/p>\n

1. Identification de l\u2019incident<\/h3>\n

Vous ne pouvez pas r\u00e9soudre les probl\u00e8mes que vous ne connaissez pas. L\u2019identification des incidents commence par une certaine forme de surveillance ou de m\u00e9canisme d\u2019alerte. Nous avons parl\u00e9 de la surveillance des syst\u00e8mes distribu\u00e9s<\/a> dans un autre article et de la fa\u00e7on dont cela se rapporte aux \u00e9quipes SRE. Savoir quand et o\u00f9 une erreur, un temps d\u2019arr\u00eat ou une latence d\u2019application se produit est un facteur essentiel pour limiter l\u2019impact sur les utilisateurs et les clients. Cependant, dans certains cas, un incident sera connu par le biais d\u2019un ticket d\u2019assistance, d\u2019un appel t\u00e9l\u00e9phonique ou m\u00eame des m\u00e9dias sociaux, ce qui n\u2019est jamais une bonne nouvelle lorsque les probl\u00e8mes sont publi\u00e9s publiquement pour que tout le monde le sache.<\/p>\n

<\/p>\n

2. Enregistrement des incidents<\/h3>\n

Quelle que soit la m\u00e9thode de d\u00e9tection, une fois qu\u2019un incident a \u00e9t\u00e9 identifi\u00e9, il doit \u00eatre enregistr\u00e9. La journalisation des incidents sert \u00e0 plusieurs fins. Il s\u2019assure qu\u2019il y a un dossier officiel qui a \u00e9t\u00e9 soumis et pour examiner les tendances des incidents plus tard. Si le m\u00eame incident, ou un incident similaire, appara\u00eet \u00e0 plusieurs reprises, cela pourrait indiquer un probl\u00e8me plus complexe qui doit \u00eatre r\u00e9solu. Lors de la journalisation d\u2019un incident, des informations pertinentes sont \u00e9galement incluses, telles que l\u2019horodatage, la description de l\u2019incident et la personne qui a d\u00e9couvert le probl\u00e8me. Plus les informations sont d\u00e9taill\u00e9es, mieux c\u2019est.<\/p>\n

<\/p>\n

3. Cat\u00e9gorisation de l\u2019incident<\/h3>\n

Vient ensuite la cat\u00e9gorisation de l\u2019incident en fonction de facteurs tels que la gravit\u00e9, l\u2019urgence ou la zone fonctionnelle touch\u00e9e. Comme l\u2019enregistrement de l\u2019incident, plus d\u2019informations fournies peuvent aider plus tard \u00e0 d\u00e9terminer la bonne \u00e9quipe ou la bonne personne \u00e0 affecter \u00e0 la r\u00e9ponse \u00e0 l\u2019incident.<\/p>\n

<\/p>\n

4. Hi\u00e9rarchisation des incidents<\/h3>\n

En fonction de la fa\u00e7on dont l\u2019incident a \u00e9t\u00e9 cat\u00e9goris\u00e9, l\u2019\u00e9tape suivante consiste \u00e0 d\u00e9finir le niveau de priorit\u00e9. Encore une fois, certaines de ces \u00e9tapes se produisent en m\u00eame temps, de sorte que dans certains cas, elles peuvent \u00eatre effectu\u00e9es en m\u00eame temps. Les organisations utilisent g\u00e9n\u00e9ralement une \u00e9chelle simple de faible, moyen ou \u00e9lev\u00e9, cependant, certains incidents peuvent automatiquement tomber dans des cat\u00e9gories sp\u00e9cifiques en fonction de ce qui est affect\u00e9. Par exemple, si l\u2019incident est li\u00e9 \u00e0 une panne, celle-l\u00e0 tomberait automatiquement en priorit\u00e9 \u00e9lev\u00e9e.<\/p>\n

<\/p>\n

5. Intervention, r\u00e9solution et fermeture des incidents<\/h3>\n

La derni\u00e8re \u00e9tape consiste enfin \u00e0 r\u00e9agir et \u00e0 r\u00e9soudre l\u2019incident pour apporter la cl\u00f4ture. Cette derni\u00e8re \u00e9tape est plus une forme d\u2019art qu\u2019une science. Il n\u2019y a pas de bouton facile ici. Cela peut prendre plusieurs cycles et tente de confirmer que l\u2019incident est finalement r\u00e9solu. Chaque tentative peut apporter plus d\u2019informations et de th\u00e9ories suppl\u00e9mentaires sur les raisons pour lesquelles l\u2019incident peut se produire. Cela peut \u00e9galement conduire \u00e0 identifier d\u2019autres opportunit\u00e9s o\u00f9 des faiblesses peuvent \u00eatre pr\u00e9sentes. Une fois l\u2019incident trait\u00e9, il est temps de fermer la demande et de r\u00e9pondre \u00e0 l\u2019utilisateur d\u2019origine qui a signal\u00e9 l\u2019incident.<\/p>\n

<\/p>\n

Post-mortems<\/h2>\n

Apr\u00e8s une r\u00e9ponse \u00e0 un incident, il est g\u00e9n\u00e9ralement judicieux d\u2019examiner les d\u00e9tails de l\u2019incident dans leur int\u00e9gralit\u00e9. C\u2019est ce qu\u2019on appelle un incident post-mortem. D\u00e9terminer quels incidents n\u00e9cessitent une autopsie sont g\u00e9n\u00e9ralement d\u00e9cid\u00e9s par l\u2019\u00e9quipe ou l\u2019organisation, mais les raisons restent les m\u00eames. Les autopsies aident \u00e0 identifier les domaines qui peuvent \u00eatre am\u00e9lior\u00e9s, \u00e0 identifier les angles morts de performance et \u00e0 affiner votre processus de r\u00e9ponse aux incidents. Une autopsie doit r\u00e9sumer tous les aspects de l\u2019incident et inclure les \u00e9l\u00e9ments suivants :<\/p>\n