La historia de SRE (Site Reliability Engineering)
Este texto retoma gran parte de las ideas de Site Reliability Engineering, The Site Reliability Workbook y Seeking SRE (libros de Google y la comunidad SRE).
Continuando con la historia de DevOps, toca hablar de SRE.
Una vez que entiendes DevOps es más fácil explicar SRE, pues SRE también es una cultura. SRE significa “Site Reliability Engineering”, que sería algo así como Ingeniería en Sistema de Alta Disponibilidad. Fue un nacimiento orgánico que se dio en Google por un detalle muy particular en sus necesidades. Tenían tanto tráfico y transacciones que caerse tan solo unos segundos podría significar una pérdida considerable en el negocio.
Piénsalo de esta manera. Si vendes 1, 10, 100, 1000, 100000, por minuto. ¿Cuánto te pesaría cerrar tu negocio un día? Pero a la vez tienes los mismos problemas con el desarrollo de más verticales en tu negocio. Por un lado tienes la urgencia de generar código para nuevas funcionalidades y por otro lado tienes los sistemas en producción que deben de estar disponibles para los usuarios. Es un dilema interesante que si no se resuelve de forma correcta puede traer grandes problemas.
Es encontrar el punto medio entre la velocidad de los desarrolladores y la estabilidad de los sistemas. En mi experiencia, SRE necesita hacer DevOps pero añadiendo algunas capas adicionales. El diablo está en los detalles y SRE anda detrás del diablo.
Cuando unos segundos importan
En Google el problema no era teórico. Con suficiente escala, «casi siempre disponible» deja de ser un slogan de marketing y se vuelve una restricción de negocio. Un despliegue mal hecho no solo molesta al equipo: corta ingresos, daña reputación y obliga a personas reales a quedarse madrugada tras madrugada recuperando lo que el cambio rompió.
No nació como un título de LinkedIn ni como un checklist de herramientas. Nació porque alguien tuvo que responder, con números y con guardias, a una pregunta incómoda: ¿cuánta inestabilidad estamos dispuestos a tolerar a cambio de seguir cambiando?
Esa pregunta es política y técnica a la vez. Política, porque el negocio tiene que aceptar que la confiabilidad cuesta (tiempo, foco, a veces features que esperan). Técnica, porque sin medición esa política se convierte en gritos después del incidente.
Qué añade SRE a DevOps
DevOps alinea autoridad y responsabilidad: quien cambia también responde. Eso ya es mucho. SRE endurece esa idea con ingeniería aplicada a la operación.
Algunas piezas clave —sin convertir esto en un manual de métricas—:
- SLI / SLO. No basta con decir «el sistema está bien». Hay que definir qué se mide (latencia, tasa de error, disponibilidad) y qué nivel es aceptable para el negocio. Sin eso, cada incidente es una pelea de opiniones.
- Presupuesto de error (error budget). Si tu objetivo es 99.9 % de disponibilidad, te «sobra» un margen de fallo. Ese margen es el permiso explícito para cambiar. Cuando el presupuesto se agota, la prioridad deja de ser desplegar features y pasa a ser recuperar confiabilidad. Es una negociación con reglas, no una guerra moral entre «los que quieren innovar» y «los que no dejan hacer nada».
- Toil. Trabajo operativo manual, repetitivo, que no escala y no deja aprendizaje duradero. SRE trata el toil como deuda: si la guardia se consume apagando incendios de forma artesanal, algo está mal diseñado. La respuesta no es heroísmo; es automatizar y eliminar fricción.
- Ingeniería sobre ritual. Monitoreo, alertas que importan (y no las que gritan por todo), postmortems sin culpar personas, capacidad de rollback. Menos teatro de «seguimos el proceso» y más sistemas que fallan de manera contenida.
La filosofía de fondo es la misma que en DevOps —libertad a cambio de responsabilidad—, pero con un lenguaje compartido para decidir cuándo acelerar y cuándo frenar. Sin ese lenguaje, «moverse rápido» es solo una forma elegante de empujar el costo hacia el usuario.
Una perspectiva de lo que puede implicar ser SRE
Imagina que no eres «el de los servidores». Eres alguien que entiende el producto lo suficiente para saber qué duele cuando se cae… y entiende la ingeniería lo suficiente para no resolverlo con fe y tickets.
A veces tu trabajo es aburrido a propósito: revisar dashboards, endurecer un despliegue, pelearte con una alerta que llora por basura. A veces son las tres de la mañana y el servicio que factura está en modo «casi». Llamadas. War rooms. Hipótesis. Rollback. Café malo. La pregunta no es solo «¿cómo lo levantamos?», sino «¿por qué el sistema permitió que esto escalara así?»
Otras veces tu trabajo es decir que no. O, más preciso: decir aún no. Producto quiere sacar una funcionalidad. Desarrollo ya tiene el código. Marketing tiene la fecha. Tú miras el presupuesto de error, la tasa de incidentes de las últimas semanas, la deuda de observabilidad… y negocias. No como policía. Como alguien que protege la capacidad de seguir cambiando mañana.
También implica empatía. Si nunca has estado del lado que programa bajo presión, es fácil volverte el nuevo silo: el que bloquea por deporte. Si nunca has cargado con una guardia, es fácil creer que «ya lo desplegamos» es el final de la historia. Los mejores perfiles que he visto —otra vez— vienen de cruzar trincheras: desarrolladores que se interesaron por la operación, o operadores que aprendieron a construir con solidez.
Hay un detalle que mucha gente subestima: el postmortem. Bien hecho, no busca un culpable al que señalar con el dedo. Busca el mecanismo que permitió el fallo y la forma de que el mismo error sea más barato la próxima vez —o imposible. Mal hecho, es teatro: un documento que nadie lee y una promesa de «mejorar el proceso» que se olvida en el siguiente sprint.
SRE no es glamour. Es la disciplina de tratar la confiabilidad como un producto más: con dueños, con métricas, con deuda y con trade-offs explícitos.
Y como todo producto, compite por atención. Si la organización solo celebra el lanzamiento y nunca celebra el mes sin incidente serio, estás premiando la velocidad y castigando en silencio a quien sostiene el piso.
SRE en la era de la IA
Hoy construir se aceleró. Un modelo puede generar servicios, pruebas, manifiestos y scripts en una tarde. Eso no hace menos necesaria la confiabilidad. La hace más frágil si nadie asume el costo de operar.
Más código generado significa, en la práctica, más superficie de cambio. Más cambios significan más formas de romper dependencias, filtrar secretos, saturar una cola o dejar un endpoint abierto «porque el prompt lo sugirió». La IA no paga la guardia. No negocia el presupuesto de error con el negocio. No mira al usuario que dejó de confiar.
Si DevOps te dice que quien construye debe poder operar, la era de la IA te sube la apuesta: quien acepta un cambio generado también hereda su comportamiento en producción. Puedes delegar escritura. No puedes delegar juicio sobre qué merece desplegarse, con qué telemetría, con qué plan de retorno y con qué margen de fallo.
Por eso SRE importa ahora quizá más que cuando solo «los de infra» hablaban de nueve cincos. No porque todos deban titularse SRE. Sino porque la tensión velocidad–estabilidad ya no es un problema de un departamento: es el día a día de quien construye con herramientas que multiplican el cambio.
El valor no está en memorizar acrónimos. Está en internalizar la cultura: medir lo que importa, ponerle precio al riesgo, reducir toil, y alinear a desarrollo y operación alrededor de un objetivo compartido —un sistema que pueda cambiar sin dejar de merecer la confianza de quien lo usa.
¿En tu organización quién define cuánta inestabilidad están dispuestos a tolerar a cambio de seguir desplegando? ¿Existe un presupuesto de error… o solo heroísmo después del incidente?
Si aún no leíste el marco cultural detrás de esto, empieza por La historia de DevOps. Y si te interesa cómo se construyen equipos que cargan con responsabilidad de verdad, sigue con ¿Cómo conseguir talento para mi organización?.