La evolución profesional de quien administra sistemas hacia roles de Site Reliability Engineering (SRE) no es solo cuestión de adoptar nuevas herramientas o aprender a usar Kubernetes. Es un cambio más profundo: implica replantear cómo entiendes tu trabajo, qué mides, cómo te relacionas con los equipos de desarrollo y, sobre todo, qué significa para ti que algo «funcione».
El problema es que este tránsito suele presentarse como una simple actualización de skills. Te dicen que aprendas a escribir código, que uses pipelines de CI/CD y que empieces a hablar de observabilidad. Y sí, todo eso importa. Pero sin entender los cambios de mentalidad que hay debajo, es fácil acabar siendo un sysadmin clásico con otro título en el email.
Este artículo va sobre esos cambios invisibles pero cruciales. El vocabulario que necesitas conocer, las prioridades que se redefinen y los errores más habituales en la transición.
Del mantenimiento reactivo al enfoque proactivo: apagar fuegos vs. evitarlos
El sysadmin clásico se mide, en muchos entornos, por su capacidad de respuesta. Algo se rompe, tú lo arreglas rápido. Cuanto más rápido, mejor profesional eres. Ese modelo tiene su lógica en ciertos contextos, pero el SRE parte de una premisa diferente: si sigues apagando el mismo fuego una y otra vez, el problema no es el fuego, eres tú.
El SRE asume la fiabilidad como un objetivo medible y gestionable, no como una consecuencia de estar siempre disponible. Esto implica diseñar sistemas con tolerancia a fallos, automatizar la resolución de problemas recurrentes y colaborar con desarrollo para mejorar el software antes de que llegue a producción con problemas conocidos.
Aquí aparece un concepto clave: el toil. En el mundo SRE, toil es el trabajo operacional que es manual, repetitivo, automatizable y que no aporta valor acumulativo. Parchear servidores uno a uno, relanzar servicios caídos cada semana, ejecutar scripts a mano en cada despliegue… todo eso es toil. El SRE tiene como objetivo explícito reducirlo. No es que sea malo hacer ese trabajo en un momento dado; el problema es cuando ese trabajo ocupa más del 50% de tu tiempo y nunca construye nada.
El cambio mental no es trivial. Requiere abandonar la satisfacción inmediata del «problema resuelto» para invertir tiempo en soluciones que tardan más en verse pero que evitan que el problema vuelva.
SLIs, SLOs y SLAs: medir la fiabilidad en lugar de suponerla
Uno de los primeros choques con el mundo SRE es el vocabulario. Se habla mucho de SLIs, SLOs y SLAs, y aunque suenan parecido, son cosas distintas que conviene tener claras.
Un SLI (Service Level Indicator) es la métrica concreta que mides: porcentaje de peticiones con latencia inferior a 200ms, disponibilidad del servicio en los últimos 30 días, tasa de errores. Es el dato en bruto.
Un SLO (Service Level Objective) es el objetivo que defines sobre ese indicador: el 99,5% de las peticiones deben responder en menos de 200ms. Es la línea que decides que no quieres cruzar. Definir un SLO es, en cierto modo, declarar públicamente qué nivel de fiabilidad consideras aceptable.
Un SLA (Service Level Agreement) es el contrato con el cliente, que habitualmente tiene consecuencias económicas si no se cumple. Lo importante aquí es que el SLA debe ser menos ambicioso que tu SLO interno: si prometes externamente el 99,9% de disponibilidad, tu objetivo interno debería ser el 99,95%, para tener margen de reacción antes de que el incumplimiento llegue al cliente.
Para un sysadmin clásico, la disponibilidad suele ser un concepto binario: el servicio está arriba o está caído. En el mundo SRE, es un espectro que se mide, se gestiona y se negocia. Eso cambia completamente cómo priorizas el trabajo.
El error budget: la idea más contraintuitiva del SRE
Si solo hay un concepto del SRE que choca de verdad con la mentalidad sysadmin clásica, ese es el error budget.
El razonamiento es este: si defines que tu SLO es el 99,5% de disponibilidad, estás diciendo implícitamente que aceptas un 0,5% de tiempo de fallo. Ese 0,5% es tu error budget, tu presupuesto de error. No es algo malo; es algo que gestionas de forma consciente.
Mientras tu error budget esté intacto, puedes hacer despliegues frecuentes, experimentar, asumir cierto riesgo. Si lo estás agotando —porque ha habido incidentes, porque el servicio está fallando más de lo esperado— reduces la velocidad: menos cambios, más estabilidad, más tiempo en revisar la causa raíz.
El error budget crea un lenguaje común entre operaciones y desarrollo. Cuando desarrollo quiere desplegar algo arriesgado y el error budget está bajo mínimos, no es el sysadmin siendo obstruccionista: es el indicador del sistema diciendo que ahora no es el momento. Eso cambia la conversación completamente.
Para alguien acostumbrado a que «cero incidentes» sea siempre el objetivo, esto resulta extraño al principio. Pero tiene mucho sentido cuando entiendes que el objetivo no es eliminar los fallos —imposible—, sino gestionar cuánto fallo puedes permitirte y cuándo.
Automatización con criterio: ni todo ni nada
La automatización es uno de los pilares del SRE, pero no debe entenderse como un fin en sí mismo. Hay una trampa habitual: automatizar porque se puede, sin evaluar el coste-beneficio. El resultado es sistemas complejos que nadie entiende del todo y que cuando fallan, lo hacen de formas inesperadas.
Un enfoque más maduro es priorizar la automatización donde el impacto es claro: procesos repetitivos con frecuencia alta, tareas propensas a error humano, operaciones con impacto directo en la disponibilidad. Y ser honesto sobre qué no vale la pena automatizar todavía, especialmente cuando el proceso cambia con frecuencia o el contexto es demasiado variable.
La automatización bien hecha libera tiempo para análisis de incidentes, mejora continua y trabajo de mayor valor. La automatización mal hecha añade deuda técnica y una capa de complejidad que al final alguien tiene que mantener.
La relación con desarrollo: de frontera a intersección
En muchos entornos tradicionales, la frontera entre operaciones y desarrollo está bastante marcada. Desarrollo entrega, operaciones despliega y soporta. Cuando algo falla en producción, empieza el debate de a quién le toca.
El SRE trabaja en la intersección entre ambos mundos. Entiende las necesidades de desarrollo y las traduce en requisitos de fiabilidad, escalabilidad y observabilidad. Aporta feedback sobre cómo el software impacta en la estabilidad del sistema y colabora en el diseño antes de que llegue a producción.
Esto puede generar tensiones al principio. Hay equipos de desarrollo que ven al SRE como un obstáculo o como un «policía» que pone trabas a los despliegues. Hay sysadmins que sienten que pierden autonomía o que se les pide que hagan trabajo de desarrollo sin la formación ni el contexto necesarios. La clave está en que la fiabilidad se entienda como un esfuerzo compartido, no como la responsabilidad exclusiva de ninguno de los dos equipos.
Las guardias: la parte que el libro de Google no cuenta bien
El on-call es uno de los cambios más importantes en la transición al SRE y también uno de los que genera más conflictos cuando se implementa mal.
En teoría, el modelo SRE de guardia tiene sentido: quien está de guardia recibe las alertas, gestiona los incidentes, y después analiza las causas raíz para evitar que vuelvan a ocurrir. La guardia es un mecanismo de retroalimentación que mejora el sistema.
En la práctica, muchas empresas adoptan la estructura de guardia SRE sin adoptar las condiciones que la hacen sostenible. El técnico recibe alertas durante la noche, gestiona incidentes en su tiempo libre y al día siguiente se espera que rinda con normalidad en su jornada. Eso no es SRE; es explotación con otro nombre.
Para que el modelo funcione de verdad, hay que compensar el esfuerzo del on-call de forma explícita: con tiempo libre compensatorio, con reducción de carga en los días siguientes a una guardia activa, o con compensación económica real. Las guardias también deben rotarse con frecuencia razonable y con equipo suficiente para que nadie cargue con una frecuencia insostenible.
Si una organización implementa guardias SRE sin resolver esto, está creando un sistema que quema a las personas más comprometidas. Y eso no es un problema técnico; es un problema de gestión que ninguna herramienta va a solucionar.
Errores comunes en la transición
El error más frecuente es asumir que ser SRE es solo un cambio de título o la adopción de ciertas herramientas. Sin cambiar la forma de medir el éxito y de entender las prioridades, es fácil mantener viejas prácticas bajo un nombre nuevo.
Otro malentendido habitual es subestimar la cultura y la comunicación. La colaboración entre operaciones y desarrollo no surge automáticamente con la creación de un equipo SRE. Requiere tiempo, confianza y la voluntad de negociar prioridades y responsabilidades de forma continua.
Por último, no calibrar bien los niveles de automatización puede generar sistemas rígidos, difíciles de mantener o simplemente infrautilizados. El equilibrio depende del contexto y de la madurez del equipo, y no hay una fórmula universal.
Qué se gana y qué se pierde
Adoptar una mentalidad SRE aporta mayor resiliencia, mejora la experiencia del usuario y puede reducir la carga operativa a largo plazo. Pero implica renunciar a cierto control manual y a la simplicidad de procesos conocidos. También puede aumentar la complejidad inicial y requiere inversión real en formación y cultura.
No siempre es recomendable aplicar el enfoque SRE en todos los entornos. En infraestructuras pequeñas o con baja criticidad, el coste de implementar estas prácticas puede superar los beneficios. Antes de embarcarse en la transformación, conviene evaluar si el contexto lo justifica.
Para terminar
El paso de sysadmin clásico a SRE no es solo una actualización técnica. Es aprender a medir la fiabilidad en lugar de suponerla, a gestionar el fallo de forma consciente en lugar de evitarlo a cualquier coste, y a trabajar con desarrollo en lugar de separarse de él.
Requiere criterio para balancear automatización y supervisión, paciencia para construir cultura y claridad para definir qué significa la fiabilidad en cada contexto concreto. Y requiere que las organizaciones que adoptan el modelo sean honestas sobre las condiciones que lo hacen viable, especialmente en lo que respecta a las personas que lo sostienen.
Al final, no se trata solo de herramientas o procesos. Se trata de una nueva forma de pensar el rol del profesional que mantiene vivos los sistemas.