Del NOC al centro de comando: operar servicios, no equipos

Un NOC centrado en la red ve equipos encendidos mientras el cliente no puede operar. Un centro de comando 24×7 vigila servicios de punta a punta y responde por ellos.

Muchas organizaciones tienen una pantalla grande con mapas de red, enlaces en verde y gráficos de CPU. Es el NOC, el centro de operaciones de red. Durante años fue suficiente: si los enlaces, los routers y los servidores estaban arriba, el servicio funcionaba. Hoy esa ecuación ya no se cumple. Una aplicación móvil depende de APIs, colas de mensajes, bases de datos, proveedores externos y servicios en la nube. Todos los equipos pueden estar en verde y, aun así, el cliente no logra completar una transferencia.

Este artículo explica por qué un NOC centrado en la red se queda corto, qué hace distinto un centro de comando 24×7 y qué necesita de la observabilidad y de la gestión de servicios para funcionar.

Por qué el NOC tradicional se queda corto

El NOC clásico nació para vigilar componentes: disponibilidad de enlaces, estado de interfaces, uso de CPU y memoria, espacio en disco. Su modelo mental es el inventario. Cada equipo tiene umbrales, y cuando uno se cruza, se abre una alerta.

Ese modelo tiene tres límites claros en una arquitectura moderna:

No ve lo que ve el cliente. Un servicio puede degradarse por un error de lógica, un certificado vencido en un proveedor, una cola que se acumula o una consulta lenta. Ninguno de esos problemas pone en rojo un enlace.
Genera ruido sin contexto. Cien alertas de CPU alta no dicen qué servicio está afectado ni a cuántos usuarios. El operador termina filtrando por intuición.
Termina en el lugar equivocado. Cuando el NOC solo puede decir "la red está bien", el incidente rebota entre equipos. Cada área demuestra que su componente funciona, y nadie es dueño del servicio completo.

El problema no es la red ni el equipo del NOC. Es la unidad de análisis. Si lo que se vigila son equipos, lo que se gestiona son equipos. El negocio, en cambio, mide servicios.

Qué es un centro de comando y qué vigila

Un centro de comando es una función de operación 24×7 cuya unidad de trabajo es el servicio de punta a punta. Responde una pregunta sencilla: ¿los clientes y los usuarios internos pueden hacer lo que necesitan hacer, ahora mismo?

Para responderla, integra cuatro tipos de señales en una sola vista:

Aplicaciones: latencia, tasa de errores y volumen de las transacciones principales, trazas distribuidas entre servicios, errores de las aplicaciones web y móviles.
Infraestructura: red, servidores, contenedores, bases de datos y nube, pero leídos como dependencias de un servicio, no como piezas sueltas.
Señales de seguridad: eventos relevantes que el equipo de seguridad comparte con la operación, por ejemplo picos de autenticaciones fallidas o tráfico anómalo que afectan la disponibilidad. El centro de comando no reemplaza al SOC; coordina con él.
Transacciones de negocio: pagos aprobados por minuto, inicios de sesión exitosos, solicitudes completadas. Son la prueba más directa de que el servicio cumple su propósito.

La diferencia de fondo está en la pregunta. El NOC pregunta "¿qué equipo falla?". El centro de comando pregunta "¿qué servicio está degradado, a quién afecta y quién lo resuelve?".

Aspecto	NOC centrado en la red	Centro de comando 24×7
Unidad de análisis	Equipo o componente	Servicio de punta a punta
Señales principales	Disponibilidad, CPU, memoria, enlaces	Experiencia del usuario, transacciones, trazas, dependencias
Alertas	Umbrales por equipo	Síntomas del servicio y objetivos de nivel de servicio
Responsabilidad	Que el componente esté arriba	Que el servicio se recupere y el negocio lo sepa
Relación con ITSM	Abre tickets	Coordina incidentes, cambios y comunicación

Mapas de servicio: el inventario que sí importa

Un centro de comando necesita saber de qué está hecho cada servicio. Para eso existen los mapas de servicio: una representación de los componentes, dependencias y proveedores que soportan un servicio de negocio.

Un mapa de servicio útil incluye, como mínimo:

El servicio de negocio y su dueño (por ejemplo, "pagos con tarjeta", dueño en el área de medios de pago).
Las aplicaciones y APIs que lo componen, y las dependencias entre ellas.
La infraestructura que las soporta: bases de datos, colas, clústeres, enlaces.
Los proveedores externos involucrados y sus contactos de escalamiento.
Los indicadores que definen si el servicio está sano y sus objetivos.

Hay dos fuentes para construirlo. La primera es la base de configuración (CMDB) de la herramienta de ITSM, que documenta relaciones declaradas. La segunda es el descubrimiento automático de las plataformas de observabilidad, que detectan dependencias reales a partir del tráfico y las trazas. Conviene usar ambas: la CMDB aporta dueños y contexto de negocio, y el descubrimiento automático muestra cómo se comunica el sistema de verdad. Cuando no coinciden, esa diferencia es en sí misma un hallazgo.

Roles y escalamiento

Un centro de comando no es solo un turno de operadores frente a pantallas. Funciona con roles definidos y un modelo de escalamiento conocido por todos.

Roles habituales

Operador de turno (primer nivel): vigila los tableros de servicio, valida alertas, ejecuta procedimientos documentados y abre el incidente.
Analista de segundo nivel: correlaciona señales, identifica el componente probable y ejecuta acciones de recuperación autorizadas.
Coordinador de incidentes: en incidentes mayores, dirige la respuesta, convoca a los equipos resolutores, controla los tiempos y decide la comunicación.
Responsable de comunicación: informa a negocio, atención al cliente y dirección con un formato y una frecuencia acordados.
Equipos resolutores: desarrollo, bases de datos, red, nube, seguridad y proveedores, cada uno con guardia definida.

Escalamiento por impacto, no por tiempo solamente

Un error frecuente es escalar solo por reloj: si en 30 minutos no se resuelve, se llama al siguiente nivel. Es mejor combinar tiempo e impacto. Una degradación que afecta un servicio crítico en horario de mayor uso debe convocar al coordinador desde el primer minuto, aunque parezca menor. Para eso, cada servicio necesita una clasificación de criticidad y una matriz de prioridad (impacto por urgencia) acordada con negocio antes del incidente, no durante.

Recomendamos que el escalamiento esté escrito en procedimientos por servicio (runbooks) con tres datos claros: quién decide, a quién se llama y qué se comunica en cada etapa.

Qué necesita de la observabilidad y del ITSM

De la observabilidad

El centro de comando depende de que el sistema se pueda observar desde fuera. Una plataforma de observabilidad (Dynatrace, Datadog u otras) captura buena parte de la infraestructura y de las aplicaciones de forma automática. Pero encontrar rápido la causa raíz exige además que el software esté escrito para ser observable:

Logs estructurados con identificadores de correlación.
Propagación del contexto de trazas entre servicios, por ejemplo con OpenTelemetry y el estándar W3C Trace Context.
Métricas de negocio emitidas por la propia aplicación.
Eventos de despliegue y de cambio enviados a la plataforma, para correlacionar degradaciones con cambios recientes.

Plataforma observable no es lo mismo que aplicación observable. Sin instrumentación en el código, el centro de comando verá que algo está lento, pero no sabrá por qué.

A esto se suma la definición de objetivos de nivel de servicio (SLO) por servicio. Alertar sobre el síntoma que ve el cliente, y no sobre cada umbral técnico, es lo que permite que un turno pequeño atienda un parque grande sin ahogarse en ruido.

De la gestión de servicios

El centro de comando es el punto donde se encuentran varias prácticas de ITIL 4: monitoreo y gestión de eventos, gestión de incidentes, gestión de problemas, habilitación de cambios y gestión del nivel de servicio. En la práctica necesita:

Integración entre la plataforma de observabilidad y la herramienta de ITSM (ServiceNow u otra), para que una alerta validada cree o actualice un incidente con el servicio afectado ya identificado.
Visibilidad del calendario de cambios, porque es habitual que un incidente coincida con un cambio reciente.
Registro de problemas para los incidentes recurrentes, con dueño y fecha de revisión.
Informes de nivel de servicio que usen las mismas métricas que el centro de comando vigila.

En el sector financiero europeo, el Reglamento (UE) 2022/2554 (DORA) exige a las entidades procesos de gestión, clasificación y notificación de incidentes relacionados con las TIC. Un centro de comando con registro ordenado de incidentes, tiempos e impacto facilita esa tarea. Cada organización debe validar el alcance exacto con su área de cumplimiento.

Cómo empezar la transición

Pasar de NOC a centro de comando no exige cambiar todo a la vez. Un camino razonable:

Elegir de tres a cinco servicios críticos con dueño de negocio identificado.
Dibujar su mapa de servicio, cruzando la CMDB con el descubrimiento automático.
Definir indicadores y objetivos por servicio: disponibilidad, latencia y una métrica de negocio.
Construir un tablero por servicio que el turno entienda en segundos: verde, degradado o caído, y por qué.
Reescribir las alertas para que avisen por síntomas del servicio y enviar las alertas por componente a los equipos técnicos como contexto.
Documentar runbooks y escalamiento para esos servicios y probarlos con simulacros.
Revisar cada incidente mayor sin buscar culpables y convertir los hallazgos en mejoras de instrumentación o de procedimiento.

Cuando esos primeros servicios funcionan bien bajo el nuevo modelo, se amplía el alcance. El equipo del NOC suele ser el mejor punto de partida: conoce la infraestructura y la operación nocturna. Lo que cambia es la pregunta que responde.