Un recorrido por Site Reliability Engineering: qué es, en qué se diferencia de DevOps, cómo se mide, por qué el trabajo manual repetitivo es su enemigo y por qué Google terminó mirando la teoría de control (STAMP) para entender sus propios sistemas. Todo con un mismo ejemplo, deliberadamente absurdo, analizado con cada método.
Ingeniería de software aplicada a la operación.
Un SRE es una especialización dentro de la filosofía DevOps. Su trabajo es producir sistemas fiables, escalables y mantenibles, y lo hace con herramientas de ingeniería: código, métricas, automatización y análisis.
Aparece con fuerza cuando el sistema ya está en producción y la estabilidad pasa a ser una necesidad de negocio. Normalmente llega a un lugar donde ya existen pipelines, y su foco es otro: gestionar incidentes, automatizar respuestas, escalar servicios, reducir el trabajo manual y sostener objetivos de nivel de servicio (SLOs).
Distintos en alcance, complementarios en la práctica.
| Aspecto | DevOps | SRE |
|---|---|---|
| Naturaleza | Filosofía o cultura | Rol o práctica técnica |
| Enfoque | Colaboración entre desarrollo y operaciones | Fiabilidad y estabilidad en producción |
| Punto de partida | Transformación cultural y organizacional | Implementación técnica sobre problemas reales |
| Métrica central | Velocidad de entrega | Fiabilidad medida en SLI, SLO y error budget |
| Responsabilidad | Principios y herramientas: infraestructura, automatización, CI/CD | Operar, escalar, reducir el toil y garantizar la disponibilidad |
| Crecimiento | Abarca a toda la organización | Sistemas críticos en producción |
| Prácticas clave | CI/CD, infraestructura como código, automatización | Incidentes, SLOs, observabilidad, post-mortems |
| Base | CAMS: cultura, automatización, métricas, sharing | Ingeniería de software aplicada a operaciones |
Los seis pilares del SRE, según Dynatrace, y lo que gana el negocio.
Dynatrace resume la práctica SRE en seis pilares. Ninguno es nuevo por separado; lo útil es verlos juntos, porque cada uno reaparece más adelante en este cuaderno con un ejemplo concreto. Debajo de cada pilar está el capítulo donde lo vas a ver funcionando.
Devolver el sistema a su estado estable lo antes posible cuando algo falla.
→ 06 · triaje con Kepner-TregoeAutomatizar donde se pueda y, mejor aún, diseñar controles que hagan innecesario el trabajo manual repetitivo.
→ 05 · el toilAnalizar el incidente sin buscar a quién castigar, para que los equipos colaboren y aprendan.
→ 07 · CAST sobre el perroVisibilidad real de la salud del sistema en producción, no dashboards que nadie mira.
→ 08 · el feedback del bucleVivir y respirar los SLOs para detectar y corregir problemas antes de violar un SLA.
→ 04 · el error budgetInfluir en las decisiones de arquitectura para que la fiabilidad venga desde la base.
→ 08 · STPA y el rediseñoLa fuente de los seis pilares.
SLI, SLO, SLA y el presupuesto de error.
El SLI es lo que mides (por ejemplo, el porcentaje de peticiones exitosas). El SLO es el objetivo interno que te pones sobre ese indicador. El SLA es el contrato con el cliente, siempre más laxo que el SLO para tener margen.
La diferencia entre el 100 % y el SLO es el error budget: la cantidad de fallo que te puedes permitir en una ventana de tiempo. Es lo que vuelve la fiabilidad una decisión de ingeniería y no una discusión: si queda presupuesto, se despliega; si se agota, se congela y se trabaja en estabilidad.
El trabajo que crece con el sistema y no deja nada atrás.
No todo trabajo operativo es toil. Toil es el trabajo manual, repetitivo, automatizable, táctico, sin valor duradero y que crece linealmente con el servicio. Escribir un post-mortem es trabajo manual, pero deja aprendizaje; reiniciar el mismo servicio cada noche no deja nada.
La respuesta clásica al toil es automatizar: un script por cada tarea repetida. Funciona hasta que deja de funcionar. En sistemas distribuidos, automatizar sin entender cómo interactúan las partes produce incidentes automatizados a escala, y el equipo termina con un toil nuevo: mantener sus propios scripts, silenciar alertas ruidosas y parchar síntomas que vuelven.
El problema no suele ser la falta de un script, sino un control mal diseñado.
Esa es la intuición que desarrolla el capítulo 08: por eso el pilar “eliminar el toil” del capítulo 03 termina, en el fondo, siendo un problema de diseño de controles.
Ningún método solo alcanza; cada uno mira un momento distinto.
Hay muchas formas de resolver un problema y rara vez basta una sola. Algunos métodos sirven para decidir rápido bajo presión, otros para encontrar causas, y otros para diseñar el sistema de modo que el problema no pueda ocurrir. La diferencia más útil es cuándo actúan.
| Método | Enfoque | Relación | Lo que se le escapa |
|---|---|---|---|
| Kepner-Tregoe | Separar el problema de la decisión | Independiente | La causa estructural |
| RCA | Encontrar la causa raíz | Enfoque general | Las interacciones; tiende a una sola causa |
| 5 porqués | Preguntar “¿por qué?” hasta el fondo | Herramienta de RCA | Sesgo lineal: un camino, un culpable |
| Ishikawa | Agrupar causas posibles por categoría | Herramienta de RCA | Los bucles de retroalimentación |
| STAMP | Accidentes como fallas de control | Framework | Exige modelar el sistema: más esfuerzo inicial |
| STPA | Prevenir acciones de control inseguras | Parte de STAMP | — |
| CAST | Post-mortem sobre la estructura de control | Parte de STAMP | — |
Un incidente doméstico, cuatro lecturas.
Un perro muerde zapatos en la sala, sobre todo por las tardes. Para leerlo como ingenieros conviene nombrar las piezas:
| En la casa | Papel en el sistema | En producción |
|---|---|---|
| Zapatos | Activo que no se puede perder | Datos, transacciones, experiencia del usuario |
| Perro | Proceso dinámico con energía propia | Tráfico, microservicios, procesos asíncronos |
| Dueños | Controlador | Equipo SRE y su automatización |
| Armario, puertas | Restricciones | Guardrails, políticas, límites, cuotas |
| Cámara, sensores | Retroalimentación | Observabilidad, alertas, SLIs |
| Entrenamiento | Ajuste del proceso | Runbooks, automatización, cambios de diseño |
Lectura SRE. Excelente para el triaje de guardia: decide rápido bajo presión. Pero no explica por qué el sistema permitió el incidente; si mañana alguien deja un zapato abajo, vuelve a pasar.
Ocurre cuando está solo o aburrido. No ocurre cuando está acompañado o tiene juguetes.
Los zapatos están ahora a su alcance y tiene menos actividad por la tarde.
Tiene juguetes atractivos o recibe atención: juegos, paseos.
Es mucho más frecuente tras periodos largos sin interacción humana.
Lectura SRE. El RCA lineal concluye “faltó supervisión” y la acción típica es “que alguien mire la cámara cada hora”. Eso es toil puro: el equivalente a mirar dashboards a mano o reiniciar servicios todos los días.
Que el perro no muerda zapatos ni objetos no designados. Para eso el sistema debe restringir el acceso, mantener al perro estimulado y supervisar y corregir.
Zapatos al alcance, sin estímulos, largos periodos sin supervisión, sin entrenamiento. Impacto: pérdida económica, refuerzo del hábito y riesgo de salud si ingiere partes.
La puerta se deja abierta; los juguetes pierden novedad; la reacción llega tarde; el entrenamiento es inconsistente.
Lectura SRE. STPA asume desde el diseño que “acordarse de cerrar la puerta” va a fallar, y obliga a buscar controles que no dependan de la memoria humana. Las Figs. 9 y 10 del capítulo 08 muestran el método en detalle.
Zapato destruido, hábito reforzado, riesgo veterinario.
Dueños (controlador), perro (proceso), zapatos (activo), entorno físico. Restricciones que fallaron: acceso, estímulo y supervisión.
Los dueños tenían un modelo mental erróneo: creían que el perro no tocaría los zapatos. No había señal temprana que contradijera esa creencia.
Almacenamiento cerrado por defecto, estímulos, sensores en zonas prohibidas, barreras permanentes.
Un SLI simple: días con zapatos intactos sin intervención humana.
Lectura SRE. CAST no pregunta “¿quién falló?” sino “¿por qué tenía sentido para ellos actuar así?”. Es un post-mortem sin culpables con método.
La evolución del SRE en Google.
STAMP (System-Theoretic Accident Model and Processes) es un modelo de accidentes creado por Nancy Leveson en el MIT. Su idea central: los accidentes no ocurren solo porque un componente se rompe, sino porque los controles y restricciones entre componentes fueron inadecuados.
En diciembre de 2024, Google explicó por qué su organización SRE empezó a usarlo. Los error budgets funcionaban bien con servicios web mayormente sin estado; pero hoy hay productos con pérdidas que no pueden ocurrir nunca, es decir, con presupuesto de error cero. Para esos casos hace falta entender cómo interactúa el sistema completo, no solo si cada pieza cumple su SLO.
La teoría de control tiene casi un siglo: nació cuando radares, cohetes y computadoras superaron lo que el análisis de componentes y el ensayo-error podían manejar. STAMP la aplica a la seguridad de sistemas. La diferencia con el RCA se ve mejor dibujada.
En la vista de cadena cada evento causa el siguiente. Sigue bajando y el diagrama se convierte en un bucle de control.
Todo lo que vimos hasta aquí —Kepner-Tregoe, RCA, CAST, incluso el error budget— necesita que algo ocurra primero: un incidente, una métrica que se mueve, un post-mortem. Se aprende pagando. Y cada incidente nuevo suele ser distinto al anterior, así que el aprendizaje siempre va un paso atrás.
La revolución de STPA es invertir el orden. Se analiza el sistema cuando todavía está en el papel y se pregunta: ¿cómo podría llegar a una pérdida que nunca ha ocurrido? No hace falta un historial de fallas. Hace falta saber qué no puede pasar, cómo se controla el sistema y de qué maneras ese control podría volverse inseguro.
No hace falta que el perro muerda el primer zapato para saber que puede hacerlo.
Fíjate en el incidente “no previsto” de la Fig. 7. No es un descuido del dibujo: es el punto. Tener análisis proactivo no hace desaparecer el modo reactivo. Lo que cambia es cuántas veces se usa y para qué.
La teoría de control —la misma de la que nace STAMP— lo explica con dos lazos. La anticipación (feedforward) actúa antes de la perturbación, con lo que el modelo predice: eso es STPA. La retroalimentación (feedback) corrige la desviación después de medirla: eso es el monitoreo, el incidente y CAST. Ningún ingeniero de control diseña con uno solo. Solo con anticipación, cualquier error del modelo pasa sin corrección; solo con retroalimentación, siempre llegas tarde.
El reactivo nunca desaparece por tres razones. El modelo siempre está incompleto: STPA descubre peligros que no conocías, pero no todos. El sistema cambia: nuevas funciones, más tráfico, gente nueva; un análisis correcto hace un año hoy puede no serlo. El entorno cambia: dependencias, proveedores, usuarios que hacen lo inesperado.
Y lo más importante: el reactivo alimenta al proactivo. Cada incidente analizado con CAST muestra en qué se equivocó el modelo, y esa corrección vuelve al siguiente análisis STPA. Sin el lazo reactivo, el proactivo se queda congelado en lo que sabías el día del diseño.
Por eso lo que cambia no es solo la cantidad de incidentes, sino su naturaleza:
| Solo reactivo | Proactivo + reactivo | |
|---|---|---|
| Frecuencia | Incidentes frecuentes | Menos incidentes |
| Tipo | Muchos se repiten o eran previsibles | Los que quedan son sorpresas reales |
| Para qué se reacciona | Para apagar incendios | Para aprender algo nuevo |
| Post-mortem | Confirma lo que ya se sospechaba | Corrige el modelo del sistema |
| Detección | Tardía: el zapato roto | Rápida: el diseño incluyó el feedback |
Esto también ordena qué lazo cuida qué. Las pérdidas inaceptables —un pago duplicado, el perro que se enferma— se cubren con el lazo proactivo: restricciones duras que salen de STPA. Las degradaciones tolerables —algo de latencia, un zapato viejo mordido— se cubren con el lazo reactivo: SLO, error budget y post-mortem. No es “proactivo o reactivo”: cada tipo de pérdida tiene su lazo.
Prevenir no es dejar de reaccionar: es reaccionar menos veces, a cosas nuevas, y aprender de cada una.
Así que el éxito no se mide en cero incidentes, sino en cero incidentes repetidos y cero pérdidas inaceptables.
STPA no es una lluvia de ideas: cada paso tiene un formato fijo, y cada elemento apunta al del paso anterior. Así, cualquier requisito final puede rastrearse hasta la pérdida que evita: requisito → escenario → UCA → peligro → pérdida. Esa trazabilidad es lo que lo vuelve ingeniería y no intuición.
Fíjate en que ningún ejemplo de abajo describe algo que haya ocurrido. Todo es anticipación.
El corazón de STPA es el paso 3: tomar cada acción de control y preguntar de cuatro formas cómo podría volverse peligrosa. No busca fallas de componentes, sino combinaciones: una acción correcta en el momento equivocado también es un riesgo.
Con el bucle a la vista, las soluciones dejan de ser “vigilar más” y se vuelven cambios de estructura:
El SRE clásico pregunta cuánto puede fallar el sistema. STAMP pregunta qué controles impiden que falle de la forma que no podemos aceptar.
Lo que vale la pena leer, cursar y revisar.
La evolución del SRE en Google hacia STAMP.
¿Vale la pena el MTTR? Sus límites estadísticos.
De los mejores blogs explicando el viaje de SRE.
Quality gates con SLI/SLO, coreografía de entrega por eventos y auto-remediación con red de seguridad basada en SLOs.
Incluidos en Coursera Plus.
La novela que popularizó DevOps.
Seguridad de la cadena de suministro de software.
Charlas, artículos y podcast sobre STPA y CAST.
Qué buscan las empresas y hacia dónde seguir.
Recopilación de lo que piden hoy las empresas.
Aspectos a tener en cuenta según la teoría y los libros de Google.
Este cuaderno sigue en revisión. Las sugerencias son bienvenidas.