23 de dez. de 2006

Segurança Física para Data Centers - Definindo o Atendimento ao Negócio


O anuário sobre gerenciamento de projetos, CHAOS Report, publicado pelo The Standish Group, apresenta as principais causas de falhas em projetos, e elas se alternam em diferentes posições mas com a mesma lista na maioria das publicações e pesquisas sobre este tema. Eu gostaria de chamar a sua atenção para três delas, que você já deve ter visto ou verá em sua vida profissional:

  1. Falta de um patrocinador: Entrar em um projeto sem um patrocinador, significa que não existe uma pessoa com poder na Organização para manter o foco junto aos clientes internos, buscar fundos adicionais caso seja necessário reavaliar os custos envolvidos e mesmo negociar com áreas resistentes ao que é proposto. Sem este componente, o projeto pode tropeçar em algum obstáculo e simplesmente ser cancelado se alguém entender que as prioridades do negócio foram alteradas.
  2. Falta de visão: Um projeto sempre é iniciado por uma idéia, que deve ser explorada para conter objetivos, premissas, cronograma de atividades, responsáveis, relacionamento de tarefas e todos os demais componentes do gerenciamento de projetos. Porém, é comum no andamento do processo que novas idéias surjam e se não houver alguém focado em manter a busca do objetivo comum, os esforços podem ser direcionados para outras atividades que não necessariamente irão ajudar a cumprir a missão original.
  3. Erro na definição de requerimentos: Qualquer projeto envolve pessoas, e muitas delas ficam impacientes com o processo de definição de requerimentos porque ele leva tempo, envolve todas as áreas que farão uso do objeto do projeto e deve ser o mais completo possível. A vontade de “fazer acontecer” das Organizações (ou a incompetência de alguns gestores mesmo …) costuma pressionar o gerente de projetos a completar essa etapa o mais rápido possível, mesmo que de forma incompleta. Isso, somado ao costumeiro “… aproveita que está fazendo isso e inclua aquilo …” que acontece no meio do caminho, são razões para impossibilitar o projeto de dar certo.

A criação de um data center deve ser tratada como um projeto, e como tal deve incluir a definição prévia dos requerimentos que a Organização irá definir, ou ajudar o responsável pela iniciativa a desenhar com base na necessidade de atendimento dos processos de negócio em questão. Isso é muito difícil se você não fala a “linguagem de negócios” comum, e pode ser auxiliado ao incluir na equipe do projeto uma pessoa que sirva de interface entre os requerimentos técnicos e o discurso dos gestores.

Ouvir os gestores da Organização dizerem que o data center deve estar disponível 100% do tempo é comum, mas fazer eles aceitarem o custo que isso implica é complicado e só pode ser feito com base em métricas claras que os ajudem a tomar uma decisão baseada em fatos e evidências, ao invés do discurso FUD  que sempre achei a pior das opções. Tabelas comuns a essa disciplina podem ser encontradas em livros e artigos sobre o assunto e usadas como exemplos para suportar esta decisão, porém recomendo fortemente que você as use como base para criar os seus próprios documentos com base em informações financeiras da Organização em questão.

A tabela abaixo é uma delas, e tem como objetivo definir o que cada classe de disponibilidade significa em termos de parada, e quanto a definição, implementação e manutenção dos controles de segurança necessários para a manutenção da disponibilidade pelo tempo desejado pode custar em termos relativos entre elas.

Classe
Tempo de Parada/AnoCusto Relativo
Convencional5-10 diasBaixo
Média Disponibilidade3-5 diasMédio
Alta Disponibilidade1 horaAlto
Altíssima Disponibilidade5 minutosAltíssimo

Note que o tempo de parada existe não só devido a falhas, mas existem necessidades de atualização de software, manutenção de hardware e mesmo testes de segurança (ex. Plano de Continuidade) do data center que irão exigir a parada dos sistemas. Isso irá acontecer em qualquer Classe adotada, e irá impactar diretamente nos processos de negócio da Organização, que devem ser sempre o guia para definir qual é a disponibilidade necessária.

Uma empresa que tem a concessão de um serviço público crítico (ex. Telefonia) possivelmente terá uma necessidade de disponibilidade maior do que uma empresa que vende bens de consumo com clientes que compram somente durante os dias úteis em horário comercial. É isso que deve ser exposto para as pessoas que irão definir os critérios do data center, e só poderá ter sucesso se várias áreas forem envolvidas.

Procure colocar frente a frente o Departamento de Vendas (que irá querer 100% de disponibilidade …) com o Departamento Financeiro (que irá quere o menor custo possível), municie ambos com informações, deixe-os discutir e aja como consultor técnico, a decisão final não é sua, é do negócio que rege a Organização. Somente depois de a disponibilidade necessária ser definida, o processo poderá ir para a frente, tenha isso em mente e não meça esforços para buscar esta premissa antes de conduzir o projeto.

Nenhum comentário:

Postar um comentário