Le Gestionnaire de problèmes identifie la cause première et élimine les problèmes récurrents

Cas d'utilisation en un coup d'œil

Personne : Un gestionnaire de problèmes responsable de l'identification des causes systémiques, de la coordination des enquêtes et de la prévention des interruptions de service récurrentes

Tâche à accomplir : Connectez les incidents récurrents à un seul enregistrement de problème, déterminez et documentez la cause première, et pilotez une résolution permanente ou une décision de risque explicite

Point de départ : L'historique des incidents, les données de service ou les tendances opérationnelles indiquent qu'une interruption identique ou associée est récurrente

Résultat positif : Le problème fait l'objet d'une analyse des causes profondes étayée, les incidents connexes et les enregistrements de mesures correctives sont traçables, les utilisateurs affectés ont approuvé des lignes directrices et les preuves postérieures au changement montrent que la récurrence ou l'impact a diminué.

Utilisez ce scénario pour déterminer si un problème récurrent est compris et contrôlé. Utilisez les rubriques d'aide associées pour les étapes de création et d'association d'enregistrements, de mise à jour de l'analyse des problèmes, de documentation d'une solution de contournement, de création d'une demande de modification, d'acceptation des risques, de réouverture d'un problème et de fermeture.

Détection d'un modèle qui mérite d'être examiné

Commencez par la preuve d'un état sous-jacent partagé plutôt que par le nombre d'incidents seulement. Comparez les symptômes, les signatures d'erreur, les services et les éléments de configuration affectés, le calendrier, les modifications récentes, les populations d'utilisateurs, les résolutions et les récurrences après la restauration du service. Des formulations similaires peuvent décrire différentes causes, alors que des incidents de formulation différente peuvent avoir pour origine le même échec.

Utilisez des tableaux de bord de problème pour rechercher des tendances, des travaux en cours, des infractions aux accords de niveau de service (SLA), des enregistrements non attribués, des temps de résolution et des modèles de code de résolution. Traitez les informations du tableau de bord comme une piste d'enquête plutôt que comme une preuve que les incidents partagent une cause. Pour plus d'informations sur les métriques de tableau de bord, consultez Problem Manager Dashboard for IT Services.

Établissement du problème sans retarder la récupération

La Gestion des incidents restaure le service pour chaque interruption active. Gestion des problèmes recherche et retire la cause systémique. Gardez ces résultats séparés : un incident peut être résolu par une solution de contournement alors que son problème associé reste ouvert, et un problème ne doit pas être fermé simplement parce que le dernier incident a cessé d'affecter les utilisateurs.

Créez ou sélectionnez un problème qui décrit la condition récurrente à l'étendue appropriée. Confirmez l'objet, la description, la catégorie, la sous-catégorie, les services et les indicateurs de performance affectés, l'impact, l'urgence, la priorité, le propriétaire et le statut d'enquête. Associez les incidents de support et les autres problèmes pertinents, les demandes de modification, les versions ou les articles Knowledge afin de permettre aux enquêteurs de distinguer les preuves des coïncidences.

Évitez de créer un problème pour chaque incident ou un problème général pour les échecs non liés. Utilisez des associations telles que Causé par et similaire uniquement lorsque les preuves disponibles appuient la relation.

Si l'action proactive Associer des problèmes similaires est activée, elle peut automatiquement associer des enregistrements de problème en fonction de la similarité sémantique. Une association similaire n'établit pas de relation Causée par. Examinez automatiquement les problèmes associés avant de les utiliser comme preuve d'une cause profonde partagée.

Pour associer des enregistrements manuellement, ouvrez le problème. Sous l'onglet Associations, cliquez sur Associer, puis sélectionnez un Type d'enregistrement et un Type de relation, par exemple Provoqué par ou similaire. Le retrait d'une association ne supprime pas l'enregistrement associé. Résoudre est séparé de la liaison et peut fermer plusieurs enregistrements associés. Par conséquent, vérifiez les enregistrements sélectionnés avant de cliquer sur Résoudre.

Pour connaître les étapes de création et d'association de problèmes, de résolution de problèmes, d'acceptation de risques et de réouverture de problèmes, consultez Gestion des problèmes pour les services informatiques. Pour créer un problème directement à partir d'un incident, consultez Gestion des incidents pour les services informatiques.

Recherche et établissement de la cause première

Élaborez une explication testable à partir des chronologies des incidents, des journaux, de la télémétrie, des données de configuration et d'actifs, des modifications récentes, des erreurs connues, des articles Knowledge et de l'expertise en la matière. Reproduisez l'échec en toute sécurité si possible. Comparez les conditions affectées et non affectées, contestez les explications concurrentes et enregistrez les preuves qui confirment ou rejettent chaque hypothèse.

Documentez la chaîne causale au lieu de reformuler le symptôme. Expliquez la condition défaillante, les raisons pour lesquelles elle a produit l'impact observé, la portée affectée et les conditions dans lesquelles le problème peut se reproduire. Citez les enregistrements ou les tests qui appuient la conclusion. Marquez les hypothèses non résolues et attribuez un travail de suivi au lieu de présenter l'inférence comme un fait.

Suivez le jalon racine configuré sans compromettre la qualité de l'enquête. Le SLA Problème standard suit les temps de réalisation des causes premières des problèmes critiques et prioritaires, mais les stratégies de votre organisation peuvent différer. La réalisation du jalon ne prouve pas que l'analyse est correcte. Consultez Stratégie d'accord de niveau de service pour les problèmes des services TI. Stratégie d'accord de niveau de service pour les problèmes des services informatiques

Réduction de l'impact avec une solution de contournement ou une erreur connue

Lorsqu'une méthode temporaire sûre réduit les interruptions, documentez son applicabilité, les prérequis, les étapes, les limitations, les risques et les résultats de vérification dans les informations de contournement du problème. Mettez le guide à la disposition des exécutants d'incidents afin qu'ils puissent restaurer le service de façon cohérente pendant que la résolution permanente est en attente.

Créez ou mettez à jour un article Knowledge sur une erreur connue lorsqu'une cause profonde confirmée et une solution de contournement réutilisable doivent être disponibles au-delà de l'enregistrement du problème. Retirez les détails spécifiques à un enregistrement et confidentiels, acheminez l'article à travers le processus de révision configuré et vérifiez que l'audience de support cible peut le trouver. Une solution de contournement contrôle les symptômes ou l'impact ; elle n'élimine pas la cause sous-jacente.

Si aucune solution de contournement sûre n'existe, déclarez explicitement et renforcez la surveillance, l'escalade, la communication et la préparation au rétablissement. Utilisez un article Knowledge pour mettre à la disposition du public cible une solution de contournement temporaire vérifiée. Consultez Principaux workflows dans Services TI.

Élimination de la cause par un changement contrôlé

Lorsque des preuves suffisantes confirment la cause première et la correction, créez et associez une demande de modification à partir du problème. Incluez la portée affectée, les preuves causales, le correctif proposé, les exigences d'implémentation, le plan de test, l'approche de restauration, les contraintes de planification et les critères de vérification. Laissez le problème ouvert pendant que la modification progresse par l'évaluation des risques, l'approbation, la planification, la mise en œuvre et la vérification.

Le résultat de la modification doit tester la réclamation causale. Vérifiez que l'état ciblé a changé comme prévu, que l'état de santé du service est demeuré acceptable, que l'annulation n'était pas requise ou a réussi, et qu'aucun effet secondaire important n'est apparu. Une modification implémentée avec succès ne suffit pas si l'échec récurrent persiste.

Lorsqu'une solution permanente n'est pas réalisable, utilisez Accept Risk uniquement lorsque les parties prenantes appropriées comprennent l'impact résiduel, la probabilité, les contrôles actuels, la propriété et les conditions d'examen. Enregistrez la justification et les conditions qui déclenchent la surveillance ou la réouverture. L'acceptation du risque est une décision régie, qui ne remplace pas une analyse incomplète. Pour les étapes de demande de modification et d'acceptation des risques, consultez Gestion des problèmes pour les services informatiques.

Vérification de la réduction et de la fermeture des récurrences

Observez le service pendant une période et un volume adaptés au modèle de récurrence d'origine. Comparez la fréquence des incidents avant et après la résolution, les utilisateurs ou les transactions affectés, les taux d'erreur, les temps d'arrêt, l'utilisation de contournement, les efforts de support et les résultats au niveau du service. Tenez compte de la saisonnalité, du trafic, des versions et des changements de rapport avant d'attribuer une amélioration au correctif.

Fermez le problème uniquement lorsque l'enregistrement contient la cause première prise en charge, les informations de résolution, les incidents associés et les mesures correctives, les preuves de vérification, le risque restant et Knowledge réutilisable. Résolvez les associations associées selon le processus de votre organisation tout en préservant leur historique. Rouvrir le problème lorsque le problème se répète, lorsque l'explication causale est infirmée ou lorsque de nouvelles preuves changent l'action requise.

La gestion des problèmes réussit lorsqu'une mesure corrective vérifiée ou une décision explicite de risque entraîne une réduction traçable de la récurrence ou de l'impact. Fermer un problème, publier un article ou effectuer une modification seul ne signifie pas que le problème récurrent a été éliminé.

Utiliser l’IA comme assistance, pas comme preuve

Lorsqu'elles sont configurées, Einstein peut rédiger un problème à partir d'un incident, et les actions Agentforce peuvent résumer les problèmes, vérifier les attributs, rechercher les enregistrements associés, proposer des résolutions et rédiger des résumés des causes premières ou des résolutions. Vérifiez les champs et les associations générés avant de les enregistrer ou d'agir en conséquence.

Les résumés générés et les correctifs proposés ne sont pas des preuves à l'origine vérifiées. Confirmez chaque réclamation importante par rapport aux journaux, aux enregistrements, aux tests, aux sources Knowledge approuvées et aux experts. Préservez la distinction entre une correspondance sémantique, une hypothèse plausible et une cause démontrée. Voir Création automatique de problèmes à partir d'incidents avec Einstein, Actions IA pour la gestion des problèmes et Actions proactives pour les problèmes informatiques.

Confirmation de la préparation de la gestion des problèmes

Avant de déployer ce processus plus largement, vérifiez que la Gestion des problèmes et ses validations de champ, matrice de priorité, présentations d'enregistrement, associations, tableaux de bord et accords de niveau de service prennent en charge votre processus. Vérifiez également que les composants Knowledge, Gestion des changements et Base de données de gestion de la configuration (CMDB) requis sont configurés. Einstein, Agentforce et les actions proactives sont des capacités facultatives qui nécessitent une configuration et des autorisations séparées.

Attribuez le groupe d'ensembles d'autorisations Gestionnaire de problèmes ou Réalisateur de problèmes approprié. Attribuez également les autorisations requises pour accepter des risques, rouvrir des problèmes, associer des incidents, des demandes de modification et des versions à des problèmes, et résoudre des associations. Consultez Configuration de Gestion des problèmes pour les services TI et Ensembles d'autorisations Gestion des problèmes pour les services TI.

Validez la configuration avant de la déployer plus largement. Vérifiez qu'un utilisateur autorisé peut trouver des enregistrements et des tableaux de bord de problèmes, inspecter les champs d'analyse et de résolution, et afficher les incidents associés et d'autres associations. Vérifiez que les actions de demande de modification et de risque appropriées sont disponibles pour l'état de l'enregistrement, ainsi que toute assistance Knowledge et IA configurée. Lors du test, quittez tout flux de création, de modification, de questionnaire, de génération, d'approbation ou de fermeture sans enregistrer les modifications.