El libro de SRE de Google, publicado en 2016, se ha convertido en la referencia de facto para ingeniería de fiabilidad. Pero está escrito para Google: miles de ingenieros, datacenters propios, herramientas internas. Aplicarlo literalmente en un equipo de 10 personas con todo en AWS produce fricción, a veces frustración. La buena noticia es que el 80% del valor viene de principios portables, no de infraestructura específica.
Los principios que sí se trasladan
Cinco ideas del libro que funcionan casi en cualquier contexto:
- SLO como contrato con el usuario. Define objetivos de nivel de servicio medibles (99.9% de peticiones exitosas, latencia p95 < 500ms). Es la diferencia entre “el sistema va bien” y “el sistema cumple la promesa hecha al cliente”.
- Error budget como permiso a correr riesgos. Si tu SLO es 99.9% y llevas el mes al 99.95%, tienes budget para probar cambios. Si estás rozando 99.9%, para de desplegar y estabiliza. Es un mecanismo de diálogo entre producto y operaciones.
- Postmortem sin culpa. Tras un incidente, analiza qué falló en procesos y sistemas, no en personas. Esta cultura se construye con prácticas explícitas — plantilla compartida, reunión sin juicio — no por buenas intenciones.
- Toil management. Toil = trabajo manual repetitivo, automatizable, sin valor duradero. El libro propone un límite: <50% del tiempo del equipo. Medirlo y atacarlo sistemáticamente es quizás el cambio cultural más valioso.
- On-call humano. Rotaciones razonables (no más de 1 semana cada 6), compensación explícita, post-incidente calm-down. Es un derecho laboral, no un ritual de paso.
Dónde hay que adaptar
Y las áreas donde la literalidad del libro choca con equipos pequeños:
Error budget policy estricta
En Google, si agotas el budget, se para todo despliegue de features y solo hay releases de fiabilidad hasta recuperar. En un equipo de 10 personas esto puede ser demasiado binario. Una política más práctica: a 50% de budget gastado, aumenta rigor de review; a 80%, bloqueo de features grandes; a 100%, solo bugfixes críticos.
Roles dedicados
Google tiene equipos dedicados a SRE separados de los equipos de desarrollo. En equipos pequeños, ambos son la misma gente. El libro asume esa separación que rara vez existe fuera de empresas grandes. Los principios funcionan igualmente bien con un equipo mixto que roles explícitos y rotaciones, sin necesidad de separar grupos humanos.
Escala de herramientas
Borgmon, Monarch, Dapper — las herramientas internas de Google tienen equivalentes open-source decentes (Prometheus, OpenTelemetry, Grafana), pero la madurez y la ergonomía no son equivalentes. Adaptar ideas sin intentar clonar herramientas ahorra frustración.
Capacity planning formal
El libro dedica capítulos a capacity planning proactivo en decenas de centros de datos. En AWS con autoscaling y serverless, la mayor parte del problema lo resuelve el proveedor. Leer esos capítulos ayuda a entender el fenómeno, no necesariamente a aplicarlo tal cual.
Un roadmap realista para empezar
Tres fases que funcionan en equipos de 5-30 personas:
Fase 1 (1-2 meses): SLOs básicos + postmortem
Elige 2-3 servicios críticos. Define un SLO simple por servicio (disponibilidad + latencia). Dashboards en Grafana que muestren el burn rate del error budget. Introduce plantilla de postmortem blameless. Tras el primer incidente con ese proceso, revisa cómo fue.
Fase 2 (3-6 meses): Toil reduction + on-call structure
Mide el toil (preguntas en Slack, manuales de despliegue, copiar-pegar entre paneles). Ataca los tres más grandes con automatización — no todos, solo los que doblen el retorno de la inversión. Formaliza rotación de on-call con compensación y reglas.
Fase 3 (6-12 meses): Alerting maduro + cultura
Revisa todas las alertas con los principios que cubrimos en cómo escribir alertas que no se ignoren. Integra postmortems como documentos vivos, no PDFs enterrados. Usa las retros del on-call para mejorar documentación y runbooks.
El papel del libro en formación del equipo
Una práctica común: lectura compartida del libro en book clubs de 1-2 capítulos por semana. No todos los capítulos son igual de relevantes; los que más valor dan fuera de Google:
- Capítulos 3 (Embracing Risk), 4 (Service Level Objectives), 5 (Eliminating Toil).
- Capítulo 11 (Being On-Call), 13 (Emergency Response), 15 (Postmortem Culture).
- Capítulos 16 (Tracking Outages), 17 (Testing for Reliability).
Los capítulos 18-20 (Cluster Management, Storage, Network) son interesantes académicamente pero poco aplicables sin ejército de infraestructura propio.
Complementario al libro: el Workbook de SRE tiene ejercicios prácticos — más accesible para equipos pequeños.
Ver también metodologías ágiles y su evolución para entender cómo SRE encaja con prácticas de entrega continua.
Conclusión
SRE como disciplina aporta principios sólidos: mide, define contratos con el usuario, analiza fallos sin culpar, automatiza lo repetitivo, trata al on-call con respeto. Esos principios funcionan en cualquier equipo. Lo que no se traslada es la infraestructura de Google — y eso está bien, porque no hace falta. Adapta ideas, no implementaciones.
Síguenos en jacar.es para más sobre SRE, observabilidad y operaciones en producción.
