Processo de

gerenciamento da
continuidade do
servio de TI
Pergunta: O que um desastre?

Pode parecer estranho comear a abordagem sobre gerenciamento da continuidade com esta
pergunta. Mas a falta de conscientizao de muitos gestores pode fazer com que a palavra desastre
traga uma enorme dor de cabea.
Segundo o OGC (2006, p. 155), desastre um acontecimento que afeta de tal forma um servio ou
sistema que a restaurao do seu nvel de desempenho original exige considervel esforo.
Um incidente chega a ser insignificante perto de um desastre, pois o desastre causa uma interrupo
no negcio. Dependendo da sua intensidade, o negcio pode parar parcial ou totalmente.
Os desastres podem acontecer de vrias formas, desde ataques via rede, causando a ruptura nas
comunicaes da organizao, at atravs de raios, incndios, enchentes (ou qualquer outro dano
causado pela gua), roubo, falta de energia, defeito no hardware, etc.

Isso tudo poderia trazer menos dor de cabea para as organizaes se as mesmas desenvolvessem
planos de continuidade do negcio. Este ato se torna cada vez mais importante na medida em que as
organizaes se tornam cada vez mais dependentes dos servios de TI.
O processo de gerenciamento da continuidade dos servios de TI prega que desastres sejam evitados
atravs da preveno.

Objetivos
O gerenciamento da continuidade visa a suportar o processo de gerenciamento da continuidade do
negcio com a garantia de que a infraestrutura tcnica e de servios sejam recuperadas dentro do
prazo especificado e acordado com o cliente. Para exemplificar, os servios a serem garantidos
podem ser: sistemas, aplicaes, redes, telecomunicaes, banco de dados, suporte e central de
servios.
Isso pode ser alcanado criando e/ou mantendo planos de continuidade atualizados, atravs de
constante anlise de risco em conjunto com o gerenciamento da disponibilidade e segurana.
Alm disso, contratos com empresas terceiras podem ser feitos para o provisionamento de
capacidades de recuperao que faam parte desses planos.
Ao se preocupar em fazer um plano de continuidade, a organizao deixa mais fcil a administrao
de uma recuperao dos sistemas, caso um desastre venha acontecer. Tem mais tempo de
disponibilidade de servio, oferece melhor continuidade dos servios para os usurios e minimiza a
interrupo de suas atividades.

O processo
de responsabilidade do gerenciamento da continuidade:
a. aps um desastre, fazer a avaliao do risco e impacto da perda dos servios de TI;
b. fazer a definio de tempo de restaurao dos servios;
c. identificar servios primordiais para o negcio para provimento de medidas de preveno
adicionais;
d. fazer a definio de qual abordagem ser tomada para a restaurao dos servios;
e. tomar medidas para prevenir e reduzir os efeitos do impacto de um desastre;

f. criar, manter e testar um plano de recuperao que seja bem detalhado para restaurar os servios,
no perodo definido, aps um desastre.
bom que dois conceitos fiquem bem estabelecidos:
O gerenciamento da continuidade do negcio (GCN) gerencia os riscos a fim de garantir que a
todo tempo a organizao possa dar continuidade sua operao, ao menos, em um nvel mnimo
predeterminado. Esse processo tem por finalidade reduzir os riscos a nveis aceitveis e criar planos
de recuperao para restaurar as atividades do negcio se esses riscos se materializarem e ocorrer
uma interrupo no negcio.
O gerenciamento da continuidade dos servios de TI (GCSTI) trabalha com os desastres que
afetam os servios de TI e mantm os servios em pleno funcionamento a fim de garantir que o
negcio no sofra interrupes. O GCSTI parte e depende do GCN.
Importante: O direcionamento do processo de gerenciamento da continuidade dos servios de TI
ocorre de acordo com os requisitos do negcio e no baseado no que a organizao de TI acha que o
negcio necessita. O GCSTI dependente das informaes que so fornecidas pelo GCN.

A anlise de impacto no negcio consiste em uma tcnica usada na identificao dos requisitos
mnimos necessrios de sistemas para manter os processos de negcio crticos.
A determinao desses requisitos vem do impacto da perda de um processo de negcio, tanto das
perdas financeiras, ou danos imagem corporativa, alm da quebra de regulamentos e leis.
A anlise de risco consiste no levantamento feito sobre as ameaas e nveis de vulnerabilidade.
Cada ameaa associada a uma possvel interrupo nos servios crticos, tanto de TI, quando do
negcio. Dessa tarefa geralmente so originados um relatrio e um plano para aplacar os riscos.

Relacionamento com outros processos

O gerenciamento da continuidade dos servios de TI interage, particularmente, com os seguintes

processos:
a. gerenciamento do nvel de servio, fornecendo informaes sobre as obrigaes dos servios de
TI;
b. gerenciamento da disponibilidade, desenvolvendo e implementando medidas de preveno;
c. gerenciamento da configurao, fornecendo informaes sobre o que preciso restaurar depois
de um desastre;
d. gerenciamento de capacidade, garantindo que as exigncias do negcio tenham suporte dos
recursos de TI;
e. gerenciamento de mudana, garantindo que todos os planos do gerenciamento da continuidade
dos servios de TI estejam atualizados e corretos.
Os itens abordados nesta leitura mostram que os desastres podem acontecer de vrias formas e que
poderia ser bem mais fcil se as organizaes desenvolvessem planos de continuidade do negcio. O
processo de gerenciamento da continuidade do servio de TI investiga, desenvolve e implementa
opes de recuperao de servios quando ocorrer uma interrupo grave no servio.
Referncia
OFFICE OF GOVERNMENT COMMERCE (OGC). Introduo ao ITIL. Norwich: OGC, 2006.
Autores: Miguel Garcia Junior e Rodrigo Santana

Gerenciamento da Continuidade de TI: 07 pontos crticos

07 problemas e desafios do processo de

Gerenciamento de Continuidade de
servios de TI que inibem o seu sucesso
nas organizaes.
Segundo a biblioteca da ITIL V3, a Gesto de Continuidade de
Servios de TI o processo que tem como objetivo apoiar a Gesto de
Continuidade de Negcio, garantindo que as instalaes de TI e servios
essenciais (incluindo sistemas, redes, aplicaes, repositrios de dados
telecomunicaes, meio ambiente, apoio tcnico e Service Desk) possam

ser retomados dentro dos requisitos e prazos adequados a necessidade de

negcio, em caso de ocorrncia de paradas e desastres.
Por ser um processo que envolve riscos, procedimentos, conscientizao,
detalhes e aes proativas, comum que seja um trabalho difcil para as
organizaes. Qualquer detalhe esquecido pode prejudicar o retorno da
operao, quando for preciso restaurar a estrutura de retorno. Um exemplo
clssico de insucesso o que ocorreu com algumas empresas depois do
atentado do 11 de Setembro em NY: muitas delas guardavam suas
estruturas de contingncia na torre gmea vizinha, e "sumiram do mapa"
aps a tragdia.

A seguir, listo 07 problemas e desafios que organizaes enfrentam ao

planejar e operar os planos de continuidade de TI.
1) Departamento de TI no conseguir convencer da importncia que
pontos crticos de TI tem para o negcio.
Por no ter intimidade tcnica com os servios e estrutura de TI, a direo
da organizao pode no patrocinar projetos de continuidade dos servios
de tecnologia, por no compreender o risco que correm na falta deles. Para
que a alta direo compre a ideia, necessrio que os servios de TI
estejam bem descritos em linguagem e efeito em relao ao impacto na
rea de negcio. Para tanto, pode ser importante que processos como
Gerenciamento do Portflio de servios de TI, Gerenciamento de Nvel de
Servios, Gerenciamento do Catlogo de Servios e Gerenciamento da
Capacidade j estejam bem maduros na organizao, pois eles traro
informaes que facilitam este alinhamento TI x Negcio.

2) Falta de testes adequados na estrutura de recuperao.

Este um ponto bastante sensvel: comum que equipes, sobretudo de
infra estrutura, tenham preparadas estruturas de contingncia mas deixem
de realizar testes nestes equipamentos / ferramentas / dados. Quem
garante ento, que a contingncia est funcionando? Realizar testes, por ser
uma atividade de natureza proativa, muitas vezes realizada apenas
quando a organizao determina como uma regra.
3) Falta de controle de mudanas na estrutura de recuperao.
Para que o "plano B" funcione, caso seja necessria invocar a estrutura de
retorno, necessrio que o controle de mudanas esteja bem definido e
adotado pelos responsveis. Qualquer mudana na estrutura principal deve
ser refletida na contingncia.

4) Falta de definio de requisitos, baseados em impacto na rea de

negcio.

Por falta de alinhamento entre o departamento de TI e a rea de negcio,

pode ocorrer da equipe de TI tomar a inciativa de criar estruturas de
recuperao baseadas em decises prprias, desalinhadas com
necessidades da organizao.
5) Falta de capacitao e conscientizao da equipe.
Para que um plano de recuperao seja invocado adequadamente preciso
que os envolvidos estejam capacitados e conscientizados para
esta atividade. Regras, responsabilidade, nveis de servio mnimos,
procedimentos; tudo isto deve ser do conhecimento de todos. Ignorar esta
necessidade provavelmente causar uma desordem no momento do
desastre, agravando o caos.
6) Realizar anlise de vulnerabilidade antes da anlise de impacto.
Se um equipamento de uma determinada estrutura est extremamente
vulnervel a alguma ameaa significa que eu devo priorizar este ativo
dentro do meu planejamento de continuidade, certo? Errado. A primeira
pergunta que devemos nos fazer sobre impacto deste equipamento para o
servio entregue a rea de negcio. Portanto, a anlise de impacto deve ser
precedida dentro da anlise de riscos. Em um outro exemplo, se um
software de anlise de vulnerabilidade instalado em seu ambiente e
detecta centenas de pontos de vulnerabilidade em sua rede, no significa
que voc esteja em uma situao crtica, preciso conhecer exatamente o
que est ou no vulnervel e o apetite de riscos da diretoria para chegar a
concluso da criticidade desta anlise.
7) Pnico e caos no momento do desastre.
Um desafio bastante comum em pases nos quais ocorrem desastres
naturais. Por mais que os planos de continuidade estejam bem definidos,
procedimentos elaborados, equipe treinada e conscientizada, natural que
no momento do desastre as pessoas corram para salvar suas prprias vidas.
Atividades para quais so necessrias intervenes humanas para recuperar
servios, provavelmente deixaro de ocorrer. Na medida do possvel,
preciso estar bem planejado para isto.