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.

Uma pergunta bastante relevante que surge na cabeça de quase todos os programadores certa hora da vida é: por que existem tantas linguagens de programação? Outra bastante comum é: qual delas é melhor? Alguém poderia responder: existem tantas porque uma vem para corrigir as falhas das outras, e a melhor é a que tem menos falhas. Certo? Errado.
Na Wikipédia, há uma lista com mais de uma centena de linguagens de programação. Será que todas elas surgiram para sanar problemas umas das outras? Se olharmos o histórico de surgimento de cada linguagem de programação, veremos que a maioria surgiu para sanar uma necessidade diferente numa determinada área. Isso já nos dá uma pista de qual delas é melhor.
Vamos começar analisando um exemplo famoso: Java. Java nasceu para substituir C e C++? Não. Java nasceu por causa da Orientação a Objetos? Não mesmo! Por que, então, Java nasceu? Nasceu pela necessidade de uma linguagem portável (cujos programas rodassem em plataformas diferentes sem necessidade de alterações). Mas já não existiam linguagens assim? Sim, existiam, mas não com esse enfoque. LISP, Smalltalk e Perl, por exemplo, são linguagens portáveis, assim como Java. Mas LISP, por exemplo, tem um paradigma de programação totalmente diferente. Smalltalk e Perl, um escopo diferente. Smalltalk, por exemplo, nasceu com o objetivo de tornar a programação mais intuitiva. Perl nasceu com o objetivo de ser uma linguagem poderosa e prática.
Há linguagens que surgiram de uma necessidade ainda mais específica. Simula, por exemplo, nasceu pela necessidade de realizar simulações de eventos discretos. MUMPS, pela necessidade de desenvolver aplicações baseadas em bancos de dados para um hospital.
Entretanto, nem todas as linguagens resolvem um problema novo. Há, sim, linguagens que vêm para competir com outras. C#, por exemplo, veio para competir com Java, uma competição que influenciou bastante esta última. Há, também, linguagens que surgem para simples diversão de geeks, como nós. Whitespace, por exemplo, não tem nada de inovador, apenas a forma de programar: o código-fonte é escrito usando-se tabs e espaços.
Dado que cada linguagem tem seus pontos fortes e fracos, não podemos dizer que uma certa linguagem é a melhor. Podemos sim, dizer, que uma linguagem é a melhor para determinado problema numa determinada situação. E, para dizer isso, precisamos avaliar o problema, o que a linguagem oferece para resolvê-lo e o que o programador sabe sobre ela. Fatores importantes na linguagem são o suporte nativo às ferramentas e paradigmas que serão utilizados e bibliotecas e extensões disponíveis.
Às vezes não vale a pena para o programador aprender uma linguagem na qual ele resolveria um problema mais facilmente; o tempo que ele levaria para aprender a nova linguagem (ou ferramenta) é maior do que o tempo que ele vai levar para resolver o problema na linguagem com a qual ele é mais familiar. Note que esse não deve ser um fator tão importante na escolha. Às vezes é melhor que o problema demore mais para ser resolvido para que depois alterações na solução possam ser incorporadas mais facilmente.
Não podemos dizer que existe a melhor e a pior linguagem, mas podemos dizer que existem linguagens boas e ruins. A linguagem ruim é aquela que não ajuda o programador a utilizar seus recursos corretamente, por exemplo: ser uma linguagem poderosa para orientação a objetos mas, ao mesmo tempo, não oferecer suporte fácil para pacotes.
É sempre bom tomar contato com diversas linguagens para saber qual usar em cada situação. Para começar, sugiro que se escolham linguagens sem uma relação forte (uma inspirada na outra). Uma boa lista de linguagens para estudar, na minha opinião:
Smalltalk
Prolog
Scheme
C
Self
Erlang
Assembly (para os mais corajosos)
Propositalmente, são linguagens não muito recentes, especialmente Assembly, C, Prolog e Scheme. As linguagens mais recentes, baseadas nessas, têm muitos recursos avançados. É bom começar pelo básico e, depois de capturar a forma de pensar em cada linguagem, partir para recursos mais avançados.
Especialmente para estudar Assembly (ou, pelo menos, os conceitos dela), sugiro usar uma máquina virtual como o Hipo.

46% das empresas brasileiras desenvolvem em Java

Pesquisa mostra crescimento do mercado de linguagens de programação da Microsoft, apesar da predominância de Java
Entre as empresas brasileiras de software, predomina o uso de linguagem de programação Java, citada por 46% dos entrevistados pela pesquisa realizada pela MBI - Mayer & Bunge Informática, em colaboração com a Associação das Empresas Brasileiras de Tecnologia da Informação, Software e Internet (Assespro - São Paulo) e do Instituto de Tecnologia de Software (ITS). A pesquisa traçou um panorama das 50 maiores representantes do setor.
Outros 20% utilizam linguagem C ou C++ para desenvolver software, e 36% trabalham com Visual Basic. Delphi foi citado por 32% dos entrevistados. Tecnologias consideradas mortas também foram citadas pelos desenvolvedores brasileiros, como Clipper (10%), Cobol (6%) e PHP (4%).