Gestion des changements et des incidents

Nous avons discuté de la façon dont la création d'une culture agile est devenue une nécessité pour la plupart des organisations et de l'importance d'évaluer la préparation opérationnelle de votre solution. La gestion du changement et la gestion des incidents sont les pierres angulaires de la gestion des opérations informatiques ; et dans un environnement agile où les changements se produisent fréquemment, ce sont des éléments clés de votre organisation.

La gestion des changements et la gestion des incidents sont des pratiques de gestion des services informatiques (ITSM) bien définies qui sont incluses dans le cadre ITIL.

Bien que ces deux sujets ne soient pas intrinsèquement liés, je crois qu'ils sont tellement interconnectés qu'ils devraient être enracinés dans la même prémisse.

La gestion des incidents consiste à disposer d'un processus structuré et bien défini pour répondre à un événement ou à une panne, et la gestion des changements consiste à disposer d'un processus pour évaluer le risque d'apporter un changement dans l'environnement qui pourrait potentiellement provoquer un incident. Si vous n'avez pas les moyens d'évaluer correctement l'impact d'une panne sur votre environnement, comment évaluer correctement le risque d'un changement donné ?

À cette fin, je propose le cadre/flux de travail suivant à titre de référence. Bien que cela puisse sembler un peu complexe au premier abord, l'objectif de ce modèle est de faire des processus d'évaluation de l'impact moins un art, et plus une science, pour éliminer une partie de la subjectivité qui peut gêner lorsqu'une panne est se produisent et les jugements sont assombris par l'urgence du moment.

Personne ne devrait jamais vous reprocher d'avoir un processus établi et bien médiatisé et de le suivre, ils peuvent ne pas être d'accord avec certains détails, mais vous pouvez toujours les inviter à des discussions pour les laisser influencer les changements à l'avenir.

Les feuilles de calcul affichées ci-dessous sont disponibles sous forme de feuille de calcul Google partagée .

Évaluation de l'impact des pannes

L'évaluation des conséquences d'une panne est généralement très subjective. Si, par exemple, l'impact est une panne complète d'un système informatique qui n'a qu'un seul utilisateur, je suis désolé de dire que la réponse de votre personnel informatique sera très différente si cet utilisateur unique est un nouveau stagiaire ou le PDG de l'entreprise. . Un système de développement peut très bien être considéré comme un système de production par vos développeurs s'ils sont incapables de faire leur travail sans ce système. Mais peut-être peuvent-ils se développer sur leur système local ? Cela dépend vraiment de votre situation, et vous devez garder à l'esprit que ce qui est vrai aujourd'hui peut ne plus l'être demain, vous devez réévaluer régulièrement l'importance de ce système.

Encore une fois, la clarté et la transparence sont essentielles, et vous devriez avoir ces discussions et parvenir à un consensus sur le résultat avec les utilisateurs et les parties prenantes du service, peut-être dans un document d'objectif de niveau de service (SLO) bien défini. Si nécessaire, incitez les utilisateurs à fournir et à conserver des informations précises sur la valeur de ce système pour leur équipe, peut-être qu'un système de production a des sauvegardes plus fréquentes mais coûte plus cher par mois.

La cotation d'importance de chaque service doit être effectuée au niveau de l'entreprise, chacun pense que sa Division est plus importante que les autres, et la cotation est relative et doit rester assez objective.

Comprendre et documenter les dépendances dans votre environnement est également essentiel, en particulier avec les microservices. Peut-être que votre service PoC est une dépendance en amont d'un système de production ? La méthodologie C4 (voir Créer des diagrammes à partir de texte ) est assez utile, la documentation est essentielle et vous n'avez pas besoin d'un architecte système pour faire des diagrammes Visio toute la journée, je préférerai un diagramme brut mais précis à un "joli" n'importe quel journée.

Disponibilité

Pour être disponible, un système doit être accessible et utilisable. Si un utilisateur ne peut pas accéder au système, ou si le système est lent ou ne répond pas, il est – du point de vue de l'utilisateur – indisponible. Généralement, le terme temps d'arrêt est utilisé pour désigner les périodes d'indisponibilité d'un système.

Gravité des incidents

La gravité est la quantité de dommages ou de dommages qu'un problème a causés à la disponibilité d'un système, telle qu'elle est vue par l'utilisateur

expérience, mesurée en termes de succès ou d'échec.

Pour déterminer la gravité de l'Incident, choisissez la catégorie pertinente la plus élevée :

Type d'impact de l'incident

Le type d'impact de l'incident prend en compte la fréquence d'occurrence, mesurée par la fréquence à laquelle le problème se produit, ainsi que la persistance du problème, mesurée en observant si les utilisateurs qui rencontrent un problème peuvent apprendre à éviter ou à surmonter le problème à l'avenir. .

Les types sont :

• Maintenu - le problème est constant pour tous les utilisateurs pendant une durée indéterminée
• Temporaire - le problème est constant pour tous les utilisateurs mais seulement pour une durée courte et prédéterminée
• Sporadique - le problème ne se manifeste que "de temps en temps" ou seulement pour certains utilisateurs

La gravité de l'incident, combinée au type d'impact, est utilisée pour sélectionner le multiplicateur du type d'impact.

Choisissez la catégorie pertinente la plus élevée :

Pondération des systèmes touchés et classement de la catégorie d'incident

Les systèmes se voient attribuer une pondération arbitraire des systèmes en fonction de leur niveau relatif de criticité pour l'organisation.

Cette pondération, combinée au multiplicateur de type d'impact , est utilisée pour déterminer le score d'impact .

Choisissez le système impacté avec le score le plus élevé :

La gestion des incidents

Une fois que vous avez une compréhension claire de l'impact d'une panne complète sur un système particulier et que nous avons un moyen de le quantifier, vous pouvez commencer à définir votre processus de gestion des incidents.

Portée

Le processus de gestion des incidents doit être suivi quelle que soit la cause réelle de la panne signalée, qu'elle soit causée par un problème dans votre centre de données interne, ou avec un fournisseur de cloud ou un FAI.

Le processus de gestion des incidents n'est PAS approprié pour les demandes des utilisateurs ou pour le suivi des problèmes avec les systèmes de l'utilisateur ou la configuration locale, il est destiné à suivre les problèmes avec les systèmes institutionnels partagés. Il n'est pas non plus approprié pour les utilisateurs de demander des modifications ou de nouvelles applications, un processus de demande de service doit être mis en œuvre à cette fin.

Objectif

L'objectif de la gestion des incidents est la restauration rapide du ou des services impactés. En fonction de la gravité et de l'impact de la panne, un processus de gestion des problèmes peut être nécessaire pour déterminer la cause première d'un ou d'une série d'incidents connexes, les deux servant un objectif connexe mais distinct.

Pas

1. Détecter
2. Répondre
3. Récupérer
4. Apprendre
5. Améliorer

La note de catégorie d'un incident donné ou d'un incident potentiel est calculée comme un facteur de la gravité de l'incident et du type d'impact qu'il a sur les systèmes impactés . Cette notation est utilisée dans la gestion des incidents (voir page 3) pour déterminer l'étendue de la panne ainsi que dans la gestion des changements2 pour déterminer le risque potentiel des actions en cours.

Le score d'impact du système impacté le plus critique est utilisé pour déterminer l' évaluation de la catégorie d'incident , qui comprend le plan d'action et de communication le plus approprié à la situation.

Classement des catégories d'incidents et plan de communication

L' évaluation du score d'impact détermine la catégorie d'incident et les étapes à suivre pour communiquer et enregistrer correctement l'événement :

Notez que ces actions sont fournies à titre d'exemple, je suis sûr que vous aurez des étapes supplémentaires à inclure.

Gestion du changement

Le processus de gestion des changements doit utiliser exactement les mêmes pondérations des systèmes impactés et le même classement des catégories d'incidents que ceux dont nous avons parlé ci-dessus, la mesure d'une panne de votre organisation n'a pas changé, la seule différence est que nous devons inclure la probabilité que cette panne se produise au cours de la monnaie. Plus à ce sujet ci-dessous, définissons d'abord notre terminologie.

Portée

La gestion du changement s'applique à toutes les modifications apportées à l'un des systèmes informatiques de l'entreprise, sur site ou dans le cloud.

Objectif

Le processus de gestion des modifications utilise le même indice d'impact que le processus de gestion des incidents . L'objectif de la gestion du changement est d'évaluer correctement le niveau de risque de tout changement apporté aux services de l'Organisation afin que les canaux de communication et l'approbation appropriés puissent être suivis. De plus, les objectifs sont également de :

1. Soutenir la mise en œuvre rapide et efficace des changements informatiques requis
2. Gérer adéquatement les risques pour l'Organisation
3. Minimiser l'impact négatif des changements sur/pour l'Organisation
4. Veiller à ce que les changements atteignent les résultats commerciaux souhaités
5. Veiller à ce que les attentes en matière de gouvernance et de conformité soient satisfaites
   

La note de catégorie d'un incident donné ou d'un incident potentiel est calculée comme un facteur de la gravité de l'incident et du type d'impact qu'il a sur les systèmes impactés .

Probabilité

La vraisemblance est la probabilité que le danger se produise et elle est souvent classée sur une échelle de cinq points :

• Certain - 80 à 100% - Un problème se manifestera très probablement pendant ou après le changement
• Probable - 60 à 80 % - Il est probable qu'un problème survienne pendant ou après le changement
• Possible - 40 à 60% - Un problème peut mais ne se produira probablement pas pendant ou après le changement
• Peu probable - 20 à 40 % - Il existe une faible possibilité qu'un problème survienne pendant ou après le changement
• Rare - 0 à 20 % - Il est très peu probable qu'un problème se produise pendant ou après le changement

Le facteur de risque du changement proposé est mesuré en multipliant la cote de catégorie d'incident la plus élevée possible par la probabilité la plus élevée que ce danger se produise :
Risque = Probabilité x Gravité

Lors de l'application de modifications aux systèmes de l'organisation et à l'infrastructure de support, l'équipe informatique évaluera l'impact potentiel de la modification sur la base de la matrice d'évaluation des risques suivante :

Évaluation du risque de changement et plan de communication

En fonction du facteur de risque , ainsi que de l' urgence du changement, l'équipe informatique suivra les étapes suivantes

étapes pour informer les utilisateurs du changement :