Qué es site reliability engineering? Guía práctica

Entonces, ¿qué es site reliability engineering? Es la práctica de operar sistemas en producción usando ingeniería de software en lugar de tareas manuales. Un equipo SRE fija un objetivo de fiabilidad numérico, mide el servicio frente a ese objetivo y automatiza el trabajo repetitivo que mantiene los servicios en pie. Si tu alerta de disco salta a las 3 de la mañana cada mes, ese es exactamente el problema que SRE existe para eliminar.

Google acuñó el término hacia 2003. Hoy la idea se usa mucho más allá de Google, desde startups de 20 personas hasta bancos. Lo que cambia de unos a otros es la escala, no la mecánica básica.

¿Qué hace realmente un site reliability engineer?

Ben Treynor Sloss, que puso en marcha el equipo SRE de Google, lo resumió en el primer capítulo del libro SRE de Google: SRE es lo que pasa cuando le pides a un ingeniero de software que diseñe un equipo de operaciones. El trabajo es operaciones hechas con código.

En una semana normal son cuatro cosas. Defines qué significa que un servicio funcione. Construyes la monitorización que te avisa cuando no funciona. Respondes cuando se rompe, y escribes la corrección para que la siguiente persona no reciba el mismo aviso.

Dos ejemplos lo hacen concreto. Un equipo que despliega a mano cada jueves construye un pipeline con rollback automático. Un equipo que reinicia cada noche un servicio con fugas encuentra la fuga. Ambos convierten una tarea recurrente en un proyecto de una sola vez, y eso es todo el objetivo.

La cuarta parte es la que muchos equipos se saltan. Un SRE que solo responde a incidentes es un ingeniero de operaciones con un título nuevo. La parte de ingeniería es lo que hace distinto al rol.

¿En qué se diferencia SRE de DevOps?

DevOps es una cultura: desarrolladores y operadores comparten la responsabilidad de lo que se despliega y de cómo funciona. Te dice que el muro entre equipos es un problema. No te dice cuánto tiempo de caída es aceptable ni cuándo dejar de desplegar.

SRE aporta los números. Ofrece objetivos de nivel de servicio, presupuestos de error y un límite al trabajo manual. El propio planteamiento de Google es que SRE es una forma concreta de llevar las ideas de DevOps a la práctica.

Dejemos de lado el debate sobre cuál es mejor. Si diriges un equipo de 8 personas, tomarás prestado de los dos. La pregunta útil es si tu equipo puede responder en una frase qué nivel de fiabilidad necesita cada servicio.

¿Qué son los SLI, los SLO y los SLA, y por qué importan?

Tres siglas cargan con casi todo el peso en SRE, y la gente las mezcla constantemente.

• SLI (indicador de nivel de servicio): una medición. Por ejemplo, el porcentaje de peticiones HTTP que devuelven una respuesta distinta de 5xx en menos de 300 ms.

• SLO (objetivo de nivel de servicio): la meta para esa medición. Por ejemplo, que el 99.9% de las peticiones cumpla la condición en una ventana móvil de 28 días.

• SLA (acuerdo de nivel de servicio): el contrato con consecuencias, normalmente reembolsos, si no se cumple. Tu SLA debe ser más laxo que tu SLO.

La razón de medir es que "el sitio debe ser rápido y fiable" no se puede comprobar. Un objetivo como "el 99.9% de los pagos se completa en menos de 500 ms" sí se puede comprobar, y además sirve para zanjar discusiones.

Empieza con dos o tres SLI por servicio. Con más, nadie se acuerda de ellos. Y mide lo que el usuario recibe, no lo que dice tu panel de infraestructura. Un servidor puede estar encendido y devolver errores 500 en cada petición.

Elige SLI que los usuarios puedan notar. El uso de CPU es una causa, no un síntoma. Los pagos fallidos, las páginas lentas y los datos desactualizados son lo que un cliente percibe de verdad.

¿Cómo funcionan los presupuestos de error?

Un presupuesto de error es la falta de fiabilidad que tu SLO permite. Es simplemente 1 menos el SLO. Un objetivo de disponibilidad del 99.9% deja un 0.1%, unos 43 minutos de caída en un mes de 30 días.

Aquí tienes una versión pequeña en código, porque la aritmética es toda la idea:

slo = 0.999
minutos_ventana = 30 * 24 * 60              # 43200
presupuesto = (1 - slo) * minutos_ventana   # 43.2 minutos
gastado = 31                                # minutos de servicio defectuoso hasta ahora
print(f"{presupuesto - gastado:.1f} minutos restantes")  # 12.2 minutos restantes

Con 31 minutos gastados de 43, quedan 12. Si el próximo incidente dura 20 minutos, el equipo ya está en rojo y la conversación sobre publicar cambia por completo. Ese es el punto: decide el número, no la intuición de quien más alza la voz.

Mientras queda presupuesto, el equipo despliega rápido. Cuando se agota, se paran las publicaciones de funcionalidades y el trabajo pasa a fiabilidad. El ejemplo de política de presupuesto de error del SRE Workbook muestra cómo un equipo escribe esa regla.

No se trata de castigar. Sustituye la vieja pelea, en la que desarrollo quiere publicar y operaciones quiere estabilidad, por un número compartido que ambos pueden leer. Solo funciona si la dirección acepta de antemano respetar la pausa. Una política que se salta cada trimestre es pura decoración.

¿Por qué existe la regla del 50% de toil?

El toil es trabajo manual y repetitivo que crece con tu servicio y no deja nada a cambio. Reiniciar a mano un worker atascado es toil. Escribir el health check que lo reinicia automáticamente es ingeniería.

La organización SRE de Google busca que el toil sea inferior al 50% del tiempo de cada ingeniero, como se describe en el capítulo sobre eliminación del toil. El resto se dedica a proyectos que reducen el toil futuro o añaden funcionalidades. El razonamiento es directo: el toil se expande hasta ocupar el 100% del tiempo de todos si nadie lo frena.

Trata el 50% como un techo, no como un objetivo. Un equipo sano con un servicio maduro está muy por debajo. Si lleva un trimestre por encima, no está haciendo SRE: está gestionando una cola de operaciones.

Una forma sencilla de empezar: durante dos semanas, etiqueta cada ticket y cada aviso como toil o proyecto. Luego ordena el toil por horas. Los tres primeros elementos son tu lista de automatización.

¿Qué cambian los postmortems sin culpables?

Cuando algo se rompe, el postmortem pregunta cómo el sistema permitió que una persona cometiera ese error, no quién lo cometió. Culpar enseña a la gente a ocultar información. Una revisión sin culpables enseña a escribirla.

Un postmortem útil es breve y tiene cuatro partes: una línea temporal, las causas que contribuyeron, lo que salió bien y las acciones con responsable y fecha. Las acciones sin responsable son deseos.

Gran parte del valor está en el seguimiento. Revisa las acciones abiertas cada mes. Si la misma causa aparece dos veces en seis meses, el primer postmortem falló, diga lo que diga el documento.

¿Qué herramientas necesita primero un equipo SRE?

No muchas. Empieza por las señales y luego añade guardia y automatización. Un error frecuente es comprar la herramienta que mejores gráficos dibuja antes de decidir qué pregunta quieres responder.

1. Métricas y paneles. Suficientes para calcular tus SLI. Grafana y Prometheus son una combinación de código abierto muy extendida; Datadog y New Relic son la vía alojada.

2. Alertas ligadas a los SLO. Avisa cuando el presupuesto se quema rápido, no cuando un solo host sube. Menos avisos, mejores.

3. Feature flags y despliegue gradual. En términos generales, la mayoría de las caídas siguen a un cambio, así que la mejora de fiabilidad más barata es hacer que los cambios sean reversibles. LaunchDarkly y Statsig cubren esto.

4. Un runbook escrito para cada aviso. Si una alerta no tiene runbook, escríbelo o elimina la alerta.

Compra o construye en ese orden. Los equipos que empiezan comprando una herramienta sin SLO acaban con paneles preciosos que no miden nada en concreto.

¿Dónde encaja leer código desconocido en SRE?

Esta es la parte que nadie pone en la descripción del puesto. Durante un incidente, un SRE suele tener que entender un servicio que no escribió, en un repositorio que no abre desde hace meses. La pregunta rara vez es abstracta. Suele ser algo como "¿dónde vive este bucle de reintentos y qué hace cuando hay un timeout?".

Ya lo has hecho: grep, blame y luego escribir a quien tocó el archivo por última vez. En un repositorio de 80K líneas funciona. En doce servicios de seis equipos se come los primeros 20 minutos de un incidente, y esos minutos cuentan contra el presupuesto de error.

Ahí es donde una herramienta de búsqueda de código que responde preguntas sobre tu propio repositorio se gana su sitio, por ejemplo para averiguar dónde un servicio define sus timeouts y qué clientes dependen de ellos. No va a arreglar la caída. Acorta el tiempo que pasas leyendo antes de poder actuar, y ese tiempo se puede medir.

¿Es SRE demasiado para tu equipo y cómo empezar?

No necesitas un equipo SRE dedicado si tienes un solo servicio, un puñado de ingenieros y usuarios que toleran alguna mala hora ocasional. Necesitas un SLO, una alerta decente y alguien que sea responsable del busca.

Plantéatelo cuando se cumpla una de estas condiciones: las caídas cuestan ingresos reales, la guardia está quemando a la gente o los desarrolladores se frenan por peticiones operativas improvisadas. Muchas empresas empiezan haciendo que uno o dos ingenieros sean SRE a tiempo parcial y miran cómo les va.

Un error común es renombrar el equipo de operaciones como "SRE" sin cambiar cómo trabaja. Si el equipo sigue gestionando tickets, despliegues manuales y sin presupuesto de error, cambió el título y nada más.

Cómo empezar la semana que viene

No necesitas una reorganización. Elige el servicio de cara al usuario que más te duele y haz cinco cosas.

1. Define un SLI y un SLO para él. Mantenlos sencillos.

2. Calcula el presupuesto de error y ponlo en un panel que todo el equipo pueda ver.

3. Registra el toil durante dos semanas y elige el primer elemento para automatizar.

4. Haz un postmortem sin culpables en tu próximo incidente, con acciones que tengan responsable.

5. Acuerda por escrito qué ocurre cuando el presupuesto llegue a cero.

Si dentro de un mes el equipo discute menos sobre si publicar y más sobre lo que dicen los números, va por buen camino. Si el presupuesto nunca se mueve porque el SLO es demasiado laxo, aprétalo.