El término AIOps (Artificial Intelligence for IT Operations) fue acuñado por Gartner en 2016 para describir plataformas que combinan big data y aprendizaje automático con el objetivo de automatizar y mejorar las operaciones de tecnología de la información. En entornos donde un único cluster de Kubernetes puede emitir millones de eventos de telemetría al día, la correlación manual de alertas dejó de ser viable hace tiempo. AIOps no sustituye al equipo de operaciones: amplifica su capacidad de detectar, diagnosticar y resolver incidencias antes de que degraden el servicio.
La premisa técnica es directa. Los datos operativos —métricas, logs y trazas distribuidas, las tres señales de la observabilidad moderna— contienen patrones que un modelo estadístico aprende mejor que un umbral fijo escrito por una persona. Un disco que llega al 90 % de ocupación con tendencia lineal predecible no debería generar la misma alerta a las 3 de la madrugada que un pico de latencia anómalo en el percentil 99 de un microservicio crítico. AIOps establece esa diferencia.
Conviene situar AIOps dentro de un ciclo más amplio. La observabilidad clásica responde a la pregunta «¿qué está pasando?» mostrando paneles y disparando alertas. AIOps avanza un paso y responde «¿qué es anómalo, por qué ocurre y qué conviene hacer?». Ese salto exige tres capacidades encadenadas: ingesta y normalización de grandes volúmenes de telemetría heterogénea, modelos que extraigan señal del ruido, y un mecanismo de acción que conecte la conclusión con una respuesta —notificar a la persona adecuada o ejecutar una remediación automatizada—. Cuando falta cualquiera de las tres, la plataforma se queda en una promesa a medias: detecta pero no actúa, o actúa pero sobre datos que no merecen confianza.
El contexto que ha hecho indispensable este enfoque es el cambio de arquitectura. Un monolito desplegado en tres servidores generaba un volumen de señales que un equipo podía vigilar a ojo. Una arquitectura de microservicios sobre contenedores efímeros, con autoescalado y despliegues continuos varias veces al día, multiplica las fuentes de telemetría y reduce la vida media de cada componente a minutos. En ese entorno, la topología cambia constantemente y ningún conjunto de reglas estáticas escrito por una persona logra mantenerse al día. AIOps aprende esa topología cambiante a partir de los propios datos.
Detección de anomalías: del umbral estático al modelo adaptativo
La detección de anomalías (anomaly detection) es el corazón de cualquier plataforma AIOps. El problema con los umbrales estáticos clásicos —«alerta si la CPU supera el 80 %»— es que ignoran la estacionalidad. Un servidor de facturación que llega al 85 % de CPU cada día 1 de mes a las 09:00 no está en incidencia: está procesando la carga esperada. Un umbral fijo genera ahí un falso positivo recurrente que erosiona la confianza del equipo en las alertas, el fenómeno conocido como alert fatigue.
Las técnicas habituales para superar esto son varias. Los modelos de series temporales como SARIMA y Prophet capturan tendencia y estacionalidad, prediciendo el rango esperado para cada momento y marcando como anómalo lo que se sale de él. Para datos multivariantes —cuando hay que correlacionar CPU, memoria, latencia y tasa de error simultáneamente— se emplean algoritmos no supervisados como Isolation Forest, que aísla observaciones raras particionando el espacio de características, o autoencoders, redes neuronales que aprenden a reconstruir el comportamiento normal y disparan cuando el error de reconstrucción crece. La elección depende del volumen de datos y de si se dispone o no de incidencias etiquetadas históricas.
Mantenimiento predictivo de infraestructura
El mantenimiento predictivo (predictive maintenance) aplica los mismos principios al hardware y a los componentes con desgaste. Un disco mecánico expone a través de S.M.A.R.T. atributos como el conteo de sectores reasignados o errores de lectura no corregibles; un modelo entrenado sobre el histórico de fallos puede estimar la probabilidad de avería en los próximos siete días con suficiente antelación para programar el reemplazo en una ventana de mantenimiento, no en plena producción.
El mismo enfoque se traslada a certificados TLS a punto de caducar, a la deriva de capacidad en bases de datos y al agotamiento de pools de conexiones. La métrica clave aquí no es solo la precisión del modelo, sino su antelación útil: una predicción correcta que llega cinco minutos antes del fallo no aporta valor operativo; la misma predicción con setenta y dos horas de margen permite actuar sin urgencia.
Correlación de eventos y reducción de ruido
Durante una incidencia real, un único fallo raíz genera una cascada de alertas: cae un nodo, sus pods se reprograman, los health checks fallan, los balanceadores marcan endpoints como caídos y las alertas de latencia se multiplican aguas abajo. La correlación de eventos agrupa todas esas señales en un único incidente y, mediante análisis del grafo de dependencias entre servicios, propone la causa raíz probable. Plataformas como Dynatrace con su motor Davis, Moogsoft o Elastic con sus capacidades de machine learning implementan esta lógica de agrupación temporal y topológica, reduciendo decenas de alertas a un incidente accionable.
La correlación se apoya en dos dimensiones. La temporal agrupa eventos que ocurren en una ventana próxima, bajo la hipótesis razonable de que comparten causa. La topológica, más potente, utiliza el mapa de dependencias entre servicios —construido a partir de las trazas distribuidas— para distinguir el síntoma de la causa: si el servicio de pagos depende de la base de datos de usuarios y ambos alertan a la vez, el grafo sugiere que la raíz está aguas arriba, en la base de datos, y que la alerta de pagos es derivada. Esta capacidad de ordenar la cascada según la dirección de las dependencias es lo que reduce el tiempo de diagnóstico, porque el equipo deja de perseguir síntomas y va directo al origen.
Remediación automatizada y el papel del humano
El último eslabón de AIOps es la respuesta. Una vez detectada y diagnosticada la incidencia, la plataforma puede limitarse a notificar o puede ejecutar una acción correctora. Las remediaciones habituales —reiniciar un servicio bloqueado, escalar horizontalmente ante un pico de carga sostenido, drenar y reemplazar un nodo defectuoso, rotar un certificado próximo a caducar— se orquestan mediante runbooks automatizados disparados por la detección. El valor es doble: se acorta el tiempo de resolución y se libera al equipo de tareas mecánicas repetidas.
Ahora bien, la automatización de respuesta debe introducirse con prudencia y de forma gradual. Un patrón seguro es el de las tres fases. En la primera, la plataforma solo observa y recomienda: «detectada degradación en el servicio X, acción sugerida: reinicio». En la segunda, ejecuta con aprobación humana mediante un clic. En la tercera, y solo para incidencias bien caracterizadas con histórico amplio de aciertos, actúa de forma autónoma dejando registro auditable. Saltarse esta progresión —automatizar de golpe sobre detecciones aún no validadas— es la receta para que un falso positivo provoque un reinicio innecesario en cadena durante el pico de tráfico. La supervisión humana sobre las acciones de mayor impacto sigue siendo un principio de diseño, no una concesión.
Pasos de implementación
Una adopción ordenada de AIOps sigue una secuencia razonable:
- Consolidar la observabilidad primero. Sin métricas, logs y trazas centralizados y con etiquetado coherente (servicio, entorno, versión), no hay materia prima para entrenar nada. Stacks como Prometheus con Grafana o el ecosistema Elastic son el punto de partida habitual.
- Establecer una línea base. Recoger varias semanas de telemetría para que los modelos aprendan los ciclos diarios y semanales reales.
- Empezar por un caso de uso acotado. Detección de anomalías sobre una métrica de negocio crítica suele dar el mejor retorno inicial sin riesgo de saturar al equipo.
- Mantener al humano en el bucle. Las primeras semanas, las acciones automatizadas deben proponerse, no ejecutarse. La confianza en la remediación automática se gana con histórico de aciertos.
- Cerrar el ciclo con runbooks. Conectar la detección con automatización de respuesta (reinicio de un servicio, escalado horizontal, rotación de un certificado) solo cuando la causa raíz esté bien caracterizada.
Errores comunes
El fallo más frecuente es saltar directamente a la remediación automática sin haber validado la fiabilidad de la detección: automatizar sobre falsos positivos amplifica el daño en lugar de reducirlo. El segundo error es alimentar los modelos con datos sucios —series con huecos, relojes desincronizados entre nodos, etiquetas inconsistentes— y esperar predicciones limpias. El tercero es tratar AIOps como un producto que se instala y funciona solo: los modelos derivan a medida que la arquitectura cambia y requieren reentrenamiento periódico. Un buen marco de referencia para estructurar el gobierno de estos sistemas es la norma ISO/IEC 23053, que describe el marco de los sistemas que usan aprendizaje automático.
Comparativa de enfoques de detección
| Enfoque | Datos necesarios | Fortaleza | Limitación |
|---|---|---|---|
| Umbral estático | Ninguno (regla manual) | Simple y transparente | Ignora estacionalidad, genera ruido |
| Prophet / SARIMA | Serie temporal univariante | Captura tendencia y ciclos | Pobre con muchas variables a la vez |
| Isolation Forest | Datos multivariantes sin etiquetar | Detecta combinaciones raras | Menos interpretable |
| Autoencoder | Gran volumen de datos normales | Modela comportamiento complejo | Coste de cómputo y entrenamiento |
Preguntas frecuentes
¿AIOps reemplaza a los ingenieros de operaciones o SRE? No. Elimina el trabajo repetitivo de triaje de alertas y deja al equipo el diagnóstico de problemas complejos y la mejora del sistema. La fiabilidad sigue siendo una responsabilidad humana.
¿Cuántos datos históricos hacen falta para empezar? Como mínimo, suficientes para cubrir los ciclos relevantes del negocio. Para captar la estacionalidad semanal conviene disponer de varias semanas; para patrones mensuales, varios meses.
¿Sirve AIOps en una infraestructura pequeña? El valor crece con la complejidad y el volumen de telemetría. En entornos pequeños, una buena observabilidad con alertas bien diseñadas puede ser suficiente; AIOps brilla cuando el número de señales supera la capacidad de correlación manual.
¿Cómo se mide el retorno de una plataforma AIOps? Con métricas operativas concretas: reducción del tiempo medio de detección (MTTD) y de resolución (MTTR), porcentaje de alertas accionables frente a ruido, e incidentes prevenidos gracias a predicción.
En Summum Sistemas abordamos AIOps como una capa que se construye sobre una base de observabilidad sólida, nunca al revés. El objetivo no es acumular modelos sofisticados, sino convertir la avalancha de telemetría de una infraestructura moderna en un puñado de decisiones operativas que el equipo pueda ejecutar con confianza. Un programa AIOps bien gobernado se nota en dos cosas medibles: las alertas que llegan al equipo son las que de verdad importan, y un número creciente de incidencias se resuelve —o se evita— antes de que el usuario final perciba degradación alguna. Esa es la frontera real entre operar reaccionando y operar anticipando.