Comprender que el monitoreo no se sostiene solo con herramientas o técnicos. Requiere una estructura mínima de gobernanza:
reglas claras sobre quién decide, quién configura, quién recibe alertas y quién responde.
Este bloque introduce la gobernanza desde una visión táctica, enfocada en hacer que el monitoreo funcione día a día.
Es el conjunto de reglas, políticas y estructuras de decisión que permiten que el monitoreo sea útil, coherente y sostenible.
No basta con que “alguien lo configure”.
Se necesita definir:
Qué se monitorea y qué no
Quién recibe qué alertas
Quién puede modificar configuraciones
Cómo se documentan los cambios
Cómo se validan las alertas
Sin gobernanza, el monitoreo se vuelve caótico, frágil o inútil.
| Elemento | Propósito operativo |
|---|---|
| Política de monitoreo | Define qué se monitorea, con qué nivel de prioridad. |
| Catálogo de servicios | Relación de servicios, sistemas y responsables. |
| Asignación de ownership | Define quién recibe y responde alertas por cada grupo. |
| Estrategia de escalamiento | A quién se notifica, en qué orden, según severidad. |
| Procedimiento de ajuste | Quién puede modificar triggers, ítems o plantillas. |
| Bitácora de cambios | Registro de ajustes hechos, cuándo y por quién. |
Se sube un nuevo servidor de aplicación a producción.
| Con gobernanza | Sin gobernanza |
|---|---|
| Se valida si entra en política de monitoreo. | Nadie sabe si debe monitorearse. |
| Se asigna template con umbrales estándar. | Alguien lo configura “igual que otro”. |
| Se asigna grupo responsable de alertas. | Las alertas llegan a quien “las puso”. |
| Se registra la configuración aplicada. | No hay evidencia ni responsables. |
El orden y la trazabilidad operativa dependen de tener una gobernanza mínima.
Toda alerta debe tener un destinatario definido.
Nadie debe poder borrar o modificar triggers sin registrar el cambio.
Todo nuevo servicio debe evaluarse para ver si requiere monitoreo.
Cada grupo de hosts debe tener un responsable técnico.
Debe haber una persona o rol que audite el sistema de monitoreo regularmente.
| Nivel | Enfoque | Ejemplo |
|---|---|---|
| Táctica | Que el monitoreo funcione día a día sin errores ni olvidos. | Quien recibe alertas de red, qué hacer si falla. |
| Estratégica | Que el monitoreo genere valor, sea auditable y escale. | Políticas globales, integración con DevOps, reporting ejecutivo. |
Este bloque se limita a lo táctico, porque es lo primero que debe resolverse.
Una política de monitoreo es un documento formal (o plantilla mínima) que define cómo se monitorea, con qué criterios y bajo qué responsabilidades.
| Elemento recomendado | Propósito operativo |
|---|---|
| Objetivo de la política | Justificar por qué se implementa el monitoreo en la organización. |
| Alcance | Qué servicios, entornos y áreas están cubiertos. |
| Criterios de inclusión | Qué se considera monitoreable y bajo qué condiciones. |
| Clasificación por criticidad | Establece niveles (Crítico, Alto, Medio, Bajo) con ejemplos. |
| Responsables operativos | Qué grupos o roles reciben qué tipos de alerta. |
| Procedimientos asociados | Documentos o flujos para alta de hosts, ajuste de triggers, etc. |
| Frecuencia de revisión | Cada cuánto se actualiza (ej. trimestral, semestral). |
Esta política no reemplaza la herramienta, pero le da estructura y coherencia a todo lo que se configura.
### Política de Monitoreo - Versión 1.0
**Alcance**: Aplica a todos los servidores de producción y servicios críticos en las áreas de Infraestructura, Virtualización y Base de Datos.
**Nivel Crítico**:
- Servicios: Base de datos principal, autenticación LDAP, sistema de nómina.
- Requiere monitoreo activo 24/7, triggers con umbrales validados, alertas con escalamiento a Soporte Nivel 2.
**Nivel Alto**:
- Servicios: Correo institucional, portales internos.
- Requiere monitoreo de disponibilidad y métricas clave (CPU, RAM, disco).
**Responsable de cada grupo de host**:
- Virtualización → Grupo `Soporte-Virtual`
- Base de datos → Grupo `DBA`
- Red y conectividad → Grupo `Infraestructura`Publicar la política en un espacio común del equipo (Notion, Confluence, SharePoint).
Incluir un resumen accesible en las capacitaciones de nuevos operadores.
Agregar la validación de cumplimiento de política en auditorías internas.
Asegurarse de que todo nuevo servicio pase por revisión de política antes de entrar en producción.
Gobernar el monitoreo no es centralizarlo:
es definir roles, responsabilidades y reglas claras para que todos sepan qué hacer con una alerta antes de que cause un incidente.
El operador debe entender que el monitoreo es parte de un sistema más amplio, con reglas que aseguran su funcionamiento correcto, y que él también tiene un rol definido dentro de esa estructura.
El operador comprende que:
Todo monitoreo responde a una política previamente definida.
No se deben aplicar templates, triggers ni alertas arbitrariamente.
El monitoreo está alineado con prioridades y responsabilidades claras.
¿Sé quién define qué se monitorea?
¿Sé a quién escalar si una alerta llega mal?
¿Puedo consultar una política de monitoreo o procedimiento vigente?
¿Hay registro de quién ajusta configuraciones?
¿Cada grupo de hosts tiene responsables asignados?
¿Sé dónde consultar la política actual de monitoreo?
¿Puedo aplicar una política de criticidad al dar de alta un host?
¿Distingo qué servicios deben tener monitoreo activo o pasivo?
¿Conozco el responsable técnico de cada grupo de hosts críticos?