Al pasar de “cajas” (appliance/ATCA) a “software + plataforma” (Linux + VM/Kubernetes + storage/red virtual), el cambio grande para Operaciones no es sólo tecnológico. Es un cambio de paradigma sobre qué significa “salud”, dónde ocurre una falla y cómo se mide. Si este cambio no se hace explícito, el resultado típico es predecible: más alertas, más “incidentes” que no lo son, más tickets “fantasma”, y diagnósticos más lentos.
1) Antes: operar “cosas” estables; ahora: operar “comportamientos” dinámicos
El mundo de las “cajas”
En plataformas basadas en appliances:
- La unidad de operación era una entidad estable: un chasis, un blade, un host.
- La identidad era constante: el mismo equipo, la misma ubicación lógica, el mismo rol.
- La salud se interpretaba como estado del dispositivo: arriba/abajo, degradado/no degradado.
- La observabilidad venía preempaquetada: alarmas del vendor con severidades y correlaciones relativamente consistentes.
Esto producía un modelo mental muy potente: “si la caja está bien, el servicio está bien” (o al menos, esa era la hipótesis inicial más razonable).
El mundo de “software + plataforma”
En entornos virtualizados/contenerizados:
- La unidad “real” ya no es el host, sino el servicio (una capacidad de negocio) implementado por componentes que cambian.
- Las entidades son efímeras: instancias que aparecen/desaparecen por diseño.
- La salud ya no es “estado”, es comportamiento: ¿está cumpliendo su promesa (latencia, errores, disponibilidad) bajo condiciones cambiantes?
- La plataforma es parte del sistema: orquestación, red virtual, almacenamiento, identidad, políticas.
Cambio de paradigma: Operaciones deja de “mantener estables objetos estables” y pasa a “garantizar resultados estables” sobre un sistema inherentemente dinámico.
2) Qué significa “salud” cambia: de métricas de infraestructura a señales de servicio
En el modelo tradicional, “salud” se respondía con métricas de infraestructura: CPU, memoria, disco, interfaces, alarmas de hardware.
En el modelo moderno, “salud” se responde de forma más completa con señales orientadas a servicio:
- Experiencia del usuario/sistema consumidor (SLO/SLI).
- Correctitud (respuestas válidas).
- Latencia y errores (no sólo “si está encendido”).
- Capacidad de sostener carga sin degradación.
No significa que la infraestructura ya no importe; significa que deja de ser el primer idioma para expresar salud. En plataformas modernas, infraestructura “bien” puede coexistir con servicio “mal”, y viceversa.
Nuevo criterio operativo: si no hay impacto medible en el servicio, muchas “alarmas” deben tratarse como diagnóstico o capacity signal, no como incidente.
3) Dónde ocurre una falla cambia: de un punto a una cadena
En appliances, muchas fallas se podían localizar en un punto: “ese equipo” o “ese módulo”. En software + plataforma, los problemas son a menudo interacciones:
- entre capas (aplicación ↔ runtime ↔ kernel ↔ red virtual ↔ storage),
- entre componentes (dependencias),
- entre políticas (seguridad, cuotas, placement),
- entre automatización y realidad (reconciliación continua).
Esto introduce un cambio clave: el incidente no vive “en un lugar”, vive en una relación. La causa no siempre es un componente roto; puede ser una decisión de configuración, una política, o un límite operativo que se alcanza.
Cambio de paradigma: de “root cause puntual” a “sistema acoplado con fallas por interacción”.
4) Cómo se mide cambia: de umbrales simples a evidencia contextual
Umbrales heredados: el origen de muchos falsos positivos
Cuando migras a cloud/containers, una tentación natural es reutilizar reglas de monitoreo “de caja”:
- CPU > X
- Memoria usada > Y
- Disco > Z
El problema: en Linux y plataformas modernas, esos indicadores no siempre significan lo mismo ni tienen la misma relación con impacto.
Resultado: aumentan falsos positivos del tipo:
- “todo está en rojo” pero el servicio está bien,
- “muchas alertas” pero ninguna explica el impacto,
- “tendencias normales” interpretadas como incidentes.
Medición moderna: impacto + contexto + correlación
Sin entrar en fallas específicas, el cambio es este:
- Primero se mide el impacto en el servicio (lo que el usuario/sistema percibe).
- Luego se usa el resto (plataforma/infra) para explicar y acotar.
- Se privilegian señales que incluyen contexto: qué cambió, dónde, desde cuándo, a qué afecta.
Cambio de paradigma: de “monitoreo por umbral” a “monitoreo por intención (SLO) y diagnóstico por capas”.
Nuevos tipos de problemas operativos (más allá de “se cayó un host”)
El paso a “software + plataforma” trae problemas operativos que antes eran raros o inexistentes:
- Problemas de dinámica: el sistema cambia constantemente (deploys, escalado, reprogramación). La estabilidad depende de la calidad del cambio y de cómo la plataforma reacciona.
- Problemas de configuración/política: pequeños cambios declarativos pueden tener efectos amplios (seguridad, red, placement, límites).
- Problemas de dependencia: más servicios internos, más componentes compartidos (DNS, ingress, certs, storage classes, registries).
- Problemas de observabilidad: más datos, pero también más riesgo de “no ver lo importante” (o verlo demasiado tarde) por falta de enfoque.
- Problemas de automatización: la plataforma repara/ajusta sola; eso es una ventaja, pero también puede enmascarar degradaciones hasta que se vuelven sistémicas.
Cambio de paradigma: se opera un sistema que “se mueve” por sí solo; lo operativo se vuelve gobernanza de comportamiento, no sólo reacción a fallas.
¿Por qué aumentan los falsos positivos (y cómo reconocerlos conceptualmente)?
Sin entrar aún en ejemplos concretos, los falsos positivos aumentan por cuatro razones típicas:
- Reuso de métricas con significado distinto La misma palabra (“memoria”, “disco”, “CPU”) describe fenómenos distintos según capa y aislamiento.
- Medir componentes en vez de medir servicio Alertas por componentes que no se traducen en impacto generan ruido.
- No modelar lo efímero como normalidad En cloud, reinicios, rescheduling y reemplazo de instancias pueden ser parte del diseño. Si eso se trata como anomalía, el monitoreo se vuelve hostil.
- Falta de correlación con cambios En plataformas dinámicas, “qué cambió” es un predictor fuerte. Sin esa dimensión, el monitoreo queda ciego a causalidad.
Idea guía: un falso positivo no es “una alerta mala”; es una alerta que no está alineada con la intención del sistema (servicio) ni con el comportamiento normal de la plataforma.
Operar promesas, no objetos…
La transición de cajas a software + plataforma no es “cambiar hardware por cloud”. Es cambiar:
- el objeto de operación (servicio vs host),
- la definición de salud (comportamiento vs estado),
- la localización de fallas (interacciones vs puntos),
- y el método de medición (impacto + contexto vs umbrales aislados).
Esto explica por qué, durante la transición, se ven: más ruido operativo, más falsos positivos, y más tiempo invertido en “traducir” señales.
Para aterrizarlo sin entrar en diagnóstico detallado, algunos ejemplos comunes que suelen aparecer en este cambio (sólo como referencia):
- “memoria alta” reportada sin impacto real en servicio,
- “pods reiniciando” como parte de reconciliación vs incidente real,
- “disco del nodo alto” por dinámicas de imágenes/logs,
- “latencia intermitente” por interacción entre capas (app/red/infra).
