El cambio de mentalidad de sysadmin a SRE
De apagar fuegos a prevenir incendios
Durante años, mi identidad como sysadmin se basó en ser el “solucionador de problemas”. El servidor se cae, yo lo levanto. La base de datos va lenta, yo la optimizo. Ser el héroe que salva el día era una insignia de honor. El problema es que ser un héroe es agotador y, sobre todo, no escala.
El paso más difícil en mi transición a SRE no fue aprender a usar Kubernetes o Terraform. Fue un cambio fundamental de mentalidad: pasar de ser reactivo a ser proactivo y basado en datos.
sysadmin tradicional: El foco en el servidor
Como sysadmin, mi universo eran las máquinas. Mi principal preocupación era la salud de los servidores individuales: el uso de CPU, la memoria disponible, el espacio en disco. Si los servidores estaban “verdes”, mi trabajo estaba hecho.
Anécdota: Recuerdo pasar días optimizando el uso de memoria de un cluster de Elasticsearch porque el uso estaba constantemente al 85%. El servicio funcionaba perfectamente para los usuarios, las búsquedas eran rápidas y no había errores. Pero mi foco estaba en la métrica de la máquina, no en la experiencia del usuario. Estaba solucionando un problema que no existía.
Mentalidad SRE: El foco en el servicio y el usuario
Un SRE cambia el foco del servidor al servicio. La pregunta más importante no es “¿Está la CPU al 50%?”, sino “¿Estamos cumpliendo nuestro SLO?”.
El SLO es la promesa que hacemos a nuestros usuarios. Por ejemplo, “el 99.9% de las búsquedas deben devolver un resultado en menos de 200ms”. Si cumplimos ese objetivo, da igual si la CPU está al 95%. Y si no lo cumplimos, da igual que la CPU esté al 10%.
Este cambio es liberador. Te permite centrar tus esfuerzos de ingeniería en lo que realmente importa.
- Antes: “Tengo que reducir el uso de memoria de este servicio”.
- Ahora: “El SLO de latencia de este servicio está en riesgo. Mi Error Budget se está agotando. Tengo que investigar si es un problema de código, de base de datos o de infraestructura para proteger la experiencia del usuario”.
El Error Budget como guía
El concepto de Error Budget (el 0.1% de fallos que nos “permitimos” si nuestro SLO es del 99.9%) se convierte en tu brújula.
- ¿Tenemos mucho presupuesto de error? Genial, podemos dedicar tiempo a lanzar nuevas funcionalidades, a experimentar, a asumir riesgos calculados.
- ¿Nos estamos quedando sin presupuesto? Alto. Es hora de que todo el equipo (desarrolladores incluidos) se centre en la fiabilidad. No más funcionalidades nuevas hasta que el servicio vuelva a ser estable.
Esta es la diferencia fundamental. En lugar de una lucha constante entre “desarrollo quiere ir rápido” y “operaciones quiere estabilidad”, SRE crea un sistema basado en datos que alinea a todo el mundo en el mismo objetivo.
El camino de sysadmin a SRE es un viaje de dejar de ser el guardián de las máquinas para convertirte en el ingeniero de la fiabilidad del servicio. Y eso, en mi opinión, es mucho más interesante y gratificante.