Site Reliability Workbook: patrones que seguimos usando
Actualizado: 2026-05-03
El Site Reliability Workbook cumple siete años y sigue siendo el segundo libro que recomiendo cuando alguien llega a un equipo de operaciones. El primero es el libro original de SRE —el azul—, pero el Workbook es el que la gente abre al día siguiente cuando tiene un incidente y necesita una plantilla. Con la distancia que dan siete años en producción he ido viendo qué capítulos resisten el uso real en equipos pequeños y cuáles solo tienen sentido a escala de un campus de Mountain View.
Puntos clave
- Los SLO honestos (ligeramente por debajo de lo que realmente consigues) son más útiles que los aspiracionales: dan presupuesto de error real para usar y negociar.
- La ventana rodante de 28–30 días evita que el último día del mes sea un día raro donde nadie quiere desplegar.
- El postmortem sin culpa no significa no señalar responsables, sino no castigar a quien ejecutó el comando; sin responsables no hay seguimiento.
- El presupuesto de error funciona como moneda de negociación con producto solo si está escrito y acordado previamente como política de tres niveles.
- En equipos de 2–3 personas, la on-call compleja es sobreingeniería; funciona mejor la política simple de “quien desplegó el viernes, responde el fin de semana”.
SLO honestos por encima de SLO aspiracionales
El capítulo de implementación de SLO sigue siendo el mejor que conozco. La idea central de medir lo que el usuario siente, no lo que el servidor reporta, sigue sin estar suficientemente asimilada. Un SLO que se calcula a partir del código de respuesta del backend antes de pasar por el CDN, la red del usuario y el navegador miente con una tranquilidad asombrosa.
En la práctica he acabado haciendo lo contrario de lo que recomiendan muchos tutoriales. En vez de definir un SLO aspiracional altísimo y quedarme corto todos los meses, prefiero definir un SLO honesto, algo por debajo de lo que realmente consigo, y tener presupuesto de error real para usar.
- Un SLO del 99.99 % que incumples el 40 % del tiempo no te da margen para nada.
- Uno del 99.5 % que cumples casi siempre te da un presupuesto medible de 3,6 horas al mes, y se convierte en la moneda con la que negocias con producto.
La técnica concreta del libro que sigo usando al pie de la letra es la ventana rodante de 28 o 30 días en lugar de mes natural. Esto evita que el último día del mes se vuelva un día raro donde nadie quiere desplegar.
Postmortems sin culpa, pero con acción
El capítulo de postmortems ha envejecido bien. La idea de postmortem sin culpa no se refiere a no señalar responsables, se refiere a no castigar a la persona que ejecutó el comando. Es un matiz que importa porque sin responsables no hay seguimiento.
Lo que hemos cambiado en la práctica es el formato. La plantilla canónica del libro tiene cronología, resumen, causa raíz, acciones y aprendizajes. En equipos pequeños acaba siendo demasiado proceso para incidentes menores. Hemos acortado a cuatro campos:
- Qué pasó en lenguaje llano.
- Qué métrica lo detectó o por qué no lo detectamos antes.
- Qué vamos a hacer distinto.
- En qué plazo.
Tres párrafos y dos acciones con fecha son más útiles que seis páginas que nadie relee.
La regla de oro: si una persona pudo romperlo, lo romperemos de nuevo. La acción no es despedir a esa persona, es convertir la operación en algo que un humano cansado no pueda romper accidentalmente. Validación previa, confirmación para operaciones destructivas, dry-run por defecto.
Presupuesto de error como moneda real
El presupuesto de error es el patrón que uso todas las semanas. Si tengo un SLO del 99.5 % mensual, tengo 3,6 horas al mes de indisponibilidad permitida. Si este mes ya he consumido 3 horas por un incidente, me queda poco margen para desplegar una versión con riesgo.
La parte que el libro describe bien y que cuesta aplicar es usar el presupuesto como señal para producto, no solo para el equipo de operaciones. Cuando el presupuesto se agota, tiene que haber una política conocida por todos que detenga los despliegues. Si eso no está acordado previamente con producto, la conversación se vuelve imposible en medio del incidente.
En mi experiencia este acuerdo funciona mejor escrito como tres niveles:
- Verde: despliegue libre.
- Ámbar: despliegue solo con revisión y cambios pequeños.
- Rojo: congelación de funcionales hasta el siguiente período.
Dos umbrales, tres estados, cero ambigüedad.
Gestión de carga y degradación elegante
El capítulo de gestión de carga es donde más me separo del libro. Los patrones que describe —con colas de prioridad, limitadores globales de tasa y técnicas de descarte selectivo— son correctos pero están diseñados para sistemas de alto tráfico distribuidos a escala masiva.
Lo que sí funciona para equipos pequeños es la idea de degradación elegante: cuando un subsistema empieza a fallar, hay que tener decidido de antemano cuál es el estado degradado aceptable.
- Si la base de datos secundaria deja de responder, la aplicación sigue en modo solo lectura.
- Si el servicio de recomendaciones cae, la página muestra contenido popular en lugar de romperse.
Estas decisiones son baratas de implementar si se toman de antemano, y carísimas en medio del incidente. El mismo principio aplica a las prácticas de FinOps aplicado a IA: tener umbrales y respuestas definidas antes de que ocurra el gasto excesivo.
Lo que no hemos adoptado
No todo el Workbook nos ha servido:
- El capítulo de gestión de on-call con rotaciones complejas, compensación y primary-secondary estrictos asume un equipo de al menos seis personas. En equipos de dos o tres personas funciona mejor la política simple de que quien desplegó el viernes por la tarde es el primero en ser llamado. Sin compensación formal, pero tampoco hay despliegues a las 18:00 de un viernes.
- El ejercicio de disaster recovery completo cada trimestre es demasiado ambicioso para mantenerse. Lo que hacemos, menos ambicioso pero más sostenible, es un ejercicio de mesa de media hora al mes: uno del equipo lanza un escenario y los demás dicen qué harían. No cae nada de verdad, pero nos obliga a revisar runbooks y encontrar huecos en la documentación.
Cuándo compensa volver al libro
El Workbook sigue en la estantería porque hay tres momentos en los que volver al índice merece la pena:
- Cuando llega alguien nuevo al equipo y hay que explicarle por qué medimos lo que medimos.
- Cuando un incidente sale mal y la retrospectiva necesita un marco compartido.
- Cuando alguien de producto pregunta por qué no podemos desplegar más rápido, y hace falta un lenguaje común para discutir fiabilidad y velocidad.
Lo que el libro hace mejor que cualquier otra referencia es dar vocabulario. Presupuesto de error, SLI, SLO, carga interactiva frente a asíncrona, fallo parcial. Sin ese vocabulario compartido, las reuniones sobre fiabilidad se quedan en impresiones personales.
Mi recomendación: no lo leas entero. Empieza por los capítulos de SLO, postmortem y presupuesto de error, aplícalos durante tres meses, y vuelve al libro después para los patrones más avanzados. Aplica el índice con respeto pero no con devoción.
