Qué es site reliability engineering SRE: guía para devs
Resumen
SRE, o site reliability engineering, consiste en tratar las operaciones como un problema de software. Fijas un objetivo de fiabilidad medible, controlas cuántas veces lo incumples y ese número decide si publicas funciones o arreglas lo que falla. Para un dev solo basta con decidir de antemano cuánta caída aceptas: un SLI, un SLO de 99.5%, un health check y un archivo de postmortems. Eso es suficiente hasta que tengas usuarios que dependan de ti.
Qué es site reliability engineering SRE? Es tratar las operaciones como un problema de software: fijas un objetivo de fiabilidad medible, controlas cuántas veces lo incumples y dejas que ese número decida si publicas funciones o arreglas lo que falla. Google le puso nombre, pero la idea sirve a cualquier tamaño. Para un dev solo con una app y unos cuantos usuarios, significa decidir de antemano cuánta caída estás dispuesto a aceptar.
Lo que suele atascarse en la práctica: la mayoría de proyectos personales no tienen ese número. Están "arriba" hasta que alguien te escribe un correo. Esta guía explica SRE en términos sencillos y luego lo reduce a algo que una persona puede mantener en un fin de semana.
¿Qué es realmente site reliability engineering?
La versión corta viene del libro de SRE de Google: SRE es lo que obtienes cuando pides a un ingeniero de software que diseñe un equipo de operaciones. En lugar de que alguien reinicie servidores a mano, escribes código que lo hace y mides los resultados.
Tres ideas cargan con casi todo el peso. La fiabilidad es una funcionalidad con un objetivo, no una sensación. El trabajo manual repetitivo (el libro lo llama toil) es un fallo que hay que automatizar. Y el error se da por hecho, así que planeas cómo aprender de él en lugar de cómo buscar culpables.
DevOps y SRE se solapan bastante. La diferencia práctica: DevOps es una cultura de publicar y operar el código juntos, mientras que SRE te da herramientas concretas para discutirlo con números. No hace falta elegir bando para usar los números.
SLI, SLO y SLA: tres siglas, una idea cada una
Un SLI (indicador de nivel de servicio) es algo que mides. En una web suele ser la proporción de peticiones que salen bien, o la proporción que responden en menos de 300 ms. Elige uno o dos. No doce.
Un SLO (objetivo de nivel de servicio) es la meta que fijas sobre esa medida, por ejemplo "99.9% de las peticiones correctas en 30 días". Es interno. Es una promesa que te haces a ti mismo.
Un SLA (acuerdo de nivel de servicio) es un contrato con un cliente, normalmente con reembolsos si se incumple. Si nadie te ha pagado por disponibilidad, todavía no tienes un SLA, y no deberías escribir uno por accidente en el texto de tu página de precios.
El presupuesto de errores: la pieza que cambia cómo trabajas
El presupuesto de errores es simplemente 100% menos tu SLO. Un objetivo de 99.9% en 30 días deja unos 43 minutos de fallos permitidos. Ese es el presupuesto que puedes gastar en despliegues arriesgados, migraciones y experimentos.
Lo útil es la regla que va asociada. Mientras quede presupuesto, publicas. Cuando se agota, dejas de lanzar funciones y arreglas la fiabilidad hasta que se recupere. El capítulo del libro sobre riesgo plantea esto como una forma de zanjar la discusión entre "ir más rápido" y "no romper nada" con un número compartido en lugar de una negociación.
También deja un punto directo que conviene repetir: el 100% casi nunca es el objetivo correcto. Los usuarios con redes móviles inestables no distinguen 99.99% de 99.9%, y cada nueve extra cuesta mucho más que el anterior. No es un objetivo perfecto. Es uno que se puede cumplir.
Si quieres el flujo de trabajo concreto para elegir indicadores y escribir el primer objetivo, el workbook de SRE sobre implementar SLO es el capítulo más práctico, y es breve.
¿Qué hace un SRE todo el día?
En una empresa grande, un SRE reparte su tiempo entre guardias, respuesta a incidentes, planificación de capacidad y automatización. El libro de Google dice que la carga operativa no debería superar alrededor de la mitad del tiempo de un ingeniero, para que el resto vaya a ingeniería. Ese límite es una restricción de diseño, no un extra opcional.
El trabajo recurrente tiene este aspecto:
Definir SLO junto a los equipos de producto y avisar por consumo del presupuesto, no por cada fallo puntual
Organizar las guardias y escribir runbooks para que el aviso de las 3 de la mañana tenga una lista de pasos
Liderar la respuesta a incidentes y después escribir un postmortem sin culpables
Automatizar cualquier tarea manual que se repita más de unas pocas veces
Revisar los lanzamientos en busca de riesgos de fiabilidad antes de que lleguen a producción
Las feature flags son un buen ejemplo de esa mentalidad. Una flag te permite apagar una publicación defectuosa en segundos, sin volver a desplegar, y eso protege el presupuesto. Si necesitas una herramienta alojada para ello depende de cuántas flags tengas: una variable de entorno puede bastar con las tres primeras.
¿Necesitas SRE si construyes tú solo?
Tres razones para hacerlo, una para no hacerlo.
Las razones para hacerlo: tu proyecto acabará despertándote, tarde o temprano; un objetivo escrito te frena cuando quieres sobre-ingeniería; y "opero producción con un SLO" suena bien cuando alguien decide si te contrata o confía en ti. La razón para no hacerlo: si tu proyecto todavía no tiene usuarios, estás practicando para un problema que no tienes. Construye primero y mide cuando alguien dependa de ello.
Así que sáltate el aparato completo. No pagues un servicio de avisos para una app de hobby, no montes Kubernetes para parecer serio y no escribas una plantilla de incidentes de 10 páginas. Sí merece la pena si tienes al menos diez usuarios reales: un health check, un SLO y un sitio donde mirar cuando algo se rompa.
Una configuración de SRE en una tarde para un proyecto personal
Este es el mínimo que suele aguantar también cuando llegas a 10 000 usuarios. Te lleva una tarde. Probado. No óptimo. Lo hacemos igualmente porque es aburrido, y lo aburrido sobrevive.
Primero, elige un SLI: la proporción de peticiones HTTP que no devuelven un 5xx. Segundo, fija el SLO en 99.5% en 30 días, lo que equivale a unas 3.6 horas de presupuesto. Empieza holgado y aprieta después. Tercero, añade una comprobación de disponibilidad externa que apunte a un endpoint de salud real.
Un endpoint de salud que merezca la pena comprueba lo que de verdad se rompe, no solo que el proceso siga vivo:
// GET /healthz
app.get("/healthz", async (req, res) => {
try {
await db.query("select 1"); // base de datos accesible
await cache.ping(); // caché accesible
res.status(200).json({ ok: true });
} catch (err) {
res.status(503).json({ ok: false });
}
});Cuarto, envía las alertas a un sitio donde las vayas a ver: una notificación push en el móvil, no un buzón de correo. Quinto, guarda un archivo de texto llamado postmortems.md y añade cuatro líneas después de cada caída: qué pasó, por qué, cuánto duró y qué cambia. Ese archivo es la herramienta de fiabilidad más infravalorada que vas a tener.
Dónde ayudan las herramientas de IA y dónde no
Los asistentes son razonablemente buenos en la parte repetitiva del trabajo: escribir el health check, el Terraform de un monitor de disponibilidad, un primer borrador de runbook o un script que calcule la tasa de 5xx a partir de los logs. Son malos decidiendo tu SLO, porque eso es una decisión de producto sobre lo que tolera tu usuario.
Durante un incidente hay que tener cuidado. Un asistente puede sugerir un arreglo plausible que aplicas en producción a las 2 de la mañana sin haberlo leído. Úsalo para explicar un stack trace o para redactar el postmortem después, y deja la decisión de hacer rollback en manos de una persona despierta.
Las puertas de calidad del código también encajan en este cuadro. Muchas caídas vienen de un cambio que parecía inofensivo en la revisión. El análisis estático en CI no te dará fiabilidad, pero elimina una clase de errores tontos antes de que consuman presupuesto.
¿Cómo escribes un postmortem que alguien lea?
Corto y sin culpables. Sin culpables no significa que nadie sea responsable. Significa preguntar qué del sistema permitió el error, no quién lo cometió. Cuando eres el único del equipo, esto pesa más de lo que parece, porque la tentación es sentirte mal y saltarte el texto.
Con cuatro apartados basta: qué pasó, por qué pasó, cuánto tiempo estuvieron afectados los usuarios y qué cambia. El último debe nombrar una acción que de verdad vas a hacer, con fecha. "Tener más cuidado" no es una acción. "Añadir una comprobación en staging para las migraciones antes del próximo lanzamiento" sí lo es.
Con el tiempo, ese archivo se convierte en un mapa de tus puntos débiles. La regla tras tres caídas causadas por el mismo certificado caducado: si una misma causa aparece dos veces, automatízala. Hizo falta una tarde para añadir la monitorización de renovaciones, y no se ha vuelto a repetir.
Avisa por ritmo de consumo, no por cada fallo puntual
Un error típico de principiante es avisarte a ti mismo cada vez que falla una sola petición. En una semana silenciarás el canal. Una señal mejor es el burn rate: a qué velocidad estás gastando el presupuesto de errores, comparado con el ritmo que lo agotaría justo al final de la ventana.
En un proyecto personal, mantenlo sencillo. Envía una notificación push si la tasa de errores de los últimos 10 minutos supera el 5%, y un resumen por correo si la tasa semanal va camino de incumplir el SLO. Así tienes dos niveles: despierta ahora, o míralo el lunes. Lo más sofisticado puede esperar hasta que los usuarios se quejen del primer nivel.
¿Es SRE una buena carrera para un dev al que le gusta construir?
Depende de lo que disfrutes. Los puestos de SRE encajan con quien prefiere los sistemas, los modos de fallo y la automatización antes que enviar interfaces. Si te satisface que las alertas suenen menos, te gustará. Si quieres ver cómo los usuarios hacen clic en tu nueva funcionalidad, probablemente no.
La entrada suele ser por el trabajo de backend o de infraestructura: empiezas a encargarte de los despliegues y avisos de un servicio y luego asumes más de su fiabilidad. Habilidades que se trasladan: nociones de Linux, redes, un proveedor de nube, una pila de monitorización y el hábito de dejar las cosas por escrito. Los proyectos personales son un buen sitio para practicarlas todas, porque tú eres todo el equipo.
Qué construir después
Elige algo que ya tengas en marcha, aunque sea una app del plan gratuito, y escribe su SLI, su SLO y la acción exacta que tomarás cuando se agote el presupuesto. Si no sabes qué dejarías de hacer, el número es decoración. ¿Cuál de tus proyectos notarías caído antes de que te lo dijera un usuario?