¿Cómo defines un SLO, y en qué se diferencia de un SLA?

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.

¿Qué es un error budget, y cómo lo usas para tomar decisiones?

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.

¿Cómo abordas el equilibrio entre el trabajo de fiabilidad y la velocidad de las funcionalidades?

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.

¿Cómo usas la IA en tu trabajo de SRE?

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.

Cuéntame sobre un incidente importante que lideraste o en el que participaste resolviendo. Explícame cómo fue.

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.

Describe un post mortem sin buscar culpables que hayas dirigido o al que hayas contribuido. ¿Qué lo hizo efectivo?

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.

Cuéntame sobre una vez que tuviste que oponerte a lanzar una funcionalidad por riesgo de fiabilidad.

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.

¿Cómo decides qué medir: qué métricas, logs y trazas importan para un servicio?

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.

¿Cómo identificas y reduces el toil en tu trabajo diario?

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.

Explícame cómo abordarías la planificación de capacidad para un servicio que espera un gran aumento de tráfico.

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.

Site Reliability Engineer

Las entrevistas para Site Reliability Engineer evalúan tu capacidad para tratar la fiabilidad como un objetivo medible y negociado, no como una meta abstracta. Los entrevistadores buscan soltura con los SLO, los error budgets y la observabilidad, además de cómo gestionas la respuesta a incidentes y los post mortems sin buscar culpables. Esta guía cubre las preguntas más frecuentes y las respuestas que consiguen ofertas.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Prepárate más

Dominar la entrevista conductual (método STAR)Cómo prepararse para una entrevista técnica

Preguntas de entrevista habituales para Site Reliability Engineer

Preguntas conductuales para puestos de Site Reliability Engineer

Preguntas técnicas para candidatos a Site Reliability Engineer

Lo que buscan los reclutadores en las entrevistas para Site Reliability Engineer

Lo que los responsables de selección buscan realmente en los candidatos a Site Reliability Engineer:

Soltura con los SLI, los SLO y los error budgets como herramientas de decisión, no solo como vocabulario. Los buenos candidatos describen cómo esas cifras cambiaron realmente una decisión concreta.
Una separación clara entre mitigación y causa raíz durante los incidentes. Los candidatos que confunden ambas cosas suelen alargar las caídas sin necesidad.
Experiencia real en post mortems sin buscar culpables. Busca un detalle concreto, como alguien que reconoce un error sin que se lo pidan, como prueba de que la cultura es real y no solo declarada.
Un enfoque cuantificado del toil. Los candidatos que pueden decir cuánto tiempo cuesta realmente el toil al equipo han medido su propio trabajo, no solo se han quejado de él.
Soltura para negociar con producto usando datos en lugar de autoridad. Los SRE que solo saben decir que no terminan siendo evitados.

Preguntas que puedes hacer al entrevistador

→¿Cuál es el SLO actual del servicio principal, y con qué frecuencia consume el equipo realmente el error budget?
→¿Cómo está organizada la guardia, y cómo es la carga de incidentes habitual por rotación?
→¿Cómo se llevan a cabo los post mortems aquí, y qué pasa con las acciones después?
→¿Qué parte del tiempo del equipo se dedica al toil frente al trabajo de ingeniería nuevo?
→¿Cómo equilibra el equipo en la práctica el trabajo de fiabilidad con la presión de la hoja de ruta de producto?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis en tu primer puesto guardado.

Puestos relacionados

Ingeniero DevOps

Tech9 preguntas

Ingeniero de plataforma

Tech10 preguntas

Arquitecto cloud

Tech10 preguntas

Ingeniero de seguridad

Tech10 preguntas

Disponible en otros idiomas

English Français