quarta-feira, 2 de agosto de 2017

Updating Systems by Parts

One of the biggest problems about systems update is the offline system time for the end user. Mostly when the actions and changes are in the Database. As big is the amount of data and size of the database, as long it will take your system offline.
Was that necessity in decrease this time that a company for which I do database consulting, brought me. I had the need to imagine an update strategy in their systems in a way that the end user would stay less time as possible with offline system, or at least, with a minimum of impact in the customer operation.
The major trouble about it is to fit the software version with its correspondent database structure. Of course, when this update leads to a database structure change, as table creation, columns, etc. In a hot update, with users using the system, you can even get the database modifications, depending on the database, but there will be a moment, in some parts of the system, that might occur errors due the difference of database structure on the tables.
Was thinking about it that I suggested a modification in their update release process of database scripts and programs. Even their data structure didn't have been made in a modular way, at the beginning, I thought on a way tot ry to modularize its update, affecting only some company areas at time. In that way their customer IT team would also prepare and schedule their system update by areas.
For example, if the company has a reception area, products supply, billing and a research & development area, they can plan system using by areas, according to the timestamp that will less impact the area. As update the reception software in the time which their have less activity in that area, or the supply software in that time where they less do products movement, etc.
The process in its general way is quite simple. There will be an initial request for update. In this request the company will also prepare the database scripts, documentation and correspondent software version. Then there's come the main process. Those database scripts will have to be prepared according to the programs that uses that specific database tables. There will exists a group of core tables, which are common to most of the programs. Surrounding those core tables there will be the specific tables used by each program. As for example the supply program must have tables which are used just for this part of the program, and so on. The process output will be the update logs and the updated product (software and database structure).

We had a pilot with this new process into one of their customer and, instead of some small problems and adjustments, everything gone well and we had a nice feedback from this customer. Now is keep the process running and maturing for the next updates and releases. And my work here is done!

sexta-feira, 24 de março de 2017

Abstract Painting

Forgive me the painters. I don't want, anyhow, to disparage them or diminish their art and their work. What I will post simply shows that I have no knowledge of abstract art (or any other paiting style). I have always found that those who painted an Abstract painting, for the most part, were people who didn't know how to paint. For example, in 1923, Kazimir Malevich painted "Black Square". Damn it! A black square, nothing more then this... Exposed in the Russian Museum.
Of course, there is a whole history and technique involved in this school, besides to its strands, which I know nothing. As well as there are also beautiful abstract pictures that I could never paint something even close, like the abstracts of Wassily Kandinsky, Albert Gleizes and Arthur Dove. I also have an uncle who has already ventured into this world:
So I decided to venture myself into this world and show all my lack of technique and artistic vein for painting. My first (and perhaps only) picture:
I used all my ogre technique to produce it, using burnt-out engine oil, tap water, and a paintbrush used to do walls of speckled cement. Still this, some people said that this picture was about something sad, distressing. I confess that I painted it in a moment more or less thus, making me believe that really, there is unconscious feeling in the abstract paintings. Anyway, I still don't know what feeling is in the "Black Square". I decided to name this painting "Oil Over Blood".

Arte Abstrata

Perdoem-me os pintores. Não quero de modo algum desmerecê-los ou diminuir sua arte e seu trabalho. O que vou postar simplesmente mostra que não tenho nenhum conhecimento de arte abstrata (ou qualquer outra linha de pinturas). Eu sempre achei que quem pintava um quadro Abstrato, em sua maioria, eram pessoas que não sabiam pintar. Por exemplo, em 1923, Kazimir Malevich pintou "Black Square". Porra véi! Um quadrado preto... Exposta no Museu Russo. Claro, existe toda uma história e técnica envolvida nessa escola, além de suas vertentes, as quais eu desconheço profundamente. Assim como também existem quadros abstratos belíssimos, que eu nunca conseguiria conceber, como os abstratos de Wassily Kandinsky, Albert Gleizes e Arthur Dove. Tenho um tio que já se aventurava nesse mundo:
Então resolvi eu mesmo me aventurar nesse mundo e mostrar toda minha falta de técnica e veia artística para pintura. Meu primeiro (e talvez único) quadro:
Utilizei toda minha técnica de ogro para produzi-la, utilizando óleo de motor queimado, água de torneira e uma brocha de pintar paredes de cimento salpicado. Ainda assim algumas pessoas disseram que esse quadro remetia a algo triste, angustiante. Confesso que pintei-o em um momento mais ou menos assim, me fazendo crer que realmente, existe sentimento inconsciente nas pinturas abstratas. Só ainda não sei que sentimento está no "Quadrado Preto". Resolvi dar o nome a esse quadro de "Óleo Sobre Sangue".

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!
Locations of visitors to this page
Côcos pelo Mundo