Preguntas de entrevista para Ingeniero SRE (Site Reliability Engineer)

Respuesta modelo

Para mí la diferencia está en qué se optimiza. Un Ingeniero DevOps optimiza el flujo de entrega: que el cambio salga de la rama y llegue a producción rápido, de forma repetible y sin sorpresas. Yo optimizo el comportamiento del sistema una vez que ese cambio ya está allí. Mi materia prima son los objetivos de nivel de servicio: elijo con producto un indicador que refleje lo que siente el cliente —disponibilidad medida en el balanceador, latencia p99 de la transferencia, frescura del saldo—, acordamos un umbral y una ventana, y de ahí sale un presupuesto de error que actúa como instrumento de gobierno. Cuando queda presupuesto, producto manda y se entrega funcionalidad; cuando se agota, mando yo y se para para arreglar. En mi último puesto esa política congeló las entregas dos veces en 2025, nueve y cinco días. Lo demás es consecuencia de ese marco: reducir el toil para tener tiempo de ingeniería, modelar la capacidad para no descubrir el límite en Black Friday, hacer experimentos de caos para encontrar el fallo antes que el cliente, y sostener unas guardias con alertas que merezcan la pena. Compartimos herramientas con DevOps casi al cien por cien, pero no compartimos la pregunta que respondemos ni el momento del ciclo en el que actuamos.

Respuesta modelo

Empecé por lo contrario de lo que suele esperarse: no miré métricas, hablé con negocio. Pregunté qué operación pierde dinero o confianza si falla y salió la transferencia inmediata. A partir de ahí definí el recorrido crítico del usuario y elegí dos indicadores: proporción de peticiones correctas medidas en el balanceador, no en la instancia, y latencia p99 de la operación completa de extremo a extremo. Luego medí cuatro semanas sin comprometer nada, para tener línea base real: estábamos en un 99,82 % con un p99 de 1,9 segundos. Propuse un objetivo alcanzable y no aspiracional, un 99,9 % con p99 por debajo de 1,2 segundos sobre ventana móvil de 28 días, y lo negocié con el responsable de producto explicando la contrapartida: ese 0,1 % son 43 minutos de presupuesto al mes y, si se consumen, se paran las funcionalidades nuevas. Firmamos también las exclusiones: ventanas de mantenimiento pactadas y errores atribuibles al cliente. Después vino la parte técnica —reglas de registro en Prometheus, generación con Sloth y alertado multiventana por burn rate— y una revisión trimestral con los datos delante. Subimos el objetivo al 99,95 % nueve meses más tarde, cuando ya lo cumplíamos con margen.

Respuesta modelo

Lo primero es que no sea una sorpresa. La política estaba escrita y aprobada por el comité de tecnología antes de necesitarla, con tres tramos: por encima del 50 % restante, ritmo normal; por debajo del 20 %, se congelan las funcionalidades nuevas y solo entran correcciones y trabajo de fiabilidad; agotado, se convoca una revisión con el responsable de producto y con dirección técnica. Escribirlo en frío, cuando nadie está enfadado, es la mitad del trabajo. Cuando se agotó en marzo de 2025, activé la congelación el mismo día, expliqué en una página por qué se había consumido —dos incidencias de base de datos y un despliegue que degradó la latencia sin llegar a caerse— y presenté una lista corta de trabajo de fiabilidad con estimación. Duró nueve días. Salimos con la conmutación por error de la réplica automatizada y con un canario que compara latencia antes de completar el despliegue. Lo importante es que la congelación no es un castigo ni una demostración de poder: es la forma de convertir una discusión de opiniones sobre si hay que invertir en fiabilidad en una decisión ya pactada. Y funciona en los dos sentidos: cuando sobra presupuesto, yo soy el primero en decir que se puede desplegar más rápido y asumir más riesgo.

Respuesta modelo

Lo medí porque sin número no hay conversación posible. Durante dos trimestres etiquetamos cada ticket de operación con cuatro criterios: si era manual, repetitivo, automatizable y si crecía linealmente con el negocio. Salió que el 58 % del tiempo del equipo era toil, y el dato incomodó lo suficiente como para que produjera efecto. Ordené la lista por horas al mes, no por dificultad técnica, y ataqué las tres primeras: rotación de credenciales, alta de tenants y recuperación de réplicas de PostgreSQL. Las dos primeras se resolvieron con automatización sencilla y la tercera exigió escribir un operador de Kubernetes en Go. Cerramos el año en el 21 %, por debajo del techo del 40 % que habíamos pactado con producto en el acuerdo de servicio interno. El techo es lo verdaderamente importante: si no se fija por escrito qué porcentaje máximo de nuestro tiempo puede ser operación, la operación se lo come todo, porque siempre es más urgente que la mejora. Ese 40 % es lo que garantiza que quede tiempo de ingeniería para que el año siguiente haya menos toil que este.

Respuesta modelo

La peor fue una degradación progresiva del canal móvil un lunes por la mañana, con el 40 % de los inicios de sesión fallando de forma intermitente durante 52 minutos. Asumí el mando de incidencia y lo primero que hice fue repartir roles: una persona a operación, otra a comunicación con negocio y atención al cliente, y una tercera anotando la cronología. Prioricé mitigar por encima de entender: desviamos el tráfico a la región secundaria en catorce minutos y solo entonces buscamos la causa. Resultó ser un cambio de configuración del pool de conexiones que interactuaba con un reintento sin jitter en el cliente móvil, y entre los dos generaban una tormenta de reintentos que saturaba la caché de sesiones. En el post-mortem, que hicimos sin culpables, quedó claro que la persona que hizo el cambio siguió el procedimiento correcto y que el fallo estaba en el sistema: no había límite de reintentos por cliente, ni prueba de carga con el nuevo tamaño de pool, ni alerta sobre saturación de la caché. Salieron nueve acciones, todas con responsable y fecha. La que más valor tuvo fue la menos vistosa: el presupuesto de reintentos con jitter en la biblioteca cliente, que replicamos en 34 servicios. Ese modo de fallo no ha vuelto a aparecer.

Respuesta modelo

Con tres insumos. El primero es la demanda del negocio, y esa no la tengo yo: la tienen marketing y producto. Me siento con ellos y saco el calendario real —rebajas de enero, Black Friday, campaña de Navidad, picos de nómina a final de mes, la campaña de la Renta si hay integración con la Administración— y el crecimiento previsto. El segundo es la curva de saturación de cada servicio, que obtengo con pruebas de carga en k6 hasta encontrar el punto en el que la latencia se dispara; ese punto, y no el uso de CPU, es mi límite real, porque un servicio puede estar al 40 % de CPU y ya haber saturado su pool de conexiones a base de datos. El tercero es el margen que decido dejar, que en servicios críticos es N+2 por zona de disponibilidad, de forma que aguante la pérdida de una zona completa durante un pico. Con eso construyo una previsión trimestral que reviso con negocio y que se traduce en límites de autoescalado, en cuotas y en presupuesto de infraestructura. Y verifico que el modelo no miente: en Black Friday de 2025 absorbimos 5,2 veces el tráfico medio sin ninguna incidencia con impacto en cliente, que es la única forma de saber que el número era bueno.

Respuesta modelo

Empiezo midiendo, porque el equipo va a decirme que hay demasiadas alertas y necesito saber cuántas y cuáles. Saco del sistema de avisos cuatro números por regla durante tres meses: cuántas veces disparó, qué porcentaje acabó en una acción humana real, cuántas se resolvieron solas antes de que nadie tocara nada y cuántas llegaron fuera de horario. Con eso aparece siempre el mismo patrón: unas pocas reglas generan la mayoría del ruido y casi ninguna es accionable. Lo siguiente es un cambio de filosofía: eliminar las alertas por umbral sobre causas —CPU al 80 %, disco al 75 %— y sustituirlas por alertas sobre síntomas que afectan al cliente, que en la práctica significa alertar sobre el consumo del presupuesto de error con ventanas múltiples. Aviso urgente si se consume el 2 % en una hora, aviso urgente si se consume el 5 % en seis horas, y ticket si se consume el 10 % en tres días. Todo lo demás pasa a panel o a ticket, nunca a teléfono. Y aplico una regla sencilla: si una alerta no tiene runbook con una acción concreta, o se le escribe el runbook o se borra. En mi último equipo pasamos de 214 reglas a 38, de 6,4 avisos por turno a 1,3 y del 34 % al 91 % de alertas accionables. Los avisos nocturnos cayeron de 19 a 3 al mes. Conviene decir que esto es también un asunto de personas: mientras se limpia, hay que ampliar la rotación, porque una rotación de tres personas no se arregla con mejores alertas.

Sobre un mes de 30 días, que son 43.200 minutos: un 99,9 % deja 43 minutos y 12 segundos de indisponibilidad; un 99,95 % deja 21 minutos y 36 segundos; y un 99,99 % deja 4 minutos y 19 segundos. Si se trabaja con ventana móvil de 28 días, que es lo que yo prefiero porque encaja con las semanas de guardia, la base son 40.320 minutos y el 99,9 % se queda en 40 minutos y 19 segundos. Estos números conviene tenerlos en la cabeza porque cambian la conversación con negocio: cuando alguien pide cuatro nueves, lo que está pidiendo es que en todo el mes, sumando despliegues fallidos, incidencias de proveedor y mantenimientos no planificados, no se acumulen más de cuatro minutos de degradación. Con eso encima de la mesa la petición se vuelve mucho más razonable, porque ese objetivo obliga a multirregión activo-activo, a despliegues progresivos con reversión automática y a una guardia de respuesta inmediata, y todo eso tiene un coste que hay que decidir si compensa.

El burn rate es la velocidad a la que se consume el presupuesto de error en relación con la que lo agotaría justo al final de la ventana. Un burn rate de 1 significa que, de seguir así, el presupuesto se acaba exactamente el último día; un burn rate de 14,4 significa que en una hora se consume el 2 % del presupuesto mensual. La configuración habitual usa tres pares de ventanas: aviso urgente si el burn rate supera 14,4 sostenido durante una hora, aviso urgente si supera 6 durante seis horas, y ticket si supera 1 durante tres días. Cada regla lleva además una ventana corta de confirmación —cinco minutos, treinta minutos, seis horas— para que la alerta se apague sola cuando el problema cesa, en lugar de quedarse colgada. La ventaja sobre el umbral fijo es doble. Por un lado, la sensibilidad se ajusta sola a la gravedad: una caída total dispara en minutos y una degradación lenta dispara en horas, con la misma regla. Por otro, la alerta está atada a algo que le importa al cliente y no a una métrica intermedia, así que deja de sonar cuando la CPU sube sin consecuencias y suena cuando el usuario sufre aunque la infraestructura parezca sana.

Porque la media esconde exactamente lo que hace daño. Si el 95 % de las peticiones tarda 100 milisegundos y el 5 % tarda 10 segundos, la media sale por debajo del segundo y parece un servicio sano, mientras que uno de cada veinte usuarios está teniendo una experiencia inaceptable. Las distribuciones de latencia tienen cola larga y la media no las describe. Yo mido p50 para entender la experiencia típica, p95 y p99 para el objetivo, y miro p99,9 en el análisis aunque no lo comprometa. El percentil que elijo depende del recorrido: en una consulta de saldo, que se ejecuta millones de veces al día, comprometo p99; en un proceso de alta de cliente, con mucho menos volumen, p95 es suficiente y p99 sería ruido estadístico. Un matiz que suele pasarse por alto: los percentiles no se pueden promediar entre instancias ni entre intervalos, así que hay que calcularlos a partir de histogramas, con cuidado además de la resolución de los cubos, porque un histograma mal dimensionado da un p99 elegante y falso. Y conviene mirar siempre la latencia del recorrido completo del usuario, no la del servicio aislado, porque el cliente suma todos los saltos.

Sí, y es un problema de aritmética, no de esfuerzo. Si las tres dependencias son secuenciales y sus fallos son independientes, la disponibilidad máxima teórica de mi servicio es 0,999 elevado a tres, es decir, un 99,7 %. Estoy comprometiendo un 99,95 % sobre una base que no puede superar el 99,7 %, así que el objetivo es inalcanzable por definición y encima estoy suponiendo que mi propio código no falla nunca. Hay cuatro salidas y normalmente se combinan. La primera es negociar SLO más exigentes con los equipos de las dependencias, lo que traslada el coste hacia ellos. La segunda es dejar de depender en serie: hacer asíncrona alguna llamada, cachear la respuesta con una frescura aceptable o precalcular el dato. La tercera es degradar con elegancia, de modo que la caída de una dependencia no tumbe la operación entera sino que reduzca funcionalidad; si puedo servir el recorrido principal sin el servicio de recomendaciones, ese servicio deja de contar en la cadena crítica. La cuarta, y muchas veces la más honesta, es bajar mi propio objetivo a algo defendible y explicarle a producto por qué. Este cálculo lo hago siempre antes de firmar un SLO nuevo: es la comprobación más barata que existe y evita comprometer por escrito algo imposible.

Con cinco elementos, y si falta uno no lo ejecuto. Primero, el estado estable definido con métricas concretas: qué significa que el sistema está sano, expresado en las mismas señales del SLO. Segundo, una hipótesis falsable escrita antes de tocar nada, del tipo «si se pierde una zona de disponibilidad, la tasa de error se mantiene por debajo del 0,1 % y el p99 no supera 1,5 segundos». Tercero, un radio de impacto acotado: empiezo en preproducción, luego paso a producción con un 1 % del tráfico o con un solo cliente interno, y solo amplío cuando la hipótesis se ha confirmado. Cuarto, un criterio de aborto automático conectado al presupuesto de error, con un botón de parada que cualquiera del equipo pueda pulsar. Y quinto, contexto humano: en horario laboral, con el equipo delante, avisando a atención al cliente y nunca durante una congelación por presupuesto agotado ni en vísperas de un pico estacional. Con ese armazón he ejecutado 22 experimentos usando AWS Fault Injection Service y LitmusChaos, e hicimos aflorar tres fallos en cascada por reintentos sin jitter y un tiempo de espera mal propagado, todos antes de que los descubriera un cliente. El valor real no está en romper cosas: está en que cada experimento obliga a escribir la hipótesis, y escribirla ya revela cuánto se desconoce del propio sistema.

MTTD es el tiempo medio hasta detectar, desde que el sistema empieza a fallar hasta que alguien o algo se entera. MTTA es el tiempo hasta que una persona acusa recibo del aviso. MTTM es el tiempo hasta mitigar, es decir, hasta que el cliente deja de sufrir, aunque la causa siga ahí. Y MTTR se usa con dos sentidos distintos —restaurar o reparar—, así que en una entrevista conviene precisar cuál se está midiendo, porque restaurar el servicio y reparar la causa raíz pueden separarse por semanas. Yo empezaría siempre por el MTTD, y por una razón práctica: el tiempo de detección se suma íntegro a todos los demás y suele ser el más barato de reducir, porque es puramente cuestión de instrumentación y de alertar sobre síntomas en lugar de sobre causas. En mi último equipo bajó de 14 a 4 minutos solo con reglas de burn rate. Después iría al MTTM, porque mitigar es lo único que le importa al cliente: tener runbooks con acciones de mitigación conocidas —desviar tráfico, revertir, activar el modo degradado— vale más que diagnosticar rápido. El MTTA se arregla con el proceso de guardia y con menos ruido: si el equipo recibe seis avisos por turno, deja de responder con urgencia, y ese número no se arregla con formación sino quitando alertas.

Cambiando el tipo de indicador. Para servicios síncronos uso disponibilidad y latencia, pero para procesamiento asíncrono los que sirven son otros tres. Frescura: qué antigüedad tiene el dato más reciente que ve el usuario, por ejemplo que el 99 % de las operaciones aparezca en el extracto en menos de dos minutos. Cobertura: qué proporción de los elementos que debían procesarse en la ventana se han procesado realmente, que es el indicador clave en un lote nocturno de conciliación. Y corrección: qué proporción de los resultados es correcta, medida con una verificación independiente, algo imprescindible en procesos financieros donde un dato mal calculado hace más daño que un retraso. En una cola, el indicador que de verdad importa no es la profundidad sino la edad del mensaje más antiguo, porque una cola con un millón de mensajes que se drena en treinta segundos está sana y una con doscientos mensajes atascados desde hace una hora no lo está. Y en un proceso por lotes con ventana crítica añado un indicador de plazo: qué proporción de ejecuciones termina antes de la hora comprometida, que es la traducción directa del compromiso con negocio.

El patrón es siempre el mismo: la dependencia no cae, se ralentiza; las peticiones se acumulan esperando; se agotan los hilos o las conexiones; y el servicio, que estaba sano, se convierte en el siguiente eslabón que falla. Introduzco seis cosas en este orden. Tiempos de espera explícitos y coherentes en toda la cadena, con propagación del presupuesto de tiempo, para que nadie espere más de lo que su llamante está dispuesto a esperar; una llamada sin tiempo de espera es una bomba de relojería. Presupuesto de reintentos en lugar de reintentos libres: como máximo un porcentaje pequeño del tráfico puede ser reintento, siempre con jitter y retroceso exponencial, porque los reintentos sincronizados convierten una degradación en una tormenta. Cortacircuitos que abren cuando la tasa de error de la dependencia supera un umbral y dejan de castigar a un servicio que ya está sufriendo. Limitación de carga con rechazo temprano y prioridades: si no puedo con todo, prefiero servir bien al 80 % que servir mal al 100 %, y el tráfico de negocio crítico pasa por delante del secundario. Mamparos que aíslen recursos por dependencia, de modo que agotar el pool de un servicio no bloquee los demás. Y degradación controlada: una respuesta parcial o cacheada es mucho mejor que un error. Después de introducirlo, lo verifico con un experimento de caos que inyecte latencia, porque estos mecanismos suelen estar mal configurados hasta que alguien los prueba de verdad.

Casi siempre es un problema de cardinalidad, no de volumen de peticiones. Lo primero es medir: identificar las métricas con más series activas y ver qué etiqueta las está multiplicando. El culpable habitual es una etiqueta de cardinalidad no acotada —identificador de usuario, de petición, de sesión, una URL con parámetros o un mensaje de error completo— que crea una serie temporal nueva por cada valor. La solución inmediata es eliminar o agrupar esa etiqueta en el reetiquetado de la recogida, y establecer un límite de series por objetivo para que un servicio mal instrumentado no tumbe la plataforma de observabilidad entera. Lo siguiente son reglas de registro para las consultas caras que alimentan paneles y alertas: precalcular las agregaciones evita recorrer millones de series cada vez que alguien abre un panel. Después revisaría la retención local, que debería ser corta, delegando el largo plazo en Thanos o Mimir con submuestreo, y separaría las instancias por dominio funcional en lugar de mantener una única gigante. Y sobre todo pondría una norma de gobierno: la instrumentación tiene coste y se revisa como se revisa el código, porque una etiqueta añadida sin pensar puede multiplicar por mil la factura. Que la plataforma de observabilidad sea el servicio menos fiable de la casa es una ironía cara: cuando hay incidencia grave es justo lo que no puede fallar.

No convierto esto en un pulso, porque perdería aunque tuviera razón. Empiezo por lo que sí es innegociable: la política estaba escrita y aprobada antes, así que la conversación no es sobre si me hacen caso, sino sobre cómo aplicamos algo que ya acordamos entre todos. Le presento tres datos: cuánto presupuesto queda, qué lo ha consumido y qué trabajo de fiabilidad concreto haría falta para recuperarlo, con estimación en días. A partir de ahí busco la salida que no existe en la versión simplista del asunto. Suele haberla: desplegar la funcionalidad detrás de un interruptor de activación y sin exponerla a tráfico, entregarla a ese cliente concreto en un anillo aislado con seguimiento reforzado, o entregar una versión reducida que no toque el recorrido crítico donde se está consumiendo el presupuesto. Si aun así hace falta saltarse la política, no me niego: la excepción se documenta, la aprueba quien tiene la responsabilidad de negocio —normalmente dirección técnica junto con producto— y se acompaña de un compromiso de trabajo de fiabilidad en el sprint siguiente. Lo que no acepto es la excepción silenciosa, porque a la tercera vez la política deja de existir. Mi papel no es impedir que se entregue, es hacer que el riesgo sea explícito y que lo asuma quien puede asumirlo.

Acuso recibo del aviso y abro incidencia con severidad alta antes de investigar nada, porque el reloj regulatorio empieza a contar desde la detección y en banca eso importa. Asumo el mando de incidencia y, si la cosa pinta larga, despierto a una segunda persona para separar roles: yo coordino, otra opera y alguien anota la cronología. Miro tres cosas en el primer minuto: qué ha cambiado en las últimas horas, si el patrón afecta a todas las regiones o a una, y si alguna dependencia está degradada. Mi prioridad es mitigar, no entender: si hubo un despliegue reciente, revierto; si es una zona, desvío tráfico; si es una dependencia externa, activo el modo degradado. Entender puede esperar a mañana, el cliente no. En paralelo abro comunicación con negocio y con atención al cliente cada quince minutos aunque no haya novedades, porque el silencio genera más llamadas que las malas noticias. Como es una entidad sujeta a DORA, en cuanto tengo una estimación de impacto en clientes y en operaciones evalúo con el responsable de cumplimiento si la incidencia se clasifica como grave, porque en ese caso hay que notificar al supervisor dentro de los plazos tasados del reglamento y luego enviar informe intermedio y final. Ese trámite no lo improviso a las cuatro de la mañana: está en el runbook, con los teléfonos y la plantilla. Cuando el servicio está restablecido, cierro la incidencia, duermo, y convoco el post-mortem sin culpables dentro de las 48 horas siguientes.

Trato esto como un problema de personas con síntomas técnicos, y en ese orden. Las dos primeras semanas mido y escucho: saco el histórico de avisos por regla, por franja horaria y por persona, y hablo con los tres uno a uno. Con ese dato voy a dirección con un mensaje muy claro: una rotación de tres personas no es sostenible ni legalmente cómoda, y el riesgo real es que se vaya alguien y nos quedemos con dos. Pido dos medidas inmediatas que no dependen de contratar: ampliar la rotación con personas de los equipos de producto que escriben esos servicios, aunque al principio solo cubran horario laboral, y silenciar de golpe todas las alertas que en tres meses no hayan derivado en una acción humana, que suelen ser más de la mitad. Eso da aire en dos semanas. Del día 15 al 60 hago el trabajo de fondo: reescribo el catálogo alertando sobre síntomas y presupuesto de error en lugar de sobre CPU y disco, escribo runbook para cada alerta que sobrevive y borro las que no lo tienen, y ataco por horas al mes las tres causas que más avisos generan. Del día 60 al 90 consolido: traspaso de turno formal, revisión semanal de la carga de guardia como métrica de equipo con objetivo explícito de menos de dos avisos por turno, y revisión con recursos humanos del plus de disponibilidad y del descanso compensatorio, porque si el modelo cambia hay que actualizar lo que se cobra por él. Y un compromiso que anuncio el primer día: yo entro en la rotación desde la primera semana. Sin eso, nada de lo anterior tiene credibilidad.

Doy el nombre del sistema, no el de la persona. Y lo argumento, porque no es una cuestión de compañerismo sino de eficacia. Si respondemos con un nombre, obtenemos una consecuencia inmediata y un problema que se repetirá, porque lo que hemos aprendido es que una persona se equivocó, cosa que ya sabíamos que puede pasar. Si respondemos con el sistema, la conversación es otra: por qué existía un procedimiento manual que requería escribir un comando destructivo a mano, por qué el entorno de producción tenía el mismo aspecto que el de pruebas en la terminal, por qué no había confirmación ni doble validación para una operación irreversible, por qué las copias de seguridad no se habían verificado nunca con una restauración real, y por qué la documentación que la persona siguió estaba desactualizada. En el post-mortem que me tocó vivir, la persona hizo exactamente lo que decía el runbook; el error humano fue el último eslabón de una cadena de decisiones nuestras. A dirección le llevo esa cadena, con las acciones correctoras y sus responsables. Y añado un argumento que suele funcionar mejor que cualquier apelación a la cultura: si señalamos a las personas, la próxima vez tardaremos más en enterarnos de lo que ha pasado, porque nadie querrá contarlo. Un equipo que oculta información durante una incidencia es infinitamente más caro que un equipo que se equivoca y lo dice en el primer minuto.

Le respondo con números antes que con opiniones, y empiezo distinguiendo dos cosas que se confunden siempre: el SLA es el compromiso contractual con penalización y el SLO es nuestro objetivo interno, que debe ser más exigente que el SLA para que nos dé margen de reacción. Si firmamos un 99,99 % como SLA, internamente tenemos que apuntar más alto, y eso significa que en todo el mes no podemos acumular más de cuatro minutos y diecinueve segundos de degradación, sumando despliegues fallidos, incidencias de proveedores y mantenimientos. Después hago la cuenta de las dependencias: si el servicio depende de tres componentes internos con tres nueves cada uno, el máximo teórico es un 99,7 % y el compromiso es sencillamente imposible, así que la conversación se acaba ahí hasta que rediseñemos la arquitectura. Si el cálculo sí da margen, expongo lo que cuesta cada nueve adicional: multirregión activo-activo, despliegues progresivos con reversión automática, guardia con respuesta en minutos y ampliación de la rotación, verificación periódica de la recuperación. Es una curva de coste que se dispara al final. Y termino con una propuesta concreta en lugar de con una negativa: comprometer un 99,9 % con penalizaciones asumibles y créditos de servicio, medir seis meses y subir el compromiso cuando tengamos datos que demuestren que lo cumplimos con margen. Un SLA que se incumple el segundo mes hace mucho más daño comercial que un SLA prudente que se cumple siempre.