Dónde fallan realmente las actualizaciones de ENM
Publicado 6 de agosto de 2026 · 5 min de lectura
Los modos de fallo que alargan una ventana de actualización de Ericsson Network Manager — y la preparación aburrida que previene cada uno.
La actualización nunca es la parte arriesgada
Los equipos se preparan para el procedimiento de actualización en sí, pero ese procedimiento es el artefacto más ensayado que entrega Ericsson. Ericsson Network Manager es el sistema de gestión unificado para las redes de acceso radio, transporte y core — y los fallos que convierten una ventana en un fin de semana viven alrededor de esa posición, no dentro del procedimiento: integraciones northbound sin dueño, integraciones de nodos sin reconciliar y planes de reversión que nadie ha ejecutado.
Un entorno ENM es un nudo de dependencias. Hacia el norte, las interfaces CORBA y SNMP de Fault Management alimentan el OSS paraguas, el ticketing y los informes; hacia el sur, ENM habla con cada tipo de elemento de red del entorno. Cada uno de esos bordes es un lugar donde una actualización puede triunfar técnicamente y aun así romper la operación.
La integración basada en modelos deriva en silencio
ENM está construido para la independencia de versiones — la integración de nodos basada en modelos (model-driven node integration) es lo que permite que software nuevo de nodo entre en la red sin actualizar el propio sistema de gestión. Esa garantía solo se sostiene mientras los modelos de nodo que carga ENM coinciden de verdad con el software que corre en campo. Los entornos que actualizan nodos con agresividad pero tratan el plano de gestión como intocable acumulan desajustes que aparecen como contadores de PM ausentes, topología incompleta en Network Explorer o envíos de CM que fallan en un subconjunto de elementos.
El remedio no tiene glamur: una matriz de versiones — cada tipo de elemento, su paso de software y el estado de modelo de nodo que ENM necesita — revisada como parte de la gestión de cambios, no redescubierta durante la ventana.
La reversión es un ensayo, no un documento
Un plan de reversión que nunca se ha ejecutado es una hipótesis. El respaldo y la restauración deben verificarse contra el sistema en marcha antes de abrir la ventana, con criterios explícitos para la decisión: qué comprobación fallida, en qué punto, activa el camino de vuelta. ENM cloud native estrecha este riesgo — Ericsson desagregó el antiguo OSS-RC monolítico en servicios componentes precisamente para permitir actualizaciones in situ con un tiempo de parada cercano a cero — pero un riesgo más estrecho no es un riesgo ausente, y los despliegues virtualizados y físicos siguen cargando la ventana completa.
Los equipos que ensayan la reversión rara vez la necesitan. Los equipos que se saltan el ensayo apuestan la ventana de mantenimiento a un documento.
Cómo se ve lo bueno
Una actualización aburrida: el entorno con línea base, los flujos FM/CM/PM y las interfaces northbound comprobados antes y después, los modelos de nodo reconciliados por adelantado, la reversión ensayada y cada paso en un runbook que alguien ya recorrió — hasta los procedimientos de AMOS y ENM CLI que los operadores van a teclear. El NOC no nota nada, y ese es el punto. Con el plano de gestión al día, el entorno queda listo para lo que Ericsson está construyendo encima: el Intelligent Automation Platform, las rApps y la operación basada en intención asumen un ENM sano debajo.