Gerenciamento da Continuidade de TI: 07 pontos críticos

07 problemas e desafios do processo de Gerenciamento de Continuidade de serviços de TI que inibem o seu sucesso nas organizações.

Segundo a biblioteca da ITIL V3 , a Gestão de Continuidade de Serviços de TI é o processo que tem como objetivo apoiar a Gestão de Continuidade de Negócio, garantindo que as instalações de TI e serviços essenciais (incluindo sistemas, redes, aplicações, repositórios de dados telecomunicações, meio ambiente, apoio técnico e #Service Desk ) possam ser retomados dentro dos requisitos e prazos adequados a necessidade de negócio, em caso de ocorrência de paradas e desastres.

Por ser um processo que envolve riscos, procedimentos, conscientização, detalhes e ações proativas, é comum que seja um trabalho difícil para as organizações. Qualquer detalhe esquecido pode prejudicar o retorno da operação, quando for preciso restaurar a estrutura de retorno. Um exemplo clássico de insucesso é o que ocorreu com algumas empresas depois do atentado do 11 de Setembro em NY: muitas delas guardavam suas estruturas de contingência na torre gêmea vizinha, e "sumiram do mapa" após a tragédia.

A seguir, listo 07 problemas e desafios que organizações enfrentam ao planejar e operar os planos de continuidade de TI.

1) Departamento de TI não conseguir convencer da importância que pontos críticos de TI tem para o negócio.
Por não ter intimidade técnica com os serviços e estrutura de TI, a direção da organização pode não patrocinar projetos de continuidade dos erviços de tecnologia, por não compreender o risco que correm na falta deles. Para que a alta direção compre a ideia, é necessário que o serviços de TI estejam bem descritos em linguagem e efeito em relação ao impacto na área de negócio. Para tanto, pode ser importante que processos como Gerenciamento do Portfólio de serviços de TI, Gerenciamento de Nível de Serviços, Gerenciamento do Catálogo de Serviços e Gerenciamento da Capacidade já estejam bem maduros na organização, pois eles trarão informações que facilitam este alinhamento TI x Negócio.

2) Falta de testes adequados na estrutura de recuperação.
Este é um ponto bastante sensível: é comum que equipes, sobretudo de infra estrutura, tenham preparadas estruturas de contingência mas deixem de realizar testes nestes equipamentos / ferramentas / dados. Quem garante então, que a contingência está funcionando? Realizar testes, por ser uma atividade de natureza proativa, muitas vezes é realizada apenas quando a organização determina como uma regra.

3) Falta de controle de mudanças na estrutura de recuperação.
Para que o "plano B" funcione, caso seja necessária invocar a estrutura de retorno, é necessário que o controle de mudanças esteja bem definido e adotado pelos responsáveis. Qualquer mudança na estrutura principal deve ser refletida na contingência.

4) Falta de definição de requisitos, baseados em impacto na área de negócio.
Por falta de alinhamento entre o departamento de TI e a área de negócio, pode ocorrer da equipe de TI tomar a inciativa de criar estruturas de recuperação baseadas em decisões próprias, desalinhadas com necessidades da organização.

5) Falta de capacitação e conscientização da equipe.
Para que um plano de recuperação seja invocado adequadamente é preciso que os envolvidos estejam capacitados e conscientizados para esta atividade. Regras, responsabilidade, níveis de serviço mínimos, 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 análise de vulnerabilidade antes da análise de impacto.
Se um equipamento de uma determinada estrutura está extremamente vulnerável a alguma ameaça 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 serviço entregue a área de negócio. Portanto, a análise de impacto deve ser precedida dentro da análise de riscos. Em um outro exemplo, se um software de análise de vulnerabilidade é instalado em seu ambiente e detecta centenas de pontos de vulnerabilidade em sua rede, não significa que você esteja em uma situação crítica, é preciso conhecer exatamente o que está ou não vulnerável e o apetite de riscos da diretoria para chegar a conclusão da criticidade desta análise.

7) Pânico e caos no momento do desastre.
Um desafio bastante comum em países 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 próprias vidas. Atividades para quais são necessárias intervenções humanas para recuperar serviços, provavelmente deixarão de ocorrer. Na medida do possível, é preciso estar bem planejado para isto.