El DRP del usuario

Es viernes por la tarde y aunque solo son las tres, iniciamos la parada de los usuarios de los sistemas centrales para lanzar los procesos de copias de seguridad, antes del horario habitual, porque vamos a realizar la instalación de una nueva versión del sistema operativo. Está todo planificado y revisado así que hacia la media noche, deberíamos tener las copias de los datos y programas en los carretes de cinta e iniciar la carga del nuevo sistema operativo. Antes ha habido que añadir el salvado de la configuración del sistema, de los perfiles de usuarios, de sus privilegios de acceso y atributos, de las colas de entrada y salida, etc. Todo ello supone un tiempo extra de copias y de recuperación en caso de tener problemas, cosa que el fabricante del sistema nos garantiza que no va a ocurrir.

Habíamos decidido instalar la nueva versión porque habían bastantes problemas de velocidad en los procesos de backup, que se comían la noche, y para poder utilizar las nuevas unidades de cintas de 8mm era necesario saltar a la versión siguiente del sistema operativo. Esperábamos que a partir de ahí, los backups se acortasen y la disponibilidad del sistema para los usuarios mejorase notablemente, como así fue finalmente, sin necesidad de cambiar la CPU, tal como sugería el proveedor, lo requería la aprobación de un presupuesto mayor para la gestión de los sistemas, que la dirección no estaba dispuesta a aprobar. Dado el riesgo que conllevan estas operaciones, habíamos advertido –por escrito- a los usuarios, durante algunos días, de que mantuvieran el control de su información escrita, por si fuese necesario trabajar manualmente en algún momento.

Hacia las once y media de la noche del viernes lanzamos la primera cinta de carga de la nueva versión del sistema. Nos fuimos a comer el bocadillo porque sabíamos por experiencia que este primer paso era bastante largo. La consola iba dando mensajes y finalmente decía “Este proceso puede durar algunas horas o más” y se quedaba tan fresco. Es una muestra de la traducción del Inglés al Español, tan habitual en la época. Hacia las dos de la mañana, a petición del sistema, pusimos la segunda cinta. Todo iba bien hasta que un llamativo mensaje de error de lectura del soporte nos hizo temblar. Tras reintentar varias veces, el proceso continuó, pero la cinta iba y venía adelante y atrás cada vez que leía un trozo y eso era muy mal síntoma, era claro que el soporte recibido estaba dañado. El caso es que a medio día del sábado, decidimos abortar la instalación y dar marcha atrás ya que el proveedor no tenía otra copia del sistema en Valencia y esta no parecía estar en condiciones de continuar instalándose.

Iniciamos la recarga de la versión anterior y pasamos el resto del sábado y la madrugada del domingo en este proceso. Por la tarde recuperamos configuración, usuarios, etc. Ya parecía que todo iba a ir bien, así que antes de terminar, hicimos algunas pruebas para asegurarnos de que en la mañana del lunes, nuestros problemas serían transparentes a los usuarios. Probamos accesos y procesos con las limitaciones que teníamos y confiamos que el entorno de producción estaría en condiciones.

El lunes por la mañana, los usuarios no podían acceder al sistema. Las autorizaciones y los perfiles parecían no trabajar adecuadamente. Iniciamos contacto con el soporte del proveedor para verificar que habíamos hecho la recuperación correctamente y así parecía ser, sin embargo no dábamos con el problema. Para no aburrir, la conclusión fue que una vez iniciada la instalación de ciertos módulos de la versión nueva del sistema, el proveedor advertía de que no podía garantizar la vuelta atrás, es más, no lo recomendaba. Sin embargo nadie lo sabía, al menos en Valencia y claro ahora habría que instalar la nueva versión cuando dispusiéramos de una cinta en condiciones y eso no sería antes del lunes al medio día. El proceso se repitió entonces y el martes a mitad de mañana todo volvió a funcionar correctamente.

Hasta aquí un relato real, como muestra de que aún haciendo el plan perfecto, puede darse el caso de que los sistemas vitales para la gestión de la empresa, no estén disponibles. Y ¿qué hace el usuario en este caso? Yo solo hablaré de mi experiencia y puedo decir que el usuario no está preparado para que le caigan los sistemas de información y en caso de suceder esto, en un breve plazo se queda bloqueado.

¿Es que el usuario es un irresponsable o un incompetente? NO y rotundamente NO. Lo que ocurre es que conforme los sistemas de proceso de la información lo permiten, la complejidad de los mismos crece y se eliminan elementos esenciales para realizar el trabajo sin ellos, léase personal suficiente para gestionar el negocio a mano, para prevenir cada paso del mismo y documentarlo, para hacer pruebas y entrenar a la gente que procesa la información, para disponer de información alternativa en otros soportes que le permitan organizarse rápidamente y seguir atendiendo a sus clientes sin impacto importante en ellos, etc.

Cuando sucedió lo que he relatado, la dirección de la empresa me llamó para una reunión de crisis. Después de tratar de explicar en lenguaje llano los tecnicismos del problema, y probablemente sin que estuvieran convencidos de que estas cosas pasan hagas lo que hagas para evitarlas, mi pregunta fue: ¿Cuánto le cuesta a la compañía en ventas un día de parada de sistemas? La respuesta era que el impacto es poco sobre el cliente si son solo 24 horas, pero es importante a partir de ahí y crítico si llega a durar 72 horas o más. Entonces ¿debemos asegurar la disponibilidad de sistemas con un margen de parada de 24 horas? pregunté al comité de dirección. SI CLARO, eso es imprescindible, no podemos permitirnos trabajar sin sistemas más de un día entero. Recordarles mi propuesta de mejora de la seguridad y disponibilidad de los sistemas fue fácil porque la tenían hacía meses en un cajón y ahora tendrían que reconsiderarla. Se aceptó un nuevo presupuesto, se instaló un sistema redundante (MIMIX en aquella época) y se mantuvo una copia en línea de las bases de datos y librerías de programas. Desde entonces las crisis tecnológicas dejaron de tener impacto directo en la actividad de los negocios, pero el plan de recuperación de desastres empezó a figurar en la agenda de todos los departamentos ya que siempre pueden darse circunstancias en las que el usuario tendrá que tomar acciones para continuar trabajando, pues el fallo tecnológico es tan solo uno de los posibles problemas que se pueden presentar. Catástrofes naturales, incendio o inundación de locales, o hasta una enfermedad contagiada a la plantilla, son ejemplos de situaciones de riesgo en las que el día a día no permite pensar pero que pueden hacer caer las cifras de un negocio si no se ha previsto como actuar en los casos de crisis.

Los departamentos o personas responsables de la organización de las empresas deben diseñar e implementar los procedimientos necesarios para dar respuesta a las situaciones de crisis y para ello, hay metodologías cuyo uso es necesario y expertos en la materia, cuya participación es recomendable si se desea garantizar un cierto nivel de seguridad en la continuidad de los negocios. Implementar el plan de recuperación de desastres, auditarlo y probarlo periódicamente es la mejor manera de garantizarse la supervivencia ante las crisis no previstas.