Artigos Canal Mais A importância do planejamento e prevenção contra eventuais falhas

Recentemente ocorreram dois eventos que chamaram a atenção nos noticiários e foram veiculados em todos os grandes meios de comunicação nacionais e internacionais.

Coincidentemente, ambos ocorreram no Brasil e no setor aéreo mais especificamente.

Embora problemas no setor aéreo, telecomunicações e bancário não sejam novidade para o brasileiro, pois o que deveria ser exceção é habitual, desta vez as falhas tomaram grandes proporções.

A primeira foi no aeroporto de Viracopos, onde um avião cargueiro quebrou no procedimento de aterrissagem e bloqueou a pista para os demais aviões.

Alguns links sobre essa noticia:

A outra falha foi no sistema utilizado pela TAM para realizar seus procedimentos de check-in, o que prejudicou não só os clientes da empresa no Brasil como também em todos os aeroportos onde ela opera.

Alguns links sobre isso:

Depois do ocorrido, tanto o Procon como a ANAC desejam apurar o ocorrido e verificar se foram tomadas as atitudes cabíveis para o caso:

Independente do que seja decidido pelo Procon ou pela ANAC, ficou muito claro que nas duas situações não existe um plano de gestão da crise, um sistema de contingenciamento, um plano pensado previamente sobre quais procedimentos adotar caso um cenário onde algo que faça parte ou seja essencial para o funcionamento normal falhe ou deixe de existir.

As ações adotadas aparentemente foram tomadas no correr da situação tentando minimizar o ocorrido, não ficou aparente em nenhum momento que houvesse um procedimento a seguir nessa situação.

Como se preparar para possíveis falhas do sistema?

Figura 1: Como se preparar para possíveis falhas do sistema?

Isso tudo nos leva a pensar em quantas empresas ou pessoas estão preparadas ou possuem um manual de procedimentos, um sistema alternativo para quando situações de crise ou falha se apresentam e o quanto isso reflete diretamente nos negócios da empresa.

Em sistemas web, sejam sites institucionais, páginas pessoais, e-commerces, etc, a intenção ao criá-los é deixá-los disponíveis 24h por dia, todos os dias da semana, o ano todo, correto?

Mas e se ele por algum motivo ficar fora do ar?

Ou se tiver o acesso ao banco de dados da aplicação comprometido ou indisponível?

E se sofrer um ataque de negação de serviço, XSS, etc.?

Você está preparado para algum desses cenários?

Já pensou o que poderá ser feito caso isso aconteça?

Enquanto a falha persistir, o quanto isso impactará nos negócios da empresa?

E os eventuais prejuízos e problemas na imagem da empresa?

Para cada tipo ou tamanho de site ou necessidade de quem o possui, as falhas citadas acima podem não ter nenhum impacto se durarem alguns dias ou horas, mas existem também aqueles não podem ficar nenhum minuto indisponível, pois o cerne do negócio reside na aplicação estar sempre disponível.

E a necessidade em estar sempre disponível não é algo que somente médios e grandes têm, o pequenino também pode ter, pois se o potencial cliente vai até ele e está indisponível, o cliente vai para o concorrente e não volta mais, deixando assim de vender e quem sabe ter um cliente que efetue compras com certa regularidade nele.

Por isso, não se pode pensar que planos de contingencia é algo que apenas grandes empresas devem ter ou algo do tipo.

Planos de contingencia e gestão de crise é algo que deve ser feito de acordo com as necessidades de cada empresa ou cliente.

Afinal, essa empresa ou cliente, comprou um software, ou contratou os serviços do desenvolvedor para ter um sistema de gestão, web site o que for, para desta forma, poder gerenciar melhor seu negócio, melhorar o atendimento a seus clientes e assim, se destacar da concorrência em algum aspecto.

É incrível uma empresa do porte da TAM não ter um sistema alternativo para realizar os procedimentos de check-in caso o principal falhasse, obrigando seus funcionários a realizá-lo manualmente.

O atraso e a insatisfação que isso gerou, já é por si só argumento mais do que suficiente para seu departamento de TI ter um sistema alternativo que opere enquanto o principal estivesse indisponível e atualiza-se o principal para manter assim os registros de forma correta para a geração de relatórios e estatísticas.

Como desenvolvedores, sabemos que é possível fazer isso, seja por meio de API'S ou pelo envio dos dados diretamente ao banco de dados no formato correto que ele armazena.

Se a empresa busca por excelência nas atividades e minimizar ao máximo eventuais prejuízos, se faz obrigatório pensar sempre no “e se...”.

Atualmente, com os sistemas de gestão sendo portados para nuvem ou desenvolvidos para operarem em diversas filiais, ou funcionando a partir do web site, não temos o controle total de todo o seu funcionamento, como era até o inicio da década passada, onde estava tudo no mesmo prédio da empresa ou algo do tipo, na maioria das empresas.

Nos dias de hoje, delegou-se muitas coisas a empresas terceirizadas seja por não ser o foco principal da empresa, seja por redução de custos e dessa forma, as eventuais falhas se tornam mais evidentes e passam a ter um peso maior quando ocorrem.

Vamos supor que a empresa (não importa o tamanho) contratou um sistema de gestão on-line para gerenciar melhor todo o negócio, por diversas razões (mobilidade, redução de custos etc.).

Para essa empresa, ela precisará ter ao menos uma segunda forma de acessar a web caso a principal falhe.

E quem comercializa esse sistema? O que precisará ter?

Ele precisará ter a garantia que o serviço que hospeda esse sistema tenha um uptime elevado, normalmente as grandes hospedagens garantem uptime de 99,99%.

E se optar por montar a estrutura de servidores localmente?

Será preciso garantir o mesmo uptime, garantindo que o fornecimento de energia não falte, bem como não fique sem acesso à internet.

Para isso, precisará investir em geradores, no-breaks, link dedicado, link alternativo via radio ou 3g, máquinas reservas, hd's reservas, etc.

Politica de backup dos dados numa frequência que em caso de perda dos dados, a restauração não seja muito distante do dia em que a falha ocorreu.

Algumas empresas realizam backups diários, outras a cada certo número de horas, depende da empresa e dos clientes que ela atende.

Redundância dos dados, possuir apenas um banco de dados pode ser satisfatório para a maioria das empresas, mas se o servidor de banco de dados ficar indisponível, as operações deixarão de ser realizadas e para impedir que a falha no acesso ao banco de dados comprometa as operações da empresa, ter um banco de dados espelho alocado num endereço diferente do principal é importante e permite que a empresa não paralise seu funcionamento.

Servidores web bem configurados, muitos dos ataques feitos a sites, sejam ataques XSS, DoS e outros, ocorrem por causa de servidores web mal configurados ou que não estão com seus patches atualizados.

Servidores de proxy reverso e outras técnicas ajudam também a reduzir significativamente a ocorrência de falhas, pois impedem o acesso direto ao servidor que abriga o sistema.

Assim como o servidor-espelho de banco de dados, um servidor-espelho da aplicação é também importante para manter o sistema funcionando sem falhas mesmo que o servidor principal fique indisponível.

E se considerarmos que os custos de hospedagem estão cada vez menores, a política de possuir espelhos se torna viável a um numero cada vez maior de empresas independente de seu tamanho.

Embora tudo isso pareça óbvio, (e realmente é!) é em casos como os citados acima que percebemos isso sendo deixado de lado por razões nem sempre claras, afinal negligenciar algo que ao falhar impactará negativamente na fonte de receitas da empresa, é no mínimo uma contradição com o objetivo principal de qualquer empresa que é o lucro. É na verdade, estúpido.

Em nome da redução de custos, não pensar em contingências para cenários de crise, e assim preferir acreditar que por razões esotéricas nunca falhará, ou algo do tipo, é como pensar que ter o pneu estepe no carro só serve para carregar um peso desnecessário, pois é muito raro o pneu do carro furar.

Mas e quando falhar?

Você estará preparado para resolver rapidamente ou vai amargar prejuízos não só financeiros como também de reputação para a empresa?

Nós desenvolvedores, normalmente programamos pensando nos requisitos do cliente, e na forma como esperamos que o usuário se comporte utilizando aquele sistema.

Como não sabemos exatamente a forma que o usuário se comportará no sistema, colocamos filtros e tentamos isolar qualquer comportamento inesperado, para se caso ocorrer, não afetar o seu funcionamento, apenas exiba uma mensagem de erro ou que ignore tal ação.

Raramente pensamos nas possibilidades de falhas ocorrerem por faltar alguma parte essencial do sistema, ou como o sistema deverá se comportar caso o banco de dados não exista.

Precisamos pensar nisso também, se o banco de dados não existir, usaremos um alternativo?

Armazenaremos tudo num arquivo de texto?

E se o acesso à base remota ficar indisponível, como o sistema se comportará?

E no caso da máquina demorar muito tempo para responder as solicitações ou sofrer alguma avaria?

É preciso pensar não só em falhas lógicas, como também nas físicas, afinal, tudo pode apresentar defeito em algum momento, e geralmente os defeitos surgem nos momentos que em o sistema mais é solicitado, tal como datas especiais, eventos sazonais onde o pico de trabalho aumenta muito e ficamos extremamente dependentes de que o sistema não falhe.

Temos de pensar além do habitual ou do ambiente ideal de funcionamento. Se faz necessário cada dia mais pensar fora da zona de conforto da aplicação, para assim cobrirmos uma gama maior de possibilidades onde a falha pode surgir e como agir em cada um desses cenários para que a crise não tome proporções tais que comprometa não só a imagem da empresa, mas também seu maior ativo que é o cliente satisfeito com os serviços dessa empresa.

Até a próxima!