You are on page 1of 16

Libro blanco

Planificacin prctica
de la recuperacin
ante desastres
Gua paso a paso
Enero de 2007

ndice
Finalidad de la Gua.................................................................................................................................................................................................. 3
Nuestra propuesta ................................................................................................................................................................................................... 3
Paso 1. Desarrolle la declaracin de una poltica de planificacin.............................................................................................................. 4
Paso 2. Efecte un anlisis de impacto sobre el negocio............................................................................................................................... 5
Anlisis del exterior al interior ....................................................................................................................................................................... 5
Anlisis del interior al exterior ....................................................................................................................................................................... 6
Paso 3. Identifique medidas preventivas ........................................................................................................................................................... 7
Paso 4. Desarrolle estrategias de recuperacin .............................................................................................................................................. 8
Paso 5. Desarrolle el plan ...................................................................................................................................................................................... 9
Seccin 1 del plan: Introduccin ..................................................................................................................................................................... 9
Seccin 2 del plan: Generalidades operativas........................................................................................................................................... 10
Seccin 3 del plan: Fase de notificacin / activacin ............................................................................................................................. 10
Seccin 4 del plan: Fase de recuperacin.................................................................................................................................................... 11
Seccin 5 del plan: Fase de reconstitucin ................................................................................................................................................ 12
Seccin 6 del plan: Apndices ...................................................................................................................................................................... 12
Paso 6. Comprobacin del plan, formacin y ejercicios............................................................................................................................... 12
Paso 7. Mantenimiento del plan ......................................................................................................................................................................... 13
Una consideracin final......................................................................................................................................................................................... 13
Otros productos XOsoft de CA........................................................................................................................................................................... 13
Informacin de contacto ...................................................................................................................................................................................... 13
Apndice A. Muestra del Formulario de Informacin sobre el Sistema (SIF)........................................................................................ 14
Apndice B. Muestra del Formulario de Informacin sobre el Sistema Principal (Master SIF) ........................................................ 15
Apndice C. Muestra del Formulario de Estrategia de Recuperacin (SRSF) ....................................................................................... 15

investigacin de las ofertas ms recientes que sean relevantes


para sus necesidades y a su discusin directa con los
distribuidores afectados.

Propsito de la Gua
El objetivo primordial de la presente gua no es, simplemente,
el proporcionarle una lista de comprobacin de tareas, sino
que busca ayudarle a desarrollar su comprensin sobre el
proceso de planificacin de la Recuperacin ante Desastres
(DR) y los principios que en ella subyacen. Antes de entrar en
detalles, consideremos nica y primeramente lo que esta gua
har por usted e, igualmente importante, lo que no har.

Sobre todo, esta gua no convertir la planificacin de


recuperaciones antes desastres en algo fcil. La complejidad
de la planificacin refleja, hasta en su mnimo detalle, la
complejidad de los procesos que deben recuperarse, y la mejor
gua de planificacin del mundo no podr cambiar eso. No
obstante, pese a que la preparacin de un plan no es sencilla,
los procedimientos aqu descritos constituirn una ayuda
significativa para sortear las dificultades y mantener la
complejidad bajo control.

Lo que har esta gua es disear un marco de planificacin DR


que abarque conceptos conceptualmente simples y le ayude a
saber los pasos que deben emprenderse y por qu, todo ello
sin un montn de jerga y formalidades innecesarias. El marco
que usaremos es igualmente relevante para la planificacin de
recuperaciones ante desastres en una divisin de una gran
corporacin multinacional que para una operacin que
involucre a una docena de personas de una oficina pequea.
Por supuesto, la escala de las tareas implicadas en esos dos
casos difiere de manera ms bien drstica.

Nuestra tcnica
Cualesquiera que sean la escala y la complejidad de su
organizacin, es importante emplear una tcnica de
planificacin de recuperaciones ante desastres que satisfaga
los ms elevados estndares. Ya sea simple o complejo el plan
final, su calidad reflejar necesariamente la calidad de los
procesos usados en su desarrollo.

Aqu, el enfoque ser prctico. Una buena planificacin de


recuperaciones ante desastres es aquella que identifica los
procesos y recursos que son realmente fundamentales,
desarrollando objetivos de recuperacin realistas para ellos y
desplegando luego un plan que permita conseguir tales
objetivos del modo ms simple y eficiente en costes posibles.

Por esa razn, la presente gua adopta el marco del que hace
uso el Instituto Nacional de Normas y Tecnologa (NIST) en su
Gua para la Planificacin de Contingencias en los Sistemas de
Tecnologas de la Informacin. La gua est orientada a las
agencias gubernamentales que se enfrentan con informacin
sensible y es bastante larga y compleja, aunque el marco es
sencillo y se compone de los siguientes siete pasos, los cuales
extraemos de manera textual del Resumen Ejecutivo:

Nos centraremos tambin en hacer que el proceso de


planificacin sea factible, an cuando con ello sacrifiquemos
una cierta sofisticacin. La realidad es que un plan DR
sofisticado que es demasiado complejo o caro de mantener y
probar es peor que un plan que slo cubre los mnimos, porque
ofrece una falsa sensacin de seguridad.

1. Desarrolle la declaracin de una poltica de planificacin


ante contingencias. Una poltica formal del departamento o
agencia proporciona la autoridad y directrices precisas para
desarrollar un plan de contingencia eficaz.

En consecuencia, la presente gua est destinada a ayudarle a


negociar las decisiones que usted necesitar tomar con el fin de
desarrollar un plan eficaz y ejecutable, el cual deber permitir
que su organizacin recupere sus procesos importantes y
pueda funcionar despus de producirse un desastre.

2. Efecte un anlisis de impacto sobre el negocio (BIA). El


BIA ayuda a identificar y priorizar los sistemas y
componentes de TI importantes.
3. Identifique los controles preventivos. Las medidas que se
tomen para reducir los efectos de las interrupciones del
sistema pueden incrementar la disponibilidad de ste y
reducir los costes del ciclo de vida de las contingencias.

Veamos ahora lo que est gua no har.


De partida, no le convertir en un experto en planificacin de
recuperaciones ante desastres. Ninguna otra cosa que la
experiencia y la observacin podr hacerlo. Es muy posible que
precise contratar conocimiento tcnico externo para
desarrollar un plan con la escala requerida por su organizacin.
Esta gua puede seguir sindole de utilidad, dado que le
ayudar a una participacin ms eficaz en el proceso de
planificacin y en la comprensin y evaluacin de lo que estn
haciendo los expertos externos.

4. Desarrolle estrategias de recuperacin. Unas estrategias


de recuperacin concienzudas aseguran que el sistema
pueda recuperarse de manera rpida y eficaz despus de
una interrupcin.
5. Desarrolle un plan de contingencia de TI. El plan de
contingencia debe contener directrices y procedimientos
detallados para la recuperacin de un sistema daado.
6. Prueba del plan, formacin y ejercicios. Las pruebas del
plan identifican lagunas en la planificacin, a la vez que la
formacin prepara al personal de recuperacin para la
activacin del plan; ambas actividades mejoran la eficacia
del plan y la preparacin global de la agencia.

Asimismo, no le ensear la totalidad de soluciones diferentes


de software, hardware y servicios disponibles como
componentes para un plan de recuperacin ante desastres.
Desde luego, le presentaremos alguna informacin general
sobre las clases de opciones disponibles y las cesiones que
impliquen, pero ese campo presenta muchas opciones diversas
y contina evolucionando con rapidez. No hay sustitutos a la

7. Mantenimiento del plan. El plan debe ser un documento


vivo y que se actualice con regularidad, a fin de mantenerse
al da de las mejoras en los sistemas.
3

A lo largo de las prximas siete secciones, consideraremos cada


uno de estos pasos por turno. Discutiremos la finalidad del
paso, fijaremos algunas directrices sobre los puntos necesarios
para ejecutarlo y analizaremos cmo implementarlo para que se
adapte a las necesidades de su negocio.

incidentes por cadas de los sistemas de TI. Otras causas


pueden incluir los errores de usuario o del software, virus y
otros ataques, mantenimiento que provoca interrupciones no
planificadas del servicio, etc. Las diferentes amenazas
requieren de diferentes tipos de soluciones.
Igualmente importante: qu quiere usted conseguir? La meta
es la simple supervivencia o debe recuperarse el
funcionamiento en el plazo de un da o de unas pocas horas o
de minutos? Posiblemente, incluso para sacar partido de la
crisis como mejora de la imagen de su organizacin de cara a
los accionistas, se trata de una buena forma de trasladar la
planificacin DR desde los costes a las inversiones estratgicas?
Intente expresar la finalidad del plan en trminos de los
requisitos externos, es decir, el impacto sobre los clientes u otros
accionistas del exterior del Departamento de TI o la necesidad
de satisfacer las obligaciones reglamentarias o del Regulador, ya
que esto maximizar su flexibilidad para alcanzar los objetivos.
Asegrese tambin de que esas metas estn cuantificadas; es
difcil alcanzar un objetivo que no se puede medir. Sitese en el
nivel ms alto posible. Puede ser necesario determinar los
requisitos de bajo nivel, como la frecuencia de las pruebas, pero
debe existir siempre una buena razn para hacerlo, como
normas industriales u obligaciones legales.

Paso 1. Desarrolle la declaracin de


una poltica de planificacin
Se trata de un paso que puede saltarse o ignorarse con
facilidad. No lo haga! Probablemente, se trata del paso ms
importante de los siete.
La descripcin del NIST es un poco rida: la poltica
proporciona la autoridad y directrices necesarias para
desarrollar un plan de contingencias eficaz. rida o no, una
declaracin clara de la autoridad y directrices necesarias es
vital para el xito de la empresa de la planificacin.
La declaracin de la poltica supone realmente la comunicacin
entre la Direccin y los responsables de desarrollar el plan.1
Dejando claros los objetivos que conducen el proyecto, el nivel
de recursos financieros y de otros tipos, las exigencias del
esfuerzo y las personas responsables particulares, la
declaracin de la poltica entrega a los planificadores todo lo
que precisen para elaborar las opciones que pueden lograr las
metas de la organizacin. Tambin proporciona una base para
que los planificadores comuniquen de nuevo a la Direccin
tanto sus xitos como la necesidad de reevaluar los objetivos o
los recursos cuando sea necesario.

mbito
Dnde termina la responsabilidad del plan y de los
planificadores? Por ejemplo: slo deben cubrirse los sistemas
hardware y software de TI? Qu sucede con los niveles de
personal y los sistemas ajenos a las TI situados entre la
infraestructura de TI y las funciones externas que dependen de
todos ellos?

La importancia de este paso se extiende ms all de la etapa


de desarrollo e implementacin del plan DR. Por qu? Porque
se incurre en gran parte del coste, a veces la mayora, despus
de la fase de inicializacin, durante la prueba y mantenimiento
y, por supuesto en el peor caso, durante y despus de un
desastre que prueba la falta de adecuacin del plan.

En general, resulta de ayuda el fragmentar el plan DR global de


una organizacin en un cierto nmero de planes ms simples y
limitados. Una tcnica del exterior hacia el interior funciona
mejor, haciendo que los recursos internos queden cubiertos
por un plan que se convierte en fuente inicial de las exigencias
externas para el siguiente nivel interno.

Este es probablemente un buen momento para apuntar que


usted necesitar un par de ciclos entre los pasos. La primera
versin de esta poltica puede establecer objetivos que se
acaben siendo imposibles bajo las restricciones de recursos
especificadas. Ser necesario que reevale la poltica y
reescale los objetivos a la baja o los recursos al alza o intente
algn replanteamiento radical. El punto importante y que debe
tenerse siempre presente en una planificacin de
recuperaciones ante desastres es que la realidad ser su
compaera y que, le guste o no, deber cooperar con ella, en
lugar de luchar contra ella.

Recursos
Cul es el mximo nivel de recursos que el plan puede
gobernar durante la preparacin, implementacin, prueba y
mantenimiento? Asegrese de citar restricciones para todos
los recursos relevantes: financieros, personal, equipamientos,
espacio, etc.

Funciones y responsabilidades
Quines son los responsables de los diversos componentes
del plan y qu autoridad tienen? Quin se reserva el derecho
a tomar las decisiones finales? Quin es el responsable de las
actividades de prueba y mantenimiento en curso?

A partir de la presentacin anterior, se citan ahora los puntos


clave que debera afrontar la declaracin de la poltica:

Objetivos:
Obviamente, existen muchos factores a considerar en este
paso. Dos comentarios finales, antes de que avancemos.
Primero: es importante que la declaracin de la poltica y, por
aadidura, el plan en su totalidad, se ponga por escrito. Por

En primer trmino, qu tipos de desastres intenta usted


cubrir? Los desastres de grandes dimensiones, como
terremotos, averas de la red elctrica, huracanes, etc.,
suponen tan solo en torno al 5% del nmero global de
4

encima de cualquier otra consideracin, el plan consiste en un


conjunto de instrucciones y stas se conservan mejor si estn
por escrito (si no deben olvidarse). Recuerde: esta poltica no
slo guiar el desarrollo inicial del plan, sino que deber guiar
su mantenimiento y revisin en el futuro, dado que declara la
finalidad y las expectativas para los recursos sobre una base de
funcionamiento con regularidad.

Anlisis desde el exterior al interior


La fase del exterior al interior del anlisis se centra en los
sistemas completos, siendo como las capas que se pelan de
una cebolla. En cada capa, consideramos los procesos o
sistemas actuales, distinguindolos de los usuarios o los dems
sistemas que dependen de ella y de los sistemas de los que
pudiese depender ella misma. En funcin de la complejidad
global de su negocio y de la divisin de elementos que ms
sentido tenga en su contexto, usted podra acabar con una
nica capa o con muchas de ellas.

Al mismo tiempo, no es necesario que la declaracin sea larga o


complicada. Media pgina con vietas que cubran los puntos
clave ser suficiente para muchas organizaciones. Es mejor
comenzar con algo pequeo y aadir cosas a medida que surjan
cuestiones que no hayan sido tratadas por la versin disponible.

Para cada capa, debemos responder a las siguientes preguntas


clave:

Esto es de utilidad an cuando una nica persona deba ponerse ambos


sombreros.

Qu disponibilidad y requerimientos de rendimiento tienen


los procesos, sistemas o recursos actuales? Qu coste
supone el incumplimiento de dichos requerimientos?
Esas exigencias son accionadas, por supuesto, por el proceso de
negocio o por otro sistema que depende de este. Por ejemplo:
puede exigirse a un sistema de procesado de transacciones que
maneje 25.000 transacciones a la hora, esencialmente con un
rgimen de 24 x 7, mientras que un sistema CRM que soporte la
fuerza de venta en campo a clientes con los que nos unen
fuertes relaciones puede vigilar nicamente unos pocos cientos
de interacciones diarias y podra sufrir una interrupcin de
hasta una semana antes de que las consecuencias fuesen
desesperadas. Una buena idea puede ser el determinar unos
niveles mnimos de rendimiento absoluto y nivel de
disponibilidad que permita que el negocio simplemente
sobreviva, frente a otros que le permitan funcionar de modo
adecuado an cuando se est en medio de una crisis. Con una
gama de opciones de disponibilidad, se dispone de una mayor
flexibilidad para las decisiones que conlleven gasto.

Paso 2. Efecte un anlisis de


impacto sobre el negocio
El propsito de este paso es el de asegurar que se est
protegiendo todo lo que es necesario proteger, sin despilfarrar
recursos sobre sistemas que tienen una importancia
secundaria. El objetivo es determinar qu debe recuperarse y
con qu rapidez; esa informacin se emplear para desarrollar
las estrategias de recuperacin. La salida de este paso ser una
lista con prioridades de los datos, funciones y recursos de TI
importantes que soportan los procesos de negocio de su
organizacin, conjuntamente con los tiempos mximos de corte
para cada uno de esos sistemas importantes.
Para empezar, usted debe identificar los procesos de negocio
clave que subyacen a la capacidad de su organizacin de
ejecutar sus actividades y los requerimientos que accionan
dichos procesos. Es muy importante que esto se realice desde
el exterior y hacia el interior, comenzando por el punto de viste
de los accionistas externos, ya sean clientes de la compaa,
proveedores externos o departamentos internos de la compaa
que dependan de los servicios de TI que usted proporciona.
Tambin es importante que se involucre en el proceso de
planificacin a los actores realmente implicados en los
procesos de negocio, incluyendo a los accionistas externos, el
personal interno que trate con ellos y las personas que cargan
con el soporte operativo del proceso.

La estimacin de costes es importante tanto para determinar


cunto debe invertirse en la capacidad de su organizacin para
recuperarse de un desastre como para fijar el nivel mximo de
interrupcin que puede tolerarse. La gua del NIST sugiere un
marco til para reflexionar sobre esto, como ilustra la siguiente
figura extrada de esa misma gua:

Coste
de
Cost of
Interrupcin
Disruption

El resto del anlisis debe realizarse para cada uno de los


procesos identificados, en dos fases distintas: una que vaya
desde el exterior al interior y otra en sentido opuesto.

Coste
Cost
Coste de
Cost to
Recuperacin
Recover

Al final de esta gua, encontrar una plantilla del Formulario de


Informacin sobre el Sistema (SIF) que podra resultarle til
para la recopilacin y organizacin de la informacin obtenida
durante el anlisis. Tanto si utiliza esa plantilla, simples
documentos de texto, hojas de clculo como otros formularios,
un fin clave que permite el registro de la informacin en un
formato estndar es que pone sta a disposicin para su fcil
referencia, tanto durante el resto del desarrollo del plan inicial
como durante el posterior mantenimiento y revisin del plan.

Tiempo
Time

En general, el coste de interrupcin es una funcin que crece


con el tiempo, como muestra la curva azul. Por ejemplo: en una
organizacin tpica, el coste de una interrupcin en el servidor
de correo electrnico oscila desde las molestias durante los
primeros minutos hasta una pequea cada de la
productividad, a medida que los trabajadores se ven forzados a
desempear actividades alternativas de menor prioridad y
llegando a una prdida real de ingresos y de la confianza de los
clientes cuando la avera se extiende hasta el punto en que la
organizacin es incapaz de cumplir con sus obligaciones. La
curva verde representa el coste de las soluciones de
recuperacin como funcin del tiempo de recuperacin que
soportan. Como poda esperarse, esta curva exhibe la
conducta opuesta a la anterior. Las soluciones que permiten
recuperarse al cabo de das o semanas son, tpicamente,
mucho ms asequibles que aquellas que permiten recuperarse
al negocio en cuestin de horas, minutos o segundos.

Cules son las funciones fundamentales en el proceso?


El carcter de esta informacin es doble. En primer lugar: en
muchos casos, esas funciones deben tenerse en cuenta para la
recuperacin. Si un proceso requiere la intervencin de una
persona de monitorizacin, gestin, anlisis o mantenimiento
sobre una base regular, cunto tiempo puede ejecutarse el
proceso durante una crisis sin esa funcin? Para los sistemas
de TI en particular, podran existir funciones de administrador
de TI que jugasen un papel fundamental tanto en la
recuperacin como en la activacin sistemas mientras durase
la crisis. La segunda razn por la que dichas funciones son
importantes es que las personas que las desempean
representan, por s mismas, fuentes fundamentales de
informacin para la determinacin de las dependencias y
exigencias de los sistemas. Son las personas que ms
ntimamente deben involucrarse tanto en esta fase de
planificacin como en las pruebas subsiguientes.

La interseccin de las dos curvas induce una estimacin basta


del mximo tiempo de corte admisible, si la proyectamos sobre
el eje temporal. Proyectada sobre el eje de los costes, ofrece la
suma objetivo que tiene sentido gastarse en esa solucin.

Qu datos estn implicados y cmo deben emplearse?


Los datos utilizados o generados durante el proceso deben
tenerse en cuenta por separado del equipamiento y las
funciones, por la simple razn de que, a diferencia de un
sistema o funcin, los datos no pueden sustituirse y,
normalmente, no pueden repararse; deben copiarse de algn
modo, emplendose dicha copia posteriormente para la
recuperacin de los datos. Tambin debe considerarse el papel
que cada proceso juega en el ciclo de vida de los datos: qu
proceso crea los datos, qu procesos los emplean y mediante
qu proceso se almacenan y mantienen?

Lgicamente, en esta etapa nos falta informacin de la curva


verde, que representa la tendencia general del coste de las
soluciones de recuperacin, que es la de crecer a medida que
permiten recuperarse ms rpidamente, por lo que estimamos
los tiempos de interrupcin admisibles sobre la base de las
mejores estimaciones. Cuando contemplemos, en el paso 4,
las estrategias de recuperacin especficas y sus costes,
empezaremos a completar la grfica. Como se ha citado
anteriormente, puede ser preciso reiterar el conjunto total de
pasos que estamos dando para determinar la mejor solucin.

Tenga en cuenta que los puntos de divisin entre las capas o


procesos son diferentes en las distintas organizaciones. Entre
los ejemplos de criterios que pueden usarse para determinar la
mejor manera de subdividir el proceso global en sistemas y
subsistemas, se incluyen: las lneas departamentales;
funciones de supervisin, mantenimiento y gestin; capacidad
de sustitucin por sistemas manuales o de otra clase;
complejidad y tamao; y por supuesto, el sentido comn.

Cules son los puntos de contacto entre el proceso o sistema


actual y los dems sistemas que los que depende?
La respuesta a esa pregunta nos da la siguiente capa de la
cebolla y cmo interacta con la capa actual. Por ejemplo: el
proceso de ventas puede involucrar a personal que trabaja con
un sistema CRM; el punto de contacto podra ser un portal
Web en el interior de la aplicacin CRM. La aplicacin CRM es,
en s misma, un sistema que puede componerse de varios
servidores Web, servidores de aplicaciones CRM y servidores
de bases de datos, todos ellos con el portal como punto de
contacto con el proceso de ventas. Adems, puede
considerarse la capa del CRM y sus puntos de contacto con,
por ejemplo, los sistemas de almacenamiento, en el caso de
que administren por separado.

Un mtodo de ayuda para trabajar durante esta fase de la


tarea es el de ejecutar un examen mental o real de cada
proceso, con la participacin de todos los que estn
normalmente implicados. Esto puede ayudar a asegurarse de
que no se olvida ninguna dependencia importante que puede
no ser obvia de inmediato.
El resultado de esta fase exterior-interior del anlisis es, para
cada proceso empresarial, una lista completa de los sistemas
afectados, los puntos de contacto entre los sistemas y los
requisitos de rendimiento y disponibilidad en cada punto.

Al final de la cadena, por supuesto, se encuentran los recursos


y sistemas de infraestructura, tales como la alimentacin
elctrica, las conexiones de telecomunicacin y los sistemas de
control medioambiental; todos ellos deben considerarse
tambin, ya que pueden verse impactados por algunas de las
interrupciones para las que se est desarrollando la
planificacin de contingencias.

valores de nivel en el sistema sigan siendo mutuamente


coherentes).

Anlisis desde el interior al exterior


La fase interior-exterior se centra en los recursos que se
precisan en cada capa, con el fin de proporcionar los servicios
que hayan sido identificados en la fase previa. Comenzando en
el sistema o capa ms profunda, enumere todos los recursos
de TI e infraestructura que son necesarios para que aqul
funcione. Seguidamente y para cada uno de esos recursos,
determine el impacto de una interrupcin en la disponibilidad
del recurso sobre el funcionamiento del sistema y su capacidad
para entregar el servicio del que dependen las capas
exteriores. En particular, determine el mximo tiempo de
interrupcin admisible para cada recurso antes de que se cree
una interrupcin inaceptable de las funciones esenciales;
bsicamente, el punto en el que la disponibilidad del sistema
cae por debajo de los requisitos ms exigentes de todos los
sistemas que dependen de l. Asegrese de incluir en el
anlisis cualquier impacto indirecto que pudiese producirse a
travs de sistemas relacionados o dependientes.

Las prioridades de recuperacin deben desarrollarse tambin


en el nivel del sistema. La coherencia es, obviamente, vital; no
ir bien a un sistema el disponer de una prioridad ms alta de
la que tenga otro sistema del que dependa de modo
fundamental, salvo que pueda continuar funcionando sin esa
dependencia y con un nivel aceptable. Es conveniente
transferir prioridades del nivel de sistema a un SIF Maestro que
recoja cada uno de los sistemas conjuntamente con una breve
descripcin de su finalidad, la prioridad de recuperacin, el
tiempo de corte mximo y el impacto sobre el negocio,
principales dependencias sobre otros sistemas y una breve
descripcin de la estrategia de recuperacin despus de que se
haya desarrollado en el Paso 4. Puede encontrarse una plantilla
sugerida para el SIF Maestro en los apndices contenidos al
final de esta gua.
Ahora, antes de tratar las estrategias de recuperacin,
consideraremos de forma breve la prevencin, puesto que
puede resultar con frecuencia considerablemente ms barata
que la recuperacin despus de que algo haya ido mal.

Es esencial que se ejecute este mismo anlisis para los datos y


funciones tambin. Una vez ms, cul es el impacto que
resulta de una indisponibilidad o prdida de los datos o de la
incapacidad de alguien para cumplir una funcin especfica? En
ltimo caso, esto puede suceder porque la persona est lesionada
o incapacitada de algn modo para realizar sus obligaciones,
aunque tambin puede ser el resultado de una falta de accesos.
Si se produjese una epidemia, por ejemplo, y se obligase al
personal a trabajar desde casa, como ocurri durante la
epidemia de SRAG (neumona asitica) de 2003, podran tener
bastante capacidad de trabajar, aunque no pudiesen hacerlo
por no tener acceso a los recursos que precisaban.

Paso 3. Identifique las medidas


preventivas
Una frmula simple para calcular el riesgo financiero asociado
a un tipo dado de desastre (y por tanto cunto merece la pena
invertir en un plan para mitigarlo) es R$ = P X C X T donde P es
la probabilidad de que se produzca el desastre, C es el coste
horario o diario del tiempo de inactividad en productividad
perdida, beneficios perdidos, etc. y T es el tiempo que se
espera permanezcan inactivos los sistemas. Por ejemplo, si la
probabilidad de que un gran huracn afecte al emplazamiento
de su empresa en los prximos tres aos es del 20% con un
coste de 100.000 $ por cada da de inactividad y se espera que
dicha inactividad se prolongue durante una semana, su riesgo
financiero es de 0,2 X 100.000 $ X 7 = 140.000 $

La realizacin de esta secuencia de anlisis conlleva, en efecto,


un completo cuadro de dependencias que va desde la capa
ms externa de los procesos de negocio hasta la ms interna
de la infraestructura de recursos, personas y datos. Esta
constituye una herramienta muy valiosa para el posterior
desarrollo de las pruebas y el mantenimiento y debera
incluirse en el plan de recuperaciones ante desastres, dentro
de la seccin de descripcin y arquitectura del sistema,
descrita ms adelante.

Una forma de minimizar este riesgo es reducir T, el tiempo de


inactividad, que es, en esencia, la finalidad del ejercicio de
planificacin de la recuperacin ante desastres. Sin embargo,
no es el nico modo. El riesgo tambin puede aminorarse
reduciendo la probabilidad de que se produzca el desastre o
reduciendo el coste en el que se incurrir si se produce. Ambos
tipos son medidas preventivas. A menudo sucede que es
mucho ms barato evitar un problema que solucionarlo una
vez que surge.

Una vez completo el anlisis, llega el momento de desarrollar


las prioridades de recuperacin para los sistemas y
componentes individuales de TI, empezando por el ltimo. Esta
tarea es sencilla si el trabajo descrito en esta seccin se ha
realizado a conciencia, ya que las prioridades de derivan, de
forma natural, del impacto de la interrupcin y de los tiempos
de corte admisibles registrados para cada componente.
Existen muchas escalas posibles que pueden emplearse en el
etiquetado de prioridades, desde una simple escala cualitativa
de tipo alta - media - baja hasta una escala numrica, pasando
por una escala que se centre en el impacto sobre el negocio,
como elevada captacin por el cliente frente a gestin y
control o baja prioridad de mantenimiento. Cualquiera que
sea la escala empleada, es importante que sea uniforme a
travs de todos los sistemas y se base en el impacto sobre el
negocio (en algunos casos, puede estar bien utilizar una escala
distinta en el interior de un proceso o sistema, siempre que los

Las medidas que reducen la probabilidad de que se produzca


un desastre van desde las bastante drsticas, como desplazar
la organizacin fsicamente para alejarla de amenazas como
huracanes o inundaciones, hasta las bastante mundanas,
como: garantizar que se ejecuta el mantenimiento regular de
los sistemas importantes; que estn incorporados los
componentes redundantes; que se encuentran instalados los
sensores de control de factores ambientales; que se han
instalado monitores de rendimiento que proporcionen
7

advertencias tempranas de fallos de funcionamiento en el


servidor; incluso algo tan simple como disponer de lonas de
plstico con las que tapar los equipos informticos de daos
causados por el agua.

repuesto. En el otro, podra resultar necesaria una instalacin


alternativa.
La segunda consideracin que de aqu se deriva es la
necesidad de contemplar soluciones de diferente amplitud de
cobertura. Evidentemente, una solucin que pueda tratar un
fallo del emplazamiento servir tambin para recuperarse de
averas de sistemas o componentes individuales. Existen varias
razones para no depender de una nica solucin para todo el
sistema que haga frente a todos los problemas. Lo ms obvio
es que dicha solucin s resultara costosa de implementar y,
con probabilidad, costosa de activar; es improbable que la
interrupcin derivada de una conmutacin de todos sus
sistemas a un emplazamiento secundario sea proporcional a
un problema derivado de una avera de un componente nico.

En ocasiones es incluso posible reducir el coste del tiempo de


inactividad reduciendo la dependencia de su organizacin en el
sistema. La idea bsica es examinar las potenciales ganancias
de retirar o sustituir todo el sistema. Al implementar nuevos
equipos y sistemas, en ocasiones se olvida que el coste total
de cualquier sistema no slo incluye el coste previo y el
mantenimiento en curso, sino tambin el riesgo asociado a
ste. Hay momentos en los que es mejor sustituir un sistema
por otro que, aunque inferior en rendimiento, exponga a la
organizacin a riesgos considerablemente inferiores.
Mientras no disponemos de ningn procedimiento particular
que ofrecer, resulta potencialmente muy til dedicar algo de
tiempo a este paso, tanto por todos los tipos de desastres
contra los que se desea proteger como para todos los sistemas
que se protegen, a nivel del sistema completo y al nivel de
componentes.

Existen otras dos razones no slo para considerar, sino


implementar de verdad varios enfoques alternativos que traten
los diferentes niveles de problemas. En primer lugar, no
importa lo buena que sea su planificacin y comprobacin.
Depender de una solucin nica, especialmente una compleja,
implica que su recuperacin sea todo o nada. Cualquiera con
suficiente experiencia en sistemas complejos sabe que esto no
es una buena idea. Es mucho mejor disponer de una serie de
soluciones de backup para que, si una falla, exista otra
disponible para la recuperacin con un coste superior, pero sin
ser totalmente devastador. En segundo lugar, las soluciones
alternativas que se implementan de verdad pueden aportarle
una flexibilidad significativa en su respuesta al desastre real.
Por ejemplo, si surge un problema en el medio de un da
laborable, puede ser importante pasar de inmediato a una
solucin cara para realizar una recuperacin rpida, pero si se
produce de noche o en fin de semana, podr instituir los
procesos de reparacin de forma ms lenta pero menos
disruptiva y menos costosa.

Paso 4. Desarrolle estrategias de


recuperacin.
La tarea principal de este paso es determinar cmo lograr sus
objetivos de recuperacin ante desastres para cada uno de los
sistemas y componentes de sistema que se identificaron en el
Paso 2. Es en este paso donde se realiza el trabajo esencial de
equilibrar los costes y beneficios de los mtodos disponibles,
antes de entrar en las complejidades del plan completo.
Este paso no trata sobre seleccionar vendedores especficos,
determinar costes exactos o desarrollar procedimientos
detallados. Ms bien, la finalidad de esta fase ser seleccionar
los tipos de solucin que se utilizarn y determinar las escalas
de los costes implicados. De este modo, por ejemplo, usted
puede determinar que un pequeo subconjunto importante de
sistemas precisa de un sitio alternativo con dotacin y recursos
especulares y preparado para asumir el mando en minutos,
mientras que otros sistemas pueden utilizar una estrategia de
backup ms tradicional, que asuma tiempos de recuperacin
ms largos con gastos ms reducidos.

Una consideracin final es que necesitar tener en cuenta las


caractersticas particulares de la infraestructura y los aspectos
humanos y de datos de la recuperacin. Deber considerarse
de forma diferente cada una de ellas, con distintos conductores
fundamentales de la decisin de en qu tipo de solucin
invertir y cunto gastar.
La infraestructura es lo ms simple. Aunque pueda acarrear
costes ms o menos significativos, la caracterstica principal de
la infraestructura es que puede sustituirse. Un servidor puede
sustituirse por otro, puede encontrarse un proveedor
alternativo para conectividad de red, etc. En muchos casos, no
es necesario que el sistema de sustitucin sea un duplicado
exacto, puesto que interconecta con otros componentes y
sistemas de forma compatible: los sistemas manuales pueden
sustituir los sistemas automatizados basados en TI o puede
subcontratar de forma provisional un sistema interno. Al
considerar las estrategias de recuperacin de la
infraestructura, el conductor fundamental es por lo general el
de coste frente a rendimiento.

Existen varias consideraciones a tener en mente mientras se


trabaja en este paso.
En primer lugar, este es el punto en el que se vuelve importante
contemplar de forma exacta los tipos de desastres para los que
es necesario prepararse y clasificarlos segn la extensin y el
tipo de impacto que tendrn. La razn es sencilla: las
estrategias de recuperacin disponibles para usted dependen
necesariamente de aquello de lo que debe recuperarse. Un
fallo en los componentes del hardware o una fuga de agua
sobre un par de servidores son asuntos muy diferentes a un
desastre que afecte a todo el emplazamiento, como una
inundacin, un incendio o un apagn en la zona. En un caso, es
posible depender de un proveedor que proporcione el

Las personas (funciones) representan un factor ms difcil. Las


funciones particulares exigen por lo general destrezas y
conocimientos especiales. Si una estrategia de recuperacin
8

exige, por ejemplo, la duplicacin de una funcin dada en un


emplazamiento alternativo, podran surgir costes adicionales
asociados a la contratacin o formacin del personal que
asumir dicha funcin duplicada. De modo parecido, la propia
solucin de recuperacin podra exigir formacin o destrezas
especiales. El conductor clave para la consideracin de las
estrategias de recuperacin desde el punto de vista de las
funciones, por consiguiente, es el grado en el cual precisan de
que duplique o adquiera destrezas especiales, lo que tendr un
impacto sobre el coste a largo plazo de la contratacin y la
formacin.

Paso 5. Desarrollar el plan.


Este paso supone la culminacin de todo su trabajo. No es, por
desgracia, un paso fcil, pero tampoco resulta complicado en
exceso, si se ha sido minucioso en todos los pasos anteriores y
se han abordado de forma sistemtica.
El resultado de este paso es tanto un plan documentado como
la implementacin completa de toda la infraestructura
necesaria para habilitar el plan. Entre la documentacin se
incluye informacin en segundo plano sobre los supuestos y
limitaciones encontrados en la realizacin del plan, as como
documentacin por escrito relativa a los procedimientos
especficos. El aspecto de la implementacin incluye la
de ubicaciones alternativas, contratacin de fuentes de red
alternativas u otros servicios de comunicacin, etc.

Por ltimo, los datos son potencialmente el elemento ms


difcil porque, por lo general, son nicos. No suele ser posible
sustituir los datos por otros que dispongan de las mismas
propiedades o similares. O los tiene o no los tiene. La pregunta
motriz desde el punto de vista de los datos es por tanto:
Cuntos datos est dispuesto a perder? Tambin es
importante recordar aqu que los datos no slo podran
destruirse, por ejemplo, a travs de la prdida del sistema en el
que se almacenan, sino que tambin pueden corromperse por
errores del usuario o el administrador o por un sabotaje
deliberado, por ejemplo, a travs de un ataque con virus.

Este paso constituye por s mismo un proyecto principal,


aunque se hayan ejecutado correctamente los pasos
anteriores. Exigir una cantidad importante de tiempo de la
persona o equipo con la responsabilidad de dirigir el desarrollo
del plan, pero tambin exigir tiempo y esfuerzo de todo aquel
cuyos sistemas se encuentren implicados, puesto que se
precisar de su competencia tanto en el desarrollo de los
procedimientos de recuperacin como, por supuesto, de su
comprobacin.

Si se tienen presentes todas estas consideraciones, este paso


consiste en revisar cada uno de los sistemas caracterizado en
el Paso 2 y determinar las estrategias al nivel del sistema y de
los componentes a aplicar, las cuales puedan lograr la
recuperacin dentro del tiempo mximo de corte, a la vez que
permanecer de forma aproximada dentro de los lmites del
presupuesto y las restantes limitaciones de recursos que se
hayan establecido. Al considerar los costes, es importante
caracterizar siempre el coste total de una solucin, lo que
implica no slo el coste de hardware, software o servicios
adquiridos, sino tambin el nivel de disrupcin provocado por
la instalacin y los costes continuos, tanto en dinero como en
personal, de mantener y comprobar la solucin.

Cubriremos todos los aspectos del plan, siguiendo de forma


aproximada la organizacin que se sugiere en la gua NIST. La
organizacin no es importante en s misma (se adaptar para
que sirva de la mejor forma a sus necesidades) pero en el plan
estarn presentes todos los tipos de informacin que
trataremos. Las secciones que utilizaremos son las siguientes:
1.
2.
3.
4.
5.
6.

Tenga presente tambin que los diferentes sistemas no son


independientes entre s y, en muchos casos, exigen la
compatibilidad de las estrategias de recuperacin. Esto podra
constituir una reflexin menor para soluciones puramente
locales, pero, si se desea configurar un emplazamiento
alternativo, se precisar garantizar que todos los sistemas
sobre los que depende un sistema dado tambin se duplican.
Por ejemplo, si se desea un sistema failover para los servidores
de correo electrnico en un emplazamiento alternativo al otro
lado del pas, adems del servidor de correo electrnico
precisar instalaciones para alojar servidor, alimentacin,
conectividad de red, ancho de banda suficiente para trabajar
durante una crisis, acceso o personal que mantenga las
instalaciones y los servidores, servidores DNS y otros sistemas
auxiliares fundamentales para el funcionamiento, etc.

Introduccin
Generalidades operativas
Fase de notificacin / activacin
Fase de recuperacin
Fase de reconstitucin
Apndices

Para cada seccin, trataremos de forma breve sus contenidos y


la finalidad de su inclusin. Revisaremos a continuacin
algunos de los principales temas o posibles escollos a tener en
mente y por ltimo ofreceremos algunas sugerencias acerca de
cmo abordar el desarrollo real de dicha seccin.
Tenga presente que es probable que esta parte del trabajo
resulte iterativa. A medida que se seleccionan soluciones
especficas y se desarrollan procedimientos paso a paso, podr
descubrir nuevas dependencias, errores en sus supuestos
iniciales o, simplemente, que la propuesta planificada excede
los recursos disponibles. Por consiguiente, tendr que visitar y
evaluar de nuevo sus estrategias de recuperacin y puede que
incluso sus objetivos de recuperacin. De hecho, es posible
que desee hacerlo a propsito al preparar todo el plan (realizar
varios pases a travs de todos los pasos de la presente gua,
pero comenzando con un esfuerzo mucho ms superficial y
profundizando de forma gradual). Este enfoque puede reducir
de forma significativa la probabilidad de imprevistos que
supongan la reconsideracin de las partes principales de su plan.

Cuando haya terminado, aada un breve resumen de las


estrategias de recuperacin para cada uno de los sistemas del
Formulario de Informacin sobre el Sistema Principal.
9

Seccin 1 del plan: Introduccin

Seccin 3 del plan: Fase de notificacin / activacin

La finalidad principal de esta seccin es documentar los


objetivos y el mbito del plan, conjuntamente con cualquier
requisito que deba tenerse en cuenta siempre que se actualice
dicho plan.

Esta es la primera de las tres secciones del plan que


documentan las operaciones de recuperacin real.
Segn la gua de NIST, esta seccin define las medidas
iniciales tomadas una vez que se ha detectado una disrupcin
o emergencia en el sistema o cuando parece que stas son
inminentes. En esta fase se incluyen actividades de notificacin
al personal de recuperacin, valoracin de los datos del
sistema e implementacin del plan. Al trmino de esta fase, el
personal de recuperacin estar listo para ejecutar las medidas
de contingencia que restauren las funciones del sistema de
forma provisional.

La preparacin de esta seccin es simple, puesto que se trata,


en esencia, de la declaracin de la poltica de planificacin que
se prepar en el paso 1 (tambin pueden incluirse aqu sus
contenidos palabra por palabra).
Este lugar tambin es el adecuado para incluir el registro de
modificaciones realizadas en el plan siempre que se actualiza.

Es comn que las organizaciones planifiquen esta fase de


forma inadecuada. La mayor parte de su trabajo dentro del
plan se centra en las medidas que debe tomar para la
recuperacin. Es muy fcil olvidar que declarar la emergencia y
decidir que es hora de iniciar las operaciones bajo el plan de
recuperacin ante desastres puede resultar difcil. Adems,
requiere tambin una planificacin avanzada. De hecho, existe
una tendencia muy natural en las personas, en ausencia de
directrices claras, de retrasar las medidas hasta que estn
convencidas de que el desastre es inminente o ya es tarde
para reaccionar. Por desgracia, para cuando se tiene la certeza,
ya suele ser demasiado tarde.

Seccin 2 del plan: Generalidades operativas


La finalidad de la presente seccin es proporcionar una imagen
concisa del enfoque general del plan.2 Contiene, en esencia,
dos tipos de informacin: (1) Una visin general de alto nivel
de los sistemas que se protegen y las estrategias de
recuperacin empleadas y (2) una descripcin de los equipos
de recuperacin y sus funciones.
La seccin aporta un contexto para comprender el plan en su
conjunto. Con slo leer la introduccin ms la presente seccin
deber ser posible alcanzar una idea del enfoque general de la
recuperacin ante desastres en todos los sistemas implicados.

En esta seccin se contestarn las preguntas siguientes:


Sobre qu base se tomar la decisin de activar el plan?
Qu informacin es necesaria?
De qu directrices adicionales se dispone para tomar la
decisin?
Quin se responsabilizar de realizar la evaluacin de
daos y amenazas que proporcionar la informacin anterior?
Qu limitaciones o directrices existen acerca de cunto
tiempo puede ocupar la valoracin o de cun segura ser la
informacin?
Quin ser el responsable de la decisin de ir / no ir?
Cules son las normas de sucesin en el caso de que dicha
persona no se encuentre disponible?
Cmo se realizar la notificacin a los equipos?
Cmo se comunicarn los equipos de recuperacin?

El primer tipo de informacin de esta seccin, una vez ms, ya


lo ha preparado usted durante los pasos anteriores: anlisis del
impacto empresarial y desarrollo de estrategias de
recuperacin. Un modo fcil de ejecutar esta parte de la
seccin consiste simplemente en incluir una copia del
Formulario de Informacin sobre el Sistema Principal (SIF), que
enumera todos los sistemas principales con SIF individual y los
comenta con prioridad en la recuperacin, tiempo mximo de
corte e impacto sobre el negocio, principales dependencias de
otros sistemas y una breve descripcin de las estrategias de
recuperacin utilizadas. Se recomienda tambin la inclusin en
un apndice del plan de todos los SIF individuales. stos sirven
como una referencia til durante las revisiones del plan y
garantizan que toda la informacin permanezca unida en
futuras actualizaciones.

Existen varios aspectos a tener en cuenta en la preparacin de


esta seccin del plan.

La visin general operativa incluir tambin una descripcin de


los equipos que sern responsabilidad de la activacin y
ejecucin del plan. En la siguiente seccin se preparar
informacin detallada acerca de los equipos y el plan de
sucesin y, por consiguiente, la informacin aqu contendida
ser breve: probablemente, no ms que una lista de equipos y
funciones clave, conjuntamente con unas palabras que
describan su funcin en el plan de recuperacin general. Es
probable que sea mejor desarrollar esta parte tras finalizar
toda esta fase del trabajo, con el fin de garantizar que refleje la
estructura real de los equipos de recuperacin cuando se
hayan tomado todas las decisiones.

Al preparar las directrices para la decisin de activacin,


responda del hecho de que existe una tendencia natural a ser
conservador en la evaluacin de riesgos, para evitar ser
considerado un alarmista en el caso de que el dao temido no
llegue a producirse de verdad. Siempre que sea posible,
proporcione directrices claras, positivas y especficas acerca de
cundo debe o no debe activar el plan la persona al cargo.
Asegrese de que la persona responsable de las decisiones se
encuentra en una posicin que le permita disponer de toda la
informacin necesaria. Por ejemplo, en el caso de que la
comunicacin resulte imposible y si la decisin exige el
conocimiento de las condiciones de un emplazamiento, es
preferible designar a alguien situado en dicho emplazamiento.
10

De hecho, la comunicacin es un aspecto clave que debe


considerarse con atencin. Dependiendo del tipo y escala del
desastre, podran no ser operativos los medios de
comunicacin habituales, como telfonos mviles, correo
electrnico y telfonos fijos. Debern desarrollarse mtodos
alternativos, como telfonos por satlite o radio, o se otorgarn
poderes a los equipos locales para que tomen decisiones de
forma autnoma, as como las herramientas necesarias para
implementar dichas decisiones.
2

El trabajo principal aqu es, por supuesto, implementar su


estrategia de recuperacin. Esto incluye desde la evaluacin y
adquisicin de componentes de las soluciones de hardware y
software, diseo e implementacin de la solucin entorno a
estos componentes, equipado de sitios alternativos para sus
sistemas, negociacin con las instalaciones de servicios
gestionadas, vendedores y empresas consultores de TI, etc. Es
posible que no podamos mostrar en unos pocos prrafos todo
lo que necesita saber. Esto exigira un libro de tamao considerable
que quedara anticuado tan pronto como fuese publicado.

En la gua NIST esta seccin se denomina Concepto de las operaciones.

Esto nos conduce al punto ms importante a tener en cuenta


en esta seccin del plan. Necesita ms que nada asegurarse de
que est buscando y utilizando toda la informacin, recursos y
ayuda posibles. Es posible que desee considerar la subcontratacin
de parte o de todo el trabajo a una organizacin de servicios
profesionales especializada en el desarrollo de sistemas de
recuperacin (aunque es importante entender que todava
tendr que poner un gran esfuerzo de su parte para garantizar
que disponen de toda la informacin necesaria sobre su
organizacin).

Esta seccin constituye una ubicacin adecuada para


conservar la informacin de contacto de todos los miembros
del equipo; tambin podra incluirse como un apndice. Tenga
presente que nunca tendr informacin de contacto suficiente.
En especial, en el caso del personal de recuperacin clave, es
posible que desee incluir sus telfonos y direcciones de correo
electrnico del trabajo y de casa, fax, telfono mvil, vecinos,
parientes, etc.
Este constituye el primer punto en el desarrollo del plan en el
que disear los procedimientos reales a seguir durante una
crisis. Es imposible desarrollar buenos procedimientos, sea
cual sea su complejidad, sin representarlos. Por este motivo, es
esencial que los procedimientos desarrollados para esta
seccin sean comprobados en el uso real, del mismo modo que
los propios procedimientos de recuperacin. Tambin resulta
til, durante la elaboracin del plan, dramatizar una crisis,
preferiblemente con las personas que se vern implicadas de
hecho, con el fin de considerar los pasos necesarios.

Lo haga todo usted mismo o subcontrate partes o incluso el


total, es una buena idea utilizar otros recursos que ayuden a
garantizar que comprende las opciones disponibles y las
transacciones implicadas. A continuacin presentamos
algunas sugerencias:
Un esfuerzo mnimo de bsqueda en Internet mostrar
numerosos artculos, guas, listas de verificacin, etc. Sitios
especializados como el de Disaster Recovery Journal lo
organizan para usted pero tambin merece la pena realizar
una bsqueda independiente. Utilice toda esta informacin.

Seccin 4 del plan: Fase de recuperacin


Esta es la segunda de las tres secciones principales que
documentan las operaciones de recuperacin reales, pero es la
que la mayora de nosotros tenemos en mente cuando se habla
de un plan de recuperacin ante desastres. Esta es la seccin
del plan que documenta al detalle las soluciones a utilizar para
recuperar cada uno de los sistemas, as como los
procedimientos necesarios para realizar la recuperacin y
restaurar las capacidades operativas.

Hable con otras empresas de su rea o similares que hayan


implementado planes de recuperacin ante desastres y
aprenda de su experiencia.

La organizacin de esta seccin es simple. Para la organizacin


en conjunto y para cada sistema en particular, el plan identifica
una secuencia de objetivos de recuperacin (por ejemplo,
restaurar la conectividad a Internet o cambiar los servicios de
correo electrnico a un sistema de backup en un emplazamiento
secundario) y suministra documentacin acerca de los
procedimientos necesarios para la consecucin de todos ellos.
Los procedimientos pueden ser tan simples como un par de
vietas o tener muchas pginas de instrucciones y listas de
verificacin, dependiendo de la complejidad de la solucin de
recuperacin y, por supuesto, del sistema.

Contrate asistencia profesional.

Existen dos puntos de vista para su trabajo en el desarrollo de


esta parte del plan: la implementacin real de las soluciones
que se alinean con las estrategias de recuperacin que se
identificaron en el paso 4 y la documentacin de los
procedimientos precisos durante la recuperacin.

No suponga que una solucin funcione como se anuncia:


obtenga pruebas. Siempre que sea posible, evale las
tecnologas en su laboratorio antes de comprometerse.
Solicite referencias de instalaciones similares a la suya.

Hable con sus proveedores y exjales ayuda. Es evidente que


tienen intereses y puntos de vista particulares, pero
tambin son especialistas en las tecnologas que ofrecen.
Asegrese de que puede hablar con personal tcnico bien
formado, no slo de ventas y marketing.
Intente considerar diferentes opciones en cada nivel.
Cuando piense en la estrategia global, pregntese si
tambin podra funcionar una estrategia radicalmente
diferente. Cuando est considerando tecnologas o tipos de
soluciones especficos, asegrese de comprobar diferentes
proveedores, no slo en los paquetes de prestaciones, sino
tambin en el tipo de compaa. Pregnteles en qu se
diferencian de la competencia, en qu son similares y,
siendo honestos, bajo qu circunstancias recomendara un
tipo de solucin distinta.

11

dificultades. Una solucin que le proporciona una recuperacin


fcil pero dificulta la reconstitucin no es una solucin
especialmente buena.

Cuando haya seleccionado e implementado las soluciones de


recuperacin que utilizar, la tarea que queda ser desarrollar
y documentar los procedimientos reales a seguir para la
recuperacin de cada sistema y para la coordinacin entre
ellos, puesto que la recuperacin de un sistema depende a
menudo de lo que ocurre en otro.

La segunda razn es incluso ms importante. Aunque los


niveles de tensin podran reducirse durante el retorno a la
normalidad, hacerlo sin procedimientos correctamente probados
y documentados, conlleva el riesgo de cometer errores que
pueden transformar en otro desastre el regreso a la normalidad.

En esta fase no existe un sustitutivo para la accin: realice la


recuperacin y ponga por escrito lo que hizo. A continuacin
hgalo de nuevo siguiendo las instrucciones y compruebe si son
correctas y completas. Es importante que el nivel de detalle de las
instrucciones se corresponda con el nivel de conocimientos del
personal menos erudito que pueda necesitar ejecutarlas.

El tipo de contenido y sugerencias para la preparacin son los


mismos que en la seccin de recuperacin. Por consiguiente,
no los repetiremos aqu.

Con el fin de minimizar las interrupciones, una gran parte del


trabajo puede simularse o dramatizarse y los procedimientos
para los subsistemas individuales pueden desarrollarse de
forma independiente. Sin embargo, es muy importante que
tanto la documentacin como la comprobacin finales incluyan
pruebas exhaustivas a imagen de lo que se espera ocurra
durante una crisis real. Este es el nico modo de descubrir
dependencias sutiles dentro del sistema que puedan omitirse
de otra manera.

Seccin 6 del plan: Apndices


Los apndices contendrn la informacin que (a) resulta
necesaria como material de consulta durante la recuperacin,
(b) pueda resultar necesaria durante cualquier revisin del
plan o (c) documente los contratos legales. Como ejemplo:
Contactos del equipo
Contacto del vendedor (incluido el almacenamiento fuera del
emplazamiento)
SOP y listas de comprobacin para recuperacin del sistema
o procesos

Es muy importante destacar cualquier punto del procedimiento


que requiera coordinacin con otros equipos u otros sistemas:
esta informacin es fcil de percibir leyendo por encima un
procedimiento dado. Si el procedimiento es largo y complejo,
podra resultar til incluir una visin general de los principales
pasos en una seccin de introduccin o extraer alguno de los
detalles en listas de verificacin o subprocedimientos
independientes. Por supuesto, aunque plenitud y correccin
son clave, ser mejor cuando ms corto y simple resulte el
procedimiento. Recuerde que estos procedimientos se
ejecutarn en un entorno de gran tensin, lo que posibilita una
mayor existencia de errores y confusin que durante una
ejecucin de prctica.

Listas de equipos, requisitos del sistema en hardware,


software, firmware, etc.
SLA del vendedor, contratos recprocos, etc.
Descripcin del / direcciones al sitio alternativo
Hojas de trabajo utilizadas para desarrollar el plan

Paso 6. Comprobacin del plan,


formacin y ejercicios
Las cosas cambian con el paso del tiempo. Los componentes
de hardware se sustituyen, se actualiza el software, las redes
se configuran de nuevo, el tamao de los datos aumenta, la
gente va y viene. Todo esto forma parte de la vida de un
entorno de TI. Y todo ello puede tener impacto en el
rendimiento de sus sistemas de recuperacin ante desastres.
Aunque estos sistemas se comprobaron a fondo cuando se
instalaron por primera vez, la naturaleza dinmica del entorno
hace que resulte importante la realizacin continuada y regular
de las comprobaciones, as como la actualizacin de la
formacin del personal.

Seccin 5 del plan: Fase de reconstitucin


Esta es la ltima de las tres secciones del plan que documenta
las operaciones reales y es de nuevo la que se viene de forma
inmediata a la mente de la mayora de las personas cuando se
reflexiona acerca de la planificacin de la recuperacin ante
desastres.
Los desastres terminan finalmente y resulta necesario devolver
las operaciones a la normalidad. Segn la gua de NIST, en esta
fase se finalizan las actividades de recuperacin y se
restauran las operaciones normales en las instalaciones de la
organizacin. Si no se pueden recuperar las instalaciones
originales, las actividades de esta fase tambin pueden
aplicarse a la preparacin de unas nuevas instalaciones que
den soporte a los requisitos de procesamiento del sistema.

Existen diferentes tipos de niveles de comprobacin. En


trminos generales, abarcan dos dimensiones clave: mbito y
realismo. El mbito hace referencia al grado para el que est
probando un sistema completo o slo componentes
individuales. Realismo hace referencia al grado para el que est
ejecutando de forma exacta los procedimientos que realizara
durante un desastre (una examen escolar dramatizado en el
que usted discute los pasos sin realizarlos de verdad
constituye un extremo y el otro una ejecucin completa). En
ambos casos, un lado del espectro tiende a resultar menos
caro y negativo para las operaciones diarias, pero tambin
menos fiable en los resultados.

Existen dos razones muy importantes para considerar y


documentar los procedimientos de reconstitucin con tanto
cuidado como los de recuperacin. La primera es que eso le
ayudar a garantizar que las soluciones que seleccione sean la
base de un retorno a la normalidad relativamente sin
12

En general, resulta una buena idea realizar una combinacin.


Pueden realizarse pruebas menos perjudiciales y con mayor
frecuencia. Las anomalas detectadas y solucionadas de este
modo evitan el impacto y los costes, ms elevados por lo
general, de detectar los problemas durante una prueba en vivo.
La gua de NIST establece que es importante que una prueba
no interrumpa nunca las operaciones normales. Nosotros
haramos una modificacin. Si no se interrumpen las
operaciones normales significa que nunca se realiza un ejercicio
completo de recuperacin ante desastres. Por consiguiente,
resulta necesario interrumpir dichas operaciones normales de
forma ocasional. El nmero de pruebas perjudiciales deber ser
el mnimo, tal vez una o unas pocas veces al ao, siempre que
se realicen de forma ms regular las comprobaciones de los
componentes y subsistemas. Es importante recordar que
resulta siempre menos caro exponerse al coste de una prueba
completa con un mtodo planificado que descubrir, durante un
desastre, que una dependencia delicada y olvidada le conduce a
una incapacidad de recuperacin absoluta.

Los dos primeros recaen directamente en el mbito de los


responsables de la planificacin de la recuperacin ante
desastres y, en consecuencia, puede realizarse la planificacin
directa. El ltimo exige tener en cuenta el impacto de los
cambios sobre el plan de recuperacin ante desastres
introducido como una consideracin estndar de los
procedimientos que quedan fuera del mbito de preocupacin
directa de los responsables de dicho plan de recuperacin ante
desastres. Como consecuencia, es necesario que, de un modo
u otro, los responsables de cambios en los sistemas asuman
cierto nivel de responsabilidad ante el impacto del plan de
recuperacin ante desastres. A pesar de que podra resultar
difcil, permite que el mantenimiento de un plan correcto de
recuperacin ante desastres resulte significativamente menos
costoso que el descubrimiento tardo de los cambios a travs
de las comprobaciones o de una revisin anual.

Un pensamiento final
Esperamos que la presente gua le resulte til en sus esfuerzos
de planificacin de la recuperacin ante desastres. Tambin le
animamos a que explore otras fuentes de informacin. La gua
NIST contiene valiosa informacin adicional, ciertos aspectos
del desarrollo del plan con ms detalle y una perspectiva
ligeramente diferente. Tambin existen otros muchos recursos
ah fuera y merece la pena que invierta esfuerzo en revisar
algunos de ellos para deducir qu sugerencias y recursos son
ms tiles para usted.

Por ltimo queremos apuntar que es importante pensar en la


faceta de las pruebas de su plan a travs de los pasos
anteriores, puesto que la comprobacin representa una parte
significativa en el coste total de su plan de recuperacin ante
desastres. En especial, cuando se consideren soluciones y
proveedores concretos, considere la capacidad de
comprobacin dentro del proceso de evaluacin.
Una formacin adecuada resulta igualmente vital. La
formacin en procedimientos de recuperacin ante desastres
debe considerarse como parte de la orientacin regular de los
nuevos contratos, si stos tienen algn papel en la
implementacin del plan. El personal clave de recuperacin
ante desastres deber recibir formacin con la frecuencia
suficiente para que se encuentren estrechamente
familiarizados con los procedimientos que tendrn que
ejecutar bajo el plan. Como se indicaba en la gua NIST, el caso
ideal sera una formacin suficiente para que puedan ejecutar
sus responsabilidades sin la ayuda del documento de
planificacin para recuperacin ante desastres real.

Otros productos CA XOsoft


CA XOsoft ofrece otros productos para proteger el acceso a
sus datos y aplicaciones ms importantes, as como para
aadir valor a travs de una entrega de contenidos rpida y
totalmente flexible. Para obtener ms informacin, le rogamos
compruebe nuestra pgina Web o contacte con un
representante CA XOsoft.
CA XOsoft WANSync para recuperacin ante desastres
CA XOsoft WANSync para entrega de contenidos
CA XOsoft Enterprise Rewinder

Paso 7. Mantenimiento del plan

Puede descargar una evaluacin de prueba de 14 das del


software en: http://www.xosoft.com/download/index.shtml

Si tanto en tiempo como en dinero merece la pena desarrollar


un plan de recuperacin ante desastres, tambin merece la
pena el esfuerzo de garantizar que dicho plan refleje de forma
precisa los requisitos y sistemas actuales. De lo contrario, es
slo cuestin de tiempo que los dos disientan lo suficiente
como para hacer peligrar de verdad su capacidad de
recuperacin ante un desastre.

Correo electrnico: info@xosoft.com


Web: http://www.xosoft.com

Por lo general, este paso se sale del mbito del presente


documento, pero queremos hacer una reflexin.
Existen tres puntos naturales en los que puede revisarse el
plan: durante las pruebas, en un examen regular anual o
semestral dedicado de forma especfica a la tarea de revisin, y
cuando las modificaciones se realizan en cualquiera de los
sistemas de TI que se estn protegiendo o en los procesos
empresariales a los que dan soporte.
13

Apndice A. Muestra del Formulario de Informacin sobre el Sistema (SIF)


Nombre del sistema:

Caractersticas ID:

Fecha:

Prioridad del sistema:

Contacto:

Descripcin del sistema: [Documentacin de la arquitectura y finalidad del sistema, incluyendo los diagramas del sistema].
Requisitos de disponibilidad y rendimiento:
Impacto (costes) si no se satisfacen los requisitos:
Sistemas que dependen de ste y puntos de contacto: [Lista de los sistemas de los que este depende, conjuntamente con una
descripcin de cmo interactan. Debe haber un SIF en cada uno de ellos].
Sistemas de los que depende este sistema: [Lista de los sistemas de los que este depende, conjuntamente con una descripcin
de cmo interactan. Debe haber un SIF en cada uno de ellos].
Recursos de TI: [Lista de todos los recursos / componentes importantes del sistema, incluyendo hardware, software, espacio,
utilidades, etc. Caracterizar el impacto sobre todo el sistema o los datos, recursos y funciones relacionados, si el recurso o
componente no se encuentra disponible, as como el periodo de tiempo mximo aceptable que el recurso puede permanecer no
disponible antes de que el impacto resulte grave. Las prioridades pueden indicarse con un sistema conveniente, pero debe
utilizarse de forma coherente en los recursos, datos y funciones de este sistema y en todos los sistemas].
Recurso

Impacto y coste del


corte de electricidad

Tiempo mximo de
corte de electricidad

Prioridad

Datos y funciones
relacionados

Recursos de datos: [Lista de todos los datos importantes que produce el sistema o se utilizan como parte de ste. Si los datos
se originan en otro lugar o se pasan a otro sistema, incluya el otro sistema. Caracterizar el impacto sobre todo el sistema o los
datos, recursos y funciones relacionados, si los datos se corrompen o no se encuentran disponibles, as como el periodo de
tiempo mximo aceptable que los datos pueden permanecer no disponibles antes de que el impacto resulte grave. Las
prioridades pueden indicarse con un sistema conveniente, pero debe utilizarse de forma coherente en los recursos, datos y
funciones de este sistema y en todos los sistemas].
Funcin

Impacto y coste de la
falta de disponibilidad

Tiempo mx. de falta


de disponibilidad

Prioridad

Recursos y datos
relacionados

Roles: [Lista de todas las funciones que constituyen una parte importante en el funcionamiento normal o configuracin del
sistema. Caracterizar el impacto sobre todo el sistema o los datos, recursos y funciones relacionados, si la funcin queda sin
cubrir, as como el periodo de tiempo mximo aceptable que la funcin puede continuar sin ser cubierto antes de que el
impacto resulte grave. Las prioridades pueden indicarse con un sistema conveniente, pero debe utilizarse de forma coherente
en los recursos, datos y funciones de este sistema y en todos los sistemas].
Funcin

Impacto y coste de la
falta de disponibilidad

Tiempo mx. de falta


de disponibilidad

14

Prioridad

Recursos y datos
relacionados

Apndice B. Muestra del Formulario de Informacin sobre el Sistema Principal


(SIF Maestro)
N de ID

Nombre del sistema


Corte de electricidad mx.

Propsito
Impacto

N de ID de las
dependencias

Estrategia de recuperacin

1.
2.
3.
4.
5.

Apndice C. Muestra del Formulario de Estrategia de Recuperacin del


Sistema (SRSF)
Nombre del sistema:

ID:

Fecha:

Estrategias de recuperacin al nivel de los sistemas:


1.

Breve descripcin de la estrategia de recuperacin 1

Clculo aproximado Subsistemas necesarios


de los costes

2.

Breve descripcin de la estrategia de recuperacin 2

Clculo aproximado Subsistemas necesarios


de los costes

Estrategias de recuperacin al nivel de los componentes:


Nombre de los recursos de TI:
1.

Breve descripcin de la estrategia de recuperacin 1

Clculo aproximado Subsistemas necesarios


de los costes

2.

Breve descripcin de la estrategia de recuperacin 2

Clculo aproximado Subsistemas necesarios


de los costes

Nombre de los recursos de TI:


1.

Breve descripcin de la estrategia de recuperacin 1

Clculo aproximado Subsistemas necesarios


de los costes

2.

Breve descripcin de la estrategia de recuperacin 2

Clculo aproximado Subsistemas necesarios


de los costes

3.

Breve descripcin de la estrategia de recuperacin 3

Clculo aproximado Subsistemas necesarios


de los costes

Nombre de los recursos de datos:


1.

Breve descripcin de la estrategia de recuperacin 1

Clculo aproximado Subsistemas necesarios


de los costes

Nombre de la funcin:
1.

Breve descripcin de la estrategia de recuperacin 2

Clculo aproximado Subsistemas necesarios


de los costes
15

Copyright 2007 CA. Todos los derechos reservados. Todas las marcas comerciales, nombres comerciales, marcas de servicio y logotipos mencionados en este documento pertenecen a sus
propietarios respectivos. Este documento tan slo tiene fines informativos. En la medida permitida por las leyes aplicables, CA proporciona este documento Tal cual sin garanta de ningn tipo,
incluidas y sin limitacin ninguna garanta implcita de comercializacin o idoneidad para un propsito particular y no infraccin. En ningn caso CA ser responsable de ningn dao o perjuicio,
directo o indirecto, causado por el uso de este documento incluyendo, sin limitacin, las prdidas de beneficios, interrupciones del negocio o prdida de plusvalas o datos, incluso si CA es
informada expresamente de dichos daos.
MP310390107

RF10041 PDRP SPA WP 06.07

You might also like