En febrero de 2026, la compañía NeuBird AI publicó los resultados de una encuesta a 1.039 profesionales de SRE, DevOps y operaciones IT en empresas de más de 100 empleados. Los números, recogidos después en medios como Carrier Management, son incómodos de leer si te dedicas a esto: el 78% de los encuestados había sufrido al menos un incidente sin ninguna alerta previa que lo anticipara, el 44% había tenido caídas de servicio provocadas por alertas que alguien había suprimido o simplemente ignorado, y un 57% reconocía que menos del 30% de las alertas que reciben son realmente accionables. El 83% admitía descartar avisos de vez en cuando, no porque sean negligentes, sino porque el ruido ya no deja distinguir la señal.
Ninguna de esas cifras describe una plantilla de sysadmins desbordada por un centro de datos anticuado. Describe equipos de 2026, con stacks modernos, SLOs definidos y presupuesto de observabilidad, que igualmente se ahogan. Y esa es la paradoja que atraviesa todo lo que se está escribiendo este año sobre el futuro del rol SRE: nunca hemos tenido tantos datos, tantas métricas y tanta automatización disponible, y sin embargo la sensación de estar vigilando bien el sistema no ha mejorado al mismo ritmo. Vale la pena preguntarse qué ha cambiado realmente en el trabajo del SRE, y qué sigue exactamente igual que hace veinte años.
De «ingeniero de software haciendo operaciones» a vigilante de modelos
El término site reliability engineering nació en Google en 2003, cuando Ben Treynor Sloss formó el primer equipo con ese nombre. La idea fundacional, recogida después en el libro de Google sobre SRE, era sencilla de enunciar aunque difícil de ejecutar: en vez de tener un equipo de operaciones separado del de desarrollo, coger ingenieros de software y ponerlos a resolver problemas de operaciones con mentalidad de ingeniería —automatizar en vez de repetir tareas a mano, y tratar la fiabilidad como algo que se diseña, no que se vigila a posteriori—. Durante mucho tiempo, eso significó sobre todo una cosa muy concreta: mantener sistemas arriba, medir la disponibilidad, gestionar el on-call y reducir el trabajo repetitivo (lo que en la jerga de SRE se llama toil).
Veintitrés años después, el catálogo de responsabilidades se ha disparado sin que el nombre del puesto haya cambiado. Según el Dynatrace State of SRE 2026, citado en el blog de Dynatrace sobre cómo la IA está cambiando el juego para los SRE, monitorizar modelos de IA en producción se ha convertido ya en el caso de uso más habitual para estos equipos, por delante incluso de la respuesta a incidentes clásica: un 67% de los SRE encuestados ya lo hace, y un 58% sitúa vigilar el rendimiento y la precisión de esos modelos entre sus tareas más frecuentes. No es un añadido menor al trabajo de siempre. Es un tipo de fallo distinto al que la disciplina nació para resolver: un modelo no «cae» como cae un servidor, sino que puede seguir respondiendo con normalidad mientras se degrada silenciosamente en precisión, sesgo o coste de inferencia, sin que ninguna de las señales tradicionales de infraestructura lo capture.
La automatización trasladó el trabajo, no lo eliminó
Uno de los hallazgos más honestos —y menos cómodos para quien vende automatización como solución universal— aparece en el SRE Report 2026 de LogicMonitor/Catchpoint, elaborado a partir de 418 profesionales de SRE e IT de todo el mundo durante el verano de 2025: pese a la adopción creciente de IA, los ingenieros siguen dedicando una media del 34% de su tiempo a tareas repetitivas. La promesa de la automatización siempre ha sido reducir ese porcentaje a base de eliminar trabajo manual. Lo que está ocurriendo en la práctica, según recoge también el propio análisis de Dynatrace, es distinto: la automatización no ha desaparecido el trabajo, lo ha desplazado. Ahora ese tiempo se dedica a validar las salidas de sistemas de IA, revisar decisiones que un agente automatizado tomó por su cuenta, y supervisar procesos que en teoría ya no requerían supervisión humana.
Es una lección que cualquiera que haya automatizado un proceso de verdad reconoce: automatizar no borra el trabajo, lo mueve a otra capa —de «hacer la tarea» a «comprobar que la tarea se hizo bien»—, y esa segunda capa no siempre es más rápida ni menos desgastante que la primera. El mismo informe de LogicMonitor/Catchpoint añade un dato que conecta con esto: aunque el 60% de los encuestados se declara optimista respecto al papel de la IA en SRE, y más de la mitad planea desplegar IA agéntica en los próximos doce meses (el doble de confianza que el año anterior), solo un 17% realiza pruebas de caos o de resiliencia de forma regular en producción. Hay más entusiasmo por delegar decisiones en sistemas automáticos que disciplina para comprobar, de antemano, qué pasa cuando esos sistemas fallan.
SRE, 2003 SRE, 2026
══════════ ══════════
[ Servidor ] → ¿está arriba? [ Servidor ] → ¿está arriba?
[ Latencia ] → ¿dentro de SLO? [ Microservicio ] → ¿traza completa, sin errores?
[ On-call ] → ¿alguien responde? [ Modelo de IA ] → ¿sigue siendo preciso? ¿a qué coste?
[ Agente IA ] → ¿la decisión que tomó fue correcta?
[ On-call ] → ¿la alerta es una de las que sí importa?
Demasiados datos, poca claridad: el problema no es que falte información
Si el primer desafío es de alcance (vigilar más cosas, de naturaleza más difícil de vigilar), el segundo es casi lo contrario: sobra información y falta capacidad de dar sentido a lo que ya se tiene. El propio artículo de Dynatrace lo resume con un dato que a cualquiera que trabaje con SLOs le va a sonar familiar: un 89% de las organizaciones ya usa objetivos de nivel de servicio, pero casi la mitad de los SRE encuestados señala el exceso de fuentes de datos como el obstáculo principal para definir objetivos que de verdad signifiquen algo. Tener el dato no es lo mismo que tener el dato correcto en el sitio correcto, y los sistemas modernos —repartidos entre contenedores efímeros, funciones serverless, colas de mensajes y ahora modelos de IA— emiten muchísimas más señales que un servidor físico con su syslog y su agente de monitorización clásico.
El SRE Report 2026 aporta un matiz que conviene no pasar por alto: la propia definición de «fiabilidad» está cambiando. Ya no basta con medir disponibilidad; cerca de dos tercios de los encuestados consideran que una degradación de rendimiento es tan grave como una caída completa, y sin embargo solo el 26% mide de forma consistente si esas mejoras de rendimiento se traducen en algo que le importe al negocio (ingresos, satisfacción de cliente). Es la misma tensión de siempre —métricas técnicas que no siempre se traducen en impacto de negocio— pero ahora multiplicada por el número de sistemas que hay que vigilar a la vez.
Lo que no ha cambiado: el hierro sigue estando ahí debajo
Con toda esta conversación puesta en modelos de IA, SLOs y observabilidad de microservicios, es fácil olvidar un hecho aburrido pero innegociable: en algún punto de la cadena sigue habiendo un servidor físico o virtual con CPU, memoria y disco, y ese servidor puede quedarse sin espacio, saturarse de logs o sufrir un pico de carga exactamente igual que hace quince años. Los datos de NeuBird sobre alertas ignoradas no hablan solo de observabilidad de aplicaciones: hablan también de la monitorización de infraestructura de toda la vida, la que avisa de que un disco está lleno o de que una CPU lleva media hora al 100%, y que sigue generando el mismo tipo de ruido —o de silencio, cuando la alerta que hacía falta nunca llegó— que las alertas de un microservicio.
Esto es, de hecho, una de las conclusiones más honestas que se pueden sacar de toda esta oleada de informes: no es que la monitorización clásica de hosts, aplicaciones y bases de datos haya quedado obsoleta y sustituida por la observabilidad moderna. Es que ahora convive con una capa nueva y mucho más compleja por encima, y los equipos de SRE tienen que sostener las dos a la vez con el mismo número de personas —o, según el propio informe de NeuBird, con más presión aún: un 93% de las organizaciones necesita tres o más ingenieros para responder a un incidente crítico, y un 40% necesita entre seis y diez—. La fiabilidad de un servicio moderno sigue dependiendo, en última instancia, de que el hierro de abajo esté sano; simplemente ya no es lo único de lo que hay que ocuparse.
Los límites de lo que la IA puede resolver aquí
Conviene ser honesto con lo que la IA aplicada a SRE (lo que la industria llama AIOps o, más recientemente, IA agéntica para operaciones) resuelve de verdad y con lo que todavía no. Reduce ruido de alertas correlacionando señales que un humano tardaría horas en cruzar a mano, y puede sugerir causas raíz más rápido que un runbook estático. Pero los propios datos de adopción muestran una brecha de confianza real: en el estudio de NeuBird, el 74% de los ejecutivos dice usar IA para resolver estos problemas, frente a solo un 39% de los ingenieros que están sobre el terreno —una diferencia de percepción que suele traducirse, en la práctica, en herramientas de IA compradas desde arriba que el equipo técnico no termina de incorporar a su día a día—. Y la adopción de IA agéntica, que toma decisiones y ejecuta acciones sin supervisión humana en cada paso, convive con un dato inquietante: solo un 17% de los equipos prueba de forma regular cómo se comporta su sistema bajo fallo. Delegar decisiones automáticas en un entorno que apenas se ha probado bajo estrés es, como mínimo, un riesgo que merece más atención de la que está recibiendo.
Qué significa esto para el día a día
Si algo queda claro al poner estos informes uno al lado del otro es que el trabajo de SRE no se ha simplificado con más automatización; se ha vuelto más ancho. Antes el reto era casi puramente técnico —tener buena instrumentación y buenos runbooks—; ahora es también un reto de priorización: decidir qué señales de las miles disponibles merecen convertirse en una alerta, qué SLO representa de verdad lo que le importa al usuario, y qué decisiones conviene automatizar del todo frente a cuáles conviene dejar con un humano en el bucle, al menos mientras la confianza en el sistema automático no esté verificada con pruebas reales de resiliencia. Nada de esto sustituye la disciplina de base —seguir vigilando el disco, la CPU y la memoria del servidor de siempre— sino que la coloca como cimiento de algo bastante más complejo que hace veinte años.
Fuentes:
- Dynatrace — AI is changing the reliability game for SREs
- LogicMonitor/Catchpoint — The SRE Report 2026: Reliability Is Being Redefined
- Carrier Management — Alert Fatigue Drags Down IT Production Environments, Leads to Costly Outages (estudio NeuBird AI, 2026)
- Rootly — History of SRE: Why Google Invented the SRE Role
- Google SRE Book — Part I: Introduction
