Qué resuelve SRE
Bienvenido a la Ingeniería de Confiabilidad de Sitios
La Ingeniería de Confiabilidad de Sitios (SRE) comenzó en Google en 2003. Ben Treynor Sloss tomó un pequeño equipo de operaciones y lo reconstruyó como si fueran ingenieros, no pagers humanos, quienes gestionaran la producción. El resultado se convirtió en el modelo estándar para operar grandes servicios de internet.
Los equipos de operaciones tradicionales mantenían los servicios en funcionamiento mediante trabajo manual: reiniciar este servidor, avisar a ese ingeniero, escribir un runbook, esperar que funcione. Ese modelo se rompe a escala. Un equipo de cincuenta operadores no puede reiniciar manualmente cinco mil servidores. Más allá de cierto tamaño, las operaciones manuales se convierten en un impuesto que consume cada hora productiva.
SRE invierte el modelo. En lugar de contratar más operadores cuando los sistemas crecen, SRE contrata ingenieros de software y les dice: escriban código que haga el trabajo operativo por ustedes. Su trabajo califica como ingeniería de software aplicada a problemas de operaciones. Su resultado: automatización, monitoreo y confiabilidad diseñada, no intervenciones manuales.
Tres ideas fundamentales impulsan la práctica de SRE:
- Objetivos de Nivel de Servicio (SLOs): metas numéricas de fiabilidad, acordadas con antelación
- Presupuestos de error: el inverso de un SLO, gastado en la toma de riesgos
- Eliminación de toil: cualquier trabajo operativo que escala linealmente con el tamaño del sistema debe desaparecer
Estas tres ideas se extienden a todas las prácticas de SRE: postmortems, rotaciones de guardia, planificación de capacidad, monitorización e ingeniería de releases.
Operaciones tradicionales versus SRE
Por qué las Operaciones tradicionales fallan a escala
Un equipo de operaciones típico crece de forma lineal con los sistemas que gestiona. Duplicar los servidores significa duplicar los operadores. Esto tiene sentido financiero en despliegues pequeños y carece de sentido a escala: no se puede contratar para salir de un problema cuadrático.
SRE limita el trabajo de operaciones al cincuenta por ciento del tiempo de un ingeniero. La otra mitad debe dedicarse a ingeniería: construir herramientas, automatizar procesos y eliminar el trabajo repetitivo que los llevó al cincuenta por ciento en primer lugar. Si el trabajo repetitivo supera el cincuenta por ciento durante demasiado tiempo, el equipo debe devolver trabajo a un equipo de desarrollo o contratar más SREs. La regla del cincuenta por ciento evita que un equipo SRE se convierta en un equipo de operaciones tradicional bajo presión sostenida.
Compare los modos de fallo:
- Operaciones tradicional: más incidentes generan más respuestas manuales, lo que deja menos tiempo para la prevención, lo que crea más incidentes. Un bucle de destrucción.
- SRE: más incidentes desencadenan postmortems, que revelan oportunidades de automatización, que reducen el tiempo de respuesta del siguiente incidente. Un bucle virtuoso, cuando funciona.
SLI, SLO, SLA
Tres Letras Que Mueven la Producción
La fiabilidad sin medición es teatro. SRE convierte la fiabilidad en un número, acordado de antemano, que todos pueden verificar.
Indicador de Nivel de Servicio (SLI): una medición del comportamiento del servicio. Ejemplos: latencia de solicitudes, tasa de errores, rendimiento, profundidad de cola. Un SLI es algo que puedes graficar.
Objetivo de Nivel de Servicio (SLO): un valor o rango objetivo para un SLI. Ejemplo: 'El 99.9% de las solicitudes HTTP tienen éxito en una ventana móvil de 28 días.' Un SLO es una promesa que haces a ti mismo y a tus usuarios sobre la calidad de servicio aceptable.
Acuerdo de Nivel de Servicio (SLA): un compromiso contractual, generalmente con penalizaciones financieras por incumplimiento. Ejemplo: 'Reembolsamos el 10% si la disponibilidad mensual cae por debajo del 99.9%.' Un SLA es una promesa respaldada por abogados.
Distinción crítica: tu SLA siempre debe ser más flexible que tu SLO. Si apuntas internamente al 99.9% y contratas externamente el 99.9%, no tienes margen. Los SRE suelen ejecutar SLOs con un nueve más estricto que el SLA: objetivo del 99.95%, contrato del 99.9%. El margen absorbe la inevitable semana mala.
Presupuestos de Error: El SLO Inverso
De los Objetivos de Confiabilidad a las Decisiones de Ingeniería
Un SLO establece un objetivo de confiabilidad. El presupuesto de error es lo que queda: la cantidad de fallos que puedes gastar antes de no cumplir el objetivo.
Si tu SLO promete un 99,9 % de éxito en 28 días, tu presupuesto de error es el 0,1 % de las solicitudes, o aproximadamente 40 minutos de caída total al mes. Ese presupuesto es tuyo para gastarlo como quieras: en lanzamientos planificados, en funciones experimentales, en ingeniería del caos o para tolerar una dependencia problemática.
Los presupuestos de error transforman el conflicto entre desarrollo y operaciones. Sin un presupuesto, cada interrupción genera una discusión sobre quién introdujo el cambio defectuoso y cómo evitar el siguiente. Con un presupuesto:
- Presupuesto disponible: lanza más rápido, asume más riesgos, ejecuta experimentos. El presupuesto lo paga.
- Presupuesto agotado: deja de lanzar nuevas funciones, congela cambios arriesgados, céntrate en el trabajo de confiabilidad hasta que el presupuesto se recupere.
Esto convierte la confiabilidad de un argumento emocional en un recurso medible. Los ingenieros pueden gastar el presupuesto de forma deliberada, como cualquier otro insumo de producción.
Definiendo Toil
Qué cuenta como Toil
No todas las tareas de operaciones califican como toil. SRE define el toil de forma precisa: trabajo que es manual, repetitivo, automatizable, táctico, carente de valor duradero y que escala linealmente a medida que crece el servicio.
Las seis propiedades deben cumplirse. Una migración de datos única es manual pero no repetitiva: eso no califica como toil. Un ingeniero senior que diseña una nueva arquitectura de servicio toma una decisión táctica pero añade valor duradero: eso no califica como toil.
Ejemplos que sí califican como toil:
- Reiniciar manualmente un servicio tras un fallo por fuga de memoria
- Pegar fragmentos de logs en un canal de chat durante la triaje de un incidente
- Rellenar un formulario de ticket para aprovisionar una nueva base de datos
- Ejecutar manualmente un informe trimestral de capacidad
- Aprobar solicitudes rutinarias de despliegue una por una
La regla del cincuenta por ciento limita el toil al cincuenta por ciento del tiempo de un SRE. Si supera el 50 %, el equipo debe devolver responsabilidad al equipo de producto o contratar más ingenieros, pero el objetivo sigue siendo claro: reducir el toil a cero reemplazándolo por sistemas automatizados que realicen el mismo trabajo sin intervención humana.
La automatización no solo ahorra tiempo. Elimina por completo una clase de errores humanos. Un script que aprovisiona una base de datos no olvida pasos después de un turno largo.
Razonamiento de la auditoría de toil
Tu equipo registra cómo se emplea su tiempo. El trimestre pasado el desglose fue: 30 % despliegues, 25 % respuesta a incidentes, 20 % trabajo de capacidad, 15 % ingeniería de funcionalidades, 10 % solicitudes puntuales de los equipos de producto.
Higiene de On-Call
Ingenieros, no pagers
El on-call conlleva un costo real. El sueño se interrumpe, los fines de semana se ven afectados y el estrés de problemas desconocidos se acumula. SRE trata el on-call como un recurso finito que debe mantenerse sostenible, no como una carga heroica que recae en quien más se preocupe.
Las rotaciones saludables de on-call siguen varios principios:
- Tiempo compensado: las horas de on-call se traducen en tiempo libre, pago adicional o un beneficio equivalente. El on-call sin compensación quema al equipo.
- Profundidad razonable de rotación: un equipo de seis personas con un primario y un secundario implica que cada ingeniero tome un turno cada tres semanas. Las rotaciones de dos personas destruyen carreras.
- Presupuesto de volumen de páginas: el libro de SRE de Google sugiere un máximo de dos eventos de paging por turno de doce horas. Por encima de ese límite, el equipo debe invertir tiempo de ingeniería en reducir el volumen de alertas, no solo en soportarlo.
- Solo alertas accionables: cada página debe requerir acción humana. Si una página se va a ignorar, automatizar o se activa repetidamente durante la operación normal, no debería existir. La fatiga de alertas es un defecto de fiabilidad.
- Traspasos follow-the-sun: los equipos distribuidos globalmente pasan los turnos en los límites de zona horaria para que nadie reciba páginas a las 3 AM a menos que el sistema realmente no pueda esperar hasta la mañana.
Postmortems sin Culpa
Cómo las interrupciones se convierten en mejoras
Cada incidente significativo recibe un postmortem: un análisis escrito de lo que ocurrió, por qué, qué lo solucionó y qué cambios evitan que se repita. El postmortem es el equivalente SRE del interés compuesto: cada uno añade fiabilidad permanente al sistema.
Sin culpa significa que el documento atribuye los fallos a sistemas y procesos, nunca a individuos. Si un ingeniero ejecutó el comando incorrecto, el postmortem pregunta: ¿por qué el sistema permitió ese comando? ¿Por qué ninguna salvaguarda lo detectó? ¿Qué cambio en el sistema, la documentación o las herramientas evitaría que el siguiente ingeniero cometa el mismo error?
La ausencia de culpa existe por una sola razón: las personas ocultan errores cuando temen el castigo. Los errores ocultos se convierten en el próximo incidente. El costo de una cultura sin culpa es barato en comparación con el costo de acumular defectos no revelados.
Los postmortems suelen cubrir:
- Resumen: descripción en un párrafo del incidente e impacto
- Cronología: reconstrucción minuto a minuto con marcas de tiempo
- Análisis de causa raíz: factores técnicos y de proceso que permitieron la falla
- Detección: cómo el equipo se enteró del incidente y cuánto tiempo tomó
- Resolución: las acciones tomadas para restaurar el servicio
- Lecciones aprendidas: qué funcionó y qué no
- Elementos de acción: tareas de ingeniería concretas, asignadas y con plazo definido
Los elementos de acción viven en un rastreador. Se priorizan como cualquier otro trabajo de ingeniería. Los postmortems sin elementos de acción se reducen a contar historias. El trabajo no cambia nada.
Las Cuatro Señales Doradas
Qué debe medir todo servicio
El libro de SRE de Google propone cuatro señales que todo servicio orientado al usuario debe exponer: latencia, tráfico, errores y saturación. Juntas describen la salud del servicio desde la perspectiva del usuario. Monitorear con menos señales deja puntos ciegos; monitorear con cientos de métricas entierra al equipo en fatiga de alertas.
Latencia: cuánto tiempo tardan las solicitudes. Realiza seguimiento de distribuciones, no de promedios. p50 (mediana) describe la experiencia típica. p99 describe al peor 1 % de los usuarios. El promedio solo oculta colas largas: un servicio con mediana de 50 ms y p99 de 5 000 ms parece bien en el promedio, pero arruina a uno de cada cien usuarios.
Tráfico: la demanda sobre el servicio. Para un servicio web, esto significa solicitudes por segundo. Para un servicio de streaming, conexiones simultáneas. Para un trabajo por lotes, elementos procesados por minuto. El tráfico se correlaciona con las decisiones de capacidad y revela anomalías en la carga de trabajo.
Errores: la tasa de solicitudes fallidas. Las fallas explícitas (HTTP 500), las fallas implícitas (HTTP 200 con datos corruptos) y las fallas de política (respuesta demasiado lenta para cumplir el SLO) cuentan todas. Distinguir entre ellas importa: un 200 con carga útil incorrecta suele perjudicar más a los usuarios que un 500 honesto.
Saturación: qué tan lleno funciona el sistema. Utilización de CPU, profundidad de cola, presión de memoria, ocupación del pool de conexiones. La saturación predice la latencia futura: un sistema al 95% de CPU tiene muy poco margen antes de que la latencia percibida por el usuario aumente.
La mayoría de las alertas de SRE se derivan de estas cuatro señales. La alerta basada en síntomas (alertar cuando los usuarios notarían el problema) supera a la alerta basada en causas (alertar cuando la CPU supera el 80%). Las cuatro señales doradas describen síntomas.
Rutas Profesionales en SRE
Dónde Pagan las Habilidades SRE
Las carreras en SRE divergen según qué parte de la disciplina disfruta más el ingeniero:
SRE de Infraestructura: construye las plataformas en las que ejecutan otros equipos. Kubernetes, service meshes, nube interna. Ingeniería de sistemas intensiva, teoría de sistemas distribuidos y diseño de plataformas. Paga extremadamente bien en grandes empresas porque el trabajo escala: un SRE de infraestructura da soporte a cientos de ingenieros de producto.
SRE Embebido: se empareja con un equipo de ingeniería de producto para mejorar la fiabilidad de un servicio específico. Mitad ingeniero, mitad coach. Las habilidades de comunicación y revisión de código importan tanto como la profundidad técnica. A menudo es el mejor camino para ingenieros que les gusta enseñar.
Herramientas de fiabilidad: construye la pila de observabilidad: monitorización, alertas, paneles, herramientas de postmortem, plataformas de gestión de incidentes. Trabajo intensivo de frontend e ingeniería de datos. El resultado lo utilizan todos los demás equipos.
Ingeniería de producción: el término de Facebook/Meta para SRE centrado en capacidad, despliegue y gestión de tráfico. Trabajo intensivo de redes y sistemas.
Certificaciones técnicas que vale la pena tener: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional y las certificaciones de la CNCF (Kubernetes Administrator, Kubernetes Application Developer) demuestran fluidez en cloud-native. Las certificaciones de la Linux Foundation indican profundidad en sistemas. Ninguna de estas sustituye el trabajo de portafolio, pero ayudan a superar los filtros de los reclutadores.
Resumen final
Lo que ya sabes
La ingeniería de fiabilidad de sitios surgió como la respuesta de Google a un problema de escalabilidad y se ha convertido en una disciplina que ahora se practica en toda la industria. Has cubierto:
- El cambio de las operaciones manuales a la fiabilidad diseñada
- SLIs, SLOs, SLAs y el concepto de presupuesto de errores (inverse-SLO)
- La definición de toil, la regla del 50 % y la reducción impulsada por la ingeniería
- Rotaciones de guardia sostenibles y la práctica de postmortems sin culpas
- Las cuatro señales doradas como punto de partida para el monitoreo de servicios
- Las trayectorias profesionales de SRE y las certificaciones que abren puertas
Dos ideas importan más que el resto. La fiabilidad es un número, acordado de antemano. Y el toil es un defecto, no una descripción de puesto. Lleva esas dos ideas contigo y el resto de SRE se deduce de forma natural.
Lectura recomendada: el libro de SRE de Google (gratuito en línea: sre.google/books/), el SRE Workbook para ejercicios prácticos, y los escritos de Charity Majors sobre observabilidad. La lección complementaria geometry-of profundiza en la estructura visual que subyace a la práctica de SRE: distribuciones de latencia, conos de presupuesto de errores, gráficos de dependencias y diseños de paneles.