Cómo crear una base de conocimiento de TI con incidentes y runbooks

Los equipos de TI pueden construir una base de conocimiento de operaciones transformando registros de incidentes, evidencias de alarmas, runbooks, postmortems y documentos de arquitectura en objetos de conocimiento gestionados, con metadatos comunes, estados de versión y revisión, límites de permisos y recuperación mediante búsquedas. El diseño de referencia ingiere conjuntamente órdenes de trabajo, alarmas, documentos y runbooks, los vectoriza para su consulta en lenguaje natural e incorpora de forma automática los postmortems revisados a la base de conocimiento.

La base de conocimiento debe conservar las pruebas y el contexto junto con las soluciones definitivas. Un registro que diga "se solucionó reiniciando" es conocimiento endeble. Un registro útil detalla qué falló, qué evidencias respaldaron el diagnóstico, qué medidas se adoptaron, si dieron resultado y a qué servicio o infraestructura afectó el incidente.

¿Qué debe incluir una base de conocimiento de operaciones de TI?

La fuente incluye explícitamente órdenes de trabajo históricas, eventos de alarma, documentos de arquitectura, runbooks de emergencia y revisiones posteriores a incidentes. La versión v2.6 de referencia también señala que las actualizaciones continuas deben nutrirse de conclusiones de órdenes de trabajo, análisis de fallos, versiones de documentos y planes de emergencia aprobados.

Estas fuentes desempeñan funciones distintas. Las órdenes de trabajo recogen lo que hicieron las personas y las alarmas reflejan lo que observaron los sistemas. Los runbooks contienen los procedimientos de respuesta aprobados, los postmortems guardan conclusiones revisadas y acciones de mejora, y los documentos de arquitectura aportan el contexto de diseño. Una buena base de conocimiento mantiene visibles esas diferencias en lugar de aplanar todo en un texto anónimo.

¿Por qué son útiles los tickets de incidentes?

Los tickets de incidentes u órdenes de trabajo albergan el historial operativo de la respuesta. Un ticket útil puede registrar el elemento afectado, el impacto en el negocio, el responsable asignado, el diagnóstico, las actuaciones, la aprobación, el resultado de la ejecución y el motivo de cierre.

El modelo de flujo de trabajo de referencia escribe los resultados de ejecución y la información de recursos de vuelta en las órdenes de trabajo. De este modo, la orden de trabajo es mucho más que un simple gestor de tareas: constituye la prueba documental de cómo se abordó un incidente real, y cuando el mismo problema reaparece, el sistema de conocimiento puede recuperar la respuesta anterior.

¿Por qué son útiles las alarmas?

Las alarmas aportan un contexto objetivo sobre los sucesos. Una orden de trabajo puede limitarse a indicar "problema de GPU resuelto". El historial de alarmas, en cambio, muestra qué tarjeta generó el error, cuándo empezó el fallo, qué alarmas vinculadas surgieron a continuación y si el problema se repitió.

El modelo de AIOps de referencia conserva las alarmas en bruto incluso después de agruparlas en incidentes. Para la base de conocimiento, esto significa que el incidente revisado puede enlazar a las evidencias de alarma pertinentes sin tener que volcar cada evento individual dentro del artículo de conocimiento.

¿Por qué los runbooks son distintos del historial de incidentes?

Un runbook describe lo que se debería hacer ante una situación conocida, mientras que el historial de incidentes describe lo que ocurrió en la realidad, y ambas cosas no son lo mismo.

Un runbook puede indicar que se verifique el estado del hardware, se retire el nodo de la planificación de tareas, se reprograme la carga de trabajo y se abra una orden de trabajo de reparación de hardware. Un incidente histórico puede mostrar que el primer paso falló porque la BMC no respondía, por lo que se recurrió a otra fuente de datos, se aisló el nodo a mano y el runbook necesitó mejoras posteriores.

Mantener separadas las pruebas del incidente y las instrucciones del runbook ayuda a la organización a aprender, ya que la experiencia del incidente puede validar o cuestionar el procedimiento documentado.

¿Por qué los postmortems son especialmente valiosos?

Los postmortems contienen un criterio operativo contrastado y revisado. La estructura de postmortem de referencia incluye una cronología, la causa raíz, los factores contribuyentes, lo que funcionó bien y las medidas de mejora, e incorpora automáticamente esa revisión a la base de conocimiento.

Un postmortem tiene mucho más peso que una simple nota de cierre de ticket porque el equipo ya ha analizado las pruebas y consensuado una explicación técnica aceptada. Quienes atiendan incidencias en el futuro podrán consultar esa conclusión validada.

Respecto al proceso de generación, el artículo sobre cómo generar postmortems de incidentes automáticamente a partir de alarmas, cronologías, órdenes de trabajo y acciones de remediación detalla cómo se reúnen las evidencias antes de la revisión humana.

¿Qué metadatos debería tener cada elemento de conocimiento?

La fuente no publica un esquema universal y único de metadatos de conocimiento, pero su modelo operativo define las relaciones que deben mantenerse vinculadas. Un registro coherente con el sistema de referencia debe conservar el tipo de conocimiento, el incidente u orden de trabajo asociada, el objeto de infraestructura, el servicio o aplicación, el proyecto o inquilino (tenant), el responsable, el periodo de tiempo, el origen, la versión, el estado de revisión y si se encuentra vigente o expirado.

Estos campos consiguen que la recuperación sea mucho más precisa. Un runbook para una familia de servidores concreta no debe presentarse como si sirviera para cualquier equipo, y un postmortem de un entorno de desarrollo no debe condicionar automáticamente la respuesta en producción. Los metadatos aportan ese contexto necesario.

¿Por qué deben incluirse los documentos de arquitectura?

Los documentos de arquitectura explican relaciones e intenciones de diseño que los sistemas de monitoreo no siempre pueden deducir, y la base de conocimiento de referencia los incluye explícitamente. Pueden describir la ruta principal y la de respaldo, dependencias entre servicios, el rol de un clúster, el diseño de red, el plan de recuperación o restricciones operativas particulares.

Esto resulta de gran ayuda durante la resolución de problemas. Una alarma avisa al ingeniero de lo que sucede, el documento de arquitectura explica por qué ese componente es importante y el asistente de conocimiento puede recuperar ambos elementos a la vez.

¿Cómo debe ingerirse el conocimiento?

La documentación de referencia indica que las órdenes de trabajo, alarmas, documentos y runbooks se ingieren y vectorizan de forma conjunta, dando lugar a una base de conocimiento operativo consultable. No detalla el modelo de embeddings exacto, la base de datos vectorial, el tamaño de fragmentación ni el algoritmo de indexación, por lo que esos detalles no deben inventarse.

El flujo de trabajo avalado por el sistema consiste en recopilar contenido operativo aprobado, preservar el origen y los permisos, analizar o estructurar el contenido, vectorizarlo e indexarlo para su recuperación. Los usuarios recurren después al lenguaje natural para localizar información relevante y el sistema muestra de dónde proviene la respuesta.

¿Cómo deben combinarse las pruebas estructuradas y no estructuradas?

Conviene mantener los campos operativos estructurados junto con el texto no estructurado. Los datos estructurados pueden incluir la hora del incidente, el identificador del dispositivo, el responsable del servicio, la gravedad, el estado de la orden de trabajo y el nombre de la métrica. El contenido no estructurado puede abarcar notas de los ingenieros, pasos del runbook, análisis de postmortems y explicaciones sobre la arquitectura.

El asistente de IA de referencia combina el conocimiento en lenguaje natural con consultas en tiempo real de monitoreo y medición, por lo que la capa de conocimiento no debe intentar convertir cada dato operativo en prosa. Emplea sistemas estructurados para métricas y relaciones actuales, utiliza la base de conocimiento para la experiencia revisada y los documentos, y deja que el asistente los combine al responder a una consulta.

¿Cómo deben actualizar la base de conocimiento las nuevas órdenes de trabajo?

La documentación indica que la base de conocimiento continúa aprendiendo a partir de las nuevas órdenes de trabajo. La guía v2.6 añade un mecanismo de control adicional: actualizar mediante las conclusiones y revisiones de las órdenes de trabajo, con procesos de vigencia, expiración y aprobación. Esto implica que la base de conocimiento no debería ingerir cualquier ticket inacabado como una pauta autorizada.

Un flujo operativo adecuado funciona así: ocurre un incidente, la orden de trabajo registra la actividad, el incidente se cierra, se revisa la conclusión y, si resulta útil, se incorpora como conocimiento. Si un postmortem posterior corrige la causa raíz aceptada, el registro de conocimiento se actualiza o sustituye la conclusión previa, evitando que hipótesis provisionales se transformen en verdades institucionales fijas.

¿Cómo deben actualizar los postmortems el conocimiento previo?

Utiliza una lógica de versiones y reemplazos. Supongamos que el ticket del incidente dice al principio "se sospecha de un problema de red" y el postmortem revisado concluye más tarde que "la latencia de almacenamiento fue la causa raíz principal". La base de conocimiento no debe conservar ambas afirmaciones con el mismo nivel de autoridad sin aportar contexto.

El sistema de referencia recomienda controles de versiones de documentos y estados de vigencia o expiración, que es el mecanismo idóneo. La anotación previa puede permanecer en el historial del incidente, mientras que el postmortem revisado pasa a ser el conocimiento válido actual para futuras búsquedas.

¿Cómo se deben gestionar los runbooks desactualizados?

Los runbooks deben disponer de estados de versión y revisión. Las directrices de la versión v2.6 señalan expresamente que el conocimiento debe contar con mecanismos de vigencia, expiración y auditoría para que la información obsoleta no condicione las decisiones.

Un runbook puede quedar desfasado tras una actualización de firmware, un cambio de arquitectura, un nuevo modelo de fabricante, la migración de un servicio, una modificación de políticas o un ajuste de automatización. La base de conocimiento debe guardar las versiones históricas para auditoría e indicar con claridad cuál es la versión aprobada en la actualidad, y el asistente debe dar preferencia al conocimiento vigente y aprobado.

¿Cómo deben aplicarse los permisos?

El asistente de IA de referencia hereda el rol y los permisos de datos del usuario, por lo que no puede consultar todos los datos de los inquilinos. En consecuencia, la base de conocimiento debe respetar los límites de inquilino (tenant), proyecto y rol. Un usuario del Inquilino A no debe tener acceso a las órdenes de trabajo, la arquitectura ni los documentos de conocimiento del Inquilino B a menos que cuente con autorización explícita.

Esto importa porque, de lo contrario, la búsqueda vectorial puede convertirse en una vía involuntaria de fuga de datos. El diseño del sistema de referencia sitúa el filtrado por permisos como un pilar del modelo de confianza.

¿Cómo debe mostrar la recuperación la atribución de fuentes?

Cada respuesta debe identificar las pruebas en las que se apoya. El asistente de IA exige atribución de la fuente de datos, definición estadística y rango temporal para los datos en vivo, y ese mismo principio de confianza se aplica a la recuperación de conocimiento. Una respuesta útil debe señalar el ID del postmortem, la versión del runbook, la referencia de la orden de trabajo, la versión del documento de arquitectura o el incidente de alarma correspondiente.

El sistema de referencia no impone una interfaz de usuario concreta para las citas. Lo que exige es verificabilidad: el operador debe poder abrir el material de origen y contrastar la respuesta.

¿Cómo deben recuperarse los incidentes similares?

Utiliza el contexto del incidente en curso como entrada para la búsqueda. Ese contexto puede incluir el tipo de dispositivo, el código de error, el patrón de alarmas, el servicio, la topología, posibles causas raíz, la carga de trabajo y el comportamiento temporal.

El asistente de IA puede apoyarse en órdenes de trabajo y postmortems históricos para asistir en la resolución de problemas. El resultado de la búsqueda debe presentar los casos similares como pruebas de apoyo y no como verdades absolutas.

Para el análisis de causa raíz, el estudio de cómo el análisis de causa raíz combina topología, métricas de series temporales, incidentes históricos y relaciones de configuración explica cómo encaja la similitud histórica con las pruebas del momento presente.

¿Cómo debe transformarse el conocimiento en un runbook?

Los patrones de respuesta que hayan tenido éxito de forma reiterada pueden convertirse en un procedimiento aprobado. El modelo de conocimiento de referencia integra órdenes de trabajo históricas y runbooks de emergencia dentro del mismo sistema operativo.

Un ciclo de mejora práctico se activa cuando ocurren varios incidentes y el mismo diagnóstico y resolución funcionan en cada ocasión. Los postmortems confirman el patrón, el equipo crea o actualiza un runbook, y este se revisa y aprueba. Los incidentes futuros se cotejan con el runbook, y la actuación puede pasar más adelante a ser semiautomática o automática si el nivel de riesgo lo permite. Así es como la experiencia operativa se convierte en una capacidad sistemática y repetible.

¿Cómo debe alimentar el conocimiento a la automatización?

El conocimiento solo debe orientar la automatización una vez aprobado el procedimiento de actuación. La arquitectura de referencia separa el análisis de IA de la ejecución en producción: el asistente puede recuperar un runbook y sugerirlo, pero la ejecución continúa sujeta a clasificación de riesgos, permisos, aprobaciones, barreras de seguridad de automatización y auditoría.

Esto evita que una simple anotación de un incidente antiguo se transforme en un comando ejecutable en producción. La base de conocimiento fundamenta la decisión y el flujo de trabajo gobierna la acción.

¿Cómo beneficia la base de conocimiento al traspaso de turnos?

El traspaso de turnos se simplifica enormemente cuando el contexto relevante ya está registrado. La documentación de referencia advierte con insistencia del peligro de que el conocimiento de operaciones dependa de la memoria de las personas.

El ingeniero que entra de turno puede buscar por qué un servidor tiene una configuración particular, si un problema ya había ocurrido antes, qué runbook corresponde aplicar y qué medidas adoptó el turno anterior. Eso reduce la dependencia de las explicaciones verbales.

Para el proceso en el turno activo, el artículo sobre qué debe incluir una lista de control eficaz para el traspaso de turnos en operaciones de TI detalla qué información pendiente requiere todavía confirmación explícita.

¿Cómo debe medirse la calidad del conocimiento?

El sistema de referencia no define un único indicador clave de rendimiento (KPI) universal para el conocimiento de operaciones. Una medición práctica y coherente con el modelo puede incluir el éxito en las búsquedas, la tasa de resultados útiles, la frecuencia de resultados obsoletos, la reutilización de runbooks, el tiempo necesario para localizar un incidente anterior, los incidentes vinculados a conocimiento existente, los elementos pendientes de revisión y los registros caducados que todavía se devuelven en búsquedas.

La prueba decisiva de calidad es estrictamente operativa: ¿ayuda el conocimiento a quien atiende el incidente a acceder a las pruebas correctas o a la acción aprobada con más rapidez? No optimices únicamente la cantidad de documentos indexados.

¿Qué debe mostrar la pantalla de operaciones de la base de conocimiento?

Una vista práctica y fundamentada en el modelo de referencia puede mostrar el origen del conocimiento, el tipo, el servicio o activo relacionado, el inquilino o proyecto, la versión, el estado de vigencia, el estado de revisión, la última actualización, los incidentes asociados, el runbook vinculado, el enlace al postmortem y la actividad de búsqueda y recuperación.

El sistema de referencia articula esta capacidad principal mediante su asistente de IA y sus capas de postmortems, órdenes de trabajo y gobernanza. Un ejemplo de plataforma que aúna órdenes de trabajo, alarmas, documentos de arquitectura, runbooks, postmortems y consultas con control de permisos es Sensaka.

Si fuera a construir la base de conocimiento, empezaría por los incidentes revisados y los runbooks en uso antes de importar cualquier documento que posea la empresa. Conviene que la colección inicial sea de confianza, esté bien etiquetada, respete los permisos y cuente con versiones. Después, añade las conclusiones de nuevas órdenes de trabajo y los postmortems mediante un proceso formal de revisión. Una base de conocimiento más pequeña pero que proporcione las evidencias operativas exactas resulta infinitamente más útil que un índice descomunal repleto de notas caducadas.