sábado, 30 de julho de 2016

System Meltdown - How Things Really Work



How self-sufficient we believe we are? How safe are we in our little world of technology I-do-it-for-you? We have been so dependent on technology and systems over the years that we can’t also notice how vulnerable we are. Almost everything we use and depend today also depends on chips, circuits and micro embedded systems. From the car we drive, communication, to even basic necessities such as electricity, water and food.
We hava a small example about it when our cell phone is out of service for just a while. Especially for those younger, who grew up in the cell phone era. We become desperate!!! When 20 years ago the person who had access to this kind of technology was quite rare. I didn’t understand, when I was young and fashion, how people lived without television.
Today everything is so dependent on systems, technology and informatics that requires complex plannings and huge investments to ensure the things working.
Eletrobras Distribuição Rondônia (a power company in North Region of Brazil), for example, invested R$600 thousand to implement an Integrated Operations Center (IOC), to gather in one place professionals and services for Operation Center of Distribution of all regions of the state, Departments of Distribution of Operations, Distribution itself and Maintenance Services. The IOC is fully computerized to provide the system operators all conditions to control, from anywhere, the electrical installations of power substations, power lines and power distribution network, keeping the economy, security and efficiency needed to ensure continuity in the supply of distributed electricity.
The more complex the environment is, the more investment and better contingency planning are also required to prevent a failure in the system. Firewalls, redundancy, backup plan, etc. And even with all this, between 2011 and early 2014 were registered 181 blackouts in BRazil, according to a survey of the Brazilian Center for Infrastructure (CBIE). Furthermore, in a hacker invasion of the IOC System, for example, it could turn off the power of an entire state.
In SOuth Australia a death of a patient is under investigation, where apparently there was a falt in the system that categorizes emergency calls, by prioritizing in dispatch ambulances and giving advices of procedures to be done. A patient died after the system flagged an emergency call as a collapse when in fact the patient was unconscious and not breathing. Thus the system also couldn’t send the advices to give a little extra survival time for this patient, by someone close to him, until the help arrives.
But let’s get out from large and complex environments to a private, small complex environment. The futuristic Driverless cars - a car without drivers. NIssan is about to launch by August this year its autopilot system, named ProPILOT. An autopilot system to be used in heavy traffic situations, slow traffic or during extended commutes.
The system can automatically manage the distance between the car and any leading car, between speeds ranging from about 18mph to about 60mph, also It also fully stoping when the car in front stops. It also keeps the car in the lane, using a monocular 360-degree camera system communicating with an on-board processing system. The plans are to gradually introduce more autonomy, but it’s staging the release of additional features. Lane switching in highway conditions is set to come to ProPILOT in 2018, and city driving, including full intersection negotiation, is currently supposed to make its debut in 2020.
Now what happens if the system fails or is compromised while the car is in motion? Even if for a brief moment, to the user recover the control isn’t instantaneous and in between this moment a serious accident may occur. A cyber-attack of this central system or some critical failure can compromise the security of several drivers.

To resume, I won’t to return to ride camels and use torches throughtout my house. The point I’m trying to getting at is that we still have a lot to improve in terms of technology to let things totaly by system control. The manual and mechanical interaction is so essential and necessary as safety to avoid disasters. The problem is that we became so used to systems thinking for us that we even forgot to think by ourselves! 

Derretendo o Sistema



Quão autossuficientes acreditamos ser? O quão seguros estamos em nossos mundinhos de tecnologia faço-tudo-por-você? Temos estado tão dependentes da tecnologia e dos sistemas durante os anos que não conseguimos enxergar também o quão vulneráveis nós somos.
Quase tudo o que usamos e dependemos hoje também depende de circuitos, chips e micro sistemas embutidos. Desde o automóvel que dirigimos, comunicação, até necessidades básicas como luz, água e comida.
Você tem um pequeno exemplo disso quando fica sem celular por um tempo ou sem acesso a internet. Principalmente para aqueles mais jovens, que cresceram nessa era, é desesperador. Quando há 20 anos atrás era raro o indivíduo que tinha acesso a essa tecnologia. Eu não entendia, quando era jovem e esbelto, como as pessoas viviam sem televisão.
Hoje tudo é tão dependente de sistemas, tecnologia e informática que são necessários complexos planejamentos e enormes investimentos para garantir o funcionamento das coisas.
A Eletrobras Distribuição Rondônia, por exemplo, investiu R$ 600 mil na implantação do Centro de Operação Integrado (COI), para reunir, em um único local, os profissionais e serviços do Centro de Operação da Distribuição de todas as regiões do Estado, dos Departamentos de Operação da Distribuição, de Serviços de Distribuição e de Manutenção. O COI é totalmente informatizado para proporcionar aos operadores do sistema as condições de controlar, a distância, as instalações elétricas das subestações, linhas e redes de distribuição, mantendo a economicidade, segurança e a eficiência necessária para garantir a continuidade no fornecimento da energia elétrica distribuída.
Quanto maior e complexo o ambiente, mais investimento e melhores planos de contingência também são necessários para impedir uma falha nesse sistema. Firewalls, redundância, backup, etc. E mesmo assim, entre 2011 e início de 2014 foram registrados 181 apagões, segundo levantamento do Centro Brasileiro de Infra Estrutura (CBIE). Além disso, em uma suposta invasão ao sistema do COI, por exemplo, o hacker poderia desligar a energia de um estado inteiro.
No Sul da Austrália uma morte de um paciente está sob investigação, onde aparentemente houve uma falha no sistema que categoriza as chamadas de emergência para a priorização no envio das ambulâncias. Uma chamada que deveria ter sido categorizada como Emergência, uma vez que o paciente não estava sequer respirando, foi informada como um mal-estar. Desse modo o sistema também não informou que cuidados poderiam ser tomados para tentar dar uma sobrevida a esse paciente, por alguém que estivesse próximo, até a chegada do socorro.
Porém vamos sair dos grandes e complexos ambientes para um pequeno e privado ambiente complexo. Os futurísticos Driverless cars - ou carros sem motoristas. A Nissan está com lançamento planejado para Agosto desse ano, do seu sistema de piloto automático, chamado de ProPILOT. Um sistema de piloto automático para ser usado em situações de tráfego pesado, trânsito lento ou deslocamentos prolongados.
O sistema consegue controlar a sua distância para o veículo da frente em velocidades entre 30 e 95 km/h. Possui uma câmera de 360 graus para monitorar as faixas na pista e os carros ao redor além de parar completamente quando o carro da frente também para. Os planos são para evoluir gradativamente, com mudança de pistas em 2018 e direção na cidade em 2020 - inclusive com tomada de decisões em cruzamentos.
Agora o que acontece se esse sistema falhar ou for comprometido enquanto o carro estiver em movimento? Mesmo que por um breve momento, a retomada do controle não é instantânea e nesse tempo um acidente grave pode ocorrer. Além do que esses sistemas irão precisar de um sistema central de informação para funcionarem. Uma invasão a esse sistema central ou uma falha crítica pode comprometer a segurança de inúmeros motoristas.
Em suma, não estou querendo voltar a andar de camelo e acender lampiões por toda a casa. O ponto onde quero chegar é que temos muito o que melhorar ainda em termos de tecnologia para deixar as coisas completamente ao controle dos sistemas. A interação manual e mecânica é sim essencial e necessária como segurança para evitar catástrofes. O problema é que nos acostumamos tanto com os sistemas pensando por nós, que esquecemos como pensar diversas vezes!

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!

terça-feira, 26 de janeiro de 2016

Too much work... So few sleep!





Since the year had begun I haven't been sleeping very well. I lay down, turn one side, turn another side, and only late at dawn I can sleep. And suddenly I have to get up to work. Even in the weekends I haven't been sleeping enough. This, somehow (or very how), has been affecting my productivity at work and even in my personal tasks.
Searching for the reasons for haven't been sleeping well, the overworking fitted perfectly. The beginning of this year was quite agitated, and has been being since then. When you get home and turn on your laptop, even for personal tasks, it leads your brain in intense activity when you lay down on bed.
A research at the American Journal of Epidemiology showed that a group of person that used to work over 55 hours a week had had worst performance on the tests results, then the group which used to work around 40 hours a week. The tests evaluated verbal memory and skills, fluid intelligence (associated with short-term memory, abstract thinking, creativity, and problem solving), and crystallized intelligence (learning accumulated over the life span in education, work, and cultural experiences). This last one even keep growing until the 60's or 70's years old, and only starts to decrease starting from 80's.
Have notice that when I speak about overworking I'm not talking about only your job by itself. Understand that overworking is also the tasks that you do when you get in your home (or somewhere out of work place). Turn on your laptop for personal stuffs, for example, when you arrive at your home, can contribute in the increasing of your week working hours.
To take the prove in this last Wednesday I resolved to, arriving home, I wouldn't turn on my laptop or TV. I took a shower, had my dinner, put on my pajamas and gone to bed. I put a Classical Music radio station and read a book. My dog laid down by my side and near 20:30 I just turned off. Slept. I woke up  in the other morning totally renewed, in ecstasies, "Good Morning Sun" and "Tinny Kisses of Light". In that day I got a better food, had more energy and even I got a better mood - those who knows me, knows how surreal it is!
So, even being necessary you do overworking sometimes, having more the 48 working hours a week, when you start to feel very tired, not getting a good sleep night, try this. Disconnect of everything that is your normal routine. Disconnect by yourself, with only your dog, with your friends or your partner. Just be abstracted of everything that reminds your routine and have a good night!

Muita atividade... Pouco sono!


Desde o começo desse ano de 2016 não tenho dormido direito. Deito, embolo pra um lado, embolo para o outro e só pelas tantas da madrugada que o sono chega. E logo tenho que levantar para o trabalho. Mesmo fim de semana não tenho conseguido por o sono em dia. Isso, de certa (ou completa) forma vem afetando minha produtividade no trabalho e até pessoal.
Em busca dos motivos de não estar dormindo direito, o excesso de atividades encaixou-se perfeitamente. O começo do ano foi bastante agitado e desde então assim tem sido. Quando você chega em casa e ainda liga o laptop, mesmo que para tarefas e coisas pessoais, deixa seu cérebro em plena atividade ao deitar-se.
Uma pesquisa publicada no Jornal Americano de Epidemiologia mostrou que grupos de pessoas que trabalhavam mais de 55 horas semanais tiveram menores pontuações nos testes do que grupos que trabalhavam até 40 horas semanais. Os testes englobavam memória e habilidades verbais, fluidez da inteligência (associada a memória a curto prazo, pensamento abstrato, criatividade e resolução de problemas.), e inteligência cristalizada (aprendizado acumulado durante a vida educacional, profissional e cultural). Essa última, inclusive, tende a aumentar até os 60 - 70 anos e só começa a diminuir a partir dos 80.
Note que quando falo em excesso de atividades não estou relacionando apenas ao trabalho por si só. Entenda por excesso de atividades, as atividades que você realiza ao chegar em casa. Ligar o laptop para coisas pessoais por exemplo, ao chegar em casa, influencia nas sua carga horária semanal.
Para tirar isso a prova, na última quarta-feira resolvi que, ao chegar em casa, não iria ligar meu laptop nem assistir TV. Tomei meu banho, jantei, coloquei meu pijamas e fui pra cama. Coloquei uma estação de músicas clássicas e fui ler um livro. Meu cachorro deitou-se ao meu lado e as 20:30 aproximadamente eu apaguei. Acordei renovado, extasiado, “bom dia sol” e “beijinhos de luz”. Nesse dia me alimentei melhor, estava mais disposto e até com o humor melhor - quem me conhece sabe como isso é surreal.
Então, mesmo que seja necessário você fazer suas horas extras, prolongar suas atividades para além das 48 horas semanais, quando sentir-se esgotado, sem conseguir dormir direito, tente isso. Desligar-se de tudo que seja rotina por uma noite. Seja sozinho com seu cachorro. Seja com amigos. Seja com sua (seu) companheiro(a). Apenas se abstraia do que remete a sua rotina e tenha uma boa noite!

quinta-feira, 11 de setembro de 2014

Tablespaces BigFile, Normais e seus tamanhos: Como e quando usá-los

Até a versão 9i do Oracle, você normalmente podia criar tablespaces com datafiles até 32G (aproximadamente). Eles eram (são) chamados "Smallfile Tablespaces". Particularmente prefiro chamá-los de "Normalfiles", porque "Small" me dá uma impressão de um tamanho até 2G ou 4G. Na versão 10g em diante o Oracle te deixa criar tablespaces com datafiles maiores, até 128T dependendo da arquitetura do SO (64 bits) e do tamanho dos blocos (32K).
Usando Tablespaces Smallfile normalmente um administrador de banco de dados pode criar até 1024 datafiles, cada um até 32G - o que nós dá aproximadamente 34T de dados - usando um block size de 8K. Bem sabemos que atualmente esse volume de dados é insignificante para alguns sistemas/empresas, como a Google, VISA, etc. Especialmente aquelas que armazenam vídeos, imagens de alta resolução e áudio.
Uma Tablespace BigFile pode armazenar mais de três vezes um banco de dados completo que utiliza apenas smallfiles, em uma única tablespace. Usando um block size de 32K o banco de dados pode atingir 8 Exabytes. É muito dado armazenado. Infelizmente isso também pode trazer problemas. Quanto maior for o datafile, maior será o tempo para restaurar seu backup ou realizar alguma manutenção nele.
Algumas dessas manutenções requerem que o sistema fique off-line, dependendo do que esteja armazenado nesse datafile. Uma boa prática para evitar isso seria desenhar o modelo de dados de modo que possa dividir as tabelas que guardariam dados grandes (ex.: tabelas com campos BLOB ou CLOB) em tablespaces BigFile, enquanto o restante dos dados permaneceria em tablespaces normais.. Ou ainda você pode particionar a tabela colocando os dados que são menos acessados em uma partição dentro do BigFile. Fazendo isso apenas uma parte do seu sistema ficaria inacessível durante uma manutenção.
Por exemplo, em um sistema de gestão hospitalar e diagnósticos. Você pode colocar as tabelas que armazenam vídeos e imagens para diagnósticos em um BigFile, enquanto o estoque, faturamento e outras rotinas administrativas podem ficar na tablespace normal. Desse modo apenas uma parte do sistema (diagnósticos) ficaria inacessível durante a manutenção.
Por outro lado já existem Appliances (máquinas fechadas com configuração de fábrica direcionada para ambientes e fins específicos) feitos para lidarem com essas necessidades, como o BigData e ExaData da Oracle, InfoSphere e Watson Foundation da IBM, o CISCO USC (da CISCO, claro) e muitos outros.
Então, é melhor você ter um conjunto de pequenos soldados, que movem-se mais rápido e distribuem-se de vários lados, ou um único enorme soldado, movendo-se lentamente e de uma única direção? Tudo depende da sua estratégia!


Locations of visitors to this page
Côcos pelo Mundo