- ¿Por qué se
necesita un Plan de Contingencia? - ¿Qué es un
desastre? - Metodología para el plan
de contingencia
¿Por
qué se necesita un Plan de
Contingencia?
A medida que las empresas se han
vuelto cada vez más dependientes de las computadoras y
las redes para
manejar sus actividades, la disponibilidad de los sistemas
informáticos se ha vuelto crucial. Actualmente, la
mayoría de las empresas
necesitan un nivel alto de disponibilidad y algunas requiren
incluso un nivel continuo de disponibilidad, ya que les
resultaría extremadamente difícil funcionar sin los
recursos
informáticos.
Los procedimientos
manuales, si
es que existen, sólo serían prácticos por un
corto periodo. En caso de un desastre, la interrupción
prolongada de los servicios de
computación puede llevar a pérdidas
financieras significativas, sobre todo si está implicada
la responsabilidad de la gerencia de
informática. Lo más grave es que se
puede perder la credibilidad del público o los los
clientes y,
como consecuencia, la empresa puede
terminar en un fracaso total.
Cabe preguntarse "¿Por se necesita un plan de
contingencia para desastres si existe una póliza de
seguro para
esta eventualidad?" La respuesta es que si bien el seguro puede
cubrir los costos materiales de
los activos de una
organización en caso de una calamidad, no
servirá para recuperar el negocio. No ayudará a
conservar a los clientes y, en la
mayoría de los casos, no proporcionará fondos por
adelantado para mantener funcionando el negocio hasta que se haya
recuperado.
En un estudio realizado por la Universidad de
Minnesota, se ha demostrado que más del 60% de las
empresas que sufren un desastre y que no tienen un plan de
recuperación ya en funcionamiento, saldrán del
negocio en dos o tres años. Mientras vaya en aumento la
dependencia de la disponibilidad de los recursos
informáticos, este porcentaje seguramente
crecerá.
Por lo tanto, la capacidad para recuperarse
éxitosamente de los efectos de un desastre dentro de un
periodo predeterminado debe ser un elemento crucial en un
plan
estratégico de seguridad para
una organización.
Imagínese una situación que interrumpa las
operaciones de
las computadoras
durante una semana o un mes; imagine la pérdida de todos
los datos de la
empresa, todas
las unidades de respaldo del sitio y la destrucción de
equipos vitales del sistema
¿Cómo se manejaría semejante
catástrofe? Si Ud. se ve en esta situación y lo
único que puede hacer es preguntarse "¿Y ahora
qué?" ¡ya es demasiado tarde! La única manera
efectiva de afrontar un desastre es tener una solución
completa y totalmente probada para recuperarse de los efectos del
mismo.
Se puede consider como un desastre la
interrupción prolongada de los recursos
informáticos y de comunicación de una organización,
que no puede remediarse dentro de un periodo predeterminado
aceptable y que necesita el uso de un sitio o equipo alterno para
su recuperación.
Ejemplos obvios son los grandes incendios, las
inundaciones, los terremotos,
las explosiones, los actos de sabotaje,
etcétera.
Estadísticas recientes sobre los tipos
más comunes de desastres que ocurren muestran que el
terrorismo,
los incendios y
los huracanes son las causas más comunes en muchos
países.
La alta gerencia tiene
que decidir el periodo predeterminado que lleva una
interrupción de servicio de la
situación de "problema" a la de "desastre". La
mayoría de las organizaciones
logran esto llevando a cabo un análisis de impacto en el negocio para
determinar el máximo tiempo de
interrupción permisible en funciones vitales
de sus actividades.
Plan de contingencia
La reanudación de las actividades ante una
calamidad puede ser una de las situaciones más
difíciles con las que una organización deba
enfrentarse. Tras un desastre, es probable que no haya
posibilidades de regresar al lugar de trabajo o que no se
disponga de ninguna de los recursos acostumbrados. Incluso, es
posible que no se pueda contar con todo el personal. La
preparación es la clave del éxito
para enfrentar los problemas.
No existe ninguna manera costeable para protegerse
completamente contra todo tipo de riesgos,
particularmente amenazas naturales a gran escala que pueden
arrasar zonas extensas. Como consecuencia, siempre se tiene que
tolerar algún riesgo residual.
La decisión sobre el alcance del desastre para el que
habrá de prepararse debe tomarse en los más altos
niveles de la empresa. Por
ejemplo, la mayor parte de las empresas implementan una estrategia que
proteja contra desastres locales, pero pocas cubren desastres a
nivel nacional o incluso internacional. Asimismo, las organizaciones
que cuentan dos o más sitios, pueden tener una estrategia de
recuperación que funcione en caso de que un sitio sea
destruido o dañado, pero no si varios sitios son
destruidos o dañados al mismo tiempo.
Un plan de contingencia es el proceso de
determinar qué hacer si una catástrofe se abate
sobre la empresa y es
necesario recuperar la red y los
sistemas.
Desdichadamente, un plan de contingencia es como el
ejercicio y la dieta: más fácil pensar en ello que
hacerlo. Con la cantidad de trabajo que la mayoría de los
gerentes tienen, el plan de contingencia tiende a dejarse para
una ocasión posterior. Uno de los problemas
asociados al plan de contingencia es saber por dónde
empezar.
Con mucho gusto le puedo ayudar a planificar,
diseñar e implementar una solución de
recuperación de desastre que cumpla con las necesidades de
su empresa tan solo escribame a
c.victor[arroba]cantv.net.
METODOLOGÍA PARA EL PLAN DE
CONTINGENCIA
El diseñar e implementar un plan de contingencia
para recuperación de desastres no es una tarea
fácil; puede implicar esfuerzos y gastos
considerables, sobre todo si se está partiendo de cero.
Una solución comprende las siguientes
actividades:
- Debe ser diseñada y elaborada de acuerdo con
las necesidades de la empresa. - Puede requerir la construcción o adaptación de un
sitio para los equipos computacionales. - Requerirá del desarrollo y
prueba de muchos procedimientos
nuevos, y éstos deben ser compatibles con las operaciones
existentes. Se hará participar a personal de
muchos departamentos diferentes, el cual debe trabajar en
conjunto cuando se desarrolle e implemente la
solución. - Implicará un compromiso entre costo,
velocidad de
recuperación, medida de la recuperación y alcance
de los desastres cubiertos. .
Como con cualquier proyecto de
diseño,
un método
estructurado ayuda a asegurar de que se toman en cuenta todos
estos factores y de que se les trata adecuadamente.
A continuación se muestran las principales
actividades requeridas para la planificación e implementación de
una capacidad de recuperación de desastres.
- Identificación de riesgos
- Evaluación de riesgos
- Asignación de prioridades a las
aplicaciones - Establecimiento de los requerimientos de
recuperación - Elaboración de la
documentación - Verificación e implementación del
plan - Distribución y mantenimiento del plan
1. Identificación de riesgos
La primera fase del plan de contingencia, el análisis de riesgos, nos
sitúa en el lugar de un asesor de una
compañía de seguros. En esta
fase, la preocupación está relacionada con tres
simples preguntas: ¿qué está bajo riesgo?,
¿qué puede ir mal? y ¿cuál es la
probabilidad
de que suceda?
1.1. ¿Qué está bajo
riesgo?
La primera de estas preguntas, ¿qué
está bajo riesgo?, necesita incorporar todos los
componentes del sistema
susceptibles de ser dañados, dando lugar a la
pérdida de conectividad, computadoras o datos. Un
diagrama de la
arquitectura
de todos los componentes del sistema facilitará la
realización de un inventario de los
elementos que pueden necesitar ser restituidos tras un desastre.
No hay que olvidar que también el software necesita ser
reemplazado, y que todos los productos
software
relevantes han de ser identificados. Esto incluye cosas como las
utilidades del sistema de archivos
empleados para facilitar las operaciones de red.
Un inventario
completo de una red muestra de manera
clara la complejidad de ésta. Cualquiera que realice
inventarios de
componentes para redes, comprende los
problemas en el seguimiento del hardware y software
utilizado por los usuarios finales. Afortunadamente, existen
algunos productos
disponibles, como los de las compañías Seagate
Software, McAfee y otros, que facilitan la construcción de un inventario de los
sistemas.
Una omisión en el inventario fácilmente
puede dar lugar a una recuperación fallida tras un
desastre. El sistema de aplicación puede no encontrarse
preparado para su uso si alguno de sus componentes no está
disponible; en tal caso, es aconsejable estar constantemente a la
expectativa de los nuevos elementos que pueden haberse olvidado.
Por ejemplo, una aplicación para acceso remoto no
funcionaría si los cables no están disponibles para
conectar los módem.
Uno de los aspectos menos agradables a tener en cuenta,
y que a menudo se pasa por alto, es que las personas esenciales
se vean afectadas por el desastre y sea necesario recurrir a
otras para realizar sus labores. Una formación
diversificada en los sistemas dentro de la
organización pude ayudar a reducir el impacto de la
indisponibilidad de uno de los colaboradores. Al menos, los
manuales de
las aplicaciones más importantes para la empresa
deberían encontrarse disponibles en un sitio
externo.
1.2. ¿Qué puede ir mal?
Lo más difícil en el plan de contingencia
es responder a la pregunta, ¿qué posiblemente pueda
ir mal? La respuesta a tal cuestión varía desde lo
evidente hasta lo casi increíble. La ley de Murphy nos
proporciona una colección de extraños e inesperados
desastres. Por ejemplo, las inundaciones son bastante frecuentes,
pero pocos podían haber predicho la inundación de
un sistema de túneles del metro en la ciudad de Chicago,
en 1992, provocada por la rotura de una tubería a
raíz de las obras de reparación de un
puente.
Las clases más obvias de desastres son los
desastres
naturales que conllevan tormentas de todo tipo o los
acontecimientos geológicos como terremotos o
volcanes. En cada
localidad existe la posibilidad de tener mal tiempo. En los
últimos años se han visto huracanes destrozar
instalaciones a lo largo Florida, islas del Caribe y el Golfo de
México.
Los tornados y vientos de elevadas velocidades han destruido
edificios cada año en el interior de los Estados Unidos y
Canadá.
Las inundaciones pueden acaecer en casi cualquier lugar
donde el drenaje existente no sea capaz de absorber el volumen de lluvia
o fango. Relacionado con las inundaciones se encuentra el
perjuicio producido por el agua. Cada
año los incendios en los edificios provocan importantes
daños a los sistemas informáticos debido al
agua, cuando
los sistemas automáticos de irrigación (sprinklers)
se activan para apagar el fuego.
Los propios incendios constituyen uno de los peores
desastres posibles. El calor, el humo
y el agua que
rodea a los incendios son tremendamente perjudiciales para los
sistemas informáticos. Los dispositivos de
almacenamiento se deterioran fácilmente debido a las
altas temperaturas y el humo. La eliminación de los
residuos tóxicos tras el incendio de una oficina puede
llevar meses, incluso años. En los Estados Unidos,
la agencia de protección ambiental (EPA), en ocasiones, ha
tenido que cerrar edificios después de un incendio debido
a la alta concentración de toxinas encontradas en el
mismo. Esto implica que puede no ser posible disponer de lo
sistemas y datos hasta bastante tiempo después del
incendio. Existen compañía especializadas en
preparar operaciones específicas de limpieza de
instalaciones víctimas del incendio, que darán su
aprobación para enviar especialistas con trajes
protectores al edificio incendiado, recuperar el equipo de
procesamiento de
datos e intentar restaurar la información de los discos.
Deben considerarse mecanismos alternativos de acceso a
la red en el caso de que, por alguna razón, sea imposible
acceder al edificio, incluso aunque el edificio puede estar en
pie y operacional. Ejemplos de sucesos que pueden impedir e
acceso al interior del edificio son los accidentes
químicos e industriales, así como los motines y
disturbios callejeros.
El fuego no tiene por qué darse necesariamente en
la propia instalación para que el problema sea devastador.
Un incendio destruyó la oficina central
dc Ameritech, en Hinsdale, Illinois, en mayo de 1988, dejando a
numerosos clientes sin servicio
telefónico durante meses mientras la
compañía reparaba la edificación
dañada. Obviamente, las comunicaciones
que empleaban las líneas telefónicas que
habían sido enrutadas a través de esta
instalación, se vieron seriamente afectadas.
Desgraciadamente, los ataques terroristas y otros actos
deliberados de destrucción cometidos por personas pueden
devastar sistemas e instalaciones. Este incluye actos violentos
(por ejemplo, descargar armas sobre los
equipos informáticos). Menos excitante, pero igual de
perjudicial para la
organización, es la pérdida de equipos debido
al robo. Existen también ataques a los datos contra los
que hay que estar prevenidos, en los que la gente destruye
intencionadamente datos mediante su borrado o
inutilizándolos. Los virus se
encuentran en este campo.
Los errores humanos son una de las causas más
probables de la pérdida o deterioro de los datos. Si un
error de este tipo provoca la pérdida de un sistema en la
red, tiene el mismo efecto que cualquier otro tipo de desastre, y
como tal debe ser tratado.
1.3. ¿Cuál es la probabilidad de
que suceda?
Si se tuviera una cantidad ilimitada de recursos y fuera
posible protegerse contra todas las calamidades, esta pregunta
carecería de interés.
Sin embargo, no se dispone de recursos infinitos; de hecho, los
recursos son bastante escasos. Por lo tanto, se deben seleccionar
los tipos de desastres contra los que uno intentará
protegerse. Obviamente, estos preciados recursos se
querrán gastar en aquellos desastres que tengan la mayor
probabilidad de afectar a la organización.
Por ejemplo, se podría intentar proteger los
sistemas de la improbable ocurrencia de la caída sobre el
edifico de un meteorito procedente del espacio exterior. Esto no
sería tan valioso como proteger los sistemas de las
inundaciones.
Responder a la pregunta: ¿cuál es la
probabilidad de que suceda? también requiere de ciertas
consideraciones presupuestarias. Ello puede ayudar a asumir
distintos escenarios de presupuesto para
comprender cuáles son los costos de
compromiso para diferentes niveles de protección y
preparación. Finalmente, se puede estar expuesto a ciertas
amenazas cuya protección no está al alcance del
presupuesto,
pero, al menos, se es consciente de su existencia y, por lo
tanto, es posible mejorar el plan en un futuro.
2. Evaluación
de riesgos
Es el proceso de
determinar el costo para la
organización de sufrir un desastre que afecte su
actividad. Si una inundación impidiera la actividad
comercial durante cinco días, la compañía
perdería cinco días de ventas,
además del deterioro físico de los edificios e
inventario. En el caso de los sistemas informáticos, la
preocupación principal es comprender la cantidad de
pérdida financiera que puede provocar la
interrupción de los servicios,
incluyendo los que se basan en las redes.
Por ejemplo, si la empresa se anuncia a través o
realiza negocios en
Internet,
¿cuál es el costo de tener el servidor web inhabilitado?
Si la red a través de la cual se produce la solicitud de
pedidos está caída, o si el sistema de control de
inventario utiliza la red, ¿cuál es el impacto
sobre la productividad de
la empresa?
Los costos de un desastre pueden clasificarse en las
siguientes categorías:
- Costos reales de reemplazar el sistema
informático - Costos por falta de producción.
- Costos por negocio perdido
- Costos de reputación.
El costo real de los equipos y el software es
fácil de calcular, y depende de si se dispone de un buen
inventario de todos los componentes de la red
necesarios.
Los costos de
producción pueden determinarse midiendo la producción generada asociada a la red. La
empresa tiene una correcta valoración de la cantidad de
trabajo realizado diariamente y su valor
relativo. La pérdida de producción, debida a la
interrupción de la red, puede ser calculados utilizando
esta información.
Los costos por negocio perdido son los ingresos perdidos
por las organizaciones de ventas y
marketing
cuando la red no está disponible. Si el sistema de
solicitud de pedidos no funciona y la empresa sólo es
capaz de procesar el 25% del volumen diario
habitual de ventas, entonces se ha perdido el 75% de ese volumen
de ventas.
Los costos de reputación son más
difíciles de evaluar y, sin embargo, es conveniente
incluirlos en la evaluación. Estos costos se producen cuando
los clientes pierden la confianza en la empresa y se llevan su
negocio a otro sitio. Los costos de reputación crecen
cuando los retardos en el servicio a los clientes son más
prolongados o frecuentes.
3. Asignación de prioridades en las
aplicaciones
Después de que acontezca un desastre y se inicie
la recuperación de los sistemas, debe conocerse qué
aplicaciones recuperar en primer lugar. No hay que perder el
tiempo restaurando los datos y sistemas equivocados cuando la
actividad empresarial necesita primero sus aplicaciones
esenciales.
Esto implica la necesidad de determinar por anticipado
cuáles son las aplicaciones fundamentales del negocio. Si
la empresa es como la mayoría, se tendrán
aplicaciones "muy importantes" dependiendo de a quién se
le pregunte. El departamento de recursos
humanos afirmará que el sistema de nóminas es
el más importante, el departamento de ventas dirá
que es su sistema de entrada de pedidos, el departamento de
producción insistirá en su control de
inventario y el departamento de compras
asignará el papel de
más importante a su sistema de facturación.
Desgraciadamente, no todos estos sistemas pueden ser el
más importante; por lo tanto, es fundamental que la
dirección ayude a determinar el orden en
que los sistemas serán recuperados.
Es de esperar que esta información sea aceptada
de buen grado por todos los jefes de departamento.
Independientemente de ello, el plan de contingencia
debería incluir la lista de los sistemas y su prioridad.
Esta sección del plan debería ser firmada por la
dirección para minimizar las
desavenencias.
Una vez conocido lo que se va a restaurar,
debería disponerse de todo lo necesario para la
disponibilidad de tales aplicaciones. Un sistema de
aplicación en una red está
compuesto por los sistemas servidores, donde
las aplicaciones almacenan sus datos, los sistemas de estaciones
de trabajo que los procesan, las impresoras o
fax empleados
para entrada/salida, la red que interconecta todo, y el software
de las aplicaciones. Las aplicaciones cliente/servidor o
distribuidas añaden un nivel extra de complejidad al
requerir que distintas partes de la aplicación residan en
máquinas separadas.
Puede caerse en la tentación de construir una
infraestructura superior a la necesaria para la aplicaciones de
mayor prioridad. Por ejemplo, si actualmente la red tiene 50
estaciones de trabajo, se puede comenzar a trabajar
inmediatamente en la reconstrucción de las 50 estaciones
de trabajo. Sin embargo, si las aplicaciones más
prioritarias sólo necesitan cinco estaciones de trabajo,
se debería detener la reconstrucción de las
estaciones de trabajo una vez alcanzado el número de cinco
y concentrar los esfuerzos en lograr que la aplicación
funcione. Es mucho mejor intentar lograr que un sistema
pequeño funcione, que no uno más grande, y de esta
manera se ahorrará gran cantidad de tiempo en el proceso.
De hecho, cuando se está asignando las prioridades a las
aplicaciones junto con la dirección, también es
posible beneficiarse de la determinación del número
mínimo de estaciones de trabajo necesarias para tener el
sistema accesible. El tamaño de la red siempre puede
incrementarse a posteriori una vez el sistema esté en
funcionamiento.
Una de las ventajas del enfoque basado en el sistema de
aplicaciones es la cantidad de tiempo necesaria para recuperar
una aplicación comparada con la cantidad de tiempo
requerida para restaurar un servidor en su totalidad. Si la
aplicación tiene sólo 500 MB de datos y el servidor
4 GB, es obvio que se ahorra una gran cantidad de tiempo
recuperando únicamente la aplicación.
Sin embargo este enfoque requiere un conocimiento
algo más detallado sobre los sistemas que actualmente se
tienen. En primer lugar, es necesario saber dónde se
encuentra toda la información que emplean las aplicaciones
y qué dependencias entre sistemas de archivos pueden
existir. Si existen archivos del sistema que contienen
información sobre la aplicación, como es el caso de
los archivos .ini de Windows, es
necesario asegurarse de que esos archivos también se
recuperan junto a la aplicación. En segundo lugar, es
preciso conocer cómo funciona el sistema de copias de
seguridad para
realizar este tipo de recuperación selectiva. Aunque esto
no supone necesariamente una dificultad, no obstante esta
operación debería ser familiar.
4. Establecimiento de requisitos de
recuperación
La clave de esta fase del proceso de elaboración
del plan de migración
es definir un periodo de tiempo aceptable y viable para lograr
que la red esté de nuevo activa. Tal y como se ha
planteado en la sección anterior, la preocupación
básica debería ser disponer de las aplicaciones
más importantes en primer lugar. El personal directivo de
la organización deseará saber cuándo
estarán sus aplicaciones funcionado para planificar la
actividades de la compañía.
Es muy importante concederse una cantidad de tiempo
adecuada y no realizar estimaciones poco realistas sobre las
propias posibilidades. No es el deseo de nadie tener a un
montón de gente alrededor esperando la finalización
de las operaciones de recuperación; una distracción
de este tipo probablemente perturbe las labores. El
término para este tiempo es tiempo de recuperación
objetivo o en
inglés
TRO (Recovery Time Objective). El TRO definido debe ser
verificado para comprobar que es realista y factible, no
sólo por uno mismo, sino por el resto de la
organización, que puede ser requerido para realizar
el
trabajo.
La dirección de la empresa debería
colaborar íntimamente con el personal de administración de redes para determinar el
TRO de las aplicaciones. Aplicaciones diferentes tendrán
TRO diferentes.
Es necesario asegurarse de que se dispone de tiempo para
recuperar las cintas localizadas en la instalación de
almacenamiento
exterior y para adquirir los sistemas necesarios. Por cierto,
debería conocerse por anticipado cómo realizar las
órdenes de compra de los equipos cuando la empresa se
encuentra en un estado de
total desorganización.
Es posible que sea necesario actualizar el sistema de
copias de seguridad para satisfacer el TRO. Un sistema de cinta
que recupera datos a 2 MB por segundo realizará la labor
mucho más rápido que uno que lo ejecute a 500 KB
por segundo. Hay que ser precavido y no suponer que se pueden
hacer muchas cosas al mismo tiempo; uno se puede encontrar
cometiendo desafortunados errores que frenan la labor si no se
presta atención al trabajo que se tiene entre
manos.
5. Elaboración de la
documentación
Crear un documento que mucha gente pueda tener como
referencia es quizás lo más difícil del plan
de contingencia. No hay que engañarse: implicará un
esfuerzo significativo para algunas personas, pero ayudará
a aprender cosas sobre el sistema y puede que algún
día salve la empresa.
Los recursos necesarios para escribir y mantener un plan
de contingencia representan más de lo que puede realizarse
en ratos libres y después de horas de oficina. La
dirección de la organización debe apoyar la
iniciativa para que sea un éxito.
Uno de los problemas del plan de contingencia en un entorno de
comunicaciones
es que la tecnología de redes
cambia tan rápidamente que resulta difícil
permanecer al día. Esto incluye nuevos dispositivos,
así como nuevos sistemas de aplicación que
introducen su propio nivel de complejidad en este campo. Como
ejemplo, considérese la recuperación de un gran
sistema de base de datos
relacional Unix. Este tipo
de trabajo requiere un conocimiento
mucho más complejo del que corresponde a la
instalación de la base de datos y
del que un administrador de
redes es probable que tenga; generalmente es necesario un
administrador
de base de datos, para el que también la labor será
un desafío.
Dado el hecho de que la tecnología de red
evoluciona tan rápidamente, debería planificarse la
actualización del plan de contingencia
periódicamente, por ejemplo una vez al año. Aunque
la redacción del plan inicial supondrá
una gran cantidad de trabajo, una vez que se dispone del plan,
las actualizaciones son relativamente fáciles.
5.1. Contenido del plan de
contingencia
El plan de contingencia debe intentar definir las cinco
áreas siguientes:
- Listas de notificación, números de
teléfono, mapas y
direcciones - Prioridades, responsabilidades, relaciones y
procedimientos - Información sobre adquisiciones y
compras - Diagramas de las instalaciones
- Sistemas, configuraciones y copias de seguridad en
cinta
Hay que cerciorarse de que se sabe a quién
notificar en primer lugar cuándo ocurre un desastre. Por
ejemplo, si hay un incendio, llamar primero a los bomberos y
luego al director general. Pueden existir otras personas o
organizaciones identificadas con características o conocimientos especiales
que puedan ayudar a minimizar el daño. Si no se dispone de
números de teléfono o direcciones actualizados, se
puede pasar muy mal contactando con las personas
afectadas.
Mapas mostrando
las ubicaciones del centro de operaciones temporal y la
instalación externa pueden ahorrar mucho tiempo.
También puede ser útil mostrar itinerarios
alternativos de acceso para el caso de que las rutas principales
no se encuentren disponibles.
Cuando en primer lugar se comienza a reflexionar sobre
cómo responder a un desastre, hay que centrarse en las
prioridades establecidas. El tiempo pasa; el trabajo
debe empezar por recuperar inmediatamente las aplicaciones de
mayor prioridad. Las personas deberían disponer de
instrucciones y responsabilidades precisas. La relación
entre tareas debería hallarse documentada de manera que
pueda identificarse cualquier cuello de botella que pudiera
surgir. Por último, deberían incluirse, de manera
detallada, las operaciones y tareas que muestren las labores de
instalación y recuperación necesarias, debiendo ser
fáciles de leer y seguir. También habría que
incluir aquí los números de teléfono de las
organizaciones de asistencia que pudieran requerirse.
Como se ha mencionado anteriormente, debe saberse
cómo expedir una solicitud de compra y obtener los equipos
para el centro de operaciones temporal. Esto significa
proporcionar a los vendedores la dirección y cualquier
instrucción necesaria para el transporte. No
hay que suponer que todos los vendedores del mundo van a
enterarse de la difícil situación y venir a nuestro
rescate. Es aconsejable disponer de copias de las facturas,
recibos y demás para mostrarlos como prueba de compra.
También viene bien tener a mano una lista de 1os
números de serie de los equipos hardware. No hay que olvidar
que, actualmente, gran parte de los productos para el mercado de
comunicaciones de LANs se vende a través de grandes
sistemas de distribución, y que los fabricantes y
desarrolladores de software de los productos utilizados puede que
no tengan ni idea de quién es su cliente. No
espere recibir los repuestos de manera gratuita; en su lugar,
debería ser capaz de llegar a acuerdos especiales de
compra y provisión para sustituir los bienes
perdidos.
Los diagramas de red
simplifican cu gran medida la labor de construir una red. Un
diagrama
detallado de la red, necesaria para las primeras aplicaciones,
facilita y agiliza la reanudación de las actividades. La
asignación de etiquetas a los cables y su almacenamiento en
un lugar reservado, probablemente no llevará mucho tiempo
y evitará muchas confusiones con posterioridad. La otra
ventaja de un diagrama de conexiones es la posibilidad de emplear
contratistas para realizar las instalaciones. Alguien
experimentado en la instalación del cableado y otros
dispositivos de red, y que se dedica a ello, puede ser capaz de
realizarlo mejor y más eficientemente que uno
mismo.
Es posible ahorrarse horas o incluso días en el
proceso de recuperación si existe la posibilidad de
almacenar algunos sistemas de repuesto con la capacidad de
gestionar tareas diferentes. Planifíquese instalar una
configuración genérica que, como mínimo,
permita ejecutar las aplicaciones de mayor prioridad sin
problemas. Si se desconoce los productos que la gente tiene en
sus PC, un producto para
inventario de LAN puede
ayudar en la recopilación de esta información.
Después de que la red alternativa se encuentre
funcionando, y se disponga de un momento de respiro, será
posible restaurar los PC con sus configuraciones anteriores
utilizando la información de configuración
extraída de los informes de
inventario.
Hay que asegurarse la disponibilidad de un sistema de
copias de seguridad de cinta en funcionamiento. Si es posible,
debe mantenerse un sistema de reserva, incluyendo adaptadores
SCSI, cables y software de unidades de dispositivo, en un sitio
alterno. No es inusual encontrarse con que los vendedores locales
no disponen de existencias de los productos necesarios,
obligando, por tanto, a esperar el envío de los repuestos
antes de poder empezar
la recuperación de los datos. Si se sigue este consejo, no
hay que olvidar actualizar este sistema cuando se actualicen los
sistemas de copias de seguridad de producción; en caso
contrario, uno se puede encontrar con formatos de cinta o
bases de datos
incompatibles u otros problemas que impedirán la
restauración de la información.
6. Verificación e implementación del
plan
Una vez redactado el plan, hay que probarlo. Hay que
estar seguro de que el plan va a funcionar. Para ello, se debe
ser escéptico sobre el propio trabajo, de manera que pueda
uno probarse a sí mismo que funciona.
Psicológicamente, esto no es fácil porque con toda
probabilidad se ha invertido una gran cantidad de tiempo y
energía personal en este proceso, aunque lo mejor
sería, si es posible, situarse de manera imparcial ante la
confiabilidad del plan. Por consiguiente, han de realizarse las
pruebas para
encontrar problemas, no para verificar que el plan funciona. Si
existen errores en la información, tómese nota de
ellos y corríjase el plan.
6.1. Comprobación del plan por
partes
No se puede tumbar el sistema algún día
para ver si se es capaz de recuperarlo. Existen muchas y mejores
formas de verificar un plan de contingencia sin causar mayores
interrupciones en el trabajo de la organización. Algunas
de las cosas en las que habitualmente no se piensa a la hora de
comprobar pueden ahorrar mucho tiempo posteriormente. Por
ejemplo, llamar a los números telefónicos de los
colaboradores incluidos en la listas telefónicas del plan
para confirmar si son actuales; llamar a los vendedores y
comprobar si disponen de existencias de productos, ya que puede
que hayan modificado su política de
inventario. Algún día, viajar hasta la
instalación alterna para saber dónde está y
cómo reconocer el edificio.
Por supuesto, también es necesario verificar los
procedimientos que se emplearán para recuperar los datos.
Compruébese el software para la realización de las
copias de seguridad para confirmar si pueden recuperarse las
aplicaciones de mayor prioridad de la manera esperada. Esto
debería hacerse en una red aislada para evitar problemas
con el servidor de licencias. Por ejemplo, si la idea es unificar
dos servidores
mediante la recuperación completa de uno de ellos en el
servidor de repuesto y a continuación restaurar
sólo los archivos de datos de usuario procedentes del
otro, finalmente se tendrá dos servidores con la misma
licencia de software de servidor en la red, lo que podría
dar lugar a la difusión por toda la red de mensajes de
aviso sobre la licencia. Incluso aunque se utilice una nueva
licencia de sistema operativo
de red, todavía existen otros conflictos
como nombres de servidores duplicados y cualquier otro problema
de duplicación que podría causar problemas en los
sistemas de
producción.
Una vez recuperada la información,
verifíquese si el usuario puede acceder a ella. Esto
requiere de algunas estaciones de trabajo conectadas a la red
para simular auténticos usuarios finales con cuentas en los
servidos originales. En este punto, puede ser necesario
actualizar el plan para incluir información sobre el
establecimiento de cuentas de
usuario. Compruébese cada una de las operaciones del plan
individualmente y examínese entonces si, como resultado,
se tiene un sistema de red en funcionamiento. No está de
más verificar el plan con otras personas de la
organización que se encuentren tan familiarizadas con los
productos o procedimientos empleados.
Revísese cada día la parte del plan
relacionada con las operaciones de copias de seguridad
verificando la finalización correcta de las mismas.
Además, supervise esto asegurándose de que algunas
personas de la organización saben realizar copias de
seguridad adecuadamente, y comprobar su
finalización.
7. Distribución y mantenimiento
del plan
Por último, cuando se disponga de un plan
definitiva ya verificado, es necesario distribuirlo a las
personas que necesitan tenerlo. Inténtese controlar las
versiones del plan, de manera que no exista confusión con
múltiples versiones. Así mismo, es necesario
asegurar la disponibilidad de copias extra del plan para su
depósito en la instalación exterior a en cualquier
otro lugar además del lugar de trabajo. Manténgase
una lista de todas las personas y ubicaciones que tienen una
copia del plan. Cuando se actualice el plan, sustituya todas las
copias y recoja las versiones previas.
El mantenimiento del plan es un proceso sencillo. Se
comienza con una revisión del plan existente y se examina
en su totalidad, realizando cambios a cualquier
información que pueda haber variado. En ese instante, se
debe volver a evaluar los sistemas de aplicación y
determinar cuáles son los más importantes para la
organización. Las modificaciones a esta parte del plan
causarán modificaciones consecutivas a los procedimientos
de recuperación. Sin embargo, esto no debería verse
como un problema porque probablemente la sección de
procedimientos tenga que actualizarse de todas formas debido a
otros cambios. Si se han realizado modificaciones al sistema de
copias de seguridad, hay que cerciorarse de incluir la
información sobre el funcionamiento del nuevo o
actualizado sistema.
Este proceso llevará tiempo, pero posee algunos
valiosos beneficios que se percibirán aunque nunca tengan
que utilizarse. Más gente conocerá la red. Esto
proporcionará a la organización una base
técnica más amplia para mantener correctamente la
red. También facilitará el crecimiento de una
perspectiva global sobre la red dentro del núcleo de
administradores de sistemas de
información y puede ayudar a identificar las futuras o
actuales áreas conflictivas. Uno de los aspectos
más difíciles en cualquier labor distribuida, como
es la gestión
y administración de LAN, es dar a
conocer la situación actual. El mantenimiento y
verificación de un plan de migración
ayudará a que se produzca dicha comunicación dentro de la
organización.
Prepararada por:
Victor Cappuccio