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.
Identification des incidents
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.
Journalisation 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.
Catégorisation des incidents
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.
Priorisation 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.
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.
Gestion des incidents SRE : outils et services
Aujourd’hui, les SRE ont apparemment un accès et des opportunités illimités à un large éventail d’outils, de plates-formes et de services pour les aider à automatiser et à gérer leur charge de travail. Certains de ces outils que nous avons déjà couverts dans un autre article, mais nous discuterons spécifiquement des outils de gestion des incidents SRE.
Lire: Top 13 des outils d’ingénieur en fiabilité de site (SRE)
Outils d’incident, d’alerte et de communication
Les outils de gestion des incidents, de communication et d’alerte peuvent être parmi les outils les plus importants utilisés par les équipes SRE. Plus tôt votre équipe est au courant, plus vite l’incident peut être pris en charge. Ces outils doivent être utilisés avec votre stratégie de surveillance. La plate-forme Dotcom-Monitor s’intègre à ces outils (et plus encore), offrant un moyen transparent d’intégrer les outils que vos équipes utilisent peut-être déjà avec vos objectifs de surveillance et d’observabilité.
PagerDuty Page
PagerDuty peut aider à identifier et à déclencher des alertes en fonction des exigences de surveillance spécifiques d’une organisation. En automatisant l’étape d’identification des incidents, les équipes peuvent réduire la quantité de surveillance manuelle et le temps nécessaire pour commencer le processus de gestion des incidents. Les bonnes équipes sont informées immédiatement, ce qui signifie que la réponse aux incidents peut se produire dès que possible.
VictorOps
VictorOps, désormais Splunk On-Call, est une plate-forme d’automatisation des incidents qui aide à réduire le temps nécessaire à la résolution des incidents, offrant aux équipes SRE et DevOps un moyen de gérer efficacement leur processus de réponse aux incidents. Splunk On-Call peut également vous aider à simplifier les calendriers d’appel et les politiques d’escalade des incidents.
lâche
Bien qu’il ne s’agit pas d’un véritable outil de réponse aux incidents, la communication est un facteur important au cours du processus de réponse aux incidents. L’une des applications de chat les plus reconnaissables et les plus populaires du marché, Slack offre aux équipes SRE la fonctionnalité nécessaire pour rassembler toutes les communications dans un seul tableau de bord. Idéal pour la communication interentreprises, Slack peut également automatiser les réponses et les événements et même se connecter à d’autres systèmes et services.
Équipes Microsoft
Si votre organisation utilise Office 365, vous connaissez probablement déjà Microsoft Teams. Comme Slack, Microsoft est une application de communication en temps réel qui offre des fonctionnalités telles que la messagerie en ligne, le chat vidéo et le partage de documents.
OpsGenie
Autre solution de réponse aux incidents, OpsGenie offre aux équipes la possibilité de mettre en place et de configurer des alertes automatisées via des groupes et des mécanismes de filtrage. En outre, les SRE peuvent gérer les règles de routage sur appel et les stratégies d’escalade spécifiques. OpsGenie fournit également des fonctionnalités telles que des rapports et des analyses afin que les équipes puissent afficher et suivre les mesures et l’efficacité de la réponse aux incidents.
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 pendant 30 jours et accédez à toutes les solutions, intégrations et fonctionnalités de la plate-forme.
