— Guía de Ingeniería de Software

3.5

3.5 Escalabilidad, rendimiento y resiliencia

Visión general y motivación

La escalabilidad, el rendimiento y la resiliencia son tres propiedades distintas que a menudo se confunden entre sí. El rendimiento determina la rapidez de respuesta del sistema y la cantidad de trabajo que procesa por unidad de recurso. La escalabilidad mide cómo mantiene ese rendimiento a medida que la carga crece. La resiliencia define su capacidad para seguir funcionando, o degradarse con naturalidad, cuando algo falla. Un sistema puede ser rápido pero no escalable (brillante con poca carga, colapsado bajo una elevada) , escalable pero frágil (que soporta volúmenes importantes pero se derrumba ante la caída de un solo componente) , o resiliente pero lento. Una organización de gran escala necesita las tres, integradas desde el inicio, porque integrar cualquiera de ellas después del lanzamiento resulta costoso y sumamente disruptivo.

En los sistemas empresariales y del sector público, las consecuencias de descuidar estas propiedades son públicas y graves. Piense en una plataforma de prestaciones que se hunde el primer día de un nuevo programa, en un sistema de declaración de impuestos que expira en el plazo límite, o en una pasarela de pagos que cae en pleno horario punta de compras. Son esos los incidentes que ocupan los titulares, generan investigaciones y erosionan la confianza del público. Estos sistemas, además, se enfrentan a picos de carga muy pronunciados y a menudo ligados a fechas legales (plazos de declaración, ventanas de inscripción, fechas de pago) y a obligaciones estrictas de disponibilidad y recuperación. Hay que planificar la capacidad para los picos predecibles, degradar con naturalidad ante los imprevistos y recuperarse dentro de límites definidos de tiempo y pérdida de datos tras un desastre. Se trata de ingeniería con una dimensión de responsabilidad pública.

Este capítulo aborda el escalado horizontal frente al vertical, la ausencia de estado y la fragmentación como habilitadores de la escala, el balanceo de carga, el escalado automático y la planificación de capacidad, la ingeniería de rendimiento con presupuestos explícitos, los patrones de resiliencia y la ingeniería del caos, y la recuperación ante desastres en varias regiones enmarcada por el OTR, el OPR y la continuidad del negocio. El mensaje unificador es que estas propiedades son fruto de un diseño deliberado y una prueba continua, no de la esperanza.

Véase también: capítulo 3.3 (sistemas distribuidos), capítulo 9.1 (ingeniería de fiabilidad del sitio) y capítulo 9.2 (observabilidad y supervisión).

Principios clave

Diseñar para el escalado horizontal, no para el vertical. El escalado vertical tiene un techo y un punto único de fallo; el escalado horizontal es la vía para alcanzar una escala grande y resiliente.
La ausencia de estado es el habilitador del escalado horizontal. Si cualquier solicitud puede atenderse en cualquier instancia, la capacidad puede añadirse y retirarse con libertad.
No se mejora lo que no se mide. El trabajo de rendimiento se dirige con perfiles y pruebas de carga frente a presupuestos explícitos, nunca con suposiciones.
Todo falla; diseñe para ello. Parta de la premisa de que los componentes van a fallar y construya el sistema para que sobreviva a su fallo.
La degradación gradual supera al fallo total. Un sistema parcialmente funcional que descarta funciones no esenciales es mejor que una caída completa.
La capacidad se planifica; los picos se absorben. Prevea la carga predecible y use el escalado automático y el margen para lo imprevisto.
Los objetivos de recuperación son decisiones de negocio. El OTR y el OPR los elige el negocio en función del costo y luego se diseñan en consecuencia.
Pruébe la resiliencia de forma deliberada. No se puede afirmar que un sistema es resiliente hasta que se ha provocado su fallo a propósito.

Recomendaciones

Preferir el escalado horizontal y diseñar servicios sin estado

El escalado vertical (máquinas más potentes) es simple y, a veces, el primer paso adecuado, pero llega a un techo rígido, se vuelve desproporcionadamente caro en el extremo superior y deja un punto único de fallo. El escalado horizontal (más máquinas tras un balanceador de carga) alcanza una escala mucho mayor y mejora la disponibilidad, porque la pérdida de una instancia es sobrevivible. El requisito previo es la ausencia de estado. No almacene estado de sesión de cliente ni de solicitud en la instancia; transfíralo a un almacén compartido (base de datos, caché, token). Los servicios sin estado pueden añadirse, retirarse, reemplazarse y balancearse con libertad, lo que hace posible tanto el escalado automático como el despliegue en lotes escalonados. Cuando el estado debe particionarse, framente por una clave que distribuya la carga de forma uniforme y mantenga los datos relacionados en la misma partición.

Balancear, escalar automáticamente y planificar la capacidad

Coloque un balanceador de carga al frente de cada capa escalada para distribuir el tráfico y desviar a las instancias no saludables mediante comprobaciones de estado. Configure el escalado automático para que añada capacidad cuando un indicador adelantado (CPU, profundidad de la cola de solicitudes, latencia) supere un umbral y la retire cuando la carga disminuya. Ajuste la velocidad de escalado y los tiempos de espera para que ni se rezague ante un pico ni entre en oscilación. El escalado automático no sustituye la planificación de capacidad. Para los picos predecibles y críticos (plazos de declaración fiscal, períodos de inscripción, eventos de venta), prevea la carga, prepocione o precaliente la capacidad y realice pruebas de carga hasta esa meta con antelación. El escalado automático por sí solo no puede reaccionar de inmediato ante un cambio abrupto, y los arranques en frío añaden latencia precisamente cuando menos puede permitirse. Siempre mantenga un margen. Operar al 100 % no deja espacio para absorber picos ni fallos.

Ingenierizar el rendimiento frente a presupuestos explícitos

Establezca presupuestos de rendimiento (metas concretas como latencia p95 de la API inferior a 200 ms, interactividad de la página en menos de 2 segundos o un costo por transacción por debajo de un umbral) y aplíquelos en pruebas y supervisión para que las regresiones fallen en la línea de integración continua en lugar de llegar al usuario. Dirija la optimización con medición. Realice el perfilado para encontrar el cuello de botella real, que rara vez está donde se espera, y lleve a cabo pruebas de carga para descubrir dónde se rompe el sistema y cómo se comporta cerca de ese límite. Concéntrate en la ruta crítica y en la cola (p95/p99), porque a gran escala las latencias en la cola determinan la experiencia del usuario. Optimice primero el cuello de botella más grande, vuelva a medir y deténgase cuando se cumpla el presupuesto. Optimizar en exceso un código ya adecuado es un esfuerzo desperdiciado.

Incorporar patrones de resiliencia y validar con ingeniería del caos

Aplique los patrones de resiliencia propios de los sistemas distribuidos: tiempos de espera, reintentos acotados con retroceso exponencial, disyuntores (que fallan de inmediato cuando una dependencia no responde) y compartimentos (que aíslan los pools de recursos para que un fallo no agote el resto), junto con la degradación gradual (abandonar o simplificar funciones no esenciales bajo estrés: desactivar recomendaciones, servir contenido en caché, encolar trabajo no urgente) y la reducción de carga (rechazar o limitar las solicitudes excedentes para proteger el núcleo en lugar de colapsar por completo). Elimine los puntos únicos de fallo mediante la redundancia en cada capa. Luego valide la resiliencia con ingeniería del caos. Inyecte fallos deliberadamente (matar instancias, añadir latencia, cortar una dependencia, fallar una zona) en experimentos controlados, empezando en entornos de prueba y madurando hasta simulacros en producción, para demostrar que el sistema se comporta según lo diseñado. Una resiliencia que nunca se ha puesto a prueba es solo una hipótesis.

Planificar recuperación ante desastres multinacionales y continuidad del negocio

Defina los objetivos de recuperación de manera explícita: el OTR (Objetivo de Tiempo de Recuperación, cuánto tiempo puede permitirse fuera de servicio) y el OPR (Objetivo de Punto de Recuperación, cuántos datos se permite perder). Son decisiones de negocio con implicaciones directas de costo que determinan la arquitectura. Las opciones varían en costo y velocidad: respaldo y restauración (la más económica y la más lenta), luz piloto, reserva en caliente y multinacional activo-activo (la más costosa, con OTR y OPR próximos a cero). Elija el nivel que justifique la criticidad de cada sistema. No todo necesita configuración activo-activo. Replicar datos entre regiones conforme al OPR elegido, automatizar el conmutado y, ante todo, practicar el conmutado con regularidad. Una recuperación ante desastres no probada falla con fiabilidad cuando finalmente se necesita. Todo ello debe enmarcarse en un plan de continuidad del negocio que cubra personas, comunicaciones y alternativas manuales, no solo la tecnología.

Compromisos: ventajas e inconvenientes

Decisión	Ventajas	Inconvenientes
Escalado vertical	Simple, sin cambios de código, bajo esfuerzo inicial	Techo rígido, costoso en el extremo superior, punto único de fallo
Escalado horizontal	Escala prácticamente ilimitada, mejora la disponibilidad	Requiere servicios sin estado, balanceo de carga y más operaciones
Escalado automático	Ajusta el costo a la demanda, maneja carga variable	Reacciona con retraso; arranques en frío; puede oscilar si se malajusta
Multinacional activo-activo	OTR/OPR próximos a cero, sobrevive a la pérdida regional	Costo y complejidad máximos, coherencia de datos difícil
Respaldo y restauración	Más económica, más simple	OTR prolongado, mayor ventana de pérdida de datos

El compromiso central es el costo frente a la garantía. Cada incremento de margen de escalabilidad, rendimiento o capacidad de recuperación cuesta dinero y complejidad, y las retornos son no lineales. Pasar del 99,9 % al 99,99 % de disponibilidad, o de un OTR de una hora a unos segundos, puede multiplicar el gasto. La disciplina consiste en calibrar cada inversión a la criticidad real del sistema y a la tolerancia del negocio ante la interrupción y la pérdida de datos, en lugar de ingenierizar todo al nivel más alto por reflejo. Un sistema de pagos orientado al ciudadano justifica la redundancia activo-activo; una herramienta interna de informes no.

Preguntas para debatir con el equipo

En su último incidente serio, ¿cuál de las tres propiedades (rendimiento, escalabilidad, resiliencia) fue la que realmente falló, y corrigieron la que correspondía? El capítulo los distingue a propósito: un sistema puede ser rápido y, sin embargo, colapsar bajo carga; escalar y, aun así, derrumbarse cuando un componente cede; o sobrevivir a los fallos pero ser lento. Los equipos a menudo diagnostican mal, añadiendo capacidad a un problema de resiliencia o blindando un sistema que simplemente estaba subprovisionado para un pico. Revise los dos últimos incidentes graves y nombre qué propiedad se rompió y qué mejoró realmente la respuesta. La distinción cambia la solución: ausencia de estado y fragmentación para la escala, redundancia y disyuntores para la resiliencia, perfilado y presupuestos para el rendimiento. Acertar la categoría es la diferencia entre gastar en la cura y gastar en un síntoma.
¿Las regresiones de rendimiento hacen fallar su línea de integración continua, o llegan al usuario antes de que nadie lo note? Un presupuesto de rendimiento (latencia p95, tiempo de interactividad de la página, costo por transacción) solo protege al usuario si se aplica de forma automática, de modo que un cambio que lo exceda falle la compilación en lugar de desplegarse. En un equipo grande con muchos colaboradores, la latencia se filtra por un millar de pequeños compromisos y, sin una barrera, la cola se degrada lentamente hasta que un lanzamiento lo expone. Examine los presupuestos actuales y verifique si están integrados en la integración continua y la supervisión, y si apuntan a p95 y p99 en lugar de medias, porque la cola es lo que el usuario percibe a gran escala. Donde no exista un presupuesto, definirlo es el primer paso. La aplicación es lo que convierte una buena intención en una propiedad que sobrevive al crecimiento del equipo.
Bajo estrés, ¿qué se abandona primero, y ese orden lo diseñaron o lo descubrirán durante la interrupción? La degradación gradual y la reducción de carga implican que el sistema renuncia al trabajo no esencial para proteger el núcleo, pero solo si se ha decidido de antemano qué es esencial. En un servicio orientado al ciudadano, ese orden suele ser una decisión de política: presentar una declaración fiscal debe sobrevivir aunque los paneles de estado y las consultas históricas queden en blanco. Si nadie ha elegido, el sistema abandona lo primero que falla, que puede ser exactamente lo que los usuarios más necesitan. Liste las funciones por orden de prioridad y confirme que la arquitectura puede descartar las de menor jerarquía (respuestas en caché, recomendaciones desactivadas, trabajo no urgente en cola) sin arrastrar la ruta crítica. Luego, pruébelo bajo carga real, porque una degradación no probada es solo una esperanza.
Para su sistema más crítico, ¿cuáles son el OTR y el OPR, quién los fijó realmente y cuándo demostró por última vez que puede cumplirlos? El Objetivo de Tiempo de Recuperación (cuánto puede permitirse fuera de servicio) y el Objetivo de Punto de Recuperación (cuántos datos puede permitirse perder) son decisiones de negocio con implicaciones directas de costo, pero en un equipo grande suelen ser inventadas por quien escribió la guía operativa en lugar de ser asumidas por los responsables del servicio. La tensión opuesta es el costo frente a la garantía: reducir el OTR de una hora a unos segundos, o el OPR de minutos a cero, puede multiplicar la factura de infraestructura, por lo que el número adecuado es aquel que el negocio estará dispuesto a pagar, no el más impresionante. Presente los objetivos documentados, la fecha del último simulacro de conmutado real y el tiempo y la pérdida de datos que aquel simulacro produjo, porque un objetivo no probado es un deseo. En entornos empresariales y del sector público, estos números pueden fijarlos una ley, un contrato o un acuerdo de nivel de servicio; por ello, nombre quién los aprueba y si el último ensayo cumplió la obligación o la incumplió en silencio.
Para su mayor pico predecible, ¿confían en que el escalado automático reaccione en el momento justo, o han previsto la carga, prepocionado y probado hasta esa meta? El escalado automático reacciona con retraso y los arranques en frío añaden latencia precisamente cuando menos se puede permitir, de modo que un cambio abrupto conocido (un plazo de declaración, una ventana de inscripción, un evento de ventas) es justo el caso en que el escalado reactivo fracasa y la planificación deliberada de capacidad gana. La tensión es el costo: precalentar capacidad para un pico significa pagar por un margen que permanece inactivo la mayor parte del año, y la tentación es confiar en que el escalado automático lo cubra gratis. Presente las cifras del pico del año pasado, la previsión de este año con el crecimiento y los resultados de una prueba de carga ejecutada hasta un múltiplo de esa previsión, no hasta el tráfico medio actual. Para un servicio del sector público o empresarial que enfrenta un pico ligado a una fecha legal, añada la consecuencia de equivocarse, porque una plataforma de prestaciones o un sistema fiscal que se derrumba el primer día se convierte en una investigación pública, no solo en una tarde lenta.
¿Alguna vez han fallado deliberadamente un componente en producción, y el nivel de redundancia de cada sistema corresponde realmente a su criticidad y a su costo? Una resiliencia que nunca se ha probado es una hipótesis, y los niveles que se pueden adquirir van del sencillo respaldo y restauración a la reserva en caliente y al costoso multinacional activo-activo, de modo que la disciplina consiste en invertir en garantía donde está justificada, en lugar de dar oro a todo o no proteger nada. Las consideraciones opuestas son el radio de impacto y el presupuesto: los experimentos de caos deben tener barreras y un interruptor de aborto, y un activo-activo para una herramienta interna de informes es un derroche, mientras que un simple respaldo para una plataforma de pagos es una negligencia. Presente un inventario de los puntos únicos de fallo, el nivel de redundancia de cada sistema crítico y la evidencia del último inyección controlada de fallos y lo que reveló. En portafolios empresariales y del sector público, asocie cada nivel a una clasificación documentada de criticidad para que un auditor pueda ver que el dinero sigue al riesgo y para que nadie tenga que justificar el gasto por primera vez durante la interrupción.

Perspectiva por sector

Startup. No es posible predecir si un lanzamiento traerá cincuenta registros o cincuenta mil, así que adquiera escalabilidad en lugar de construirla: ejecute servicios sin estado tras un balanceador de carga gestionado y deje que la plataforma escale automáticamente según la tasa de solicitudes. Fije un presupuesto de rendimiento modesto y elija bases de datos gestionadas para que un pico de tráfico no obligue a una reingeniería a las dos de la mañana. Omita la recuperación ante desastres multinacional y los programas de caos por ahora; mantenga respaldos probados y dedique su escasa atención de ingeniería al producto, no a una redundancia que su tráfico aún no justifica.

Pequeña empresa. Sin especialista en fiabilidad y con un presupuesto ajustado, la elección entre comprar y construir tiende fuertemente a comprar: una plataforma gestionada o una pila sin servidor convierte el escalado y el conmutado en responsabilidad del proveedor, y una única región bien administrada suele bastar. Enmarque la resiliencia como un pequeño número de promesas concretas que puede cumplir, como un respaldo nocturno del que se ha restaurado al menos una vez y una ventana de recuperación realista comunicada a los clientes. Evite pagar por un activo-activo o una prueba de carga continua que ni el tráfico ni el personal justifican.

Empresa. El reto es la coherencia entre muchos equipos: estandarice los presupuestos de rendimiento aplicados en la integración continua, una biblioteca compartida de patrones de resiliencia (tiempos de espera, disyuntores, compartimentos) y un nivel de redundancia documentado para cada sistema vinculado a su criticidad. Reserve el multinacional activo-activo para servicios de primera categoría, ejecute un programa de ingeniería del caos con barreras y simulacros en producción, y trate la planificación de capacidad para picos conocidos como una disciplina programada y no como una ocurrencia de última hora. Goberne el OTR y el OPR de forma centralizada para que cada sistema crítico tenga objetivos propios, probados y verificables por un auditor.

Sector público. La carga suele estar fijada por ley y las obligaciones de disponibilidad son estatutarias, por lo que la planificación de capacidad no puede depender de que el escalado automático reaccione en el momento justo: prevea el pico del plazo, prepocione y pruebe la carga con mucho margen sobre la previsión. La adquisición debe especificar el OTR, el OPR y un calendario de simulacros de conmutado como requisitos contractuales, no promesas del proveedor, y debe evitar el acoplamiento a una sola región en los servicios críticos. Decida de antemano qué vía es legalmente esencial (presentar una declaración, solicitar una prestación) para que la degradación abandone primero los paneles de estado y las consultas, y sea transparente con el público sobre las interrupciones y las recuperaciones en lugar de esperar que nadie las note.

Ejemplos

Startup. Una pequeña empresa que lanza su producto en Product Hunt no puede prever si recibirá cincuenta registros o cincuenta mil, así que mantiene sus servicios sin estado tras un balanceador de carga gestionado y deja que la plataforma escale automáticamente según la tasa de solicitudes. Fija un presupuesto de rendimiento modesto (las páginas responden en menos de 300 ms en el percentil 95) y elige una base de datos gestionada para que un pico de tráfico no obligue a una reingeniería a las dos de la mañana. Cuando llega el auge del día del lanzamiento, el sitio se ralentiza un poco en lugar de caerse, y el equipo dedica la jornada a hablar con los nuevos usuarios en vez de luchar contra una interrupción.

Empresa. Una plataforma de streaming en vídeo ejecuta servicios sin estado en varias regiones tras un balanceo global de carga, escalando automáticamente según la tasa de solicitudes para seguir la ola de horario estelar. Los presupuestos de rendimiento condicionan cada despliegue a la latencia p99 de inicio. Ante un fallo regional, el tráfico se desvía automáticamente a las regiones sanas y las funciones no esenciales (arte personalizada, actualización de recomendaciones) se degradan primero para proteger la reproducción. La empresa ejecuta experimentos de caos continuos en producción, terminando instancias e inyectando latencia de forma rutinaria, de modo que los fallos reales son indistinguibles de los simulacros y no provocan ninguna interrupción visible para el cliente.

Sector público. Una agencia tributaria sabe que su sistema de declaración enfrenta cada año un pico enorme y de fecha legalmente fija. En lugar de depender del escalado automático en el momento del incidente, prevee la carga máxima a partir de años anteriores, prepociona la capacidad con semanas de antelación y prueba la carga al 150 % de la previsión. La arquitectura es sin estado tras balanceadores de carga con una región de respaldo en caliente. El OTR y el OPR los fija la política (no más de 15 minutos de interrupción y pérdida de datos prácticamente nula para las declaraciones presentadas), y el conmutado se ensaya cada trimestre. Bajo carga extrema, las funciones no críticas (paneles de estado, consultas históricas) se abandonan primero para que la presentación de la declaración, la vía legalmente esencial, siga disponible.

Justificación empresarial: motivaciones, retorno de inversión y costo total de propiedad

La escalabilidad, el rendimiento y la resiliencia son el clásico caso en que el costo del fallo supera con creces el de la prevención. Pero la prevención aparece en el presupuesto y el fallo es solo potencial, por eso suelen estar crónicamente subfinanciados hasta el primer desastre. El costo de adopción es real: infraestructura redundante, capacidad multinacional, herramientas de prueba de carga y de caos, y el tiempo de ingeniería para construir la ausencia de estado y los patrones de resiliencia. El costo de no invertir es una interrupción de alto perfil durante la demanda máxima: ingresos perdidos por minuto en el comercio, obligaciones estatutarias incumplidas e investigaciones públicas en el sector público, penalizaciones por acuerdo de nivel de servicio y un daño reputacional duradero.

Presente el caso ante la dirección con cifras que el negocio ya entiende. Estime el costo de una hora de interrupción en hora punta (transacciones perdidas, penalizaciones, remediación, reputación) y compárelo con el costo anual de la redundancia y la prueba que lo previene. Para los sistemas críticos, la prevención es casi siempre una fracción de un solo incidente grave. Vincule el OTR y el OPR a dinero explícito: cuántos ingresos o cuántas transacciones se pierden por cada hora de interrupción, y cuánta pérdida de datos es tolerable legal o comercialmente. Presente el rendimiento como palanca de ingresos y satisfacción, pues los sistemas más rápidos convierten mejor y cuestan menos por transacción, y la resiliencia como un seguro cuya prima es pequeña frente a la pérdida cubierta. El argumento más sólido es que estas propiedades son baratas de integrar en el diseño y ruinosas de añadir después, cuando la interrupción obliga a hacerlo.

Antipatrones y trampas

Sesiones persistentes y estado en la instancia. Almacenar el estado de sesión en el servidor impide el escalado horizontal libre y el reemplazo seguro de instancias.
El escalado automático como planificación de capacidad. Suponer que el escalado automático absorberá un pico predecible ante el que reacciona demasiado lento.
Operar al límite sin margen. Funcionar cerca del 100 % de utilización, sin espacio para absorber picos ni fallos.
Optimizar sin perfilar. Ajustar código que no es el cuello de botella mientras el verdadero pasa desapercibido.
Ignorar la cola. Informar la latencia media mientras los usuarios en p99 sufren; la media oculta el dolor a gran escala.
Recuperación ante desastres no probada. Un plan de recuperación y respaldos que nunca se han ensayado y que fallarán cuando se necesiten.
Puntos únicos de fallo. Un solo balanceador de carga, un solo primario de base de datos, una sola región: un componente no redundante que tumba todo.
Ingeniería del caos sin barreras. Inyectar fallos sin control del radio de impacto ni interruptor de aborto, provocando la misma interrupción que se pretendía prevenir.

Modelo de madurez

Nivel 1: Iniciar. Ad hoc y reactivo. Instancia única o escalado vertical, con estado en el servidor. Sin pruebas de carga, sin presupuestos de rendimiento y sin recuperación ante desastres más allá de respaldos ocasionales que nadie ha restaurado. El fallo de cualquier componente provoca una interrupción total y los problemas de escala se descubren en producción.
Nivel 2: Desarrollar. Aparecen prácticas básicas pero varían de un equipo a otro. Algunos servicios están escalados horizontalmente y sin estado tras un balanceador de carga, con escalado automático básico en unos pocos. La prueba de carga se realiza antes de grandes lanzamientos pero no de forma rutinaria, existen respaldos pero la recuperación ante desastres está documentada y rara vez se ejercita. Lo que un equipo hace bien, otro no lo ha iniciado.
Nivel 3: Estandarizar. Las prácticas están documentadas y aplicadas en toda la organización. La capacidad se planifica para picos conocidos con margen, los presupuestos de rendimiento se aplican en la integración continua de modo que las regresiones fallen la compilación, y los patrones de resiliencia (tiempos de espera, reintentos acotados, disyuntores, compartimentos) junto con la degradación gradual son el estándar. El OTR y el OPR se definen por sistema, se asignan niveles de redundancia según la criticidad y el conmutado de recuperación ante desastres se ensaya con un calendario regular entre equipos.
Nivel 4: Gestionar. Las propiedades se miden y controlan frente a líneas base. Los equipos siguen la latencia p95 y p99, los presupuestos de error y la utilización y el margen frente a la previsión, y alertan ante incumplimientos en lugar de descubrirlos en el lanzamiento. Los tiempos de conmutado probados se comparan con el OTR y el OPR objetivo, los umbrales de degradación y reducción de carga se validan con métricas, y las decisiones de despliegue y capacidad se toman en función de los datos. Cuando las cifras se desvían de la línea base, la brecha es visible y tiene responsable, en vez de ocultarse tras las medias.
Nivel 5: Orquestar. La escalabilidad, el rendimiento y la resiliencia mejoran de forma continua y se integran en toda la organización. El multinacional activo-activo se emplea donde la criticidad lo justifica, la ingeniería del caos funciona de forma continua, incluidos simulacros en producción, y la previsión de capacidad alimenta directamente la planificación y la adquisición. La resiliencia se valida de forma permanente, los objetivos de recuperación se cumplen y se demuestran con constancia, y la arquitectura se adapta conforme cambian los patrones de carga y el panorama de riesgo, integrada en la continuidad del negocio y la gestión de riesgos.

Ideas para la reflexión

¿Qué servicios siguen almacenando estado en la instancia y qué impide convertirlos en servicios sin estado?
Para su sistema más crítico, ¿cuáles son el OTR y el OPR, quién los fijó y cuándo demostró por última vez que puede cumplirlos?
¿El escalado automático realmente le protege ante su mayor pico conocido, o confían en que haga algo que no está en su capacidad?
¿Dónde reside su punto único de fallo restante y cuál es el plan para eliminarlo?
¿Miden y presupuestan la latencia p99, o se refugian tras las medias?
¿Alguna vez han provocado el fallo de un componente en producción? Si no, ¿cómo saben que su resiliencia funciona?

Ideas clave

Distinga entre rendimiento, escalabilidad y resiliencia; un sistema de gran escala necesita las tres, integradas desde el inicio.
El escalado horizontal y los servicios sin estado son la base de la escala, la disponibilidad y el despliegue seguro.
Combine el escalado automático con una planificación de capacidad real y un margen para los picos predecibles y críticos.
Dirija el rendimiento con perfilado y pruebas de carga frente a presupuestos explícitos, centrándose en la ruta crítica y la cola.
Construya resiliencia con tiempos de espera, disyuntores, compartimentos, degradación gradual y redundancia, y valídelo con ingeniería del caos.
Fije el OTR y el OPR como decisiones de negocio, adapte la recuperación ante desastres a la criticidad de cada sistema y ensaye el conmutado con regularidad.

Referencias y lecturas complementarias

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering y The Site Reliability Workbook
Casey Rosenthal y Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile