In the world of a site reliability engineer (SRE), failure is not only an option, but also expected. Les systèmes, les applications Web, les serveurs, les périphériques, etc., sont tous sujets à des problèmes de performances et à des pannes inattendues à un moment donné. C’est un fait inévitable. Ces échecs inattendus peuvent entraîner d’énormes pertes de revenus, la confiance des clients et, selon l’industrie, peut-être des amendes. Heureusement, la gestion des incidents SRE est l’une des pratiques de base utilisées pour limiter les perturbations causées par des problèmes inattendus. Dans un autre article, nous avons parlé de l’ingénierie du chaos et de la façon dont les équipes SRE recherchent et testent de manière proactive les échecs pour éviter que le pire ne se produise. Cependant, comme nous le sommes tous conscients, les problèmes peuvent passer entre les mailles du filet. L’objectif est d’éviter que ces incidents ne se deviennent des défaillances en cascade à grande échelle. Les équipes SRE et DevOps peuvent utiliser ces incidents pour mieux reconstruire et améliorer leurs systèmes et services.
Qu’est-ce qu’un incident?
Avant d’approfondir ce sujet, nous devons d’abord discuter de ce qu’est un incident. Où se situe la ligne de démarcation entre quelque chose qui nécessite une action immédiate et quelque chose qui peut faire l’objet d’une enquête plus tard? Si chaque problème était classé comme urgent, personne n’obtiendrait de solution. Dans le contexte de la TI (technologie de l’information), un incident est simplement un événement ou un problème qui perturbe le fonctionnement normal ou la qualité du service. Cela n’a pas entraîné d’échec, mais s’il n’est pas contrôlé, il a la possibilité d’avoir un impact plus important sur vos services et vos opérations. Et ils se produisent généralement à 2h00 du matin pendant que vous dormez béatement et que vous êtes réveillé par le son de votre téléphone qui s’éteint. Nous plaisantons bien sûr, mais vous savez que quelque chose ne va pas si cela se produit si tôt le matin. Rien de bon ne se passe à 2h00 du .m., surtout quand on parle de l’industrie informatique.
Qu’est-ce que la gestion des incidents ?
Maintenant que nous avons parlé de ce qu’est un incident, la gestion des incidents est le processus par lequel les équipes résolvent ces événements et ramènent les systèmes et les services à un fonctionnement normal. Il convient également de noter que la gestion des incidents n’est qu’un élément d’un concept plus large connu sous le nom de gestion des services informatiques, ou ITSM. ITSM définit la façon dont les équipes conçoivent, créent et fournissent leurs services. C’est bien plus qu’un simple support informatique. L’ITSM est la politique, les processus et la structure qui sous-tendent le cycle de vie des services informatiques. L’ITSM est l’une des pratiques de la Bibliothèque de l’infrastructure des technologies de l’information, ou ITIL.
ITIL fournit le cadre et les lignes directrices pour la création de solutions ITSM. Vous connaissez peut-être déjà d’autres frameworks, tels que Business Process Framework (eTOM), Control Objectives for Information and Related Technologies (COBIT), FitSM, ISO/IEC 20000 et Microsoft Operations Framework (MOF).
Le cadre de gestion des services informatiques (ITSM)
Si nous prenons un peu de recul et que nous nous concentrons un peu sur les éléments du cadre ITSM, il y a six autres composants qui composent la «roue» ITSM avec la gestion des incidents. Bien que nous n’entrons pas dans les détails à ce sujet, il est important de comprendre comment tous ces éléments s’intègrent avec la gestion des incidents.
Catalogue de services
Le catalogue de services informatiques est généralement une base de données ou une ressource qu’une organisation crée pour fournir aux utilisateurs des informations sur leurs services et offres opérationnels. Ces catalogues de services fournissent des informations utiles sur les services actuels et prévus, ainsi que sur les prix, le processus d’achat, les points de contact et d’autres livrables.
Centre de services
Le centre de services peut être considéré comme le point de contact entre le fournisseur de services et les utilisateurs, tels que les employés internes, les parties prenantes ou les clients. C’est le «hub» central où les utilisateurs se rendent pour obtenir de l’aide et des services. Selon la définition ITIL, le centre de services peut prendre la forme d’une résolution d’incident ou de demandes de service, mais quoi qu’il en soit, l’objectif principal du centre de services est de fournir un service rapide et efficace.
Gestion des problèmes
Lorsque nous parlons de gestion des incidents, une équipe SRE peut être en mesure de résoudre rapidement un incident, mais le problème sous-jacent peut toujours exister et persister pendant un certain temps encore. La gestion des problèmes est le processus par lequel les causes profondes des incidents sont définitivement corrigées, ce qui améliore les performances à long terme et les déploiements de services futurs.
Gestion du changement
Tout type de changement, qu’il s’agisse de nouveaux déploiements de services ou de changements personnels, il y a toujours un élément de risque. La gestion du changement est le processus qui consiste à déterminer comment les changements affecteront le déploiement du service et/ou à prendre en compte les effets sur l’entreprise elle-même. La gestion du changement est également parfois regroupée avec la gestion des versions.
Gestion d’actifs
Vous ne pouvez pas tout virtualiser… encore. Les services logiciels nécessitent toujours des périphériques physiques et du matériel pour fonctionner. Et les organisations doivent suivre, gérer et continuellement mettre à jour ces appareils pour s’assurer que leurs services peuvent fonctionner correctement. La gestion des actifs est également appelée gestion des actifs informatiques, ou ITAM.
Gestion des connaissances, des politiques et des procédures
L’objectif de la gestion des connaissances est de réduire la redondance en termes de collecte, d’examen et de partage d’informations au sein d’une organisation. Cela permet d’améliorer l’efficacité et de garantir que les informations sont cohérentes, à jour et disponibles.
Lifecyle de gestion des incidents : processus et étapes
La réponse d’une organisation à un incident, qu’il s’agisse de temps d’arrêt, de failles de sécurité ou de cyberattaques, ou même de latence prolongée et d’erreurs répétées, est essentielle au succès continu de l’entreprise et à la confiance du client ou de l’utilisateur final. Les SRE doivent gérer des systèmes distribués complexes. Bien que les avantages de ces systèmes soient qu’ils sont plus fiables, évolutifs et tolérants aux pannes, cela les rend également extrêmement complexes, ce qui peut entraîner des temps de correction plus longs, car les problèmes sont plus difficiles à détecter et à identifier. Les meilleures équipes de gestion des incidents SRE adhèrent à un processus strict de gestion et de correction des incidents. Bien que les étapes et les processus réels puissent varier d’une organisation à l’autre, la plupart suivent le même chemin de base. Examinons le processus et les étapes de la gestion des incidents SRE.
1. Identification de l’incident
Vous ne pouvez pas résoudre les problèmes que vous ne connaissez pas. L’identification des incidents commence par une certaine forme de surveillance ou de mécanisme d’alerte. Nous avons parlé de la surveillance des systèmes distribués dans un autre article et de la façon dont cela se rapporte aux équipes SRE. Savoir quand et où une erreur, un temps d’arrêt ou une latence d’application se produit est un facteur essentiel pour limiter l’impact sur les utilisateurs et les clients. Cependant, dans certains cas, un incident sera connu par le biais d’un ticket d’assistance, d’un appel téléphonique ou même des médias sociaux, ce qui n’est jamais une bonne nouvelle lorsque les problèmes sont publiés publiquement pour que tout le monde le sache.
2. Enregistrement des incidents
Quelle que soit la méthode de détection, une fois qu’un incident a été identifié, il doit être enregistré. La journalisation des incidents sert à plusieurs fins. Il s’assure qu’il y a un dossier officiel qui a été soumis et pour examiner les tendances des incidents plus tard. Si le même incident, ou un incident similaire, apparaît à plusieurs reprises, cela pourrait indiquer un problème plus complexe qui doit être résolu. Lors de la journalisation d’un incident, des informations pertinentes sont également incluses, telles que l’horodatage, la description de l’incident et la personne qui a découvert le problème. Plus les informations sont détaillées, mieux c’est.
3. Catégorisation de l’incident
Vient ensuite la catégorisation de l’incident en fonction de facteurs tels que la gravité, l’urgence ou la zone fonctionnelle touchée. Comme l’enregistrement de l’incident, plus d’informations fournies peuvent aider plus tard à déterminer la bonne équipe ou la bonne personne à affecter à la réponse à l’incident.
4. Hiérarchisation des incidents
En fonction de la façon dont l’incident a été catégorisé, l’étape suivante consiste à définir le niveau de priorité. Encore une fois, certaines de ces étapes se produisent en même temps, de sorte que dans certains cas, elles peuvent être effectuées en même temps. Les organisations utilisent généralement une échelle simple de faible, moyen ou élevé, cependant, certains incidents peuvent automatiquement tomber dans des catégories spécifiques en fonction de ce qui est affecté. Par exemple, si l’incident est lié à une panne, celle-là tomberait automatiquement en priorité élevée.
5. Intervention, résolution et fermeture des incidents
La dernière étape consiste enfin à réagir et à résoudre l’incident pour apporter la clôture. Cette dernière étape est plus une forme d’art qu’une science. Il n’y a pas de bouton facile ici. Cela peut prendre plusieurs cycles et tente de confirmer que l’incident est finalement résolu. Chaque tentative peut apporter plus d’informations et de théories supplémentaires sur les raisons pour lesquelles l’incident peut se produire. Cela peut également conduire à identifier d’autres opportunités où des faiblesses peuvent être présentes. Une fois l’incident traité, il est temps de fermer la demande et de répondre à l’utilisateur d’origine qui a signalé l’incident.
Post-mortems
Après une réponse à un incident, il est généralement judicieux d’examiner les détails de l’incident dans leur intégralité. C’est ce qu’on appelle un incident post-mortem. Déterminer quels incidents nécessitent une autopsie sont généralement décidés par l’équipe ou l’organisation, mais les raisons restent les mêmes. Les autopsies aident à identifier les domaines qui peuvent être améliorés, à identifier les angles morts de performance et à affiner votre processus de réponse aux incidents. Une autopsie doit résumer tous les aspects de l’incident et inclure les éléments suivants :
- Résumé général et chronologie de l’incident.
- Analyse des causes profondes et source de l’incident.
- Mesures prises pour résoudre l’incident et lesquelles ont été efficaces ou non.
- Prévention des incidents futurs ainsi que des informations supplémentaires qui ont été découvertes.
Les autopsies sont l’une des règles fondamentales de la culture SRE. En fait, ils appellent cela un post-mortem irréprochable. L’idée derrière ce concept est que tous les membres de l’équipe ont agi avec les meilleures intentions et que personne n’est à blâmer pour l’incident. L’accent est mis sur l’identification des raisons pour lesquelles cela s’est produit et sur la façon d’améliorer les performances du système à l’avenir. Les erreurs font naturellement partie de l’industrie, donc au lieu de blâmer les individus, l’accent est mis sur la création d’un système plus robuste et résilient afin que les problèmes ne se reproduisent plus jamais.
Conclusion : Gestion des incidents SRE – Vue d’ensemble, techniques et outils
La gestion des incidents SRE est essentielle pour maintenir les systèmes, les applications, les sites et les services opérationnels. Les secondes comptent, surtout quand il s’agit de l’expérience de l’utilisateur. Dans les grands systèmes distribués, le plus petit problème peut causer des problèmes en cascade. La mise en place proactive des bonnes alertes et notifications peut faire la différence lorsque des problèmes se produisent et garantir que l’impact sur les utilisateurs est limité. Pour plus d’informations sur la façon dont la plate-forme Dotcom-Monitor s’intègre à ces outils de gestion des incidents, veuillez consulter notre base de connaissances.
Essayez Dotcom-Monitor gratuitement et accédez à toutes les solutions, intégrations et fonctionnalités de la plateforme.
