Las arquitecturas híbridas y multinube han cambiado radicalmente la ecuación de la resiliencia. Ahora, las aplicaciones abarcan regiones, proveedores, plataformas SaaS, redes de distribución de contenidos (CDN), servicios de identidad y entornos perimetrales. Este alcance aporta agilidad y escalabilidad, pero también introduce una exposición sistémica.
Pero para los equipos que gestionan la tecnología y la infraestructura de las que dependen nuestras presencias digitales, la cuestión ya no es si se producirá una disrupción, sino si la arquitectura subyacente está diseñada para contenerla, adaptarse mientras dure y mejorar gracias a ella. Es aquí donde la ciberresiliencia antifrágil adquiere una importancia estratégica.
“Las arquitecturas diseñadas con ciberresiliencia no se limitan a «recuperarse». Se adaptan sobre la marcha y salen reforzadas para la próxima vez.”
La primera parte de esta serie de dos partes estableció las prácticas que hacen que la resiliencia cibernética sea antifrágil. Ahora, veamos cómo cada nivel convierte el control del radio de impacto, la adaptación basada en políticas, la diversificación y el aprendizaje continuo en medidas concretas que adoptar durante y después de un incidente en curso.
De resiliente a antifrágil
Tradicionalmente, la «arquitectura resiliente» se refiere a la capacidad de resistir las disrupciones. La resiliencia antifrágil lleva este concepto mucho más allá.
Un sistema antifrágil limita el alcance de los daños durante una interrupción y se adapta mientras esta se desarrolla. Estas prácticas de resiliencia incorporan las lecciones aprendidas de una interrupción al comportamiento futuro de la arquitectura y reducen la probabilidad y el impacto de que vuelva a producirse.
En lugar de tratar los fallos como una excepción, el diseño antifrágil considera las disrupciones una condición operativa normal. Para aplicar la antifragilidad a gran escala, las empresas necesitan una estructura. Un modelo de resiliencia antifrágil de cinco niveles proporciona esa estructura.
Los cinco niveles de una empresa antifrágil
Los niveles definen dónde debe integrarse la resiliencia. Las prácticas antifrágiles definen cómo mejora la resiliencia. Juntos, transforman las disrupciones en avances arquitectónicos.
1. El nivel global: limita los fallos de todo el sistema antes de que se propaguen
El nivel global rige los servicios ubicuos que abarcan distintas regiones y entornos: DNS, identidad, confianza federada y gestión global del tráfico. En este nivel, la resiliencia antifrágil se materializa en políticas que tienen en cuenta el estado de los sistemas y ajustan automáticamente el enrutamiento cuando las dependencias se vuelven inestables, antes incluso de que se abra una incidencia. Esto limita por diseño el radio de impacto (nombres, autenticación y rutas) y recurre a alternativas globales para mantener intactos los flujos de usuarios.
Los fallos en este nivel son especialmente peligrosos porque afectan a una capa superior a las cargas de trabajo individuales. Si fallan el enrutamiento global o la identidad, todos los servicios dependientes se ven afectados simultáneamente.
Las prácticas antifrágiles en este nivel se centran en tres elementos. El control del radio de impacto establece límites explícitos de confianza y de fallo para evitar que un fallo en una región, nube o dependencia se propague sin control. La adaptación basada en políticas implica sustituir las configuraciones codificadas de forma rígida por políticas que respondan al estado actual. Las decisiones relativas al enrutamiento del tráfico, la autenticación y la confianza deben ajustarse dinámicamente. Además, la diversificación de dependencias exige introducir alternativas para los servicios críticos y gestionar la opcionalidad para impedir que un único proveedor determine el comportamiento del sistema.
Cuando el sistema está sometido a presión, el nivel global debe aplicar los límites de confianza y de fallos, y seguir un enrutamiento basado en políticas para evitar que los fallos de un proveedor se conviertan en incidentes que afecten a toda la empresa. Entre las métricas clave que deben supervisarse durante un incidente se incluyen la velocidad del redireccionamiento automático del tráfico, la variación de la tasa de éxito de la autenticación, el tiempo de conmutación por error de DNS y el porcentaje de solicitudes atendidas por proveedores alternativos.
El objetivo es evitar que un único proveedor o incidente del plano de control determine el comportamiento de toda la empresa. Los servicios globales deben contener los fallos, no amplificarlos.
2. El nivel de sitio: proporciona aislamiento controlado y zonas de ejecución alternativas
El nivel de sitio define dominios de ejecución regionales: regiones de nube, centros de datos y clústeres de edge computing.
En los modelos tradicionales, las regiones eran réplicas redundantes. En las arquitecturas antifrágiles, se diseñan como zonas de aislamiento. Cada sitio se convierte en un dominio de fallos delimitado con tres áreas de capacidad.
El funcionamiento independiente implica configurar los sitios de forma que puedan operar tanto como partes de una red agregada más amplia, como nodos independientes, preservando así cierto nivel de funcionalidad para los usuarios en caso de interrupción del servicio.
La conmutación por error controlada reduce el efecto «dominó» y la probabilidad de que una interrupción en un sitio se propague a otros. Determinar cómo y dónde pueden realizar la conmutación por error los sitios permite que la red en su conjunto absorba el impacto de una interrupción.
Las rutas de ejecución alternativas constituyen otro conjunto de capacidades clave. Desvían activamente el tráfico de un proveedor que está fallando hacia una ruta alternativa e independiente, alejando así los servicios críticos del área afectada por la interrupción.
El nivel de sitio debe ayudar a que los sitios actúen como dominios de fallo acotados cuando el sistema esté sometido a estrés. El tráfico debe desviarse o reasignarse a otras regiones o proveedores sin provocar efectos en cadena. Entre las métricas clave que deben supervisarse en este nivel se incluyen el tiempo medio de resolución para el aislamiento del sitio, el tiempo de salida entre proveedores y el porcentaje de servicios críticos con alternativas validadas previamente.
La diversificación de las dependencias es fundamental en este nivel, ya que las empresas deben garantizar que existan alternativas viables cuando se degrade una región, una ruta de CDN o un proveedor de tránsito de red. Este nivel convierte el riesgo sistémico en una interrupción localizada y gestionable.
3. El nivel de plataforma: automatiza la respuesta y permite la portabilidad de las cargas de trabajo
La capa de plataforma incluye clústeres de Kubernetes, entornos de virtualización y cualquier infraestructura de computación que aloje cargas de trabajo. En entornos híbridos multicloud, la portabilidad y la automatización determinan la rapidez con la que comienza la adaptación, ya que los ciclos de respuesta humana son demasiado lentos durante eventos sistémicos.
Las prácticas antifrágiles en este nivel hacen hincapié en la automatización en tiempo de ejecución para automatizar las respuestas en empresas resilientes, de modo que la adaptación comience antes de que el incidente se agrave.
Otra práctica clave es la movilidad de las cargas de trabajo, que consiste en desplegar aplicaciones en varios entornos para garantizar la continuidad, creando una red de cargas de trabajo redundantes y diversificadas.
Cuando está sometido a presión, el nivel de plataforma debe ser capaz de ayudar al sistema a escalar automáticamente, con políticas de disyuntor implementadas y la capacidad de cambiar la capacidad o la postura mientras el incidente aún está en curso. El tiempo transcurrido hasta la primera acción automatizada del sistema, el número de cambios de políticas por incidente y el porcentaje de cargas de trabajo con entornos de ejecución secundarios son métricas fundamentales en este nivel.
Cuando las señales de estado se deterioran, las decisiones de enrutamiento, el comportamiento del escalado y la postura de seguridad deben ajustarse automáticamente. La automatización garantiza que la adaptación comience antes de que el incidente se agrave, mientras que la diversificación de las cargas de trabajo garantiza que los servicios críticos estén siempre disponibles. Este nivel determina si una interrupción provoca una degradación gradual o un fallo en cascada.
4. La capa de aplicación: absorbe las interrupciones sin deteriorar la experiencia del usuario
Las aplicaciones proporcionan lógica de negocio y valor al usuario. En las arquitecturas tradicionales, los fallos de las aplicaciones solían ser un reflejo de los fallos de la infraestructura.
El diseño antifrágil introduce una adaptación gradual, incluida la degradación controlada en lugar de un fallo total. Los equipos pueden evitar fallos catastróficos limitando la funcionalidad de un servicio, incluso cuando gran parte de este no está disponible debido a una interrupción u otra incidencia.
La priorización de funcionalidades en situaciones de estrés es otro elemento crucial de la capa de aplicación, ya que garantiza que los flujos de trabajo esenciales de los usuarios sigan estando disponibles, aunque no se pueda ofrecer la experiencia completa, al tiempo que evita que los servicios opcionales provoquen la caída de servicios importantes.
Los reintentos inteligentes y los disyuntores son estrategias que tienen en cuenta el contexto y permiten que las aplicaciones respondan de forma adaptativa cuando fallan las dependencias, en lugar de caer en bucles de reintentos indiscriminados que pueden aumentar la carga y acelerar los fallos.
La capa de aplicación debe ayudar a que las funcionalidades no esenciales reduzcan la carga para garantizar que los flujos de trabajo principales sigan funcionando correctamente. Los clientes deben adaptarse a los cambios válidos en el comportamiento de los servicios ascendentes (p. ej., DNS/identidad), evitando avalanchas de solicitudes. Asegúrese de supervisar las compras y los inicios de sesión completados correctamente durante interrupciones parciales, el consumo de los presupuestos de reintentos y las tasas de apertura y cierre de los disyuntores.
Las aplicaciones deben tolerar cambios válidos en el comportamiento de los servicios de los que dependen. Deben asumir que los proveedores de identidad, las respuestas DNS o las API pueden evolucionar sin previo aviso. En esta capa, la resiliencia se mide por la continuidad de la experiencia del usuario, no por el tiempo de actividad de la infraestructura.
5. El nivel de gestión: convierte los eventos operativos en mejoras de la gobernanza y las políticas
El nivel de gestión abarca la observabilidad, la orquestación, el análisis y la gobernanza. Sin una gobernanza basada en datos de telemetría, la resiliencia se estanca. Los incidentes se convierten en tickets cerrados en lugar de dar lugar a mejoras arquitectónicas.
Las prácticas antifrágiles en este nivel se centran en múltiples factores, entre ellos la gobernanza basada en la observación, que utiliza la telemetría para orientar la toma de decisiones. La resiliencia mejora cuando las suposiciones de diseño se sustituyen por el comportamiento real observado en situaciones de estrés.
Para garantizar una validación continua, compruebe constantemente las hipótesis de resiliencia, los controles de seguridad y los comportamientos arquitectónicos, no solo durante las auditorías programadas o después de las interrupciones del servicio.
Base la evolución de las políticas en el comportamiento real, incorporando los datos operativos (latencia, errores, eventos de conmutación por error, etc.) a los marcos de gobernanza y orquestación para actualizar y perfeccionar las políticas, de modo que los sistemas aprendan de eventos reales, no de predicciones ni suposiciones. Los artefactos de cumplimiento automatizados convierten los eventos operativos en información verificable y lista para auditorías, minimizando la intervención humana.
El nivel de gestión garantiza que la telemetría se convierta en una fuente de información para la gobernanza. Los incidentes de TI generan políticas actualizadas de enrutamiento y segmentación, así como artefactos listos para auditoría.
Las métricas clave incluyen el tiempo transcurrido desde el cierre del incidente hasta la actualización de la política, el porcentaje de incidentes que dan lugar a cambios en los controles y el número de artefactos de auditoría generados automáticamente.
Aquí es donde la resiliencia adquiere un carácter estratégico. Cada interrupción sirve para perfeccionar las políticas de enrutamiento, mejorar la segmentación, reforzar los límites de confianza y robustecer la lógica de automatización.
Cómo funcionan conjuntamente los niveles
La fuerza del modelo reside en la integración.
- El nivel global limita la propagación sistémica
- El nivel de sitio contiene los fallos dentro de zonas definidas
- El nivel de plataforma se adapta automáticamente
- La capa de aplicación preserva la experiencia de usuario
- El nivel de gestión garantiza que cada interrupción fortalezca el sistema.
Cuando se diseñan de forma cohesionada, estos niveles eliminan la fragilidad generada por prácticas fragmentadas.
La resiliencia ya no es responsabilidad exclusiva de NetOps, SecOps ni de las operaciones en la nube. Se convierte en un modelo operativo transversal alineado con la gobernanza, la arquitectura y la estrategia ejecutiva.
La resiliencia como capacidad estratégica
Los entornos de aplicaciones híbridas han introducido, quizá irónicamente, una concentración de riesgos a una escala sin precedentes. Un reducido grupo de proveedores de hiperescala sustenta infraestructuras críticas a nivel mundial. Las empresas que aprovechan estas tecnologías pueden beneficiarse de la escalabilidad y el rendimiento que ofrecen, pero también heredan la fragilidad no deseada que conlleva depender en exceso de un número reducido de proveedores. Eliminar por completo la dependencia externa no es viable ni deseable.
El objetivo es garantizar que su arquitectura no dé por sentada la disponibilidad permanente del proveedor ni permita que los fallos se propaguen sin control.
Una arquitectura resiliente no considera la recuperación como la meta final ni repite el mismo patrón de fallo. La ciberresiliencia antifrágil replantea las disrupciones, que dejan de ser una molestia operativa para convertirse en un factor diferenciador competitivo.
La ciberresiliencia antifrágil replantea las disrupciones, que dejan de ser una molestia operativa para convertirse en un factor de diferenciación competitiva, y propone prácticas específicas en cada nivel. Las políticas globales contienen la propagación. Los sitios se aíslan y redirigen el tráfico. Las plataformas automatizan la transición a una capacidad alternativa. Las aplicaciones reducen sus prestaciones de forma controlada para preservar los flujos esenciales. La gestión convierte los incidentes en políticas formalizadas. Las arquitecturas diseñadas de este modo no se limitan a «recuperarse». Se adaptan sobre la marcha y vuelven reforzadas la próxima vez.
Si desea obtener más información sobre la resiliencia cibernética desde una perspectiva antifrágil, no deje de leer nuestra entrada anterior del blog, «Un nuevo manual para la resiliencia cibernética en entornos híbridos multicloud», y consulte nuestra descripción general de la solución.
Si quiere profundizar en cómo empezar a implementar un enfoque antifrágil en su estrategia de ciberresiliencia, consulte este documento técnico sobre arquitectura.
¿Quiere hablar sobre resiliencia con un equipo de F5? Póngase en contacto con nosotros!
Sobre los autores
Griff Shelley es director de marketing de producto en F5 y está especializado en soluciones de entrega de aplicaciones de hardware, software y SaaS. Impulsado por su pasión por vincular la tecnología innovadora con el éxito de los clientes, Griff dirige proyectos de comercialización en los ámbitos de la entrega de aplicaciones a escala global y local, los servicios en la nube y la infraestructura de tráfico de datos para IA. Antes de iniciar su carrera en el sector tecnológico, fue asesor académico de educación superior y obtuvo titulaciones en Eastern Washington University y Auburn University.
Más artículos de Griff ShelleyColin Clauset es director sénior de marketing de producto en F5 y está especializado en soluciones SaaS para la entrega de aplicaciones. Colin lidera la estrategia de comercialización de proyectos y servicios de entrega de aplicaciones distribuidas, y siente especial pasión por comprender cómo la tecnología puede simplificar procesos complejos para satisfacer mejor las necesidades de los profesionales de TI. Gracias a su experiencia previa en consultoría antes de incorporarse a F5, Colin aborda los retos de los clientes con una visión orientada a soluciones integrales que van más allá de productos concretos.
Más artículos de Colin ClausetMark Menger es arquitecto de soluciones en F5 y está especializado en alianzas tecnológicas en los ámbitos de la IA y la seguridad. Lidera el desarrollo de la arquitectura de referencia de IA de F5, impulsando soluciones de IA seguras y escalables. Gracias a su experiencia como arquitecto de soluciones globales e ingeniero de soluciones, Mark contribuyó a la arquitectura de nube segura de F5 y participó en el desarrollo de su arquitectura distribuida de cuatro niveles. Como coautor de Solving IT Complexity, aporta su experiencia en la resolución de retos de TI. Anteriormente, trabajó como desarrollador de aplicaciones y arquitecto empresarial, centrándose en las aplicaciones modernas, la automatización y la aceleración del valor obtenido de las inversiones en IA.
Más artículos de Mark MengerArtículos relacionados del blog
IA agéntica en ciberseguridad: promesas y riesgos
Descubre por qué el uso de la IA agéntica en ciberseguridad es esencial para combatir las amenazas impulsadas por IA y por qué los agentes también generan nuevos riesgos empresariales.
Cómo los clientes de F5 del sector financiero abordan la soberanía digital sin frenar la innovación
¿Cómo se materializa la soberanía digital en el mundo real? Dos proyectos recientes de F5 con clientes muestran cómo distintas empresas están afrontando estos retos.
Soberanía operativa: cómo desarrollar resiliencia en un mundo impredecible
Para muchas organizaciones, la cuestión ya no consiste únicamente en controlar los datos, sino en mantener la capacidad de operar, adaptarse y recuperarse a medida que evolucionan las leyes y las circunstancias.
No se puede proteger una conversación con un cortafuegos: cómo el red teaming de IA se volvió esencial
Dado que las implementaciones de IA avanzan a la velocidad de las máquinas, los métodos tradicionales de prueba de software ya no resultan adecuados.
Protege tu canalización de datos de IA sin ralentizarla
Proteger el flujo de datos de la IA no es opcional. Eso está claro. Lo que resulta mucho menos evidente —y mucho más difícil— es cómo protegerlo adecuadamente.
Las extranets no están muertas; solo necesitan una actualización
Modernice su extranet: descubra cómo F5 y Equinix ofrecen una conectividad para partners repetible, segura y escalable, sin la complejidad de las redes tradicionales.