O 11 de Setembro está debutando!

O crédito da imagem é do History Channel.

Só que não há nada para comemorar.  Até parece que foi ontem:  lá se vão 15 anos de um dos maiores “desastres” que os EUA (e o mundo) já presenciaram.  Coloquei a palavra entre aspas proprositadamente.  Apesar de obviamente ter sido uma tragédia, não se tratou de um acidente, mas de um incidente.

Ok, mas ataques terroristas à parte, o que podemos tirar de lição disso tudo em termos de Tecnologia da Informação?  Afinal, não há nada mais certo que o ditado que diz que “tudo na vida é aprendizado”.  De fato!  Algumas das coisas que citarei aqui já foram discutidas em fóruns, apresentações, rodas de conversa, simpósios, sites e tantos outros meios de comunicação.  No entanto, nunca é demais lembrar os conceitos e reforçar o que precisa ser feito para minimizar perdas materiais em situações como esta.  Perdas humanas são inestimáveis, mas estão além do escopo deste blog.

Foquemo-nos nas torres gêmeas.  É bem sabido que diversas empresas possuíam um data center em cada torre.  Assim, numa situação inimaginável de uma torre simplesmente sumir do mapa, a empresa continuaria existindo por conta de seu backup na torre vizinha.  Naturalmente que diversos planos de continuidade de negócios não consideraram a situação ímpar das duas torres sumirem, praticamente ao mesmo tempo.  Disto, tiramos a primeira lição:

Lição 1:  quando for ativar um data center de backup, escolha locais geograficamente distantes entre si.

E não é só questão de ataque terroristas, mas há que se considerar qualquer desastre natural possível, especialmente em países propensos aos mesmos, tais como:  terremotos, furacões, enchentes, entre outros.  Preferencialmente, os data centers precisam ser distantes por algumas dezenas de quilômetros.

O leitor atento associará imediatamente o plano de continuidade de negócios (ou BCP, em Inglês) com outro termo muito comum:  análise de riscos.  Isto é um dos fatores presentes em qualquer plano e também em gerenciamento de projetos.  Uma boa análise precisa ser quantitativa e qualitativa para apresentar uma noção de QUANTO deve ser protegido (e os respectivos custos) e também O QUE precisa ser protegido.

Continuando com as lições aprendidas (outro termo muito comum em gerenciamento de projetos), lembremos o pandemônio que foi para conseguir notícias, acionar autoridades competentes, quantificar danos e iniciar as contramedidas no 11/9.  Assim sendo, confiar em um único canal de comunicação, como telefone ou e-mail, não é nada “saudável”.  Vamos à nossa segunda lição:

Lição 2:  estabeleça uma sequência efetiva de meios de contato que podem ser usados em situações de recuperação de desastres no seu data center.

Como não se pode confiar em apenas um canal de comunicação, todas as possibilidades devem ser consideradas:  Internet, Telefone fixo e móvel, Rádio em FM ou AM, rádio-amador (como o que foi necessário no caso recente do furacão Irma no Caribe) e, por fim, acionamento presencial.

As equipes de contenção precisam estar cientes do que fazer numa situação de DR e como agir para restabelecer o serviço o mais rápido possível e com o menor impacto permitido.  A tolerância à perda de dados envolve os conceitos de RPO (Recovery Point Objective) e RTO (Recovery Time Objective) e precisa ser muito bem estabelecida previamente.

Ótimo!  Agora, temos um data center de backup ativo, com as cargas de trabalho redirecionadas e suportando o negócio da empresa.  O data center principal foi recuperado e precisa ser colocado de volta à ativa, pois, muitas vezes, o de backup consiste apenas de um percentual do principal.  Isto é, nem todo o negócio está funcionando no backup.  Assim, chegamos à nossa terceira e última lição deste post:

Lição 3:  tenha uma política de rollback (retorno) bem feita para garantir que a replicação de dados ocorra corretamente.

De preferência, que seus controles sejam automáticos o suficiente para permitir que quaisquer sincronismos de storage sejam feitos transparentemente.  O roteamento entre os diversos segmentos de rede também precisam ser pensados.  Muitas abordagens de recuperação incluem repetição de blocos de endereços no lado do backup.  Isso pode nem sempre ser viável devido ao custo final.  Neste caso, é preciso ter uma política de retorno bem escrita, endereçando pontos como:  redes internas, links Internet ou conexões a pontos remotos da empresa, armazenamento, máquinas virtuais em execução (ou em standby) e clusters de servidores ou de aplicações.

A política precisa ser testada e revisada constantemente (como toda política deveria ser).  Estabeleça um planejamento de testes parcial e total e execute-os.  Anote os controles que não funcionaram, os colaboradores que não estão seguros quanto à execução dos mesmos e o tempo total para retornar.

Avalie a real necessidade de replicação síncrona entre os storages.  Muitos fornecedores de hardware costumam cobrar mais caro pela mesma.  Dependendo de como os procedimentos forem desenhados (e da criticidade do negócio), é perfeitamente possível trabalhar com replicação assíncrona e ter tudo funcionando no site backup.

Tenha em mente que desastres podem acontecer a qualquer momento, de forma intencional ou não.  Seus sistemas precisam ser projetados para suportar falhas físicas e lógicas, e capazes de se recuperar das mesmas.  O famoso ciclo PDCA (Planejar, Executar, Verificar e Ajustar) é perfeitamente aplicável aqui também.

Sucesso em seu data center e até o próximo post! 😉