Resolvendo o Problema "X"

Pegue suas boas ideias, anote-as e logo depois tente destruí-las! A princípio parece bem estranho, mas depois que li esse artigo no LinkedIn a ideia parece bem sensata e promissora (e até lógica). Gosto ainda mais porque confronta paradoxalmente aquelas frases de Facebook do tipo “Por não saber que era impossível, ele foi lá e fez!” ou “Não tenha medo de propor suas ideias, pois pior é não ter nada o que propor!”, entre muitas outras. Detesto essas frasesinhas...

Astro Teller, diretor dos projetos “MoonShots” da Google, explica que, nos projetos “X” da Google (Google X, Google Glass, Google driveless car, etc.), a empresa incentiva a “pré-morte” das ideias. Ou seja, diferentemente do conceito de post mortem onde você faz um retrospecto de toda ideia tentando encontrar o ponto onde ela falhou, no pre mortem você tenta mostrar e provar de todas as formas porque aquela ideia está fadada ao fracasso.

A estratégia é bastante simples. Você tenta constantemente mostrar as razões as quais sua ideia é inviável, não iria funcionar, não daria para levar adiante, não teria os recursos necessários, etc. As ideias que sobreviverem a essa sabatinada de “desincentivos” serão as que realmente valem a pena levar adiante.

Ora, bastante lógico do meu ponto de vista! Além disso, agregando valor ao camarote, você já tem um esboço do seu Plano de Contingência e Recuperação, seu Plano B, uma vez que já pensou nos possíveis cenários de desastre que sua ideia pode enfrentar.

Vamos tomar por exemplo uma Migração de banco de dados entre diferentes plataformas (Oracle). Nesse cenário consideremos que o banco utiliza ASM. Você escolhe três estratégias:

1. Usando Conversão na Origem - Você executa os scripts de conversão na origem, transfere os datafiles para fora do asm, copia-os para o outro servidor e insere-os novamente no asm (destino);
2. Usando Conversão no Destino - Você arranca os datafiles do ASM, transfere os mesmos para o servidor destino e insere-os novamente no ASM destino (a conversão do datafile é feita automáticamente quando você copia-o de volta ao ASM);
3. Usando Active Databade - O RMAN faz todo o trabalho pra você;

A primeira coisa que precisamos fazer, sempre que possível, é o ensaio do processo, ou seja, fazer uma simulação do processo que será feito no dia “D”. Para os três processos acima o banco precisa estar no mínimo no modo READ-ONLY, ou seja, aberto apenas para consultas. Então normalmente o sistema que utiliza esse banco não estará acessível aos usuários.

Criei um sistema de pontuação que ajuda a decidir uma melhor estratégia para o processo. Os valores podem ser quaisquer um, desde que você estipule um valor “central”. No meu caso escolhi o “5”:

Etapa 1: Tempo em que o banco de dados estará inacessível durante a conversão e/ou transferência dos datafiles para fora do ASM.

• Usando estratégia 1: Considerar o tempo de conversão+cópia dos datafiles para fora do ASM. 5 pontos;
• Usando estratégia 2: Considerar o tempo apenas de retirada dos datafiles do ASM: 3 pontos;
• Usando estratégia 3: O banco ficará inacessível durante todo o processo: 8 pontos;

De cara eu descarto a estratégia 3, pois, somente para criar o ambiente de ensaio, vai ser a que mais penalizará os usuários.

Vamos imaginar agora um desastre qualquer (desligamento inesperado do servidor, problema de hardware, falha lógica, etc.).

• Usando estratégia 1:
• Durante conversão/cópia do ASM na origem: Pode ser retomado à partir do datafile que estava sendo trabalhado no momento. 5 pontos;
• Durante a cópia entre servidores: Pode ser retomado à partir do datafile que estava sendo copiado no momento. 5 pontos;
• Durante a cópia dos datafiles para o ASM destino:Pode ser retomado à partir do datafile que estava sendo copiado no momento. 5 pontos;
• Usando estratégia 2:
• Durante cópia do ASM na origem: Pode ser retomado à partir do datafile que estava sendo trabalhado no momento. 5 pontos;
• Durante a cópia entre servidores: Pode ser retomado à partir do datafile que estava sendo copiado no momento. 5 pontos;
• Durante a cópia dos datafiles para o ASM destino:Pode ser retomado à partir do datafile que estava sendo copiado no momento. 5 pontos;

Ficamos no zero a zero nos cenários acima. Nada mudou. Porém, em ambos os processos pode haver corrompimento de algum datafile durante o processo de conversão ou cópia. A diferença é que se isso ocorrer durante a conversão na origem, você terá que restaurar o backup, então o tempo de sistema offline para o usuário será maior. Com isso posso descartar a Estratégia 1 também, pois há um risco de ter o sistema offline por um tempo maior para o usuário. Ficamos com a Estratégia 2 como vencedora!  

Então não precisa chorar se suas ideias foram destruídas antes mesmo de serem colocadas em prática. Suas ideias ajudaram a escolher a melhor estratégia, a que tem mais chance de sucesso e a que pode fazer um mundo melhor!