De administradores a SRE: una transición por etapas

Muchas áreas de infraestructura quieren adoptar ingeniería de confiabilidad de sitios (SRE, por sus siglas en inglés) y empiezan por el lugar equivocado: cambian el nombre del equipo, compran una herramienta de monitoreo y esperan que el resto llegue solo. Al cabo de unos meses el equipo hace lo mismo que antes, con otro cargo en la firma del correo.

SRE no es un título. Es una forma de operar que se apoya en tres ideas: la confiabilidad se mide desde el usuario, el trabajo manual repetitivo tiene un límite y el equipo dedica tiempo real a la ingeniería que reduce ese trabajo. Llegar ahí desde un equipo de administradores de sistemas es posible, pero conviene hacerlo por etapas, sin desarmar la operación que hoy sostiene el negocio. Este artículo propone cinco etapas, qué se logra en cada una y cómo saber que es momento de pasar a la siguiente.

Por qué no basta con cambiar el nombre

El Site Reliability Workbook de Google, en el capítulo "SRE Team Lifecycles", describe tres formas de empezar un equipo SRE: crearlo para un proyecto nuevo, armar un equipo transversal que asesora a otros o convertir un equipo de operaciones existente. La tercera es la más frecuente en organizaciones con trayectoria, y el mismo capítulo advierte el error típico: renombrar el equipo sin cambiar sus prácticas.

El mismo texto plantea que se pueden adoptar prácticas SRE antes de tener personas con ese cargo, empezando por los objetivos de nivel de servicio. Ese es el punto de partida de una transición sana: primero cambian las prácticas y la forma de medir; los roles y la estructura se ajustan después, cuando hay evidencia de que funcionan.

Hay una segunda razón para ir por etapas. Un equipo de administración en una organización regulada carga con compromisos que no pueden pausarse: cierres contables, ventanas de cambio, auditorías, contratos con niveles de servicio. Cualquier transición que exija detener eso para "rehacer" el modelo fracasa antes de empezar.

Cinco etapas para la transición

Cada etapa produce algo que la siguiente necesita. Saltarse una suele obligar a volver atrás.

Etapa 1. Medir el trabajo repetitivo

El libro Site Reliability Engineering de Google, en el capítulo "Eliminating Toil", define el toil como el trabajo operativo manual, repetitivo, automatizable, táctico, sin valor duradero y que crece en proporción al tamaño del servicio. No todo trabajo operativo es toil: una reunión de planificación o la revisión de un diseño no lo son.

Durante unas semanas, cada persona registra en qué se va su tiempo operativo, con una unidad simple (horas) y categorías acordadas: reinicios, altas de usuarios, renovación de certificados, atención de alertas, solicitudes de cambio. El capítulo sobre toil del Workbook recomienda exactamente eso: elegir una unidad objetiva y medir antes, durante y después de reducirlo. El resultado es una línea base y una lista de las principales fuentes de toil. Sin ella, cualquier mejora posterior es una opinión.

Etapa 2. SLO en pocos servicios

Elige dos o tres servicios con dueño de negocio claro y datos disponibles. Para cada uno define un indicador de nivel de servicio (SLI) medido cerca del usuario, un objetivo (SLO) y, sobre todo, una política de presupuesto de error firmada por producto, desarrollo y operaciones. El capítulo "Implementing SLOs" del Workbook es claro: sin una política escrita que diga qué pasa cuando el presupuesto se agota, el SLO es un indicador más en un tablero.

No intentes cubrir todo el catálogo. Pocos servicios bien medidos enseñan más que cincuenta SLO que nadie revisa. Si quieres el detalle de cómo convertir esos SLO en alertas útiles, lo tratamos en alertas sin fatiga con SLO.

Etapa 3. Guardias sostenibles y postmortems sin culpa

Con los SLO definidos, las alertas que despiertan a alguien pasan a ser las que indican que el usuario está sufriendo. Las demás bajan a tableros o tickets. El capítulo "Being On-Call" del libro de SRE propone como referencia que la guardia no ocupe más del 25 % del tiempo de una persona y estima como máximo dos incidentes por turno de guardia de 12 horas, porque cada incidente bien atendido, con su análisis y su seguimiento, consume horas.

En paralelo se instala el postmortem sin culpa: un documento escrito tras cada incidente relevante que busca las causas que contribuyeron, sin acusar a personas ni equipos, y que termina en acciones con responsable y fecha. Es la etapa en la que más cambia la cultura, y la que más depende del ejemplo de los líderes.

Etapa 4. Automatizar y acotar el toil

Con la línea base de la etapa 1, el equipo elige las fuentes de toil de mayor peso y las automatiza o las elimina. Google propone mantener el toil por debajo del 50 % del tiempo de cada SRE; el resto se dedica a ingeniería que reduce el toil futuro o mejora los servicios. Ese límite se vuelve un compromiso explícito con la dirección: si el toil lo supera de forma sostenida, se planifica cómo bajarlo, en lugar de contratar más personas para absorberlo.

Etapa 5. Nuevos perfiles y formación

Solo ahora tiene sentido formalizar roles. Con prácticas funcionando, se definen los perfiles SRE, los criterios para que un servicio pase a ser operado con este modelo y el plan de formación para quienes vienen de la administración de sistemas.

Perfiles y formación: el cambio más lento

Un administrador de sistemas con experiencia conoce el comportamiento real de la plataforma, los procedimientos de recuperación y las dependencias que no están en ningún diagrama. Ese conocimiento es el activo más valioso de la transición y no conviene perderlo por exigir de golpe un perfil de desarrollador.

Recomendamos un plan por competencias, no por cursos sueltos:

• Programación aplicada a la operación: un lenguaje de scripting, control de versiones y revisión de código entre pares.
• Infraestructura como código y gestión de configuración, para que los cambios sean repetibles y auditables.
• Medición: SLI, SLO, presupuesto de error y lectura de métricas de latencia y error.
• Respuesta a incidentes: roles de coordinación, comunicación y redacción de postmortems.
• Diseño para la confiabilidad: capacidad, degradación controlada y dependencias.

Conviene combinar formación con práctica guiada: parejas entre perfiles de operación y de desarrollo, rotaciones cortas por el equipo de producto y tiempo protegido para proyectos de automatización. Un plan de formación sin tiempo protegido compite con el toil y pierde.

Qué se mantiene de ITIL

SRE y la gestión de servicios no son excluyentes. Una organización regulada sigue necesitando procesos definidos, trazabilidad y controles que un auditor pueda revisar. Lo que cambia es cómo se ejecutan.

• Gestión de incidentes: se mantiene el registro, la clasificación y la comunicación. SRE aporta las alertas por síntoma y roles claros durante la respuesta.
• Gestión de problemas: los postmortems sin culpa son, en la práctica, una forma disciplinada de gestionar problemas. Sus acciones deben quedar en el mismo registro de problemas.
• Gestión de cambios: el presupuesto de error da un criterio objetivo para decidir el ritmo de cambio. Los cambios estándar, automatizados y probados pueden seguir un camino preaprobado; los de alto riesgo mantienen su revisión.
• Gestión del nivel de servicio: los SLO internos se alinean con los acuerdos de nivel de servicio (SLA) contractuales y suelen ser más exigentes que ellos, para dar margen de reacción.
• Catálogo y CMDB: siguen siendo la referencia de qué servicios existen y quién es su dueño, base necesaria para definir SLO.

La regla práctica: conserva el control y el registro que exige la regulación, y cambia la ejecución manual por automatización medible.

Checklist de etapas

La tabla resume qué se logra en cada etapa y qué evidencia conviene tener antes de pasar a la siguiente. Los plazos dependen del tamaño del equipo y de la cantidad de servicios.

Etapa	Qué se logra	Evidencia para avanzar
1. Medir el toil	Línea base del tiempo operativo y sus principales fuentes	Varias semanas de registro con categorías acordadas
2. SLO en pocos servicios	SLI, SLO y política de presupuesto de error firmada	Al menos un ciclo de revisión del presupuesto con producto y desarrollo
3. Guardias y postmortems	Alertas por síntoma, rotación con carga medida y postmortems sin culpa	Avisos por turno registrados y acciones de postmortem con seguimiento
4. Automatizar el toil	Reducción medible del toil respecto a la línea base	Toil por debajo del límite acordado de forma sostenida
5. Perfiles y formación	Roles definidos, plan de competencias y criterios de adopción de servicios	Servicios nuevos que entran al modelo con SLO y runbooks desde el inicio

Errores frecuentes

• Empezar por la estructura. Reorganizar el área antes de medir genera resistencia y no cambia el trabajo diario.
• SLO sin consecuencias. Si agotar el presupuesto de error no cambia ninguna decisión, el SLO no está gobernando nada.
• Automatizar sin medir. Sin línea base no se puede demostrar el ahorro, y el programa pierde apoyo en el primer recorte de presupuesto.
• Dejar el toil sin límite. Si el equipo absorbe toda la operación nueva sin techo, la ingeniería desaparece y el modelo vuelve a ser administración con otro nombre.
• Descuidar a quienes sostienen la operación actual. La transición necesita su conocimiento; un plan que los deja fuera pierde el activo principal.

Antes de comprometer cambios en los procesos de cambios o incidentes que revisan los auditores, valídalos con Riesgo y Cumplimiento: el objetivo es cambiar la ejecución sin debilitar el control.