Operational Issues y ciclo de vida

El Operational Issue como unidad de trabajo — modelo base, diferencia entre Issue y Task, tipos único y masivo, el workflow de estados con su matriz de transiciones y el registro de auditoría inmutable.

Operational Issue

Operational Issue es la entidad central de OHM.

Es un objeto con estado (stateful) que representa un problema de explotación durante todo su ciclo de vida.

Modelo base

yaml

id: OHM-2026-001842
kind: single
canon: no_hourly_archive
title: 'Hourly archive is missing'
priority: P1
severity: critical
confidence: 0.94

scope:
  organization: 'Demo Gas Utility'
  region: 'North'
  asset_id: 'station-5690'

ownership:
  zone: backend_integration
  assignee: 'Integration-2'

timestamps:
  first_detected_at: '2026-07-21T04:00:00Z'
  created_at: '2026-07-21T04:03:12Z'
  acknowledged_at: '2026-07-21T05:10:00Z'
  due_at: '2026-07-22T04:00:00Z'
  resolved_at: null

status:
  workflow: in_progress
  snapshot: persistent
  overdue: false
  unattended: false
  chronic: false

root_cause:
  class: communication
  hypothesis: 'device does not establish a communication session'
  confidence: 0.82
  confirmed: false

evidence: []
tasks: []
history: []
related_issues: []
knowledge_articles: []

Ficha de un Operational Issue con la barra de pasos del workflow, las evidencias de los detectores, una hipótesis de causa raíz generada por AI con su probabilidad, el resumen del impacto de negocio y los artículos de la base de conocimiento ordenados por relevancia — Ficha del Issue: barra de pasos del workflow, evidencias de los detectores, AI Root Cause con su probabilidad, impacto de negocio y artículos de soluciones conocidas (KB) ordenados por relevancia

Issue y Task son entidades distintas

Un Issue responde a la pregunta:

¿Qué problema de explotación hay que resolver?

Un Task responde a la pregunta:

¿Qué acción concreta hay que ejecutar?

Un mismo Issue puede contener varias tareas. Para el Issue falta el archivo en 38 dispositivos:

Task 1 — comprobar la disponibilidad del gateway;
Task 2 — revisar la cola del servidor;
Task 3 — comparar las versiones de firmware;
Task 4 — ponerse en contacto con el operador de red móvil;
Task 5 — realizar una inspección de campo por muestreo.

El cierre de una sola tarea no cierra automáticamente el Issue.

Issues únicos y masivos

OHM emplea un único modelo para ambas escalas:

Tipo	Descripción
`single`	problema que afecta a un activo o a una entidad lógica
`massive`	incidente sistémico que afecta a un grupo de activos
`manual`	problema registrado por una persona
`external`	problema importado de un sistema externo

Ciclo de vida de un Operational Issue

Workflow principal

flowchart TD
  S1["Detectado"] --> S2["Triaje realizado"]
  S2 --> S3["Asignado"]
  S3 --> S4["Aceptado"]
  S4 --> S5["En curso"]
  S5 --> S6["Pendiente de verificación"]
  S6 --> S7["Verificado"]
  S7 --> S8["Resuelto"]
  S8 --> S9["Archivado"]

Desenlaces finales adicionales:

cancelado;
duplicado;
no reproducido;
no se corregirá;
riesgo aceptado.

Estados del workflow

Estado	Significado
`detected`	el Issue se creó de forma automática o manual
`triaged`	se han revisado la criticidad (Severity), la zona de responsabilidad y el contexto inicial
`assigned`	se ha determinado el ejecutor responsable
`accepted`	el ejecutor ha confirmado la aceptación
`in_progress`	los trabajos están en curso
`awaiting_verification`	el trabajo se declara terminado y queda a la espera de verificación
`verified`	el resultado se ha confirmado
`resolved`	el Issue se cierra con un resultado establecido
`archived`	el objeto finalizado se ha trasladado al historial de largo plazo
`cancelled`	el Issue se canceló por un motivo documentado
`duplicate`	el Issue es un duplicado de otro objeto
`not_reproduced`	el problema no se confirmó durante la verificación
`wont_fix`	se tomó la decisión de gestión de no repararlo
`accepted_risk`	el riesgo fue aceptado formalmente por una persona autorizada

Estado del Snapshot

Además del workflow, OHM mantiene el estado del problema según el Snapshot diario de los detectores:

Estado del Snapshot	Significado
`new`	el problema aparece por primera vez
`persistent`	el problema persiste
`worsened`	el estado ha empeorado
`improved`	el estado ha mejorado, pero el problema no ha desaparecido
`cleared`	el detector ya no confirma el problema
`reopened`	el problema ha vuelto a aparecer tras el cierre

El estado del workflow y el estado del Snapshot nunca se mezclan.

Ejemplo: workflow_status = in_progress junto con snapshot_status = improved.

Esto significa que los trabajos siguen en curso mientras los datos objetivos ya muestran una mejora.

Matriz de transiciones

Estado actual	Transiciones permitidas
detected	triaged, assigned, duplicate, cancelled
triaged	assigned, cancelled, accepted_risk
assigned	accepted, in_progress, reassigned
accepted	in_progress, reassigned
in_progress	awaiting_verification, escalated, accepted_risk
awaiting_verification	verified, in_progress
verified	resolved
resolved	reopened, archived
reopened	triaged, assigned, in_progress
cualquiera activo	duplicate, cancelled

Cada transición queda registrada en un log de eventos inmutable.

Pantalla de referencia con los estados del ciclo de vida del Issue y sus transiciones permitidas, los estados del Snapshot y las etapas del incidente — Estados y workflow: el ciclo de vida del Issue con sus transiciones permitidas, los estados del Snapshot y las etapas del incidente

Registro de auditoría (Audit Trail)

Todas las acciones significativas se registran en un historial inmutable.

Un evento contiene:

yaml

event_id: EVT-9038172
issue_id: OHM-2026-001842
event_type: status_changed
timestamp: '2026-07-23T10:14:00Z'
actor:
  type: user
  id: 'usr-231'
  role: 'zone_manager'
before:
  status: assigned
after:
  status: in_progress
reason: 'Diagnostics started'
source:
  ip: 'masked'
  client: 'web'
correlation_id: 'req-982310'

Se registran siempre:

la creación;
la asignación;
la reasignación;
el cambio de prioridad;
el cambio de plazo;
el cambio de estado;
el comentario;
la incorporación de Evidence;
la confirmación de la Root Cause;
la verificación manual;
la aceptación del riesgo;
la aplicación de un artículo de la KB;
la fusión y la división de Issues;
el cambio de configuración de un detector;
las acciones de exportación e integración.

Continuación de la ficha del Issue con la lista de comprobación de tareas y la cronología de eventos que registra en orden temporal cada acción realizada sobre el Issue — Ficha del Issue (continuación): lista de comprobación de tareas y cronología completa de eventos — la fuente única de todos los KPI

Temas relacionados

¿Te resultó útil esta página?