TMACUL

ASSUNTO DO DIA: Gerenciando mudanças (A história do "dedo-duro")  05/10/2015

Blog Post created by TMACUL Champion on Dec 30, 2015

A infraestrutura de TIC muda todo dia em qualquer empresa e isso é inevitável. Mas quando as mudanças começam a gerar resultados inesperados, o assunto "Controlar as mudanças" vem a tona.

Conforme o ITIL, o objetivo do processo de mudanças é maximizar a disponibilidade dos serviços diminuindo ao máximo o impacto gerado aos clientes. Mas todos sabemos que além disso, um dos maiores entregáveis desse é processo é responder à clássica pergunta: "Quem foi que fez isso?"

 

Imaginar que todos os usuários seguirão o processo de mudanças de olhos fechados é no mínimo uma enorme ingenuidade. Ninguém gosta de preencher formulários e ninguém gosta de ser controlado. Ainda mais quando tratamos com usuários de conhecimento privilegiado.

 

E já que não é possível fechar todas as portas que possibilitem a execução das mudanças, é conveniente criar alguns mecanismos sistemáticos que consigam no mínimo auditar o que foi executado. Monitorar o restart de equipamentos/serviços, alterações de DNS e liberações de versão de sistemas (Deploys) podem ser bons exemplos do que pode ser monitorado.

 

E mais importante do que monitorar, é conseguir consolidar estes registros em uma única base a fim de cruzar estes dados com os tickets de incidente, problema e mudança. Somente dessa forma o processo de mudança se complementa e consegue fornecer mais respostas.

 

E para que isso seja possível, imagine o seguinte cenário:

 

1) Através dos agentes de monitoria (por SNMP) é possível identificar o restart de qualquer equipamento "gerenciável";

 

2) Os scripts de gerenciamento de "Application Servers" (Tomcat, Weblogic, IIS, etc) geram log's das intervenções que são realizadas; O mesmo se aplica para alterações de DNS;

 

3) Deploys de versão de sistemas devem ser feitos apenas utilizando-se ferramentas de liberação padronizadas;

 

4) Na SDM, cria-se um novo objeto chamado "z_lib") para armazenar todos as liberações realizadas. Neste novo objeto existiriam atributos do tipo categoria da liberação, ferramenta de liberação, responsável, detalhes da liberação, Nº da mudança, Nº do incidente/problema, Serviço afetado, IC, data da liberação, Nº do registro de liberação, etc.

 

5) Todos estes atributos seriam fornecidos pelos agentes de liberação que se reportariam à SDM através de webservice/outra integração. É desejável que este processo ocorresse de forma online;

 

6) Em um segundo momento, quando todos os agentes de liberação fossem implantados, seria possível, autorizar ou reprovar a liberação caso uma janela de mudança não estivesse sendo respeitada;

 

7) Assim que estes registros de liberação estivessem dentro da SDM, seria possível implementar mecanismos que auxiliassem os agentes e gestores de atendimento quando estes estivessem registrando/investigando/solucionando mudanças, incidentes, problemas, etc.

 

 

PRINCIPAIS BENEFÍCIOS

 

- Métricas precisas para auditar a eficiência e a utilização do processo de mudanças;

- Novas funcionalidades que permitissem a investigação das possíveis causas de incidentes;

- Novas notificações/relatórios para auxliar a gestão;

- Poder culpar qualquer um com o "dedo-duro", ops, digo, conseguir identificar os responsáveis pelas liberações para então orientá-los sobre os procedimentos corretos adotados na empresa.

- E um monte de outros benefícios. Basta usar a imaginação.

 

Até a próxima.

 

 

Publicado Originalmente: 05 de outubro de 2015 às 21:19

Em: CA SDM Brasil - facebook

Por: daniel-bighelini

Outcomes