English readers and other languages: Many posts are in portuguese, you can use the Translate button at left side.

Clique nas imagens dos artigos! Elas levam você para o site do artista que a criou e muitas
vezes tem assuntos relacionados ou outras imagens para expandir seus horizontes!

quarta-feira, 2 de setembro de 2009

Caminho do Aprendizado

Se quer ser bom na sua profissão, estude suas ferramentas, aprimore-se, domine o assunto.

Se quer ser um mestre da profissão, estude as pessoas.


.'.

DM9 dá uma escorregada, mas logo passa


"Vazou" um trabalho da DM9, com aviões sobre Nova York, o que com certeza incomodou o pessoal do Onze de Setembro. Quer dizer, publicaram mesmo e depois disseram que foi por engano.

Link para a matéria:
http://portalexame.abril.com.br/blogs/4p/20090902_listar_dia.shtml?permalink=193324


Meu comentário:

Um trabalho tecnicamente bem feito. Claro que não deveria ter vindo a público, pois as demais pessoas do mundo, nem sempre ficariam muito contentes em descobrir como alguns pensam.

Sobre o tema, bem, típico alarde ecochato da pregação da verdade única batendo com o livro na cabeça dos outros para conversão na marra.

Só esquecendo, ao meu ver, que naquela situação, conta menos a quantidade do que a causa (ação da natureza Versus ação de um).

De resto, a DM9 e uma ótima agência, e uns deslizes acontecem, mesmo que machucando uma perna para aprender a usar o calçado correto, quando necessário ;)


Vide também: Ainda sobre a DM9 e o WWF

.'.

Performance: Quando A Culpa Não é do Banco de Dados

The IBM Stretch supercomputer.
Photo: IBM

Performance: Quando A Culpa Não é do Banco de Dados
02/09/2009

Otizimizando a performance em SQL com Join e Subquerys


Com frequência temos casos em que uma determinada seleção de registros, apesar de parecer atender as necessidades iniciais, não é satisfatória devido a demora do processamento.

Uma das causas, é pela utilização apenas de dados de teste, em tabelas pequenas. Com isto, o tempo real de execução deixa de ser avaliado e, como resultado, o coitado do DBA vai ter que ouvir mais uma vez que “minha Select funcionou, então é o banco de dados é que tem problema”. Ou então, será alegado culpa do usuário...

Mas existem muitas diferenças entre simplesmente “funcionar”, e funcionar de forma eficiente.

A complexidade de uma seleção de dados, vai levar em conta, o tempo de que dispomos para sua codificação é claro, mas também, é preciso ponderar no ganho de tempo, mesmo na fase de testes com dados reais, e os recursos utilizados em produção. Na maior parte das vezes, o tempo ganho estudando a otimização compensa largamente e geralmente diminui o tempo de programação e testes.

Outra falha, é confiar excessivamente nos recursos de otimização automática dos gerenciadores de banco de dados. Nem sempre estes farão a melhor escolha. Como por exemplo, ao avaliar a disponibilidade de outros índices, neste caso, mudando as chaves de seleção de alguma forma, que poderá ter um impacto significante. Também a hierarquia como serão processadas as condições de seleção e até mesmo, transferir parte dos recursos para outra tabela, ainda assim de forma mais eficiente no resultado geral, pelo aproveitamento de dados em cache.

Tomei para este exemplo, uma seleção de dados numa tabela real, mudando é claro os nomes para o exemplo, com cerca de 60 milhões de registros de movimentos relativos a um conjunto de setores, relacionadas noutra tabela.

Esta transação era utilizada diariamente numa consulta pelo usuário final, os diretores da empresa para decisões de mudanças estratégicas em tempo real para ofertas nas suas lojas, mas demorava até absurdamente 2 horas! Imagine alguém da diretoria precisando tomar decisões de enorme valor financeiro a nível nacional, literalmente milhões de $ e tendo que esperar este tempo todo! Certamente era desejável obter uma boa performance.

É importante observar, que mesmo que fosse o caso de um programa de execução única ou eventual, a enorme perda de tempo durante a fase de testes compensa largamente que se faça um código melhor.
Veja bem: como é que vou trabalhar se entre um teste e outro preciso esperar horas? Estamos no Século XXI, é hora das coisas funcionarem melhor e serem melhor feitas. 
Desta forma, teremos nosso trabalho pronto mais rápido, e também, estaremos economizando os recursos do sistema e da empresa que também são utilizados pelos demais usuários.
E também muito importante, é lembrar que geralmente, não teremos exclusividade de uso do servidor. Existem outros programas disputando recursos. No caso do exemplo atual, eram mais de 5000 estações fazendo todo tipo de transação acessando exatamente a tabela principal desta pesquisa, além de uma grande quantidade de processamento batch realmente volumosos.

O sistema gerenciador de banco de dados (SGBD) neste caso, era o Sybase AES (Adaptative Server Enterprise) 12.5. Usei os comandos sp_showplan e sp_statistics para listar resumos das execuções.
Os conceitos aqui mostrados servem para qualquer outro SGBD Relacional, como Oracle, Sql Server, etc.


A Select original que está abaixo, vai retornar a soma para quatro condições diferentes em cada setor existente.
Para nosso exemplo temos duas tabelas: Setores e Movimentos. Precisamos selecionar os Setores de Tipo = 'X', e os movimentos dentro de um periodo de datas, que tenham um determinado CodigoTeste igual ou diferente de zero e, que poderá ter uma segunda condição a ser testada. Ainda, precisamos o total geral de registros.

Neste modelo, em que a tabela de setores é a principal, simplesmente fizeram quatro varreduras na tabela de movimentos para cada um dos setores dentro do período selecionado. Uma leitura para cada um dos campos a ser somado! O tempo de execução foi obviamente bastante longo.

Logo abaixo estão as estatísticas de execução.

Select Original:

select Setores.codigoSetor,
       (select count(*) from Movimentos b
               where Setores.codigoSetor = b.codigoSetor and
                     dataOperacao between '04/01/2009' and '04/30/2009'),
       (select count(*) from Movimentos c
               where Setores.codigoSetor = c.codigoSetor and
                     dataOperacao between '04/01/2009' and '04/30/2009' and
                     codigoFlagTeste 0),
       (select count(*) from Movimentos d
               where Setores.codigoSetor = d.codigoSetor and
                     dataOperacao between '04/01/2009' and '04/30/2009' and
                     codigoFlagTeste = 0 and tipoABCDE in (1, 2, 3, 4)),
       (select count(*) from Movimentos e
               where Setores.codigoSetor = e.codigoSetor and
                     dataOperacao between '04/01/2009' and '04/30/2009' and
                     codigoFlagTeste = 0 and tipoABCDE not in (1, 2, 3, 4))
  from Setores (index indiceSetores01)
  where (tipoSetor = 'X' or Setores.codigoSetor = 999)
  order by Setores.codigoSetor


Estatística da Execução:
----------------------------------
Table: Movimentos scan count 121, logical reads: (regular=124152 apf=0 total=124152), physical reads: (regular=1129 apf=123023 total=124152), apf IOs used=123023

Table: Movimentos scan count 121, logical reads: (regular=6949399 apf=10100 total=6959499), physical reads: (regular=843310 apf=5103725 total=5947035), apf IOs used=5090713

Table: Movimentos scan count 121, logical reads: (regular=1003943 apf=2237 total=1006180), physical reads: (regular=37563 apf=261910 total=299473), apf IOs used=262198

Table: Movimentos scan count 121, logical reads: (regular=1003943 apf=0 total=1003943), physical reads: (regular=0 apf=0 total=0), apf IOs used=0

Table: Setores scan count 1, logical reads: (regular=51 apf=0 total=51), physical reads: (regular=47 apf=16 total=63), apf IOs used=1


===> Total actual I/O cost for this command: 132.860.664... !!!
Total writes for this command: 125

Execution Time 749.
SQL Server cpu time: 74900 ms. SQL Server elapsed time: 1.471.296 ms.

(121 rows affected)
----------------------------------


Vemos que houve um processamento bastante repetitivo e bem pesado. Para cada linha selecionada na tabela Setores, são feitos quatro leituras na tabela de Movimentos, que neste caso, pelo menos tinha um Indice por data. Mas ainda assim, é demais.

Podemos melhorar isto em duas partes principais.
  1. Fazer apenas um ciclo de leitura na tabela de Movimentos eliminando as subconsultas. 
  2. Otimizar a forma como vamos validar quais código de setor serão validados.

Para aproveitar melhor o ciclo de leitura, fazendo a contagem das condições que precisamos verificar, utilizamos o comando CASE WHEN, que é semelhante a do SQL Server. A maioria dos SGBDs possui uma condição de critério.
A tabela de Movimentos passa a ser o principal e não mais o de Setores, também temos no mesmo um índice por setor e data.
E usamos o Join que não era usado!

Assim teremos:

  select codigoSetor, count(*),
        sum ( case
                when b.codigoFlagTeste 0 then 1 else 0 end ),
        sum ( case
                when b.codigoFlagTeste = 0 and
                     tipoABCDE in (1, 2, 3, 4) then 1 else 0 end ),
        sum ( case
                when b.codigoFlagTeste = 0 and
                     tipoABCDE not in (1, 2, 3, 4) then 1 else 0 end )
   from Movimentos b
   join Setores (index indiceSetores01)
     on Setores.codigoSetor = b.codigoSetor
   where dataOperacao between '04/01/2009' and '04/30/2009' and
        (tipoSetor = 'X' or Setores.codigoSetor = 999)
   group by codigoSetor
  

Estatística da Execução:
----------------------------------
Table: Movimentos scan count 1, logical reads: (regular=60523 apf=53 total=60576), physical reads: (regular=48421 apf=6249 total=54670), apf IOs used=6173

Table: Setores scan count 95560, logical reads: (regular=99289 apf=0 total=99289), physical reads: (regular=10 apf=0 total=10), apf IOs used=0

Table: Worktable1 scan count 1, logical reads: (regular=6545 apf=0 total=6545), physical reads: (regular=0 apf=0 total=0), apf IOs used=0


===> Total actual I/O cost for this command: 1.317.060... (apenas 1% do anterior)


Execution Time 15.
SQL Server cpu time: 1500 ms. SQL Server elapsed time: 83.800 ms.


Basta uma rápida olhada para perceber imediatamente que a diferença na quantidade de I/Os e no tempo de processamento é impressionante, próximo de apenas 1% da select original!

Mas ainda podemos mudar um pouco isto para explorar alternativas.

Observem que utilizamos um Join para validar a tabela de setores. Mas neste caso, poderemos ter várias releituras da mesma.

Também seria possível a condição 'where... IN' para validar o setor, ao invés de Join. Mas neste caso, pode ocorrer um aumento no número de I/Os, que é pequeno em relação ao problema original, mas que deverá ser estudado se for noutra implementação

Assim teremos:

select codigoSetor, count(*),
       sum ( case
               when b.codigoFlagTeste 0 then 1 else 0 end ) ,
       sum ( case
               when b.codigoFlagTeste = 0 and tipoABCDE in (1, 2, 3, 4) then 1 else 0 end ) ,
       sum ( case
               when b.codigoFlagTeste = 0 and tipoABCDE not in (1, 2, 3, 4) then 1 else 0 end )
  from Movimentos b
  where dataOperacao between '04/01/2009' and '04/30/2009' and
        codigoSetor in (select codigoSetor
                          from Setores (index indiceSetores01)
                          where tipoSetor = 'X' or Setores.codigoSetor = 999)
  group by codigoSetor  

Estatística da Execução:
----------------------------------
Table: Movimentos scan count 1, logical reads: (regular=60523 apf=26 total=60549), physical reads: (regular=51955 apf=4993 total=56948), apf IOs used=4822

Table: Setores scan count 95560, logical reads: (regular=99627 apf=0 total=99627), physical reads: (regular=27 apf=0 total=27), apf IOs used=0

Table: Worktable1 scan count 1, logical reads: (regular=6545 apf=0 total=6545), physical reads: (regular=0 apf=0 total=0), apf IOs used=0


===> Total actual I/O cost for this command: 1.358.992.
Total writes for this command: 6884

Execution Time 18.
SQL Server cpu time: 1800 ms. SQL Server elapsed time: 107.326 ms.

(113 rows affected)
----------------------------------


Portanto vemos que a Alternativa A ainda foi uma melhor modificação.

Uma observação adicional, é que ao mudarmos a select original, também foram eliminados alguns resultados desnecessários, que precisariam processamento posterior, daí a diferença na quantidade de registros resultante ter baixado de 121 para 113.


Comparativo


Custo Total
I/O
Tempo Execução
Tempo CPU
SQL Server elapsed time
Original
132.860.664
749
74900 ms
1.471.296 ms
Alternativa A
1.317.060
15
1500 ms
83.800 ms
Alternativa B
1.358.992
18
1800 ms
107.326 ms



Conclusão:

Obtive para a empresa uma redução aproximada de 99% na quantidade de I/Os necessários e de 98% no tempo de execução.

Alguns pontos podem ser melhorados, mas em face do ganho obtido, já ficou num nível mais satisfatório, especialmente considerando a cultura local da empresa. 

Assim, passaram a tomar decisões mais rápidas, negócios de milhões $ que puderam agilizar de maneira melhor e certamente maiores lucros. 


Resultados:

  • Enorme economia de recursos.
  • Maior disponibilidade do servidor para atender outras transações.
  • Maior satisfação do usuário final que passou a ter muito mais agilidade.
  • Ciclo de desenvolvimento e testes do programa foram reduzidos a uma fração do previsto.
  • Ganhos de milhões de $ para a empresa diariamente. 


Gostaram do exemplo? 

Apenas para citar, que tal outro caso de uma aplicação chave para a empresa, novamente envolvendo muitos milhões de $ e demorava 16-18h. Só podiam executar no fim de semana e tinham que cortar os servidores da rede. Consegui reduzir para menos de 2h e sem afetar a rede. Neste caso, além de otimizar o SQL também foram utilizadas soluções de lógica complexa necessarios para melhor uso da CPU e obter melhores resultados. 

Quanto sua empresa ganha com serviço bem feito


Se precisam de um profissional de longa experiência que sabe o que fazer, aceito convites que sejam realmente sérios. Só falo diretamente com o responsável pela contratação, não entro em fila e nem preencho ficha em site.  




Leia também:



..

terça-feira, 1 de setembro de 2009

Lei da caça

Klingon Hamlet
Foto:
Brian Rivera - USA




Lei da Caça

"Aja, e você terá o jantar.
Espere, e você será o jantar."


"Act and you shall have dinner.
 Think and you shall be dinner."


Gowron 
Provérbio Klingon

(Star Trek: Deep Space Nine)


.'.

Procura-se deuses para estágio

A Ana Paula Idris da Silva escreveu um excelente comentário sobre sonhos e caminhada dos primeiros anos de carreira. Publicado no fórum da ComputerWorld, CwConnect.



"Sensacional foi perceber que os anúncios de emprego, nos murais das escolas, tem pedido estagiários que sejam "deuses".
O engraçado é que além dos verdadeiros disparates, porque na maioria das vezes aquela lista enorme de requisitos não tem nada a ver com o que realmente a pessoa vai fazer, também não tem nada a ver com as reais necessidades da empresa.
A salada de requisitos, parece uma misturada de pedidos para todos os deuses, e mais os requisitos para super-heróis de quadrinhos.
Engraçado, pois empresários que agem como ateus, pedem deuses. E pior, ao pedir também super-poderes, misturam também a fantasia das estórias em quadrinhos com a realidade."

30/08/2009

.'.

Leia também:

.'.

sexta-feira, 28 de agosto de 2009

Linux contra Windows mas a favor do quê mesmo?

Referente a matéria da Computerworld:

http://computerworld.uol.com.br/tecnologia/2009/08/27/grupo-a-favor-de-software-livre-faz-campanha-contra-windows-7

Me parece que a Free Software Foundation está dizendo: Não paguem pelo Windows, vocês devem pagar para nós!
São os detentores das malditas linhas de comando necessárias para instalar qualquer coisa no Linux é que querem seu dinheiro!
Só os legitimos possuidores da única verdade absoluta é que devem ser pagos para dar suporte a vocês míseros profanos incultos e sem faculdade paga pelo "papi, e que instalaram de graça uma cópia qualquer do Linux, (pois isto não é tão necessário para o usuário tradicional do Windows)!
Vamos vender suporte para Linux!
Vamos incentivar as inúmeras variações, muitas sem sentido, para se conseguir configurar qualquer coisa por mais simples que seja! Vamos incentivar o uso de software ruim, assim acabamos com a lista das 500, afinal, nenhuma empresa destas conseguiria se manter sem ter software bom e isto será finalmente a realização da grande obra, acabando com todos os hereges que não concordam com a verdade suprema!

Pagar pelo software deve ser um absurdo terrível, principalmente quando o que mais vejo, são pessoas que são sustentadas pela família, ou são funcionários públicos, ou deram sorte de ser muito amigos do chefe, para poderem trabalhar e ainda assim, receber dinheiro. Mas não por terem sido produtivas.
Sabe aquelas campanhas dos eco-chatos? Aquela turma que descobriu uma maneira bem legal de viver, mas que acham que devem bater na cabeça dos outros para serem convertidos! Pior ainda quando os mais fanáticos (e frustrados ao meu ver), descobrem que sexo deve ser só espiritual... mas porque então, costumam fazer TANTOS filhos? (risos)...

Deixando um pouco a brincadeira de lado, eu trabalho com Linux e Unix desde o século passado, tenho uma enorme bagagem em mainframes e muito Windows no caminho. Linux é uma ótima escolha se a empresa investir nele, no mínimo, tanto quanto vai gastar com a Microsoft.
Quer ter todos recursos mesmo? Compre uma versão Enterprise, pague salários dignos para ter pessoal de suporte capacitado. Vai gastar a mesma coisa ou mais.
A grande vantagem, ao meu ver, são características de estrutura, principalmente de servidor. O resto, vai depender, e muito, de você conseguir fazer o que quer neste ambiente.
Mas se a questão for ter que reinventar a roda, porque algo não funciona ou não existe ou vai ficar ruim no ambiente Linux, então é muito mais barato (e inteligente), usar o Windows.
A quantidade de ferramentas para Windows que me permitem uma produtividade muito maior é significante. Começando pela plataforma Ms-Office. Desenvolvo em Ms-Access (ótima plataforma de nível profissional, e fácil de usar até por novatos), façoo programação VBA avançada que me permite ter a imensa facilidade de trabalhar na parte de front-end com alta qualidade e sofisticação, ao mesmo tempo que posso controlar cada mínimo detalhe, incluindo integrando com outros bancos de dados, etc. A maioria das IDEs de desenvolvimento, são voltadas primeiro para ambiente Windows. Felizmente a maioria agora também são disponíveis para Linux. Mas na hora de configurar alguma coisa eu prefiro mil vezes o Windows.

Pessoal da FSF, Stallman, Peter Brown, respeito sua opinião, mas a minha é diferente. Trabalho nisto todos dias, faz décadas. E faz muito tempo que existe a funcionalidade de clicar no arquivo Setup e a coisa funcionar sózinha. Mas (na minha opinião), na ampla maioria de quase tudo que se possa imaginar em Linux, isto não existe e tem que ser na base da linha de comando e sair garimpando o que for diferente, porque sempre tem algum detalhe idiota que te faz perder tempo. É só olhar nos inúmeros fóruns de Linux, em que o pessoal troca idéias sobre como conseguir configurar as coisas mais absurdas. Acho que a inexistencia de instaladores automáticos é por puro relaxamento e preguiça. Quer ter seu software bem aceito pelo usuário médio, ou por gente como eu, que não aceita perder tempo e dinheiro com coisas primárias, então por favor, faça um instalador decente!

terça-feira, 25 de agosto de 2009

Levando Legados ao Ideal

Uma coisa que me ocorre quando se trata de sistemas legados, e até por ter que lidar tanto com eles nestes anos todos, entre uma conversão e outra, é que temos um mundo real e um ideal.

O mundo ideal, é aquele em que estamos longe do legado. Usamos outras ferramentas mais atuais, espiamos pela janela do vizinho para ver como são lindas as interfaces gráficas (que ele j-u-r-a que funcionam), conexões entre as mais diversas plataformas...

Enfim, o mundo ideal é aquele que muitas vezes sonhamos em alcançar, mantendo tudo de bom que o sistema atual tem e agregando tudo que gostariamos que tivesse.



Sabem, depois de mais de quinze anos usando Clipper e participando de fóruns, principalmente na Usenet onde encontramos caras como o Dave Pearson e outras feras que participaram na criação destas linguagens, podemos observar que as alternativas podem estar muito mais próximas do que pensamos.

Claro que eu gostaria de converter tudo direto para algo "topo de linha", do dia para a noite, sem nunca mais me preocupar em ter que manter dois sistemas em paralelo durante o desenvolvimento, muito menos ouvir a choradeira de alguém com saudade dos velhos programas... (AAAARGGGGG!!!!....)

Mas e se dizermos por partes? Agregando algo aqui e ali. Fazendo, por exemplo no Clipper, um super tunning simplesmente com a adoção do ADS, que ajuda a resolver a vasta maioria dos problemas de limitação dos arquivos DBF, aumenta estupidamente a performance, com segurança e integridade e, sem limitação de tamanhos de arquivo? E de quebra, fica pronto para você migrar para DB relacional... Claro que corrupção de dados pode ser por erro de programação ou projeto, mas aí já entra o nosso trabalho.

Fazendo um tunning destes, claro que você não deve contar o milagre todo para seu usuário, que poderia automaticamente pensar que você ficou desocupado e vai atropelar o resto do trabalho.

Continuando, sobre coisas que se vê por aí. Na usenet conversavamos com uns caras de uma rede de lojas norte-americana. Eles já usavam algo tipo VPN (no início dos anos 2000), conectando todas as lojas, num enorme sistema integrado que cobria todo o país. Tamanho da coisa? Mais de MIL lojas. Tudo em Clipper 5.2e, um pouco de sabedoria, muita experiência e aquela paciência necessária para fazer algo bem feito.

Posteriormente estavam começando a colocar uma interface gráfica para Windows, creio que era o FiveWin, e na época, não cogitavam ainda usar o Harbour que recém estava engatinhando.

Fazendo uma revisão aqui, na época, o sistema deles tinha integração com e-mail, planilhas, diversos outros sistemas de arquitetura diferentes, etc. A parte de relatórios a muito já estava sendo migrada para utilização de ferramentas produtividade, como Crystal Reports, o próprio Ms-Access e outras tantas.

Mas o que importa, é que essa idéia funciona: ir aos poucos colocando coisas novas. Sabe que as vezes o Frankenstein pode funcionar melhor numa migração tranquila do que arriscar uma fortuna numa migração maciça?
.'.

TI Verde. Indo além dos paradigmas

Organic Neuron
By: Brian Burt


Existem várias alternativas ótimas, mas muitas vezes, vamos bater de frente com (pré-)conceitos, dogmas e paradigmas que são sagrados para que os tem. O apego a certas formas de trabalho, ou sistemáticas e metodologias que foram adotadas nalgum momento também é fator de impacto.

Só para dar um exemplo de alternativa para virtualização, numa grande empresa, seria a adoção de mainframes da série Z da IBM. O Z10, topo de linha, permite a execução de cerca de 3.000 PCs.
Lembrete: Nota: Este artigo foi escrito em 2009.

Mas e se a empresa já está "catequizada" contra mainframe? Vai continuar com milhares de máquinas avulsas e todo problema de fazer isto tudo funcionar.

Tem custos? Claro que tem. Nada é de graça. Mas são alternativas que deveriam ser consideradas. Só para lembrar, a quantidade de tentativas de downgrade, de mainframe para plataformas PC, que foram grandes fracassos e prejuízos gigantescos, é algo digno de nota.

No site www.actscorp.com tem algumas histórias muito interessantes, muitas coisas ainda desde os anos 90, mas muitas delas ainda servem como alerta para os dias atuais quando olhamos a quantidade de fracassos (geralmente não muito comentados).

Em tempo, falando em TI verde, seria interessante ver o que "realmente" pensam as empresas em termos de pessoa humana como parte fundamental no processo TI-Verde. Quer dizer, seria interessante que as pessoas, e não apenas o corte de custos e lucro, fossem destacados quando se fala em TI-Verde.

Ainda hoje, em pleno século XXI, se você falar que pratica yoga, meditação ou algo assim para relaxar e melhorar seu desempenho, aprendizado, produtividade e qualidade, ainda assim, poderá ser olhado no mínimo, como mais doido do que ser apenas o tradicional "meio-doido" que todo profissional de TI é considerado (risos).

Mas como procurar alternativas para melhor utilização dos recursos técnicos, se tantas vezes parecem tornar-se apenas um fim em si, ficando o discurso do meio-ambiente (no qual interagimos) em segundo, terceiro plano?


25/08/2009
.'.

Leia outros artigos relacionados clicando nas tags abaixo:

segunda-feira, 24 de agosto de 2009

Internet: Redes do governo têm 48 mil ataques por dia

Meu comentário na Revista Info: Redes do governo têm 48 mil ataques por dia

Basta seu computador estar conectado na internet para ser alvo de tentativas de invasão através de programas automáticos.

No tempo da conexão discada, não se percebia tanto, mas quando começou a banda-larga, o log do firewal de repente deu um pulo na quantidade de tentativas de acesso de toda parte.

Sites de empresas e instituições governamentais com toda certeza serão alvo de maior interesse.

Não se trata de meramente invadir sites para fazer pixações, isto é coisa de criança desocupada.

Invadir servidores tornou-se um ótimo negócio e chantagem e terrorismo são apenas um dos pontos.

Outros pontos que são muito lucrativos, são por exemplo, conseguir informações contábeis e documentos que indiquem linhas de negócio para ter vantagem em lucrativas negociações na bolsa de valores. Isto já ocorre e tem grupos europeus oferecendo este tipo de informação, numa área em que qualquer mínima informação pode significar milhões de lucro da noite para o dia, sem nenhum alarde quanto a invasão.

Grupos indiretamente ligados a governos também atuam na obtenção de informações estratégicas, grandes companhias vasculham a rede para saber quem faz o quê, aonde está uma nova fonte de minério, ou descobrir detalhes picantes de algum dirigente, para usar esta informação quando preciso.

Capacidade técnica o nosso pessoal tem. A questão, é que devemos todos pensar e ponderar, principalmente os dirigentes de todas áreas, em nossa atitude em relação as pessoas e seu uso da internet.

A rede faz parte da sociedade do século XXI. Simplesmente barrar seu acesso, estimula as pessoas ao descuido. Regras simplesmente não terão resultado sem bom senso na sua aplicação. É necessário que a participação seja estimulada e voluntária. É como querer esconder algo de uma criança pequena. Ela ficará mais curiosa ainda e será descuidada em seus atos. Pergunte a pais que aprenderam que pode-se falar naturalmente sobre sexo com as crianças desde pequenas, respeitando-se é claro, seu nível de entendimento...

Na internet é o mesmo...

Pregar que a cegonha traz seu e-mail, enquanto tranca as janelas da empresa sem vidro achando que as pessoas não conversam e descobrem a verdade é tão temerário quanto achar ques pessoas podem fazer algo errado sómente após as 22hs.

É precisa estar realmente aberto à diálogos (ambos poderem falar e ser ouvidos), e assim estimular o acesso consciente e responsável, que é a maior arma contra invasores.

sexta-feira, 21 de agosto de 2009

Porque ERP fracassa

Este é o meu comentário para Computerworld:

Empresa são feitas de pessoas, incluindo a direção. A mudança começa em nós mesmos.
"Informatizar a bagunça", é comum. Não existem milagres e "ser parecido" pode ser muito diferente.

Exemplificando, trabalhei muitos anos desenvolvendo PCP específico para vestuário e observei no mercado muitas soluções, baseadas noutras indústrias diferentes, como mecânica, moveleira, etc, e que não representavam produtividade na parte de produtos, só agregavam mais burocracia. Se tiver interesse neste sistema, escreva-me. (Não é pacote).

As vezes acontece como comprar algo olhando só anúncios. Usar o "ERP das estrelas de cinema", não significa que você vai para Hollywood! Ser realista, usar o lado bom da ferramenta buscando produtividade e qualidade. E lucro é resultado de investimento. Cuidado ao economizar justamente onde e quando deveria investir. Usar bem os recursos é diferente. Comprando só baratinho (ou de grátis), espremendo fornecedores, tentam tirar leite de pedra.

Mesmo o mais sólido fornecedor, não vai ficar no mercado, ou manter produtos, se não houver a adequada e merecida compensação. Isto é o barco furado de muitas empresas, que espremem o fornecedor, até este desistir do produto (as vezes até quebra). O sistema perde continuidade e o ciclo todo tem que recomeçar.

Veja "Por que os projetos de ERP fracassam". Ótima matéria do Rodrigo Caetano.