SRE —Site Reliability Engineering, o ingeniería de confiabilidad— es la práctica de tratar la disponibilidad de un servicio como un problema de ingeniería con métricas y presupuestos, en lugar de como una tarea de vigilancia. Nació en Google y hoy es el modelo operativo de referencia cuando la disponibilidad deja de ser un asunto del área de infraestructura y se convierte en un compromiso con el negocio.
Su idea central es contraintuitiva: la meta no es que el sistema nunca falle. La meta es decidir, de forma explícita y con números, cuánta falla puede tolerar el negocio, y usar ese margen como presupuesto para innovar.
¿Qué problema resuelve SRE?
Hay una conversación que se repite en casi todas las organizaciones que entregan software de forma continua. El equipo de desarrollo quiere lanzar; el equipo de operaciones quiere estabilidad. Cada lanzamiento es un riesgo, y cada semana sin lanzar es una oportunidad perdida. La discusión se resuelve por jerarquía, por costumbre o por quien argumenta mejor, pero rara vez por evidencia.
El síntoma clásico: después de una caída visible, se congelan los despliegues “hasta nuevo aviso”. Nadie sabe cuándo termina ese “hasta nuevo aviso”, porque no hay un criterio que lo defina. Meses después el ciclo se repite.
SRE resuelve exactamente eso. Convierte la confiabilidad en una cifra acordada por las dos partes antes del conflicto, y deja que esa cifra decida. Cuando el servicio está por encima de su objetivo, se lanza. Cuando cae por debajo, la prioridad cambia. La discusión deja de ser sobre opiniones y pasa a ser sobre un número que ambos lados aceptaron.
SRE frente a DevOps: cómo se relacionan
Es la confusión más común, y vale despejarla temprano.
DevOps describe el objetivo: eliminar el muro entre quienes construyen el software y quienes lo operan, para entregar cambios de forma frecuente y segura. Es una filosofía y un conjunto de principios culturales.
SRE describe una implementación concreta de ese objetivo, con prácticas prescriptivas y métricas definidas. Donde DevOps dice “compartan la responsabilidad de la producción”, SRE dice cómo: definan estos indicadores, acuerden estos objetivos, midan este presupuesto, y cuando se agote, hagan esto.
| Dimensión | DevOps | SRE |
|---|---|---|
| Qué es | Filosofía y cultura | Disciplina de ingeniería con prácticas definidas |
| Pregunta que responde | ¿Cómo entregamos software mejor? | ¿Cuánta confiabilidad necesitamos y cómo la sostenemos? |
| Unidad de medida típica | Métricas DORA | SLI, SLO y presupuesto de error |
| Origen | Movimiento de la comunidad (2009) | Práctica interna de Google, publicada en 2016 |
| Relación con el riesgo | Reducirlo mediante automatización | Presupuestarlo de forma explícita |
La formulación más citada lo resume bien: SRE es lo que ocurre cuando le pides a un ingeniero de software que diseñe un equipo de operaciones. No se elige entre uno y otro; en la práctica, la mayoría de los equipos que adoptan SRE ya venían trabajando con prácticas DevOps y necesitaban el siguiente nivel de precisión.
SLI, SLO y SLA: los tres términos que ordenan la conversación
Estos tres conceptos son el vocabulario mínimo de SRE, y se confunden con frecuencia porque en el lenguaje comercial peruano casi todo se llama “SLA”.
- SLI (indicador de nivel de servicio): una medida cuantitativa y cuidadosamente definida de algún aspecto del servicio. Los más habituales son la latencia de las solicitudes, la tasa de error y la disponibilidad expresada como proporción de solicitudes exitosas.
- SLO (objetivo de nivel de servicio): el valor o rango que ese indicador debe cumplir. Por ejemplo: “el 99% de las solicitudes de consulta responden en menos de 100 milisegundos”.
- SLA (acuerdo de nivel de servicio): el contrato con el cliente, que incluye consecuencias —normalmente económicas— si el objetivo no se cumple.
La prueba para distinguir un SLO de un SLA es de una sola pregunta: ¿qué pasa si no se cumple? Si no hay una consecuencia explícita, es un SLO. Un incumplimiento real de SLA es materia contractual.
Tres criterios prácticos al definir objetivos, tomados de la experiencia documentada de quienes llevan más tiempo en esto:
- No elijas el objetivo mirando el desempeño actual. Adoptar como meta lo que hoy se logra por casualidad amarra al equipo a sostener un sistema que exige esfuerzos heroicos y que no se puede mejorar sin rediseñarlo.
- Ten los menos objetivos posibles. Si un objetivo nunca sirve para ganar una discusión de prioridades, probablemente no valga la pena mantenerlo.
- No sobrecumplas. Los usuarios se apoyan en el comportamiento real del servicio, no en el prometido. Un servicio que promete 99,9% y entrega 99,99% de forma sostenida genera dependencias que se romperán el día que vuelva a su objetivo.
El presupuesto de error: el número que destraba la discusión
El presupuesto de error es la diferencia entre el 100% y el objetivo acordado. Si el objetivo es 99,9% de solicitudes exitosas en el trimestre, el presupuesto es ese 0,1%: la cantidad de falla que el servicio puede gastar sin incumplir su compromiso.
El mecanismo es simple y por eso funciona. Mientras quede presupuesto, se lanzan cambios. Si el presupuesto se agota, los lanzamientos se pausan y el esfuerzo se redirige a pruebas, resiliencia y corrección de causas raíz. Un incidente que consume el 20% del presupuesto es exactamente eso: el 20%, no “un problema grave” o “algo menor” según quién lo cuente.
El efecto organizacional es más interesante que el técnico. El equipo de desarrollo deja de necesitar que alguien lo frene, porque administra su propio margen: nadie quiere gastar el presupuesto en un despliegue apurado si eso le bloquea el lanzamiento del mes siguiente. Y una caída de un proveedor de nube también consume presupuesto, lo que alinea a todos alrededor del mismo número en lugar de repartir culpas.
Lo que cuesta cada nueve
La decisión sobre el objetivo es económica antes que técnica. Esta tabla traduce cada nivel a tiempo de indisponibilidad tolerado en un año calendario:
| Objetivo de disponibilidad | Indisponibilidad tolerada al año | Indisponibilidad tolerada al mes |
|---|---|---|
| 99% | 3 días 15,6 horas | 7 horas 18 minutos |
| 99,9% | 8 horas 45 minutos | 43,8 minutos |
| 99,95% | 4 horas 23 minutos | 21,9 minutos |
| 99,99% | 52,56 minutos | 4,38 minutos |
| 99,999% | 5,26 minutos | 26,3 segundos |
Cada nueve adicional reduce el tiempo tolerado en un orden de magnitud, pero el costo de conseguirlo no crece de forma proporcional: crece mucho más rápido. Por eso el nivel correcto no es el más alto que la tecnología permita, sino el que corresponde a lo que el negocio pierde por hora de caída. Un sistema de facturación mensual y una pasarela de pagos no necesitan el mismo número, y tratarlos igual es caro en un caso e insuficiente en el otro.
El trabajo repetitivo: la deuda operativa que sí se puede medir
SRE le puso nombre a algo que todo equipo de operaciones conoce: el trabajo repetitivo —toil— es el trabajo manual, automatizable, sin valor duradero, que crece en proporción directa al tamaño del servicio. Reiniciar un proceso a mano cada madrugada, aplicar el mismo parche servidor por servidor, ejecutar el mismo procedimiento de doce pasos cada vez que suena la misma alerta.
No es lo mismo que “trabajo aburrido” ni que “trabajo operativo” en general. La característica que lo define es que escala linealmente con el crecimiento: si el servicio duplica su tamaño, este trabajo duplica sus horas. Es deuda con interés.
La disciplina propone un techo explícito y verificable: mantener ese trabajo por debajo del 50% del tiempo de cada ingeniero, y dedicar al menos la otra mitad a trabajo de ingeniería que lo reduzca o que agregue capacidades al servicio. El valor de fijar el techo es que hace visible un deterioro que normalmente pasa desapercibido: cuando un equipo cruza esa línea de forma sostenida, deja de ser un equipo de ingeniería y se convierte en uno de tareas, sin que nadie haya tomado esa decisión.
Post-mortem sin culpables: aprender de la falla
Después de cada incidente relevante, la práctica es escribir un análisis que reconstruya qué pasó, qué lo permitió y qué se cambia para que no vuelva a pasar del mismo modo. La condición que lo hace funcionar es que sea sin culpables: el foco está en las condiciones del sistema, no en la persona que ejecutó el comando.
El supuesto de fondo es de ingeniería, no de amabilidad. Si una acción individual pudo tumbar el servicio, el hallazgo relevante no es que alguien se equivocó, sino que el sistema permitía ese error sin red de contención. Ahí está la corrección que vale la pena hacer.
El efecto práctico se ve en el reporte temprano. En una cultura que busca responsables, quien nota una anomalía a las 2 a.m. espera a ver si se resuelve sola. En una que analiza condiciones, la reporta de inmediato. La diferencia entre esas dos reacciones son horas de indisponibilidad.
Dónde termina SRE y dónde empieza la continuidad
Conviene trazar una línea que suele quedar borrosa. SRE se ocupa de la confiabilidad de la operación normal: que el servicio cumpla su objetivo día a día, y que las degradaciones se detecten y corrijan antes de que el cliente las sufra.
Los objetivos de continuidad —RTO y RPO— pertenecen a otra conversación: la de recuperación ante desastres, que define cuánto puede tardar el servicio en volver y cuántos datos es aceptable perder cuando ocurre algo excepcional, como la pérdida de una región completa.
Se complementan y se necesitan, pero no son intercambiables. Un servicio puede cumplir su objetivo de disponibilidad todos los meses y no tener una estrategia de recuperación que funcione. Y un plan de recuperación impecable no evita la muerte por mil degradaciones pequeñas.
SRE sobre AWS
Las prácticas de SRE son independientes del proveedor, pero necesitan instrumentación para existir: sin medición no hay indicador, sin indicador no hay objetivo y sin objetivo no hay presupuesto. AWS ofrece los componentes para cerrar ese ciclo de forma gestionada.
- Amazon CloudWatch concentra métricas, logs y alarmas. CloudWatch Application Signals permite definir objetivos de nivel de servicio sobre aplicaciones y seguir el consumo del presupuesto de error desde el tablero de objetivos de la consola, en lugar de calcularlo a mano en una hoja.
- AWS X-Ray aporta las trazas distribuidas que permiten ubicar en qué salto se degrada una solicitud —imprescindible cuando el indicador es la latencia y la arquitectura son microservicios.
- AWS Fault Injection Service ejecuta experimentos controlados de falla para comprobar que el sistema se comporta como se espera, en vez de descubrirlo durante el incidente real. Es la base de nuestra práctica de chaos engineering.
- Automation, la herramienta de AWS Systems Manager para procedimientos operativos, ejecuta con guiones reutilizables las tareas de mantenimiento y remediación que se repiten, que es la forma concreta de bajar el trabajo repetitivo por debajo del techo.
- AWS Well-Architected Framework, y en particular su pilar de confiabilidad, ordena la revisión periódica de la arquitectura contra buenas prácticas conocidas. Es el punto de partida habitual de un Well-Architected Review.
Todo esto se apoya en una base de observabilidad: métricas, logs y trazas correlacionadas. Un objetivo de nivel de servicio sin observabilidad detrás es una declaración de intenciones.
Cómo empezar con SRE sin reorganizar la empresa
La adopción no exige crear un área nueva ni contratar un perfil escaso. Empieza por acordar el vocabulario y medir:
- Elige los dos o tres servicios que sostienen el negocio. No todos los sistemas necesitan objetivos formales.
- Define un indicador por servicio, desde la experiencia del cliente. Proporción de solicitudes exitosas o latencia percibida, no el CPU del servidor.
- Acuerda un objetivo con el dueño del negocio, no solo con el área técnica. Es una decisión sobre cuánto cuesta una caída, y esa cifra no vive en el área de sistemas.
- Mide el presupuesto de error durante un trimestre antes de aplicar consecuencias. El primer trimestre sirve para calibrar el número, no para frenar despliegues.
- Instrumenta el post-mortem sin culpables desde el primer incidente. Es la práctica más barata de adoptar y la que más rápido cambia el comportamiento del equipo.
En Caleidos acompañamos esta adopción como parte de nuestra práctica de DevOps y la sostenemos en el tiempo con Caleidos Lens©, nuestra mesa de servicio 24×7: los objetivos que se acuerdan en un taller solo se vuelven reales cuando alguien los mide todos los días y actúa cuando se desvían.
¿Quieres ver cómo lo aplicamos? Revisa nuestros casos de éxito o conversemos.
