quarta-feira, 8 de junho de 2016

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!

Resolving the "X" Problem



Take you best ideas, write them and after try to destroy them! In a first look this seems to be quite strange, but after I had read this article at LinkedIn the idea seems to be very reasonable (and even logical). I liked even more because it confronts those Facebook quotes like “Because he didn’t know that was impossible, he did it!” or “Never be afraid to show your ideas, because to have no ideas to propose is worst!”, among so many others. Just hate those quotes…
Astro Teller, Chief of Google “MoonShots” projects, explains that, at the “X” Projects from Google (Google X, Google Glass, Google Driveless Car, etc.) the company promotes the “pre mortem” of ideas. That means that, on the contrary of the post mortem concept where you review your original idea trying to find out where it failed, at pre mortem you try to show and prove, in every way, why your idea is faded to fail.
The strategy is very simple. You try constantly to prove that your idea doesn’t worth any effort, wouldn’t work, cannot go further, wouldn’t have enough resources, etc. Those ideas which survive to this attack of “unpromoting” things will be those one which really worth to go on.
Very well, it’s a very logical thing! Besides that, adding value to it, in the end you’ll also have a draft of your contingency plan, your B Plan, once you had had thought all the disasters situations and fail points your idea could pass.
Let’s make an example in a Database migration cross-platform (Oracle). Let’s also consider that the database uses ASM technology. So you take three different strategies:
1.   Using Origin Conversion: You execute the conversion scripts, transfer the datafiles out from the ASM, copy the files for the destination server and put them back to the ASM (destination);
2.   Using Destination Conversion: You take-off the datafiles from the ASM, transfer files through to the destination server and put them back to the ASM at destination (datafiles conversion are made implicit in this process);
3.   Using Active Database: RMAN does all the work for you;
First thing to do, ever its possible, is to rehearse the process to be made in the big day. Simulate it. All the three process above needs to that, at minimum, the database in READ-ONLY mode. So, normally, the software which uses this database won’t be accessible to the end-user.
I made an individual score system to help to choose the best strategy for the process. You can choose any standard value, as long as you chose a “central” value. In my case I choose “5”.
Step 1: Offline system during the datafiles conversion and transferring out-from the ASM.
·        Using strategy 1:
Consider the time for conversion + datafiles copy out-from ASM. 5 points;
·        Using strategy 2:
Consider the time only to take out the datafiles out-from ASM. 3 points;
·        Using strategy 3: System will remain offline during all process. 8 points;
For sure I avoid the strategy 3, because just to create the Test environment, the end-user will suffer much more then the other two options with the offline system.
Now let’s think about some disaster during the process (Server being halt, power fail, logical fail, hardware problem, etc).
Using Strategy 1:
· During the conversion/copy of datafiles from ASM at origin: Process can be resumed from the datafile which was in conversion at the moment of the fail. 5 points;
·        During the copy between servers: Can be resumed from the datafile that was being copying at the moment of the fail. 5 points;
·         During the copy of datafiles to the ASM (destination): Process can be resumed from the datafile which was in conversion at the moment of the fail. 5 points;
Using strategy 2:
·         During the conversion/copy of datafiles from ASM at origin: Process can be resumed from the datafile which was in conversion at the moment of the fail. 5 points;
·         During the copy between servers: Can be resumed from the datafile that was being copying at the moment of the fail. 5 points;
·         During the copy of datafiles to the ASM (destination): Process can be resumed from the datafile which was in conversion at the moment of the fail. 5 points;
The risks on the two processes above are the same. Nothing changed. But, in both process there’s a possibility of datafile corruption during the process of conversion or copy. The difference is that if its occur during the conversion at the origin side (strategy 1), you’ll have to restore the database/datafile backup. So, the offline system for the end-user will be larger. With this information I also can discard the strategy 1, because of the risk of a bigger time with offline system. The winner is Strategy 2 - Using Destination Conversion!

So my friend, you don’t need to cry if your ideas become destroyed even before they come out from the papers. Your killed ideas helped to chose the best path, the path with better chances of success and that can make a better world for all!
Locations of visitors to this page
Côcos pelo Mundo