Causa ou consequência?
Este é um blog em homenagem à Simone Bormann e ao Rodrigo Dias , com quem estive conversando na semana passada. A Simone é responsável por divulgar em clientes nossa visão de Dynamic Systems Initiative (DSI) e como nossa linha de produtos usa esta visão em sua evolução. O Rodrigo é um dos nossos especialistas de infra-estrutura, com foco em gerenciamento de TI.
A conversa era sobre uma mesa-redonda de DSI e gerenciamento que ela e Rodrigo vão moderar brevemente e ela me contou sobre diálogos que normalmente tem com clientes sobre monitoração de aplicações. É interessante como, ainda hoje, muitas pessoas acreditam que um produto de gerenciamento pode, magicamente, fazer aquilo para o qual não há solução instantânea. Instale um produto de mercado, execute-o e, tcham, tudo se resolve. Ainda é difícil acontecer. A questão básica é: o que se quer monitora? A causa ou a conseqüência?
O que temos hoje, para uma aplicação que é construída sem que a equipe se preocupe com o fato de que ela seja operável (veja o tópico Design for Operations no link do DSI acima), é a análise do impacto que esta aplicação tem no meio-ambiente de TI, seja ele o ambiente do servidor no qual ela executa, seja na estrutura geral de TI ou na experiência do usuário.
Quando pegamos uma aplicação deste tipo, podemos monitorar apenas processo, working-set, memória, acessos a disco, etc. Esses parâmetros são os mesmos que temos quando monitoramos superficialmente um sistema operacional. O que estamos medindo, na verdade, é a reação do ambiente operacional à execução desta aplicação. É análise de conseqüência, não de causa. Um processo dentro do sistema operacional é agregação e gestão de recursos necessários para encapsular uma aplicação e permitir com que ela execute. Se tudo der certo, o processo consegue isolar o comportamento da aplicação de forma a conter o impacto de sua execução no ambiente, tornando-o o mais previsível possível. A chamada "aplicação mal-comportada" é aquela que consegue "furar" os bloqueios e espalha seu efeitos pelo resto do ambiente. Eu não sei necessáriamente o que ela está fazendo, mas sei os sintomas que o ambiente me apresenta.
Se temos que realmente analisar o que uma aplicação está fazendo, ao invés de como ela usa os recursos do ambiente operacional, é necessário instrumentá-la ou invadi-la. A invasão é um recurso pobre e cada vez mais difícil, visto que cada vez mais os sistemas operacionais aperfeiçoam seus mecanismos de proteção à invasão do espaço de um processo.
Chamo a atenção de vocês para o projeto Design for Operations do Codeplex. O objetivo deste projeto é fornecer subsídios, aos arquitetos e todos aqueles envolvidos no design de um sistema, para a geração de modelos das aplicações, que são um dos pilares do DSI. A versão do link acima é bem nova, de fevereiro deste ano.
