Cuánto tarda en volver si se cae Azure — Gestión de servidores en Azure en Barcelona

Es la pregunta que sale en todas las reuniones y casi nunca se contesta de verdad.

La respuesta honesta es depende. Y no es una evasiva: es que la cifra no depende de Azure, depende de tu entorno. Dos empresas con el mismo servicio contratado pueden tardar veinte minutos y tres días respectivamente, y las dos estarían diciendo la verdad.

Lo que sí se puede hacer es descomponer de qué depende, y eso es esta página.

Los dos números que hay que tener claros

Se llaman RTO y RPO y suenan a jerga, pero son dos preguntas de negocio:

• Cuánto tiempo puedes estar parado. Eso es el RTO. Cuántas horas aguanta tu facturación, tu atención al cliente o tu producción sin sistema.
• Cuánta información puedes perder. Eso es el RPO. Si volvemos a las copias de anoche, ¿se pierde el trabajo de un día entero o solo el de la última hora?

Ninguno de los dos es una decisión técnica. Los decide la empresa, y el segundo suele doler más que el primero.

Y aquí está el problema de fondo: casi nadie ha decidido estos números. Cuando se pregunta, la respuesta habitual es «cuanto antes» y «nada». Con eso no se puede diseñar una recuperación.

De qué depende el tiempo real de vuelta

Por orden de lo que más lo alarga:

1. Si alguien ha ensayado la vuelta. Esto va primero porque es el que más pesa y el que menos se hace. Un entorno con copias perfectas y sin procedimiento probado tarda más que uno con copias peores y un procedimiento que se ha ejecutado de verdad. El día del incidente no es el día de averiguar en qué orden se levantan las cosas.

2. Qué está redundado y qué no. Tener el servicio en dos zonas no es lo mismo que tenerlo en dos regiones, y no todo merece la segunda. Lo que hay que saber es cuál es la pieza que no está redundada, porque esa marca el tiempo.

3. Las dependencias que nadie apunta. Antes del servidor hay que levantar el directorio, la red y el DNS. Y antes que eso, que alguien tenga la llave. La mitad de los retrasos reales no son técnicos: son una credencial que estaba en el móvil de quien ya no está.

4. Las copias y cómo están hechas. Cuánto se tarda en restaurar, no cuánto se tarda en hacer la copia. Y si esa restauración se ha probado alguna vez.

5. Quién decide. Durante un incidente alguien tiene que decir «levantamos así aunque falte esto». Si esa persona está en una reunión, el reloj sigue corriendo.

Dónde está el cuello de botella casi siempre

No es Azure. Azure tiene sus incidencias, las publica y son bastante menos frecuentes de lo que la gente cree.

El cuello de botella está en el punto 1. En la mayoría de entornos que he visto, nadie ha recuperado nunca el sistema en frío. Se sabe que hay copias, se sabe dónde están, y nadie ha hecho nunca el ejercicio de levantar todo desde cero con el cronómetro delante.

Eso convierte una incidencia de una hora en una de dos días, y no por falta de medios: por falta de ensayo.

Qué se puede comprobar hoy mismo

Sin montar nada y sin gastar nada:

1. Preguntar en voz alta: ¿cuánto podemos estar parados y cuánta información podemos perder? Si no hay respuesta, ese es el problema, no Azure.
2. Preguntar cuándo se hizo la última prueba de restauración real. No de la copia: de la restauración. Si la respuesta es «nunca» o no hay respuesta, ya sabes por dónde empezar.
3. Localizar la pieza que no está redundada. Casi siempre hay una y casi nadie la tiene identificada.
4. Encontrar las credenciales que nadie tiene. Las que usaba quien ya no está.

Con esas cuatro respuestas se puede poner un número a la pregunta inicial. Y el número suele ser más grande de lo que se esperaba.

Quién lo lleva

Todo esto entra dentro de la gestión de los servidores: la monitorización, las copias y su revisión, y el informe trimestral donde estos números aparecen escritos y no de memoria.

Si quieres saber el número que te toca, se empieza por la revisión del entorno actual con permisos de solo lectura: qué hay, qué está redundado, qué copias existen y cuándo se probaron. De ahí sale una estimación honesta, y a partir de ahí se decide si merece la pena invertir en bajarla.

← Gestión de servidores en Azure en Barcelona