Famille de processus
Processus de gestion des services informatiques : modèles d'incidents, de…
La famille de gestion des services informatiques : gestion des incidents, gestion des changements ITIL et publication de logiciels en une seule chaîne, avec le service d'assistance, la classification de la gravité, le tri des bogues, le…
La gestion des services informatiques est la partie exécution de l'informatique. Une interruption est enregistrée et le service restauré, le correctif permanent est généré sous forme de demande de modification et une modification autorisée atteint la production via une version. Les trois modèles de la séquence sont ces transferts ; les sept qui les entourent sont les files d'attente et les cycles qui alimentent le travail : service d'assistance, gravité, bogues, déploiement, correctifs, vulnérabilités et enregistrement des modifications SOC 2.
Un incident arrive sous forme de contact utilisateur ou d'alerte. Le service d'assistance l'enregistre, le sépare d'une demande de service, corrige ce qu'il peut en première ligne et transmet le reste à gestion des incidents : définir la priorité, ouvrir le pont d'incident majeur s'il en est un, diagnostiquer par rapport à l'objectif SLA, restaurer le service, fermer lorsque l'utilisateur confirme. Si la cause première est encore inconnue à la clôture, la dernière étape génère un enregistrement de problème. Le correctif permanent est élevé en tant que RFC et entre gestion du changement comme standard, normal ou urgence : évaluation d'impact, plan de rollback, le CAB ou l'ECAB, le calendrier des modifications, une revue post-implémentation.
Lorsque le changement est logiciel, le processus de libération fait passer la construction du gel de la portée à la porte de test automatisée, au staging et à l'UAT jusqu'au go/no-go, à la fenêtre de publication, aux tests de fumée et à la période d'absorption, avec des branches de restauration et de correctifs. Le modèle de déploiement couvre les mécanismes que suppose l'approbation : contrôle de qualité, promotion du registre, vérifications intermédiaires, bleu-vert ou canari, et restauration lorsque le budget d'erreurs est dépassé. Le tri des bogues est la prise en compte des défauts derrière les deux : la reproduction, la vérification des doublons, la gravité et la priorité, la révision du code et la vérification de l'assurance qualité, et un défaut de production déclenche un incident plutôt que d'attendre le retard.
Les échecs habituels sont au niveau des coutures. Priorité argumentée au cas par cas : l'arbre de classification de gravité fixe P1 à P4 à partir de quatre questions, indisponible ou dégradé, combien d'utilisateurs ou de sites, fonction critique ou revenus bloqués, données ou exposition sécurité, donc les mêmes preuves donnent le même niveau. Correctifs appliqués sans enregistrement : le flux de travail de modification SOC 2 CC8.1 est le même tableau RFC à révision avec une approbation enregistrée à chaque porte ; la gestion des correctifs effectue l'avis de routine, d'urgence ou mensuel, test de régression, fenêtre autorisée, sonnerie pilote en premier, nouvelle analyse ; la gestion des vulnérabilités est l'autre apport, les analyses authentifiées, la notation CVSS, les bandes SLA, la nouvelle analyse avant la fermeture, les découvertes en retard ont augmenté.
Il manque une étape : il n’existe pas encore de modèle de gestion des problèmes ITIL. Le modèle d'incident et le service d'assistance se terminent par « Créer un enregistrement de problème », et rien ici ne le reçoit, donc l'itinéraire d'un incident récurrent à une erreur connue n'est pas tracé ; ce qui s'en rapproche le plus est l'analyse des causes profondes dans la famille de la qualité, qui relève du CAPA, et non d'un changement. Une alerte de sécurité exécute la même forme de journalisation, de classification et d'escalade avec confinement et notification au lieu de restauration et de fermeture : c'est-à-dire Réponse aux incidents de sécurité, et l'arborescence de gravité sert les deux. La discipline du changement ici est le membre informatique de la famille plus large des Changer le contrôle, aux côtés de l'ingénierie, du laboratoire et du changement SOP.
La séquence
Étape 1: Organigramme du processus de gestion des incidents
Un organigramme de processus de gestion des incidents interfonctionnels couvrant la journalisation, la priorisation, l'escalade des incidents majeurs, la violation des SLA, la résolution et la clôture.
Étape 2: Diagramme du processus de gestion des changements (ITIL)
Diagramme du processus de gestion des changements ITIL : accueil des RFC, tri standard, normal et urgence, approbation du CAB, planification, déploiement et retour arrière.
Étape 3: Organigramme du processus de publication du logiciel
Un organigramme du processus de publication de logiciels couvrant le gel de la portée, la porte de test automatisée, la préparation et l'UAT, l'approbation go/no-go, le déploiement, la restauration et les correctifs.
Également dans cette famille
- Organigramme de classification de la gravité des incidents — Un organigramme de classification de la gravité des incidents : un arbre de décision prenant en compte les tests de disponibilité, de portée, d'impact commercial et d'exposition jusqu'à P1, P2, P3 ou P4.
- Organigramme du processus d'assistance informatique (incidents et demandes) — Organigramme des processus du service d'assistance informatique : une file d'attente pour les incidents et les demandes de service, avec triage, priorité, résolution de première ligne, escalade de niveau 2, exécution et clôture.
- Diagramme du processus de tri des anomalies — Diagramme du processus de tri des anomalies : réception, reproduction, vérification des doublons, gravité et priorité, escalade, correction, revue de code, vérification QA et mise en production.
- Organigramme du processus de déploiement de logiciels : de la conception à la… — Un organigramme du processus de déploiement de logiciels : créer et versionner l'artefact, contrôle de qualité, promotion du registre, vérifications intermédiaires, déploiement Canari, restauration automatique.
- Organigramme du processus de gestion des correctifs (tester, approuver,… — Modèle d'organigramme de gestion des correctifs : réception et applicabilité des conseils, triage d'urgence ou de routine, tests de régression, autorisation de modification, déploiement en anneau, restauration, vérification de nouvelle…
- Organigramme du processus de gestion des vulnérabilités (analyse jusqu'à la… — Modèle de diagramme de gestion des vulnérabilités : étendue et couverture de l'analyse, analyses authentifiées, triage et faux positifs, CVSS et évaluation des exploits, bandes SLA, vérification de nouvelle analyse, exceptions et…
- Workflow de gestion des changements informatiques (SOC 2 CC8.1) — Un workflow de gestion des changements informatiques compatible SOC 2 : demande de changement, évaluation d'impact, approbation, tests, déploiement, examen post-implémentation, avec signatures d'approbation capturées par porte.
Guides associés
- Comment créer un processus de contrôle des changements — Comment concevoir un processus de contrôle des modifications : définissez vos catégories de modifications, gardez la liste pré-approuvée courte, exigez un plan de restauration et tracez la voie d'urgence plutôt que de prétendre qu'elle…
- Comment créer un organigramme de décision — Comment créer un organigramme de décision : rédiger chaque décision sous forme de question, rendre les sorties exhaustives et exclusives, énoncer les critères et donner une fin à chaque résultat. Avec un exemple de tri de bogues en direct.
- Comment créer un organigramme SOP — Comment créer un organigramme SOP : une procédure par diagramme, des étapes numérotées, des points de décision avec des critères énoncés et une version approuvée sous contrôle des modifications. Avec un exemple concret de réponse à…
- Comment créer un processus de gestion des incidents — Comment concevoir un processus de gestion des incidents où la gravité évalue tout en aval : classer avant de diagnostiquer, tracer une reclassification en tant qu'itinéraire et transférer la cause dans un enregistrement distinct.