Para adotar contingência, não é preciso esperar o caos

Projetos de redundância e prevenção ganham importância
O dia três de julho ficou marcado para muitos profissionais de TI como a data que seus sistemas de redundância foram postos à prova. Uma pane na rede IP/MPLS da Telefônica deixou o Estado de São Paulo sem internet durante quase 40 horas. Diversas empresas ficaram sem poder realizar atividades importantes, no entanto, aquelas que dependiam da web para sobreviver (como companhias com vendas online) foram as que mais sofreram.
Com proporções enormes, o estrago deixou um aprendizado: não há contrato de nível de serviço (SLA, na sigla em inglês) que substitua a redundância – de links, de sistemas, de data centers, de tudo. E também deixou claro que poucas empresas têm estruturado este processo de forma adequada. O primeiro motivo para isso é o custo extra ao orçamento de TI. Para se ter uma idéia, a Empresa Brasileira de Correios e Telégrafos (ECT) gastou, entre 2001 e 2008, cerca de R$ 226,5 milhões na centralização do processamento de dados em dois data centers, um em Brasília e outro em São Paulo, que operam em esquema de contingência.
Os sites abrigam os sistemas corporativos que manipulam dados de interesse geral da empresa e que tenham reflexo nos resultados contábil, financeiro, administrativo e operacional da ECT. “Como padrão de instalação, eles foram acomodados em salas de segurança física, com tamanhos variando entre 150 m² a 350 m²”, diz Menassés Leon Nahmias, diretor de tecnologia e infra-estrutura dos Correios.
O projeto da companhia aparenta quase como um esquema de guerra contra a falta de acessibilidade. Isso porque as operações dependem basicamente do cumprimento de prazos, que, por sua vez, estão diretamente ligados ao funcionamento ininterrupto dos sistemas. Mas, mesmo para empresas que não operam em esquema de missão crítica, todos sabem o quanto atrapalha uma queda de um sistema ou de um link. O difícil é convencer a diretoria que isso pode acontecer e, pior, com graves conseqüências. Aimar Martins Lopes, professor da Fundação Escola de Comércio Álvares Penteado (Fecap) nas disciplinas de sistemas de informação e gestão de negócios, diz que os altos investimentos de projetos de redundância ganham proporções maiores pelo fato de não serem “produtivos” e não estarem diretamente atrelados à redução de despesas ou aumento de receita. Mas, certamente, podem evitar prejuízos.Aposta na prevençãoA Serasa possui infra-estrutura redundante há cinco anos, com replicação total dos recursos em dois sites diferentes. A empresa já enfrentou incidentes nos quais, sem este esquema, teria perdido faturamento e a confiança do cliente, além de diminuição do padrão de qualidade ou até mesmo visto ir embora alguns contratos. “Uma dificuldade qualquer no nosso sistema impacta não só a nossa produtividade, mas a dos clientes também, o que pode levar a queda de receita para eles e, conseqüentemente, para nós”, explica o CIO da empresa, Dorival Dourado.
Já a produtora de aves Doux Frangosul, a exemplo de outras empresas industriais, está em fase incipiente na adoção de processos e ferramentas de recuperação de desastres. Rafael Nicolela, gerente-geral de TI da companhia, acredita que os sistemas de redundância ficaram mais latentes por conta da migração dos softwares de gestão do ambiente mainframe – redundante por construção – para plataformas baixas. “Com a migração, surge um número maior de elementos de TI necessários para a entrega dos serviços, e todos estes itens podem falhar”, pondera.
Para desenhar seu esquema de contingência, a Doux Frangosul identificou os elementos mais críticos para a entrega do ERP e quais seriam as soluções para redução dos riscos. No segundo semestre deste ano, a Doux vai ganhar a reestruturação física do data center, que hoje ainda não conta com contingência.
Outra razão pela qual as empresas não consideram esquemas de redundância é a maior complexidade na operação. Replicar um sistema que já existe e está rodando e fazer com que duas estruturas caminhem juntas demanda um planejamento minucioso dos elementos de infra-estrutura, redes, armazenamento e software envolvidos no esquema, bem como uma implantação e manutenção cuidadosas. Nahmias, dos Correios, alerta que o projeto deve envolver ainda aspectos como recursos humanos, viabilidade econômica, planejamento da comunicação, manutenção da imagem institucional em caso de sinistros graves e priorização do atendimento aos principais clientes.
Para não ter de estruturar o “plano B”, algumas corporações apóiam-se totalmente no contrato feito com os fornecedores diversos, acreditando que eles vão cumprir exatamente o prometido e que o SLA resolverá qualquer problema. Contudo, existem situações, como a queda na internet, citada no início desta reportagem, que nem o prestador de serviço conseguiu prever ou resolver em tempo hábil. “Não se pode acreditar nas especificações técnicas dadas pelos fornecedores, pois às vezes elas falham e não há contrato de nível de serviço que faça um sistema voltar ao ar”, pontua Dourado.
Exatamente o que aconteceu com a Companhia de Processamento de Dados do Estado de São Paulo (Prodesp), cujo contrato com a Telefônica para estruturar uma rede MPLS e fornecer a integração das redes de comunicação de dados, voz e de vídeo das secretarias e órgãos do Estado (Intragov) previa a redundância em caso de queda nos links. Como a causa do “apagão” foi justamente na rede MPLS da operadora, em média, metade dos 13 mil links da Prodesp ficou indisponível durante a pane – em momentos alternados. “O nível do acordo de serviço é alto, com tempo de parada máximo previsto em contrato de dez horas”, ressaltou o presidente da Prodesp, Leão Roberto Machado de Carvalho, em entrevista para o portal IT Web.
No caso da Prodesp, a preocupação com a contingência ficou a cargo da Telefônica. “Nos preocupamos com a redundância, mas não dava para prever esta catástrofe. Se colocássemos todas as possíveis vulnerabilidades em contrato, o custo ficaria inviável”, afirmou, na época, Leão Machado. O contrato com a telco foi fechado por R$ 250 milhões, em meados de 2005, com vigência de cinco anos e prevê uma rede de 18 mil links.
Melhores práticasO envolvimento das áreas de negócio na avaliação dos processos críticos e do impacto de possíveis falhas no cotidiano da empresa ajuda a ultrapassar a barreira do custo da adoção de um projeto de contingência. Especialistas acreditam que, ao se depararem com os impactos negativos, a diretoria se sensibiliza e se convence da importância da redundância. Luiz Inacio Meinerz, CIO da Bausch&Lomb, empresa da área de soluções para oftalmologia, indica a análise de impacto nos negócios (ou BIA, na sigla em inglês). “Ela recebe o input das áreas de negócio acerca da criticidade de seus processos e da dependência destes da TI, mensurando os impactos e identificando pontos da TI onde a redundância é necessária ou ao menos desejável”, pontua.
O escopo deve ter contornos bastante definidos, mas nada impede que ele aumente na medida em que o processo fique maduro. Fernando Diaz Roldan, diretor-executivo da Produban, empresa do Grupo Santander, considera as melhores práticas aquelas ligadas a determinar os serviços críticos que devem entrar no pacote de contingência e os respectivos tempos de retorno. Ele orienta ainda que a equipe de TI fique atenta a problemas reais que aconteçam durante a fase de desenho. “São excelentes oportunidades para reflexão e aprimoramento de uma boa arquitetura de alta disponibilidade.”
Com os processos críticos em redundância, todos os projetos novos devem sempre levar em consideração o que está sendo implementado e qual o impacto para a operação da empresa. “Desta maneira, pode-se tomar a decisão de incluir ou não o projeto no esquema de contingência. Se o projeto adiciona equipamentos ou serviços no site principal, isso também deve ser levado em conta”, lembra José Parolin, líder global de aplicações da Cargill, para quem a melhor hora para a decisão sobre a redundância é justamente no planejamento.
Ou seja, o melhor caminho para as companhias não é esperar até que algum incidente ocorra, mas se preparar para prevenir e antecipar possíveis conseqüências graves. Assim como todos os projetos, o plano de redundância deve primar pelo equilíbrio entre necessidade e orçamento, levando em consideração quais sistemas e equipamentos devem constar. Seja pela demonstração “ao vivo” dos prejuízos que a queda de sistemas sem contingência podem trazer, seja pelo plano de negócios, as companhias têm mostrado que estão preocupadas com o assunto e têm trabalhado para colocar o tema em prática, para evitar de deixar os negócios no escuro.