A pergunta do título faz todo sentido. E se seu data center pegasse fogo hoje ? Você teria um plano de contingência? Sua contingência funcionaria?

Pois hoje, após pouco mais de um mês desde o incêndio no data center da Oi, posso dizer que a Fidelize sobreviveria. E com louvor.

O objetivo desse post, e dos próximos, é falar sobre as lições aprendidas com o desastre. O que deu certo. O que deu errado. Soluções encontradas. Algo muito comum em gerenciamento de projetos.

Para explicar melhor o que foi feito, vou dividir esse post em 2:

• Disaster Recovery – Lições aprendidas de um incêndio (que será tratado a seguir).
• Lições aprendidas na Amazon – Porque a estratégia que você usa no seu data center pode não funcionar na Amazon.

Disaster Recovery – Lições aprendidas de um incêndio

De cara, as duas lições mais importantes que aprendi foram:

• A importância da empresa, e seus sócios, estarem alinhados para tocar um projeto de criação de um plano de desastre. Algo que começou há quase dois anos atrás.
  • Inclusive, desde que entrei na Fidelize, redundância e disaster recovery sempre foram tratados com obsessão na empresa.
  • Ainda mais no ambiente de uma empresa que cresce mais de 40% há 5 anos seguidos e não para de criar produtos novos e evoluir os existentes. Algo que facilmente poderia fazer de um plano de desastre secundário, esquecido.
• Tão importante quanto o alinhamento da diretoria foi ter um corpo técnico com capacidade e comprometimento para executar o plano, ouvir e questionar. Valores imprescindíveis no processo.
  • De fato, para mim, se salvar de um desastre pode ser possível com um ótimo time e sem um plano previamente concebido. Mas acho impossível se salvar de um desastre com um ótimo plano e um time ruim.

O que deu certo:

1) Ter um plano.

Meio óbvio. Mas ter pensado em como teria que ser feito, reduziu em muito nossas perdas. Ser capaz de priorizar os serviços pelo impacto ao cliente também foi crítico.

2) Ter obsessão em seguir os processos quando tudo estava certo.

Manter o time atento e concentrado na garantia da replicação dos dados, antes do incêndio ocorrer, foi chave. E isso é difícil de colocar na cabeça das pessoas. É natural que a pessoa pense que a desgraça nunca vai ocorrer. Mas insegurança nesses dados faria a estratégia toda afundar. Porque tudo teria que ser validado de início e transmitiria insegurança e perplexidade à toda equipe.

3) Fazer pausas para reavaliação

Sempre separamos o que cada um deveria fazer. Isso deu e dá velocidade. Mas fazer uma pausa, rever o que está dando certo e o que não está dando certo, ajuda a evoluir de verdade mais rapidamente.

4) Depois de muito tempo trabalhando, trabalhar em dupla ajuda a diminuir os problemas potenciais

A operação como um todo varou a madrugada e o dia seguinte. Foram, ao todo, 36h de trabalho seguido. No meio da madrugada, foi importante passarmos a trabalhar em dupla. Assim o outro podia validar o que estava sendo feito. Perguntar como uma forma de checar se o processo estava alinhado. Isso zerou nossos erros de processos, algo crítico naquela noite.

O que não deu tão certo assim:

1) Demoramos muito a saber o que realmente havia acontecido por falta de informação da Oi e, quando tivemos as primeiras informações, as mesmas estavam incorretas.

Somente quando chegamos ao data center é que soubemos que havia um incêndio no prédio. E já haviam sido decorridos mais de 40 minutos desde o início da pane. Mais do que isso, 1h após o início do incêndio, eu ainda recebia ligações da equipe de suporte da Oi dizendo que ainda estavam checando (nem sabiam que um incêndio tinha ocorrido).

Após 1:30h, as informações no local eram de que o incêndio tinha sido controlado, os equipamentos não haviam sido danificados e a operação poderia voltar ao normal no mesmo dia. Ou no máximo teríamos que mover de data center.

A verdade era que o incêndio havia sido controlado mas eles haviam inundado o andar e perdido quase a metade de nossos servidores, incluíndo os 2 storages novos e os 2 servidores de balanceamento de carga.

Com isso, iniciamos a ativação dos servidores de aplicação do disaster recovery apenas 5h após o ocorrido, aumentando nossa janela de downtime (os de dados já estavam on line desde o início por conta da replicação).

Conclusão: se você tem um plano de desastre e um desastre ocorreu, ative o plano integralmente. Não protele por conta de informações externas que não estão no seu controle

2) Mantenha backup dos arquivos de configuração de produção.

Nossos softwares são todos versionados. Para garantir que os desenvolvedores possam trabalhar, os arquivos de configuração são transformados em modelos e apenas os modelos conseguem ser commitados. Isso quer dizer que tudo que precisamos para colocar uma aplicação no ar é fazer uma cópia dos modelos e colocar as configurações de produção.

Ocorre que o número de arquivos de configuração beirava 150. E tinhámos backup dos arquivos de produção, mas não havia garantia de que essas eram as últimas versões em produção de cada projeto. Ou seja, gastamos 150 vezes o tempo para homologar cada arquivo de produção. Em uma tarefa de checagem individual.

Conclusão: Versione as configurações dos clientes. Ou tenha backup ativo das mesmas. Vai poupar muito tempo.

3) Nossa plataforma não escalou tão bem na Amazon como planejamos

Apesar disso ser tratado em um post separado, a lição é clara:

Fazer um teste com carga máxima para a operação como um todo ajuda a dimensionar com antecedência os eventuais gargalos de processo.