La pregunta y cuándo aplica
Supón que una plataforma en crecimiento enfrenta problemas de disponibilidad, latencia, corrección, cumplimiento normativo y solicitudes de nuevas funciones al mismo tiempo. Explica cómo identificas los problemas de confiabilidad más importantes, estimas el impacto y el esfuerzo, ordenas el trabajo en la hoja de ruta y explicas los trade-offs.
Google SRE utiliza los presupuestos de error (error budgets) como un mecanismo compartido para la confiabilidad y el ritmo de lanzamientos. AWS Well-Architected recomienda clasificar las mejoras por importancia para el negocio y esfuerzo de implementación, y luego hacerles seguimiento de forma iterativa. La señal clave es traducir la confiabilidad en resultados para el usuario y el negocio.
Qué evalúan los entrevistadores
Los entrevistadores buscan un pensamiento centrado en los recorridos del usuario (user journeys), razonamiento sobre SLOs y presupuestos de error, trade-offs explícitos de riesgo y costo, hitos con responsables asignados, resultados medibles y un plan de aprendizaje cuando la evidencia es incompleta.
Preguntas para aclarar antes de responder
- ¿Cuáles son los recorridos del usuario y las promesas a los clientes más importantes?
- ¿Cuáles son los SLOs, el consumo del presupuesto de error (error-budget burn) y las principales clases de fallas?
- ¿El impacto se refleja en churn, ingresos, cumplimiento normativo, carga de soporte o trabajo operativo de ingeniería (toil)?
- ¿Qué esfuerzo, dependencias y costo de oportunidad tiene cada mejora?
- ¿Qué riesgos pueden mitigarse de inmediato y cuáles requieren una solución de raíz?
- ¿Quién es responsable de las decisiones de producto, ingeniería, finanzas y cumplimiento?
- ¿Cómo se verificará el éxito y en qué ventana de tiempo?
- ¿Existe una política que congele los lanzamientos cuando se agota el presupuesto?
Estructura para una respuesta de 30 segundos
“Defino SLOs en torno a los recorridos críticos del usuario y mapeo incidentes, latencia, errores de datos y cumplimiento con el impacto en el negocio. Clasifico el trabajo usando el consumo del presupuesto de error, impacto, severidad, esfuerzo, reversibilidad y valor de aprendizaje. Aplico mitigaciones rápidas de alto impacto mientras programo soluciones de raíz con hitos claros. Si el presupuesto se agota, pauso los lanzamientos no esenciales. Cada elemento tiene un responsable, una métrica objetivo y una fecha de revisión, y explico con claridad qué cosas no estamos haciendo”.
Respuesta detallada paso a paso
Paso 1: Definir las consecuencias para el usuario y el negocio
Comienza con recorridos como inicio de sesión, pago, publicación o exportación. Separa disponibilidad, latencia, corrección y privacidad; no trates todas las alertas internas por igual.
Paso 2: Establecer una línea base
Confirma SLOs, consumo del presupuesto, frecuencia de incidentes, usuarios afectados, tiempo de recuperación y demanda de soporte. Las métricas deben conectarse con una experiencia o una promesa.
Paso 3: Dividir las soluciones por horizonte temporal
Clasifica el trabajo como contención inmediata, mitigación, solución de raíz o monitoreo. Un límite de tasa (rate limit) puede coexistir con un rediseño del modelo de datos cuando ambos están vinculados en la hoja de ruta.
Paso 4: Comparar impacto, costo y aprendizaje
AWS recomienda considerar la importancia y el esfuerzo, y hacer seguimiento del progreso mediante hitos. Incluye explícitamente el costo de oportunidad.
| Dimensión | Pregunta | Evidencia de ejemplo |
|---|---|---|
| Impacto en el cliente | ¿Quién se ve afectado y con qué severidad? | Tasa de fallas en recorridos críticos |
| Riesgo | ¿Seguridad, cumplimiento o daño irreversible? | Registros de incidentes y auditorías |
| Esfuerzo | ¿Costo de ingeniería, dependencias y mantenimiento? | Semanas-persona e hitos |
| Velocidad | ¿Es posible una mitigación reversible? | Prueba de degradación o limitación de tráfico (throttling) |
| Aprendizaje | ¿Qué prueba pequeña reduce la incertidumbre? | Observación por etapas |
Paso 5: Utilizar el presupuesto de error para decisiones de lanzamiento
Mientras el servicio esté dentro del presupuesto, continúa con entregas de valor y programa trabajo de confiabilidad. Cuando el presupuesto se agote, pausa los cambios no esenciales y restablece el SLO. La seguridad y el cumplimiento siguen siendo restricciones estrictas.
Paso 6: Alinear la hoja de ruta y los recursos
Asigna responsables, objetivos, dependencias y condiciones de finalización. Planifica el trabajo de confiabilidad con la misma cadencia que las nuevas funciones e indica qué se pospone intencionalmente.
Paso 7: Verificar y ajustar
Haz seguimiento de los SLOs, el presupuesto, el tiempo de recuperación, el volumen de soporte, la retención y los costos. Si una mejora no reduce el impacto en el usuario, revisa la hipótesis en lugar de continuar por el sesgo del costo hundido.
Paso 8: Explicar el trade-off
Utiliza un registro de decisión breve con la elección, la evidencia, el riesgo, las alternativas y la fecha de revisión. Explica qué resultado para el cliente y qué promesa de negocio protege la inversión.
Ejemplo de respuesta de alta calidad
“Dividiría la plataforma en inicio de sesión, transacciones principales y generación de reportes; luego definiría SLOs y presupuestos de error para cada uno. Clasificaría el trabajo según el consumo del presupuesto, el impacto en clientes críticos, el riesgo de cumplimiento, el esfuerzo y la reversibilidad.
Si los errores en transacciones consumieran el presupuesto durante dos semanas, primero implementaría limitación de tráfico (throttling) y degradación elegante, y luego programaría la solución de raíz. La latencia en reportes que afecta a usuarios infrecuentes podría recibir instrumentación y un hito con fecha definida. Con ingeniería asignaría responsables y dependencias, congelaría los lanzamientos no esenciales mientras el presupuesto estuviera agotado y explicaría el impacto en el cliente a Ventas.
Cada dos semanas revisaría los SLOs, el tiempo de recuperación y la demanda de soporte. Si la mitigación eliminara el impacto, reevaluaría el proyecto de raíz; si no, detendría ese enfoque y probaría otro camino. Esto mantiene la confiabilidad alineada con los resultados y el costo de oportunidad”.
Errores comunes
- Clasificar alertas por severidad técnica sin considerar el impacto en el cliente.
- Afirmar que la confiabilidad importa sin definir SLOs ni presupuestos de error.
- Elegir únicamente un rediseño permanente e ignorar el aprendizaje reversible.
- Tratar el presupuesto de error como un permiso para ignorar la seguridad o el cumplimiento normativo.
- Omitir responsables, hitos y fechas de revisión.
- Reportar latencia y disponibilidad sin vincularlas a resultados para los clientes.
- Discutir únicamente las preferencias de ingeniería.
Preguntas de seguimiento y cómo responderlas
Pregunta de seguimiento 1: ¿Qué pasa si el negocio insiste en lanzar una función?
Cuantifica el presupuesto, el impacto en el cliente y las alternativas. Si la política exige un congelamiento, expón la regla y permite que el responsable autorizado decida sobre el riesgo residual.
Pregunta de seguimiento 2: ¿Qué pasa si faltan datos?
Instrumenta de forma económica, clasifica las fallas o ejecuta un experimento pequeño con un objetivo de aprendizaje y una condición de parada, en lugar de inventar una precisión inexistente.
Pregunta de seguimiento 3: La confiabilidad no tiene una línea de meta definitiva. ¿Qué se hace entonces?
Utiliza los SLOs y el presupuesto para definir un límite aceptable, compara el beneficio marginal con el costo de oportunidad y revisa si aún se alinea con las promesas establecidas.
Pregunta de seguimiento 4: ¿Qué pasa si una mitigación genera deuda técnica?
Registra la deuda, el responsable y su fecha de expiración; vincúlala a un hito de solución de raíz y escala el problema cuando la fecha se cumpla.
Pregunta de seguimiento 5: ¿Cómo demuestras el valor generado?
Compara el antes y el después en SLOs, recuperación, soporte, impacto en el cliente, retención o costos en una ventana de tiempo definida y declara los márgenes de incertidumbre.
Pregunta de seguimiento 6: ¿Qué pasa si los requisitos de los clientes difieren entre sí?
Segmenta por recorridos y promesas contractuales, aísla la capacidad cuando sea necesario y evita transferir un riesgo inaceptable a clientes de menor prioridad.