El Gestor de problemas identifica la causa raíz y elimina problemas recurrentes

Caso de uso de un vistazo

Persona: Un gestor de problemas responsable de identificar causas sistémicas, coordinar la investigación y evitar interrupciones de servicio recurrentes

Trabajo por hacer: Conecte incidentes recurrentes con un único registro de problema, establezca y documente la causa raíz e impulse una solución permanente o una decisión de riesgo explícita

Punto de inicio: El historial de incidentes, los datos de servicio o las tendencias operativas indican que la misma interrupción o una relacionada es recurrente

Resultado satisfactorio: El problema tiene un análisis de causa raíz compatible, los incidentes relacionados y los registros de corrección son rastreables, los usuarios afectados tienen directrices aprobadas y la evidencia posterior al cambio muestra que la recurrencia o la repercusión disminuyeron.

Utilice este escenario para determinar si se comprende y se controla un problema recurrente. Utilice los temas de Ayuda relacionados para pasos para crear y asociar registros, actualizar análisis de problemas, documentar una solución, crear una solicitud de cambio, aceptar riesgos, reabrir un problema y cerrarlo.

Detectar un patrón que vale la pena investigar

Comience con pruebas de una condición subyacente compartida en vez del número de incidentes solo. Compare síntomas, firmas de errores, servicios afectados y elementos de configuración (IC), cronología, cambios recientes, poblaciones de usuarios, resoluciones y recurrencia tras la restauración del servicio. Una redacción similar puede describir diferentes causas, mientras que incidentes redactados de forma diferente pueden originarse en el mismo fallo.

Utilice tableros de problemas para encontrar tendencias, trabajo abierto, infracciones de acuerdos de nivel de servicio (SLA), registros no asignados, tiempo de resolución y patrones de código de resolución. Trate la información del tablero como un prospecto de investigación en vez de una prueba de que los incidentes comparten una causa. Para obtener detalles acerca de mediciones de tableros, consulte Tablero Gestor de problemas para Servicios de TI.

Establecer el problema sin demorar la recuperación

Gestión de incidentes restaura el servicio para cada interrupción activa. Gestión de problemas investiga y elimina la causa sistémica. Mantenga esos resultados separados: un incidente puede resolverse a través de una solución mientras su problema relacionado permanece abierto, y un problema no debe cerrarse simplemente porque el incidente más reciente dejó de afectar a los usuarios.

Cree o seleccione un problema que describa la condición recurrente en el ámbito apropiado. Confirme su asunto, descripción, categoría, subcategoría, servicios e IC afectados, repercusión, urgencia, prioridad, propietario y estado de investigación. Asocie los incidentes de apoyo y otros problemas relevantes, solicitudes de cambio, versiones o artículos Knowledge de modo que los investigadores puedan distinguir pruebas de coincidencias.

Evite crear un problema para cada incidente o un problema amplio para fallos no relacionados. Utilice asociaciones como Causado por y Similar solo cuando la evidencia disponible admita la relación.

Si la acción proactiva Asociar problemas similares está activada, puede asociar automáticamente registros de problemas basándose en similitud semántica. Una asociación Similar no establece una relación Causada por. Revise automáticamente los problemas asociados antes de utilizarlos como evidencia de una causa raíz compartida.

Para asociar registros manualmente, abra el problema. En la ficha Asociaciones, haga clic en Asociar y, a continuación, seleccione un Tipo de registro y un Tipo de relación, como Causado por o Similar. La eliminación de una asociación no elimina el registro asociado. Resolver está separado de la vinculación y puede cerrar múltiples registros relacionados, de modo que revise los registros seleccionados antes de hacer clic en Resolver.

Para consultar los pasos para crear y asociar problemas, resolver problemas, aceptar riesgos y reabrir problemas, consulte Gestionar problemas para servicios de TI. Para crear un problema directamente desde un incidente, consulte Gestionar incidentes para servicios de TI.

Investigar y establecer la causa raíz

Cree una explicación comprobable a partir de cronologías de incidentes, registros, telemetría, datos de configuración y activos, cambios recientes, errores conocidos, artículos Knowledge y experiencia en la materia. Reproduzca el fallo de forma segura cuando sea posible. Compare condiciones afectadas y no afectadas, impugne explicaciones en competencia y registre qué pruebas confirman o rechazan cada hipótesis.

Documente la cadena causante en vez de volver a indicar el síntoma. Explique la condición con fallo, por qué produjo el impacto observado, el ámbito afectado y las condiciones bajo las que el problema puede repetirse. Cite los registros o pruebas que admiten la conclusión. Marque supuestos no resueltos y asigne trabajo de seguimiento en vez de presentar inferencias como hechos.

Realice un seguimiento del evento clave de causa raíz configurado sin comprometer la calidad de la investigación. El SLA de problemas estándar realiza un seguimiento del tiempo de finalización de causas raíz para problemas de prioridad crítica y alta, pero las políticas de su organización pueden diferir. La finalización del evento clave no prueba que el análisis sea correcto. Consulte Política de SLA para problemas para servicios de TI.

Reducir la repercusión con una solución o un error conocido

Cuando un método temporal seguro reduce las interrupciones, documente su aplicabilidad, requisitos previos, pasos, limitaciones, riesgos y resultados de verificación en la información de solución del problema. Ponga las directrices a disposición de los que realizan incidentes de modo que puedan restaurar el servicio de forma coherente mientras la solución permanente está pendiente.

Cree o actualice un artículo Knowledge acerca de un error conocido cuando una causa raíz confirmada y una solución reutilizable deben estar disponibles más allá del registro del problema. Elimine detalles confidenciales y específicos del registro, enrute el artículo por el proceso de revisión configurado y verifique que la audiencia de asistencia prevista puede encontrarlo. Una solución controla los síntomas o la repercusión; no elimina la causa subyacente.

Si no existe ninguna solución segura, explíquelo explícitamente y fortalezca la preparación de monitoreo, distribución, comunicación y recuperación. Utilice un artículo Knowledge para hacer que una solución temporal verificada esté disponible para la audiencia prevista. Consulte Flujos de trabajo clave en Servicios de TI.

Eliminar la causa a través de cambios controlados

Después de que haya pruebas suficientes que apoyen la causa raíz y la solución, cree y asocie una solicitud de cambio desde el problema. Incluya el ámbito afectado, la evidencia causal, la solución propuesta, los requisitos de implementación, el plan de prueba, el enfoque de reversión, las restricciones de programación y los criterios de verificación. Mantenga el problema abierto mientras el cambio continúa a través de la evaluación, aprobación, programación, implementación y verificación de riesgos.

El resultado del cambio debe probar la reclamación causante. Confirme que la afección dirigida cambió según lo previsto, el estado del servicio siguió siendo aceptable, no se requirió reversión o se realizó con éxito y no aparecieron efectos secundarios significativos. Un cambio implementado correctamente no es suficiente si el fallo recurrente continúa.

Cuando una solución permanente no es factible, utilice Aceptar riesgo solo después de que las partes interesadas apropiadas comprendan el impacto residual, la probabilidad, los controles actuales, la propiedad y las condiciones de revisión. Registre la justificación y las condiciones que desencadenan el monitoreo o la reapertura. La aceptación de riesgos es una decisión gobernada, no un sustituto del análisis incompleto. Para los pasos de solicitud de cambio y aceptación de riesgo, consulte Gestionar problemas para servicios de TI.

Verificar la reducción y el cierre de repeticiones

Observe el servicio durante un periodo y un volumen apropiados al patrón de repetición original. Compare la frecuencia de incidentes previos y posteriores a la reparación, los usuarios o transacciones afectados, los índices de error, el tiempo de inactividad, el uso de soluciones, el esfuerzo de asistencia y los resultados a nivel de servicio. Tenga en cuenta la estacionalidad, el tráfico, las versiones y los cambios de creación de reportes antes de atribuir mejoras a la solución.

Cierre el problema solo cuando el registro contenga la causa raíz admitida, información de resolución, incidentes asociados y corrección, pruebas de verificación, riesgo restante y Knowledge reutilizable. Resuelva asociaciones relacionadas de acuerdo con el proceso de su organización preservando su historial. Vuelva a abrir el problema cuando se repita el problema, se rechace la explicación causal o nuevas pruebas cambien la acción requerida.

La gestión de problemas se realiza con éxito cuando una decisión de riesgo explícita o de corrección verificada da como resultado una reducción rastreable de la recurrencia o la repercusión. El cierre de un problema, la publicación de un artículo o la realización de un cambio solo no muestra que se eliminó el problema recurrente.

Utilizar la IA como asistencia, no como evidencia

Cuando se configura, Einstein puede redactar un problema desde un incidente, y las acciones Agentforce pueden resumir problemas, comprobar atributos, encontrar registros relacionados, proponer resoluciones y redactar resúmenes de causas raíz o resoluciones. Revise los campos y las asociaciones generados antes de guardarlos o actuar sobre ellos.

Los resúmenes generados y las soluciones propuestas no son pruebas de causa raíz verificadas. Confirme cada reclamación material con registros, registros, pruebas, fuentes de Knowledge de confianza y expertos en la materia. Mantenga la distinción entre una coincidencia semántica, una hipótesis plausible y una causa demostrada. Consulte Crear problemas automáticamente desde incidentes con Einstein, Acciones de IA para Gestión de problemas y Acciones proactivas para problemas de TI.

Confirmar que Gestión de problemas está lista

Antes de implementar este proceso de forma más amplia, confirme que Gestión de problemas y sus validaciones de campo, matriz de prioridad, formatos de registro, asociaciones, tableros y SLA admiten su proceso. Confirme también que los componentes requeridos de Knowledge, Gestión de cambios y base de datos de gestión de configuración (CMDB) están configurados. Einstein, Agentforce y las acciones proactivas son funciones opcionales que requieren permisos y configuración separados.

Asigne el grupo de conjuntos de permisos Gestor de problemas o Rellenador de problemas apropiado. Asigne también los permisos requeridos para aceptar riesgos, reabrir problemas, asociar incidentes, solicitudes de cambio y versiones con problemas y resolver asociaciones. Consulte Configurar Gestión de problemas para servicios de TI y Conjuntos de permisos Gestión de problemas para servicios de TI.

Valide la configuración antes de implementarla de forma más amplia. Confirme que un usuario autorizado puede encontrar registros y tableros de problemas, inspeccionar campos de análisis y resolución y ver incidentes relacionados y otras asociaciones. Confirme que la solicitud de cambio y las acciones de riesgo apropiadas están disponibles para el estado del registro, junto con cualquier asistencia de Knowledge y IA configurada. Al probar, salga de cualquier flujo de creación, modificación, cuestionario, generación, aprobación o cierre sin guardar los cambios.