La tienda abre. Las cajas cobran. Los clientes siguen entrando.
Mientras tanto, el equipo que debe aprobar un cambio urgente no puede consultar el expediente. Finanzas tiene una orden pendiente y no sabe si alguien la aprobó. Y el responsable que tiene que coordinar la respuesta ha perdido el correo, la agenda y el canal por el que normalmente reúne al equipo.
¿Está funcionando el negocio?
Si miramos las ventas de esa mañana, probablemente sí. Si miramos cuánto tiempo puede seguir operando así, la respuesta es algo menos cómoda.
La incidencia de Microsoft 365 del 12 y 13 de noviembre de 2026 me hizo volver a esa pregunta. Varios servicios sufrieron problemas de acceso o funcionaron en modo degradado. La conversación se centró, como es lógico, en cuándo iba a volver Microsoft. A mí me interesa otra cosa: ¿qué podemos seguir haciendo nosotros mientras tanto?
Migramos deprisa. Las dependencias llegaron después
Pienso en cómo trabajaban muchas empresas antes de la pandemia. Podían tener correo en la nube, alguna aplicación SaaS y cargas en un proveedor de infraestructura. Pero buena parte de la operación todavía vivía repartida entre sistemas propios, aplicaciones locales y distintos proveedores.
Con la pandemia, muchas organizaciones tuvieron que acelerar esa transición. Había un problema real que resolver: poner a trabajar a equipos distribuidos sin esperar dos años a que terminara un proyecto de transformación. La nube resolvió buena parte de ese problema y aportó ventajas que seguimos aprovechando hoy.
Lo que cuesta más ver es lo que hemos ido concentrando desde entonces. Una misma plataforma puede llevar el correo y las reuniones, custodiar documentos, autenticar a los usuarios y sostener los flujos con los que aprobamos cambios o compras.
Compramos esas capacidades en momentos distintos. Las usamos como si fueran herramientas distintas. Pero, cuando fallan juntas, descubrimos que algunas dependían del mismo sitio.
Tener otra región resuelve un problema concreto
En infraestructura como servicio, si pierdo una región, otra región puede ser una buena respuesta. Si el escenario que necesito cubrir es perder al proveedor, lo que tengo que demostrar es que puedo operar fuera de él.
Son dos escenarios diferentes y deberían aparecer por separado en el plan de recuperación.
El incidente de AWS de octubre de 2025 es un buen ejemplo de por qué importa esa distinción. Empezó con un problema de resolución DNS en los endpoints regionales de DynamoDB en Virginia del Norte y terminó afectando a otros servicios. Eso no significa que una segunda región sea inútil. Significa que hay que identificar qué dependencias comparten la carga principal y la alternativa.
Al hablar de proveedores estratégicos solemos pensar en AWS, Microsoft Azure y Google Cloud. Pero tampoco basta con decir «tenemos Azure y AWS». Si para levantar en AWS el servicio que ha dejado de funcionar en Azure necesito iniciar sesión con Entra, recuperar una clave de un servicio afectado o ejecutar un procedimiento que solo está en SharePoint, sigo teniendo un problema. Tengo dos proveedores en el inventario. Me falta demostrar que uno puede sostener la operación cuando el otro no está disponible.
¿Justifica eso duplicar toda la infraestructura? Para mí, no. Mantener dos entornos cuesta dinero, añade trabajo y exige que ambos estén preparados. Lo reservaría para las cargas cuyo impacto lo justifique. Y, según el caso, la alternativa podría estar en otro proveedor, en infraestructura propia o en una forma más sencilla de prestar temporalmente el servicio.
Internet también tiene puntos de concentración
Aquí solemos detener el dibujo demasiado pronto. Dibujamos dos proveedores cloud y dos operadores de telecomunicaciones. Ponemos varias líneas entre ellos y damos por hecha la diversidad.
Pero ¿por dónde van realmente esas líneas?
Dos operadores pueden compartir la última milla, un tramo de fibra, un proveedor de tránsito o un punto neutro donde intercambian tráfico. Y el problema también puede ser lógico: si una ruta deja de anunciarse o se propaga de forma incorrecta, puede haber conectividad física y, aun así, no llegar al destino que necesitamos.
Que dos operadores coincidan en un punto neutro tampoco implica que todo su tráfico pase obligatoriamente por él. Esa es precisamente la pregunta que hay que hacer: si perdemos ese camino, ¿qué otro camino queda y qué servicios siguen siendo accesibles por él? Los puntos neutros son valiosos porque permiten que muchas redes se interconecten. Esa misma concentración merece atención cuando diseñamos la continuidad.
Cambiar de nube sirve de poco si, desde la sede que tiene que ejecutar el plan, las dos nubes han quedado fuera de alcance. Antes de dar por válida la alternativa, me interesa saber qué ruta podríamos perder, desde dónde y cómo lo hemos probado.
La alternativa también tiene dependencias
- Infraestructura¿La alternativa funciona si perdemos una región o si perdemos al proveedor? Son pruebas distintas.
- Conectividad¿Desde dónde podemos llegar a ella si perdemos una ruta, un operador o un punto de interconexión compartido?
- Operación¿Podemos autenticarnos, consultar los datos y tomar una decisión urgente sin la plataforma habitual?
Con SaaS, el margen de maniobra es otro
Con una aplicación que gestiono yo, puedo preparar otra instalación, replicar datos o levantar una versión reducida. Con un SaaS, normalmente no puedo arrancar una copia de la aplicación del proveedor en otro sitio. Puedo proteger parte de los datos y preparar una forma alternativa de trabajar. Son capacidades distintas.
Un backup de correo puede ser muy útil si pierdo un buzón. Durante una caída del servicio, las preguntas cambian: ¿puedo consultar los mensajes que necesito? ¿Puedo recibir uno nuevo y responder? ¿Y puedo hacerlo si también falla la identidad con la que entro en la alternativa?
Con los documentos pasa algo parecido. Quizá tenga una copia del procedimiento, pero la operación requiere una aprobación. Si el flujo habitual no está disponible, necesito saber quién puede aprobar, cómo queda constancia y cómo se incorpora esa decisión al sistema cuando vuelva. De otro modo, consigo ver el documento, pero sigo sin poder completar el trabajo.
El modo degradado puede ser incluso más difícil de gestionar que una parada clara. Un correo sale, otro se queda pendiente y no sé si el cliente lo recibió. Alguien vuelve a cursar una petición porque no ve el resultado de la primera. Cuando se recupera el servicio, queda una pregunta bastante práctica: ¿qué se hizo una vez, qué se hizo dos veces y qué no se llegó a hacer?
Que la caja siga cobrando no cuenta toda la historia
Los equipos de primera línea pueden seguir trabajando durante una incidencia. Es una buena señal, pero solo describe una parte del negocio.
Pensemos en una tienda que vende con normalidad, pero no puede escalar una avería al equipo que tiene que resolverla. O en un proveedor que puede entregar el pedido de hoy, pero no recibe la confirmación para el de mañana. El impacto no tiene por qué aparecer en la primera hora. Puede acumularse durante todo el día y hacerse visible en el siguiente turno.
Y aquí conviene ser selectivos. Hay reuniones que pueden esperar. Hay informes que pueden salir al día siguiente. Y hay decisiones, autorizaciones y comunicaciones que sostienen la operación aunque nadie las vea desde el mostrador. Son esas las que quiero identificar primero.
¿Qué deberíamos ser capaces de hacer sin el proveedor?
Yo haría el ejercicio con los responsables de negocio, sin empezar por el catálogo de productos. Supongamos que mañana no disponemos del entorno de trabajo habitual durante una jornada. ¿Qué podemos aplazar? ¿Qué tiene que salir de todas formas? ¿Quién puede hacerlo y por qué vía?
Para algunos procesos bastará con un teléfono y un procedimiento accesible fuera de la plataforma. Otros necesitarán una alternativa ya preparada, con acceso independiente y los datos mínimos para trabajar. Y habrá procesos para los que no exista una alternativa razonable: también es útil saberlo de antemano, porque permite decidir si el impacto es asumible o si hay que cambiar el diseño.
Un proveedor puede ofrecernos un SLA excelente y seguir siendo la dependencia que más nos preocupa. Su porcentaje de disponibilidad habla de su servicio. Nosotros tenemos que demostrar otra cosa: cuánto tiempo puede seguir funcionando la empresa cuando ese servicio falta.
La próxima vez que revisemos el plan de recuperación, yo empezaría por una prueba muy sencilla: quitemos del ejercicio el correo, el chat y el acceso al plan. ¿Quién puede convocar al equipo y sacar adelante la primera decisión urgente?
Referencias para profundizar
Fuentes oficiales para contrastar y ampliar estos conceptos. Este artículo presenta un enfoque práctico; no reproduce los requisitos completos de las referencias.
- Microsoft 365 Service Health · MO1550821 (University of Pennsylvania mirror)
- AWS · Summary of the Amazon DynamoDB Service Disruption (Northern Virginia)
Los ejemplos son ilustrativos. Las decisiones de implementación deben adaptarse a los requisitos y dependencias de cada organización.