Por qu se necesita un Plan de Contingencia?

A medida que las empresas se han vuelto cada vez ms dependientes de

las computadoras y las redes para manejar sus actividades, la disponibilidad
de los sistemas informticos se ha vuelto crucial. Actualmente, la mayora
de las empresas necesitan un nivel alto de disponibilidad y algunas requiren
incluso un nivel continuo de disponibilidad, ya que les resultara
extremadamente difcil funcionar sin los recursos informticos.
Los procedimientos manuales, si es que existen, slo seran prcticos por un
corto periodo. En caso de un desastre, la interrupcin prolongada de
los servicios de computacin puede llevar a prdidas financieras
significativas, sobre todo si est implicada la responsabilidad de
la gerencia de informtica. Lo ms grave es que se puede perder la
credibilidad del pblico 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 pliza de seguro para esta eventualidad?" La respuesta es que
si bien el seguro puede cubrir los costos materiales de los activos de
una organizacin en caso de una calamidad, no servir para recuperar el
negocio. No ayudar a conservar a los clientes y, en la mayora 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 ms del 60% de las empresas que sufren un desastre y que no tienen
un plan de recuperacin ya en funcionamiento, saldrn del negocio en dos o
tres aos. Mientras vaya en aumento la dependencia de la disponibilidad de
los recursos informticos, 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 estratgico de seguridad para una organizacin.
Imagnese una situacin que interrumpa las operaciones de las
computadoras durante una semana o un mes; imagine la prdida de todos
los datos de la empresa, todas las unidades de respaldo del sitio y la
destruccin de equipos vitales del sistema Cmo se manejara semejante
catstrofe? Si Ud. se ve en esta situacin 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 solucin completa y
totalmente probada para recuperarse de los efectos del mismo.
Qu es un desastre?
Se puede consider como un desastre la interrupcin prolongada de los
recursos informticos y de comunicacin de una organizacin, que no puede
remediarse dentro de un periodo predeterminado aceptable y que necesita
el uso de un sitio o equipo alterno para su recuperacin.

Ejemplos obvios son los grandes incendios, las inundaciones, los terremotos,
las explosiones, los actos de sabotaje, etctera.
Estadsticas recientes sobre los tipos ms comunes de desastres que
ocurren muestran que el terrorismo, los incendios y los huracanes son las
causas ms comunes en muchos pases.

La alta gerencia tiene que decidir el periodo predeterminado que lleva una
interrupcin de servicio de la situacin de "problema" a la de "desastre". La
mayora de las organizaciones logran esto llevando a cabo un anlisis de
impacto en el negocio para determinar el mximo tiempo de interrupcin
permisible en funciones vitales de sus actividades.
Plan de contingencia
La reanudacin de las actividades ante una calamidad puede ser una de las
situaciones ms difciles con las que una organizacin 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
preparacin 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 algn riesgo residual. La decisin sobre el alcance del desastre para
el que habr de prepararse debe tomarse en los ms 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 ms sitios, pueden tener una estrategia
de recuperacin que funcione en caso de que un sitio sea destruido o
daado, pero no si varios sitios son destruidos o daados al mismo tiempo.
Un plan de contingencia es el proceso de determinar qu hacer si una
catstrofe 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:
ms fcil pensar en ello que hacerlo. Con la cantidad de trabajo que la

mayora de los gerentes tienen, el plan de contingencia tiende a dejarse

para una ocasin posterior. Uno de los problemas asociados al plan de
contingencia es saber por dnde empezar.
Con mucho gusto le puedo ayudar a planificar, disear e implementar una
solucin de recuperacin de desastre que cumpla con las necesidades de su
empresa tan solo escribame a c.victor[arroba]cantv.net.
METODOLOGA PARA EL PLAN DE CONTINGENCIA
El disear e implementar un plan de contingencia para recuperacin de
desastres no es una tarea fcil; puede implicar esfuerzos
y gastos considerables, sobre todo si se est partiendo de cero. Una
solucin comprende las siguientes actividades:
1. Debe ser diseada y elaborada de acuerdo con las necesidades de la
empresa.
2. Puede requerir la construccin o adaptacin de un sitio para los
equipos computacionales.
3. 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
solucin.
4. Implicar un compromiso entre costo, velocidad de recuperacin,
medida de la recuperacin y alcance de los desastres cubiertos. .
Como con cualquier proyecto de diseo, un mtodo estructurado ayuda a
asegurar de que se toman en cuenta todos estos factores y de que se les
trata adecuadamente.
A continuacin se muestran las principales actividades requeridas para
la planificacin e implementacin de una capacidad de recuperacin de
desastres.
1. Identificacin de riesgos
2. Evaluacin de riesgos
3. Asignacin de prioridades a las aplicaciones
4. Establecimiento de los requerimientos de recuperacin
5. Elaboracin de la documentacin
6. Verificacin e implementacin del plan
7. Distribucin y mantenimiento del plan
1. Identificacin de riesgos

La primera fase del plan de contingencia, el anlisis de riesgos, nos sita en

el lugar de un asesor de una compaa de seguros. En esta fase, la
preocupacin est relacionada con tres simples preguntas: qu est bajo
riesgo?, qu puede ir mal? y cul 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 daados, dando
lugar a la prdida de conectividad, computadoras o datos. Un diagrama de
la arquitectura de todos los componentes del sistema facilitar la realizacin
de un inventario de los elementos que pueden necesitar ser restituidos tras
un desastre. No hay que olvidar que tambin el softwarenecesita 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 compaas Seagate Software, McAfee
y otros, que facilitan la construccin de un inventario de los sistemas.
Una omisin en el inventario fcilmente puede dar lugar a una recuperacin
fallida tras un desastre. El sistema de aplicacin 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
aplicacin para acceso remoto no funcionara si los cables no estn
disponibles para conectar los mdem.
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
formacin diversificada en los sistemas dentro de la organizacin pude
ayudar a reducir el impacto de la indisponibilidad de uno de los
colaboradores. Al menos, los manuales de las aplicaciones ms importantes
para la empresa deberan encontrarse disponibles en un sitio externo.
1.2. Qu puede ir mal?
Lo ms difcil en el plan de contingencia es responder a la pregunta, qu
posiblemente pueda ir mal? La respuesta a tal cuestin vara desde lo
evidente hasta lo casi increble. La ley de Murphy nos proporciona una
coleccin de extraos e inesperados desastres. Por ejemplo, las
inundaciones son bastante frecuentes, pero pocos podan haber predicho la
inundacin de un sistema de tneles del metro en la ciudad de Chicago, en
1992, provocada por la rotura de una tubera a raz de las obras de
reparacin de un puente.

Las clases ms obvias de desastres son los desastres naturales que

conllevan tormentas de todo tipo o los acontecimientos geolgicos como
terremotos o volcanes. En cada localidad existe la posibilidad de tener mal
tiempo. En los ltimos aos se han visto huracanes destrozar instalaciones a
lo largo Florida, islas del Caribe y el Golfo de Mxico. Los tornados y vientos
de elevadas velocidades han destruido edificios cada ao 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 ao los incendios en los edificios provocan importantes daos a
los sistemas informticos debido al agua, cuando los sistemas automticos
de irrigacin (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 informticos. Los dispositivos
de almacenamiento se deterioran fcilmente debido a las altas
temperaturas y el humo. La eliminacin de los residuos txicos tras el
incendio de una oficina puede llevar meses, incluso aos. En los Estados
Unidos, la agencia de proteccin ambiental (EPA), en ocasiones, ha tenido
que cerrar edificios despus de un incendio debido a la alta concentracin
de toxinas encontradas en el mismo. Esto implica que puede no ser posible
disponer de lo sistemas y datos hasta bastante tiempo despus del
incendio. Existen compaa especializadas en preparar operaciones
especficas de limpieza de instalaciones vctimas del incendio, que darn su
aprobacin para enviar especialistas con trajes protectores al edificio
incendiado, recuperar el equipo de procesamiento de datos e intentar
restaurar la informacin de los discos.
Deben considerarse mecanismos alternativos de acceso a la red en el caso
de que, por alguna razn, 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 qumicos
e industriales, as como los motines y disturbios callejeros.
El fuego no tiene por qu darse necesariamente en la propia instalacin
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 telefnico durante meses mientras la compaa
reparaba la edificacin daada. Obviamente, las comunicaciones que
empleaban las lneas telefnicas que haban sido enrutadas a travs de esta
instalacin, se vieron seriamente afectadas.
Desgraciadamente, los ataques terroristas y otros actos deliberados de
destruccin cometidos por personas pueden devastar sistemas e
instalaciones. Este incluye actos violentos (por ejemplo,
descargar armas sobre los equipos informticos). Menos excitante, pero

igual de perjudicial para la organizacin, es la prdida de equipos debido al

robo. Existen tambin ataques a los datos contra los que hay que estar
prevenidos, en los que la gente destruye intencionadamente datos
mediante su borrado o inutilizndolos. Los virus se encuentran en este
campo.
Los errores humanos son una de las causas ms probables de la prdida o
deterioro de los datos. Si un error de este tipo provoca la prdida de un
sistema en la red, tiene el mismo efecto que cualquier otro tipo de desastre,
y como tal debe ser tratado.
1.3. Cul es la probabilidad de que suceda?
Si se tuviera una cantidad ilimitada de recursos y fuera posible protegerse
contra todas las calamidades, esta pregunta carecera de inters. 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 querrn gastar en aquellos desastres que tengan la mayor
probabilidad de afectar a la organizacin.
Por ejemplo, se podra intentar proteger los sistemas de la improbable
ocurrencia de la cada sobre el edifico de un meteorito procedente del
espacio exterior. Esto no sera tan valioso como proteger los sistemas de las
inundaciones.
Responder a la pregunta: cul es la probabilidad de que suceda? tambin
requiere de ciertas consideraciones presupuestarias. Ello puede ayudar a
asumir distintos escenarios de presupuesto para comprender cules son los
costos de compromiso para diferentes niveles de proteccin y preparacin.
Finalmente, se puede estar expuesto a ciertas amenazas cuya proteccin 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. Evaluacin de riesgos
Es el proceso de determinar el costo para la organizacin de sufrir un
desastre que afecte su actividad. Si una inundacin impidiera la actividad
comercial durante cinco das, la compaa perdera cinco das de ventas,
adems del deterioro fsico de los edificios e inventario. En el caso de los
sistemas informticos, la preocupacin principal es comprender la cantidad
de prdida financiera que puede provocar la interrupcin de los servicios,
incluyendo los que se basan en las redes.
Por ejemplo, si la empresa se anuncia a travs o
realiza negocios en Internet, cul es el costo de tener
el servidor web inhabilitado? Si la red a travs de la cual se produce la
solicitud de pedidos est cada, o si el sistema de control de inventario
utiliza la red, cul es el impacto sobre la productividad de la empresa?

Los costos de un desastre pueden clasificarse en las siguientes categoras:

Costos reales de reemplazar el sistema informtico

Costos por falta de produccin.

Costos por negocio perdido

Costos de reputacin.

El costo real de los equipos y el software es fcil de calcular, y depende de

si se dispone de un buen inventario de todos los componentes de la red
necesarios.
Los costos de produccin pueden determinarse midiendo la produccin
generada asociada a la red. La empresa tiene una correcta valoracin de la
cantidad de trabajo realizado diariamente y su valor relativo. La prdida de
produccin, debida a la interrupcin de la red, puede ser calculados
utilizando esta informacin.
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 slo 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 reputacin son ms difciles de evaluar y, sin embargo, es
conveniente incluirlos en la evaluacin. Estos costos se producen cuando los
clientes pierden la confianza en la empresa y se llevan su negocio a otro
sitio. Los costos de reputacin crecen cuando los retardos en el servicio a los
clientes son ms prolongados o frecuentes.
3. Asignacin de prioridades en las aplicaciones
Despus de que acontezca un desastre y se inicie la recuperacin 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 cules son las
aplicaciones fundamentales del negocio. Si la empresa es como la mayora,
se tendrn aplicaciones "muy importantes" dependiendo de a quin se le
pregunte. El departamento de recursos humanos afirmar que el sistema
de nminas es el ms importante, el departamento de ventas dir que es su
sistema de entrada de pedidos, el departamento de produccin insistir en
su control de inventario y el departamento de compras asignar el papel de
ms importante a su sistema de facturacin. Desgraciadamente, no todos
estos sistemas pueden ser el ms importante; por lo tanto, es fundamental
que la direccin ayude a determinar el orden en que los sistemas sern
recuperados.

Es de esperar que esta informacin sea aceptada de buen grado por todos
los jefes de departamento. Independientemente de ello, el plan de
contingencia debera incluir la lista de los sistemas y su prioridad. Esta
seccin del plan debera ser firmada por la direccin para minimizar las
desavenencias.
Una vez conocido lo que se va a restaurar, debera disponerse de todo lo
necesario para la disponibilidad de tales aplicaciones. Un sistema de
aplicacin 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 aaden un nivel extra de
complejidad al requerir que distintas partes de la aplicacin residan
en mquinas separadas.
Puede caerse en la tentacin 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 reconstruccin de las 50 estaciones de
trabajo. Sin embargo, si las aplicaciones ms prioritarias slo necesitan
cinco estaciones de trabajo, se debera detener la reconstruccin de las
estaciones de trabajo una vez alcanzado el nmero de cinco y concentrar
los esfuerzos en lograr que la aplicacin funcione. Es mucho mejor intentar
lograr que un sistema pequeo funcione, que no uno ms 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
direccin, tambin es posible beneficiarse de la determinacin del nmero
mnimo de estaciones de trabajo necesarias para tener el sistema accesible.
El tamao 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 aplicacin comparada con
la cantidad de tiempo requerida para restaurar un servidor en su totalidad.
Si la aplicacin tiene slo 500 MB de datos y el servidor 4 GB, es obvio que
se ahorra una gran cantidad de tiempo recuperando nicamente la
aplicacin.
Sin embargo este enfoque requiere un conocimiento algo ms detallado
sobre los sistemas que actualmente se tienen. En primer lugar, es necesario
saber dnde se encuentra toda la informacin que emplean las aplicaciones
y qu dependencias entre sistemas de archivos pueden existir. Si existen
archivos del sistema que contienen informacin sobre la aplicacin, como es
el caso de los archivos .ini de Windows, es necesario asegurarse de que
esos archivos tambin se recuperan junto a la aplicacin. En segundo lugar,
es preciso conocer cmo funciona el sistema de copias de seguridad para
realizar este tipo de recuperacin selectiva. Aunque esto no supone

necesariamente una dificultad, no obstante esta operacin debera ser

familiar.
4. Establecimiento de requisitos de recuperacin
La clave de esta fase del proceso de elaboracin del plan de migracin 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 seccin anterior, la
preocupacin bsica debera ser disponer de las aplicaciones ms
importantes en primer lugar. El personal directivo de la organizacin
desear saber cundo estarn sus aplicaciones funcionado para planificar la
actividades de la compaa.
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 montn de gente alrededor esperando la
finalizacin de las operaciones de recuperacin; una distraccin de este tipo
probablemente perturbe las labores. El trmino para este tiempo es tiempo
de recuperacin objetivo o en ingls TRO (Recovery Time Objective). El TRO
definido debe ser verificado para comprobar que es realista y factible, no
slo por uno mismo, sino por el resto de la organizacin, que puede ser
requerido para realizar el trabajo.
La direccin de la empresa debera colaborar ntimamente con el personal
de administracin de redes para determinar el TRO de las aplicaciones.
Aplicaciones diferentes tendrn TRO diferentes.
Es necesario asegurarse de que se dispone de tiempo para recuperar las
cintas localizadas en la instalacin de almacenamiento exterior y para
adquirir los sistemas necesarios. Por cierto, debera conocerse por
anticipado cmo realizar las rdenes de compra de los equipos cuando la
empresa se encuentra en un estado de total desorganizacin.
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 ms rpido 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 atencin al
trabajo que se tiene entre manos.
5. Elaboracin de la documentacin
Crear un documento que mucha gente pueda tener como referencia es
quizs lo ms difcil del plan de contingencia. No hay que engaarse:
implicar un esfuerzo significativo para algunas personas, pero ayudar a
aprender cosas sobre el sistema y puede que algn da salve la empresa.
Los recursos necesarios para escribir y mantener un plan de contingencia
representan ms de lo que puede realizarse en ratos libres y despus de

horas de oficina. La direccin de la organizacin 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 tecnologa de redes cambia tan
rpidamente que resulta difcil permanecer al da. Esto incluye nuevos
dispositivos, as como nuevos sistemas de aplicacin que introducen su
propio nivel de complejidad en este campo. Como ejemplo, considrese la
recuperacin de un gran sistema de base de datos relacional Unix. Este tipo
de trabajo requiere un conocimiento mucho ms complejo del que
corresponde a la instalacin 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 tambin la labor
ser un desafo.
Dado el hecho de que la tecnologa de red evoluciona tan rpidamente,
debera planificarse la actualizacin del plan de contingencia
peridicamente, por ejemplo una vez al ao. Aunque la redaccin del plan
inicial supondr una gran cantidad de trabajo, una vez que se dispone del
plan, las actualizaciones son relativamente fciles.
5.1. Contenido del plan de contingencia
El plan de contingencia debe intentar definir las cinco reas siguientes:
1. Listas de notificacin, nmeros de telfono, mapas y direcciones
2. Prioridades, responsabilidades, relaciones y procedimientos
3. Informacin sobre adquisiciones y compras
4. Diagramas de las instalaciones
5. Sistemas, configuraciones y copias de seguridad en cinta
Hay que cerciorarse de que se sabe a quin notificar en primer lugar cundo
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 caractersticas o conocimientos especiales
que puedan ayudar a minimizar el dao. Si no se dispone de nmeros de
telfono o direcciones actualizados, se puede pasar muy mal contactando
con las personas afectadas.
Mapas mostrando las ubicaciones del centro de operaciones temporal y la
instalacin externa pueden ahorrar mucho tiempo. Tambin 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 cmo 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 deberan disponer de
instrucciones y responsabilidades precisas. La relacin entre tareas debera

hallarse documentada de manera que pueda identificarse cualquier cuello

de botella que pudiera surgir. Por ltimo, deberan incluirse, de manera
detallada, las operaciones y tareas que muestren las labores de instalacin
y recuperacin necesarias, debiendo ser fciles de leer y seguir. Tambin
habra que incluir aqu los nmeros de telfono de las organizaciones de
asistencia que pudieran requerirse.
Como se ha mencionado anteriormente, debe saberse cmo expedir una
solicitud de compra y obtener los equipos para el centro de operaciones
temporal. Esto significa proporcionar a los vendedores la direccin y
cualquier instruccin necesaria para el transporte. No hay que suponer que
todos los vendedores del mundo van a enterarse de la difcil situacin y
venir a nuestro rescate. Es aconsejable disponer de copias de las facturas,
recibos y dems para mostrarlos como prueba de compra. Tambin viene
bien tener a mano una lista de 1os nmeros 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 travs de grandes
sistemas de distribucin, y que los fabricantes y desarrolladores de software
de los productos utilizados puede que no tengan ni idea de quin es su
cliente. No espere recibir los repuestos de manera gratuita; en su lugar,
debera ser capaz de llegar a acuerdos especiales de compra y provisin
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 reanudacin de las actividades. La
asignacin 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 instalacin del cableado y otros
dispositivos de red, y que se dedica a ello, puede ser capaz de realizarlo
mejor y ms eficientemente que uno mismo.
Es posible ahorrarse horas o incluso das en el proceso de recuperacin si
existe la posibilidad de almacenar algunos sistemas de repuesto con la
capacidad de gestionar tareas diferentes. Planifquese instalar una
configuracin genrica que, como mnimo, 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 recopilacin de esta informacin. Despus 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
informacin de configuracin extrada 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 envo de los repuestos antes
de poder empezar la recuperacin 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 produccin; en caso contrario, uno se puede
encontrar con formatos de cinta o bases de datos incompatibles u otros
problemas que impedirn la restauracin de la informacin.
6. Verificacin e implementacin 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 escptico sobre el propio trabajo,
de manera que pueda uno probarse a s mismo que funciona.
Psicolgicamente, esto no es fcil porque con toda probabilidad se ha
invertido una gran cantidad de tiempo y energa personal en este proceso,
aunque lo mejor sera, 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 informacin, tmese nota de ellos y corrjase el plan.
6.1. Comprobacin del plan por partes
No se puede tumbar el sistema algn da 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
organizacin. 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 nmeros telefnicos de los colaboradores incluidos en
la listas telefnicas 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 poltica de inventario. Algn da, viajar
hasta la instalacin alterna para saber dnde est y cmo reconocer el
edificio.
Por supuesto, tambin es necesario verificar los procedimientos que se
emplearn para recuperar los datos. Comprubese el software para la
realizacin de las copias de seguridad para confirmar si pueden recuperarse
las aplicaciones de mayor prioridad de la manera esperada. Esto debera
hacerse en una red aislada para evitar problemas con el servidor de
licencias. Por ejemplo, si la idea es unificar dos servidores mediante la
recuperacin completa de uno de ellos en el servidor de repuesto y a
continuacin restaurar slo 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 podra dar lugar a la difusin por toda la red de
mensajes de aviso sobre la licencia. Incluso aunque se utilice una nueva
licencia de sistema operativo de red, todava existen otros conflictos como
nombres de servidores duplicados y cualquier otro problema de duplicacin
que podra causar problemas en los sistemas de produccin.

Una vez recuperada la informacin, verifquese si el usuario puede acceder

a ella. Esto requiere de algunas estaciones de trabajo conectadas a la red
para simular autnticos usuarios finales con cuentas en los servidos
originales. En este punto, puede ser necesario actualizar el plan para incluir
informacin sobre el establecimiento de cuentas de usuario. Comprubese
cada una de las operaciones del plan individualmente y examnese entonces
si, como resultado, se tiene un sistema de red en funcionamiento. No est
de ms verificar el plan con otras personas de la organizacin que se
encuentren tan familiarizadas con los productos o procedimientos
empleados.
Revsese cada da la parte del plan relacionada con las operaciones de
copias de seguridad verificando la finalizacin correcta de las mismas.
Adems, supervise esto asegurndose de que algunas personas de la
organizacin saben realizar copias de seguridad adecuadamente, y
comprobar su finalizacin.
7. Distribucin y mantenimiento del plan
Por ltimo, cuando se disponga de un plan definitiva ya verificado, es
necesario distribuirlo a las personas que necesitan tenerlo. Intntese
controlar las versiones del plan, de manera que no exista confusin con
mltiples versiones. As mismo, es necesario asegurar la disponibilidad de
copias extra del plan para su depsito en la instalacin exterior a en
cualquier otro lugar adems del lugar de trabajo. Mantngase 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
revisin del plan existente y se examina en su totalidad, realizando cambios
a cualquier informacin que pueda haber variado. En ese instante, se debe
volver a evaluar los sistemas de aplicacin y determinar cules son los ms
importantes para la organizacin. Las modificaciones a esta parte del plan
causarn modificaciones consecutivas a los procedimientos de
recuperacin. Sin embargo, esto no debera verse como un problema porque
probablemente la seccin 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
informacin sobre el funcionamiento del nuevo o actualizado sistema.
Este proceso llevar tiempo, pero posee algunos valiosos beneficios que se
percibirn aunque nunca tengan que utilizarse. Ms gente conocer la red.
Esto proporcionar a la organizacin una base tcnica ms amplia para
mantener correctamente la red. Tambin facilitar el crecimiento de una
perspectiva global sobre la red dentro del ncleo de administradores de
sistemas de informacin y puede ayudar a identificar las futuras o actuales
reas conflictivas. Uno de los aspectos ms difciles en cualquier labor
distribuida, como es la gestin y administracin de LAN, es dar a conocer la

situacin actual. El mantenimiento y verificacin de un plan de migracin

ayudar a que se produzca dicha comunicacin dentro de la organizacin.

Leer
ms: http://www.monografias.com/trabajos11/plconting/plconting.shtml#ixz
z4OhHNM1cx

Planes de contingencia, ejemplos de la vida real

Votar

Como puede inferirse de su nombre, estos Planes buscan mejorar las

posibilidades de que una organizacin pueda continuar desarrollando su
objeto social, aun en medio de una situacin de emergencia. Si los Planes
de Contingencia deben servir para contener los efectos de un evento
indeseado, por su parte los Planes de Continuidad se disean para que la
organizacin pueda reasumir sus procesos, productivos o generadores de
valor, en el menor tiempo que ello sea posible. Cabe entonces la opcin de
considerar que dichos planes puedan actuar de manera simultnea, para
que mientras un equipo de personas y recursos se dedica a la recuperacin
de la normalidad fsica de la empresa, otro equipo trabaje en la
normalizacin del flujo de ingresos de la misma. De contarse con ambos
equipos, sera posible que la organizacin reiniciase actividades aun antes
de lograr la recuperacin de los activos o procesos afectados por la
materializacin de un riesgo.
Veamos algunos ejemplos:
Un grupo empresarial es propietario de la fbrica en la que se producen las
cajas de cartn para empacar sus productos. La fbrica se ve afectada por
un incendio, que destruye parte de sus bodegas y algunas mquinas. Como
resultado, resulta imposible la venta de sus productos, ya que las cajas son
fabricadas con especificaciones nicas para los mismos. Para atender la
emergencia, requiere de dos equipos: el primero, encargado de la
reconstruccin fsica del inmueble y la reposicin de la maquinaria; mientras
el segundo se ocupa de coordinar la elaboracin de las cajas en una fbrica
vecina, con cuyos propietarios se haba celebrado un convenio de apoyo
mutuo en casos como este. Con anterioridad, haban enviado a dicha fbrica
troqueles y planchas de impresin de sus principales referencia de cajas.
As, sus productos pudieron seguir llegando de manera ininterrumpida a los

clientes, mucho antes de terminar la reconstruccin de su propia Planta. En

este caso, mientras la fbrica es reconstruida, la empresa puede mantener
viva su operacin y satisfechos a sus clientes. Los costos adicionales de
maquila o produccin con terceros, seran reconocidos eventualmente por
una buena pliza de Lucro Cesante por Incendio. No hay por qu esperar a
que se terminen las obras civiles y el montaje de la nueva maquinaria, para
poder reanudar la produccin y los despachos. Basta con haber establecido
los convenios y alianzas adecuadas, con la suficiente anticipacin.
- En otro caso, una empresa generadora de energa hidroelctrica sufre un
atentado dinamitero que afecta el muro de contencin de la presa de agua.
Como consecuencia, debe ser demolido todo el muro, vaciada la represa,
retirado el sedimento, desviados los ros que la surten y reconstruido el
muro de contencin. Toda esta labor tomar al menos cinco aos,
dependiendo del rgimen de lluvias y otros factores imposibles de controlar.
Qu pasar con los contratos de suministro de energa que dicha
generadora tiene en vigor?
Aunque puedan existir en los contratos clusulas de fuerza mayor y similar,
lo cierto es que, si esta empresa no cuenta con un plan alterno de
suministro de electricidad, probablemente no sobreviva al prolongado
perodo de tiempo durante el cual su capacidad generadora estar
indisponible. Por muy eficiente que sean sus Planes de Contingencia,
pasaran al menos cinco aos antes de recuperar su capacidad generadora y
por ende sus posibilidades de percibir ingresos por ventas. En el hipottico
caso de contar con plizas que cubran daos y lucro cesante derivados de
actos terroristas, estas no se extenderan a compensar la prdida de
posicin en el mercado por un perodo tan prolongado. En consecuencia,
para garantizar su supervivencia, se hace indispensable contar con un Plan
de Continuidad, que involucre alternativas como el arrendamiento de otras
generadoras, con las cuales pueda surtir a sus clientes a travs del sistema
de interconexin. Ello mejorara en gran medida sus posibilidades de
sobrevivir a este tipo de ataques.
- Otro caso: en una empresa de ventas al detal, se descubre que un
vendedor se ha venido apropiando de dineros recaudados de sus clientes. Al
confrontrsele, admite su delito y renuncia a la empresa. No obstante, sigue
visitando clientes y recaudando dineros por cuenta de su anterior
empleador, obviamente en su propio beneficio. Cmo pudo ocurrir esto?
Muy sencillo. A nadie en la organizacin se le ocurri que no bastaba con
desvincularlo, para evitar que siguiera robando. Si se hubiera contado con
un Plan de Continuidad, alguien en la empresa debera haber asumido las
funciones del empleado despedido, procediendo de inmediato a notificar o
visitar a sus clientes. Ello habra evitado un robo mayor. Si se tiene en
cuenta que ya no era empleado, no podra reclamarse el monto del hurto
posterior a su despido, como siniestro bajo la pliza de Manejo.