Bien. Después de varias semanas o meses y un esfuerzo significativo, ya tenemos listo nuestro Plan de Continuidad de Negocio. Con su trabajo de campo, su Análisis de Riesgos y Análisis de Impacto sobre el Negocio, sus decisiones ejecutivas, estrategias de recuperación, Plan de Crisis y tal. Muchas horas de trabajo con sus respectivos cafés, colaboración más o menos voluntaria por parte de todos para obtener una serie de documentos y controles que reflejan la realidad de nuestra organización y la preparan para una contingencia que, afortunadamente, esperemos que no aparezca.
Y por suerte, el desastre no aparece. Pasan los meses y las cosas empiezan a cambiar: dos semanas después el responsable de mantenimiento cambia de teléfono móvil y a los seis meses se cambia el robot de copias y el software. Nueve meses más tarde, entra con impulso un nuevo técnico de comunicaciones y mejora significativamente la segmentación de la red. Un año después, se actualiza la aplicación que utiliza Recursos Humanos a la última versión y después de muchos dolores de cabeza conseguimos que todo funcione bien.
Hagamos algunas hipótesis.
Primero, seamos positivos. Además de todo lo descrito, nuestro Plan de Continuidad incluye un Plan de Mantenimiento que, adecuadamente, describe las circunstancias y condiciones en las que cada uno de los documentos, especialmente los ejecutivos, tienen que ser actualizados: cambio de infraestructura, actualizaciones, cambio de personal, etc. Y de acuerdo a éste, el Plan de Continuidad ha ido evolucionando de manera adecuada, reflejando todos y cada uno de los cambios.
Seamos un poco más negativos. Incluya nuestro Plan de Continuidad o no un Plan de Mantenimiento, lo cierto es que en escasas ocasiones alguien se ha acordado de actualizarlo. En general, sigue contemplando la realidad de la organización, aunque cada vez un poco menos. La aplicación de Recursos Humanos ya no es la versión que pone en la documentación, el software de copias tampoco y las competencias en materia de comunicaciones han cambiado, entre otras cosas.
Así que un buen día, sin avisar ni concertar cita previa, el desastre se presenta. Una tubería que pasa por encima de una sala que antes no era un CPD pero ahora sí lo es se rompe y provoca un cortocircuito que echa a perder un puñado de servidores, alguna placa base y el cuadro eléctrico del CPD. ¿Tiempo de resolución estimado? No tengo ni idea, pero menos de tres días no va a ser, contesta el de industrial. Parece que además del cuadro eléctrico, el SAI también está tocado y el proveedor dice que tiene que traer un rectificador del otro lado del mundo porque esa pieza no la tiene en España. Dado que 72 horas es mucho más de lo que cualquier proceso crítico es capaz de tolerar, es hora de poner en marcha nuestro Plan de Continuidad de Negocio.
Volvamos a nuestras hipótesis.
Primero, seamos positivos. Durante estos meses hemos realizado las respectivas pruebas de continuidad y aunque algo puede haber cambiado, lo cierto es que conocemos los problemas que surgen al utilizar un direccionamiento diferente en la aplicación de Recursos Humanos, el proveedor no nos mira con cara rara cuando le hablamos de desastre, y los usuarios tienen una idea aproximada de qué es lo que tienen que hacer. Bien por nosotros.
Segundo, un caso un poco más negativo. Aunque hemos actualizado el Plan de Continuidad de manera regular, lo cierto es que no se ha hecho ninguna prueba, ya sea por falta de tiempo, recursos o por confiar equivocadamente en que si está actualizado, no es necesario probarlo. Así que cuando llega el momento, todo está en su sitio, pero la base de datos de copias del nuevo sistema no podemos restaurarla hasta que no se ha instalado la aplicación, pero ésta no encuentra la base de datos y no se deja instalar y en eso perdemos tres horas. Y después, la recuperación no va a la velocidad que se esperaba, y perdemos otras dos. Al final, sí, todo recuperado, pero en un tiempo mayor del esperado.
Tercero, la joya de la corona. Imagínense. El Plan de Continuidad lleva guardado año y pico acumulando polvo. Ni se ha actualizado, ni se ha probado, ni siquiera se ha utilizado como papel reciclado. El caso es que al tipo de mantenimiento no lo localiza ni CSI, la aplicación de recursos humanos se reinstala desde cero… con la versión antigua, que como Murphy podría adelantar no es compatible con la actual y la base de datos no se puede restaurar (ni por tanto localizar el teléfono del de mantenimiento). El switch de backup que se suponía que debía servir para una posible contingencia (o eso pensábamos) se utilizó para poner en marcha la nueva segmentación, y en su lugar alguien decidió dejar un hub que sólo da pena. Cuando llamas al proveedor del sistema eléctrico, a la palabra “desastre” le sigue un silencio eterno por su parte y los usuarios se miran unos a otros como si el tema ni fuese con ellos y preguntan cuándo se va a arreglar. Y alguien se empieza a poner nervioso.
Tras estos escenarios, hagan un repaso mental y piensen cuál es su situación. En próximas entradas veremos las ventajas de llevar a cabo las pruebas de continuidad (aunque a la vista de lo anterior debería ser obvio) y entraremos a comentar los diferentes tipos de pruebas que se pueden realizar para que nadie se ponga más nervioso de lo necesario en una contingencia.
