Site Reliability Engineer

Un SLI es la medición real, algo como el porcentaje de solicitudes que responden correctamente en menos de 300 milisegundos. Un SLO es el objetivo interno que fijamos para ese SLI, digamos que el 99,9% de las solicitudes cumplen ese umbral en una ventana móvil de 30 días. Un SLA es diferente en naturaleza, no solo en grado: es un compromiso externo, a menudo contractual, con un cliente, normalmente con consecuencias económicas o de reputación si no se cumple, y suele fijarse más laxo que el SLO interno para dar margen al equipo. Trato el SLO como la cifra que realmente guía las decisiones del día a día, y reservo la conversación sobre el SLA para lo que se comunica a clientes y al departamento legal, porque confundir ambos lleva a los equipos a sobreinvertir en una fiabilidad que nadie está pagando, o a infrainvertir y arriesgarse a incumplir un contrato real.

El error budget es simplemente 1 menos el SLO, expresado como una cantidad de fallo aceptable en una ventana de tiempo. Si nuestro SLO es del 99,9% en 30 días, el error budget es del 0,1%, lo que en un servicio de alto tráfico se traduce en un número concreto de minutos de caída o solicitudes fallidas que podemos permitirnos. Lo uso como herramienta de decisión, no solo como métrica de reporting: cuando el budget está saludable, el equipo tiene margen para avanzar más rápido y asumir más riesgo, incluyendo lanzamientos más arriesgados o cambios de infraestructura. Cuando el budget está cerca de agotarse, cambiamos el foco al trabajo de fiabilidad y ralentizamos o pausamos nuevas funcionalidades hasta que se recupere. El valor de este planteamiento es que convierte la pregunta de si es seguro lanzar de un debate subjetivo en una cifra compartida que ingeniería y producto pueden mirar juntos y aceptar.

Trato el error budget como el mecanismo que resuelve esta tensión en lugar de intentar solucionarla a base de reuniones de negociación. Mientras el budget esté saludable, producto e ingeniería pueden avanzar a máxima velocidad, porque los datos muestran que el servicio puede absorber ese nivel de riesgo. Cuando el budget empieza a agotarse, eso se convierte en una señal automática y acordada de antemano para priorizar el trabajo de fiabilidad: corregir las causas raíz de los incidentes recientes, reducir el toil, o reforzar una dependencia frágil, antes de añadir más riesgo funcional. También hago seguimiento del toil por separado, el tiempo dedicado a trabajo operativo manual y repetitivo, porque un toil alto erosiona la velocidad silenciosamente aunque el SLO se vea bien sobre el papel. Acertar con este equilibrio depende primero de fijar el SLO con honestidad: un SLO demasiado estricto agota a todo el equipo persiguiendo una fiabilidad que nadie necesita realmente, y uno demasiado laxo deja acumular problemas de fiabilidad reales sin que nadie se dé cuenta.

Uso herramientas de observabilidad con detección de anomalías para detectar patrones inusuales de latencia o tasa de error antes de que crucen un umbral de alerta, lo que da al equipo margen de tiempo ante problemas emergentes. Durante un incidente activo he usado resumen de logs asistido por IA para extraer rápidamente las líneas relevantes de un volumen enorme de ruido, lo que acelera los primeros diez minutos cuando todo el mundo intenta entender el alcance. Algunos de nuestros runbooks ahora tienen próximos pasos sugeridos por IA según la alerta que se disparó, aunque siempre trato eso como una hipótesis de partida, no como una instrucción a seguir a ciegas. Lo que sigue siendo completamente humano es el rol de incident commander y el análisis del post mortem: decidir qué pasó realmente, qué contribuyó, y qué cambios merece la pena hacer requiere un criterio sobre el contexto organizativo y las decisiones de compromiso que las herramientas no pueden ver.

Nuestra base de datos principal sufrió un problema de agotamiento del pool de conexiones que dejó el checkout caído durante unos 22 minutos en medio de un pico de tráfico promocional. Yo era el incident commander: mi primer movimiento fue declarar el incidente formalmente y traer a un especialista en bases de datos y a un ingeniero de backend en lugar de intentar depurarlo solo. Mitigamos primero, no buscamos la causa raíz primero: escalamos el límite del pool de conexiones y reiniciamos las instancias del servicio afectado, lo que restauró el checkout en unos ocho minutos, y luego pasamos el resto del incidente confirmando la estabilidad. Publiqué una actualización de estado cada diez minutos en nuestro canal de incidentes, incluso cuando no había nada nuevo, porque el silencio de cara a los interesados es peor que una actualización repetida de seguimos investigando. Una vez que el servicio estuvo estable, pasé la investigación de la causa raíz al especialista en bases de datos y cerré el incidente activo, porque mantener un incidente abierto más allá de la mitigación solo añade carga de proceso sin ayudar a los usuarios.

Tras un fallo en el pipeline de despliegue que causó un retraso de dos horas en un parche de seguridad crítico, dirigí el post mortem y establecí la regla básica desde el principio: vamos a nombrar los factores que contribuyeron en el sistema y el proceso, no a la persona que hizo clic en desplegar. Construimos la cronología juntos como grupo en lugar de que yo la presentara sola, lo que sacó a la luz un detalle que se me habría escapado: la alerta que debería haber detectado el fallo había sido silenciada tres semanas antes durante una sesión de depuración sin relación y nunca se había reactivado. Cada acción recibió un responsable nombrado y una fecha límite en la misma reunión, sin quedar como un seguimiento vago, y revisamos primero las acciones del post mortem anterior para confirmar que se habían completado de verdad. El post mortem funcionó porque nadie gastó energía en defenderse: el ingeniero que había silenciado la alerta compartió ese detalle por su cuenta en cuanto quedó claro que la sala buscaba causas, no un culpable.

Producto quería lanzar un rediseño importante del checkout dos semanas antes de nuestro periodo de mayor tráfico del año, y nuestro error budget para ese servicio ya había bajado a alrededor del 15% restante del mes tras unas semanas complicadas de incidentes. No me limité a decir que no. Llevé los datos del error budget a la reunión de planificación y lo planteé como una decisión de riesgo compartido: lanzar ahora, con una ruta de código sin probar, durante el pico de tráfico, con casi nada de budget, era un riesgo concreto y cuantificado, no una preocupación vaga. Propuse lanzar el rediseño a un pequeño porcentaje del tráfico de inmediato, vigilar el SLO durante una semana, y solo generalizarlo si se mantenía, en lugar de un lanzamiento completo justo antes del pico. Producto aceptó en cuanto el riesgo se planteó con cifras en lugar de precaución general, y el lanzamiento gradual detectó una fuga de memoria bajo carga que habría causado un incidente real durante el pico de tráfico si hubiéramos lanzado por completo según el calendario original.

Ancoro las métricas en torno a las cuatro golden signals: latencia, tráfico, tasa de error y saturación, porque juntas cubren la mayor parte de lo que indica si un servicio está sano sin ahogarte en ruido. Para un solo servicio esos datos vienen de las métricas, pero en cuanto hay una cadena de llamadas entre varios servicios, las métricas solas dejan de ser suficientes, y ahí es donde el tracing distribuido justifica su coste: una traza muestra exactamente qué salto de una solicitud añadió la latencia en lugar de solo decirte que el conjunto se ralentizó. Mantengo los logs estructurados, con campos consistentes como el ID de solicitud y el nombre del servicio, precisamente para que puedan correlacionarse con una traza durante un incidente en lugar de revisarse manualmente. Soy deliberado con el muestreo en servicios de alto volumen, porque capturar el 100% de las trazas se vuelve caro rápido y rara vez aporta más valor que una tasa de muestreo bien diseñada combinada con la captura completa de todo lo que produce un error.

Defino el toil como trabajo manual, repetitivo, táctico, que crece de forma lineal con el crecimiento del servicio en lugar de aportar valor de ingeniería duradero, cosas como reiniciar manualmente un job atascado o editar a mano una configuración para cada cliente nuevo que se incorpora. El primer paso es medirlo con honestidad: sigo cuánto tiempo de guardia va realmente al toil frente a la respuesta a incidentes genuina, porque los equipos subestiman esto de forma constante hasta que lo registran durante unas semanas. Todo lo que se repite más de un puñado de veces pasa una prueba clara: se puede automatizar con un esfuerzo de ingeniería razonable, y eliminarlo libera suficiente tiempo para justificar ese esfuerzo. He automatizado cosas como la renovación de certificados y la limpieza de recursos obsoletos de esta manera, lo que quitó toil real de la guardia de forma permanente en lugar de solo hacer cada instancia un poco más rápida. También protejo tiempo en la hoja de ruta específicamente para este trabajo, porque la reducción de toil siempre pierde frente a la presión de funcionalidades si no se planifica explícitamente.

Empiezo por la cifra de crecimiento real que espera producto, no un vago mucho más tráfico, y la convierto en un objetivo concreto de tasa de solicitudes. Miro patrones de crecimiento históricos de eventos pasados similares para comprobar si la proyección es realista, y luego hago pruebas de carga contra un entorno de staging configurado para parecerse lo máximo posible a producción, porque probar contra un entorno infradimensionado da una falsa confianza. Fijo un objetivo de margen, normalmente planificando bastante más que el pico proyectado, no justo lo necesario para alcanzarlo, porque el tráfico real tiene más picos de lo que sugiere cualquier proyección suavizada. Reviso específicamente los límites de autoscaling, porque un servicio puede tener capacidad teórica de sobra y aun así fallar si el número máximo de instancias del autoscaler o el límite de conexiones de una dependencia aguas abajo lo limita por debajo de lo necesario. El coste también forma parte de la conversación: presento un plan con el margen que recomiendo y su coste, para que la decisión de aceptar más riesgo a cambio de menor coste la tome explícitamente el negocio, no por defecto.