No Community Zone que ocorreu na semana passada estávamos conversando em uma mesa, não vou citar os nomes porque não lembro todos e seria injusto, e chegamos no assunto acima. De um lado da mesa tinhamos alguns IT PROs e do alguns desenvolvedores. Os desenvolvedores já logo criticam o pessoal de Infra pela dificuldade que eles impõe e sempre jogam a culpa nos sistemas e programadores.

Eu atuo nas duas áreas desde que comecei a trabalhar em 1988. Neste época sistema operacional era CPM, rede era multiplexada serial, linguagem era Dbase II que já era o banco de dados também. Desde então tento manter os dois universos, estudo tanto os produtos de rede quanto as linguagem de programação. Posso dizer que está ficando dificil, os produtos se tornaram muito complexos, mas ainda consigo me organizar por estudar a fundo um por vez focando nas mudanças.

Mas enfim, a idéia do post é falar da experiencia de quem a um bom tempo convive nos dois mundos.

O que os desenvolvedores fazem para serem “odiados”?

O principal problema dos profissionais de redes é conseguir monitorar as aplicações. Os desenvolvedores não se interessam muito em como os IT PROs trabalham e não dão os recursos necessários para eles. Algumas coisas simples como métricas, logs e identificação clara de processos já resolveriam muitas discussões.

O que podemos fazer como desenvolvedores para trazer a paz?

Alguns exemplos de recursos que poderiam ser facilmente utilizados pelos desenvolvedores:

• Na string de conexão com o banco de dados inclua o parametro Application Name para o DBA poder monitorar a aplicação. É um parametro muito simples e extremamente necessário, porque em aplicações é comum utilizar usuários fixos para aplicações e sem o nome não é possivel saber qual sistema está executando aquele comando que gerou locks ou wait times excessivos. Um exemplo de uma string de conexão “bem feita” seria:
  ”Provider=SQLServerOleDB;Server=ABC;Database=DEF;UID=Joao;PWD=1234;Application Name=SISContabil”
• Inclua nos seus aplicativos contadores de performance utilizando os objetos PerformanceCounter e Installer. Estes objetos geram no Performance Monitor do Windows dados que podem ser transformados em gráficos, traces, alertas e logs. O processo para criar um contador é muito simples:
  1. Insira o objeto PerformanceCounter em sua aplicação
  2. Configure o objeto criando uma categoria (CategoryName) e contador (CounterName)
  3. Clique com o botão direito no objeto e escolha Add Installer para que sua aplicaçoes crie no registry do Windows os registros do contador
  4. No seu código ao acessar um banco de dados, por exemplo, utilize o objeto PerformanceCounter com o método Increment para aumentar o valor do contador
• Gere erros ou alertas de problemas no log de eventos do Windows. Este recurso permitirá aos operadores vasculhar no Event Viewer do Windows problemas que estão ocasionando paradas. Tão útil é este recurso que os IT PROs poderão utilizar produtos como o System Center Operations Manager, NetIQ ou Tivolli para quando um evento acontecer disparar emails de alerta para os administratores, ou melhor ainda, executar scripts que automaticamente resolvem o problema.
  Para fazer isso basta seguir os passos:
  1. Acrescente ao seu aplicativo o objeto EventLog
  2. Defina o nome do Log (Log) que será criado e o nome da aplicação (Source)
  3. Dentro do seu aplicativo utilize o método WriteEntry para passar os parametros que serão gravados no log do SO

Estes são 3 exemplo que poderão ser utilizados e resolverão muitos dos problemas que hoje existem entre estes grupos. Claro que os exemplos estão baseados em aplicações Windows Forms, mas os mesmos objetos podem ser utilizados programaticamente no ASP.NET.

Para que os desenvolvedores tenham uma idéia do porque é importante os passos acima, pense que o IT PRO trabalha com resolução de problemas baseados em comportamento de sintoma-causa-solução e sem contadores de performance e eventos não tem como achar a causa sobrando apenas culpar o programador que “andou mexendo no servidor”.

Outro recurso muito importante que os passos acima possibilitam é criar o Baseline onde os IT PROs tem uma base de alterações no ambiente. Por exemplo, fazem a medição de contadores ao longo de um periodo e quando o servidor apresenta problemas de performance eles comparam os contadores atuais com os de base para descobrir onde estão as variações. Se o desenvolvedor não dá as medições o IT PRO irá verificar os contadores e como nenhum demonstrará o problema, mais um vez o “programador que mexeu aqui” é o culpado.

Outra forma de monitoração com produtos que já foram citados são os Dashboards do SCOM que mostram em grandes monitores o estado de cada servidor por monitorar os eventos no log e o baseline de performance. Se a aplicação não gera nem log nem contadores, o servidor não irá apresentar o erro, resumindo a dizer que o IIS ou o SQL está com tempo de resposta lento quando o problema já se alastrou para todos os subsistemas (disco, processador e memória).

É isso ai, como programador também me incluo entre os que deixam de prover as ferramentas. Mas vamos mudar isso !!!!!

Se alguem lembra de outros métodos para “pacificar” essa apimentada relação, comente.