O WordPress.com que oferece um serviço gratuito de hospedagem teve uma pane e saiu do ar por algumas horas no dia 18/02, e deixando 10,2 milhões de blog fora ar. Mas o que isso tem haver com Itil? … Tudo!

Aproveitei a notícia apenas para ilustar alguns aspectos desse fato no mundo do Itil, tentando evidenciar na prática alguns processos dessa biblioteca de boas práticas.

O primeiro e mais evidente deles, o serviço saiu do ar, o que caracteriza um incidente, e que precisar ser resolvido no tempo mais rápido possível. Dessa forma foi contornado (work around) através de uma identificação superficial de onde estava o problema. A prioridade era restabelecer o serviço, colocando as páginas no ar novamente.

Após isso a WordPress afirma que irá investigar a fundo a causa do incidente, ou seja gerencia de problemas irá entrar em ação para identificar a causa raiz do problema ocasionou a parada no serviço.

Um terceiro aspecto é uma mudança não prevista em um roteador importante no DataCenter parceiro, quem ou qual processo fez a liberação dessa mudança no ambiente de produção? O serviço ficou fora por 110 minutos (dowtime). A partir dai já se pode pensar também em nível de serviço, e é bem provavel que existia um acordo de nível de serviço, para estipular o tempo para restabelecer um serviço em caso de incidente com prioridade crítica.

Existem mecanismos de de redundância, mas na hora “H” não funcionaram (disponibilidade e continuidade), talvez por falta de testes adequados, enfim.

A idéia não é encontrar o culpado, e sim identificar as lacunas em cada processo e aperfeiçoa-lo, é um ciclo constante por melhoras. Provavelmente além desses existem outros aspectos que possam ser abordados, caso alguém enxergue algum outro, por favor, comentem.

Um abraço!

Alexsander Oliveira

Existe um livro da versão três (V3) do Itil (Continual Service Improvement, 2007) que trata exclusivamente desse tema. É intitulado como um guia prático em avaliação e aperfeiçoamento da qualidade dos serviços, e é indicado para pessoas ligadas as boas práticas de gerenciamento dos serviços de TI que, pretendem compreendê-las e melhorá-las continuamente. Baseado no ciclo de Deming conhecido como Plan, Do, Check and Act, o famoso PDCA.

São definidos 7 passos para o processo de melhora continua.

1 – Definir o que você deve medir.
Converse com as pessoas do negócio, clientes, gerencia de TI. Utilize o catalogo de serviços como ponto inicial bem como os requisitos de níveis de serviço de diferentes clientes. No cenário ideal, o que deveria ser medido?O que é importante para o negócio?
Faça uma lista do que você entende que deveria ser medido, mas não uma lista complexa, seja objetivo.

2 – Definir o que você pode medir.
As organizações podem encontrar limitações no que ela está medindo, o fato é que, se você não pode medir, não deve nem aparecer no acordo de nível de serviço.
Identifique as ferramentas que você usa atualmente para isso. Essas ferramentas incluem softwares de gerenciamento, monitoramentos, relatórios, investigação, entre outros. Nessa etapa é possível inclusive identificar oportunidades.

3 – Coleta de dados.
Os dados coletados devem estar baseados nas metas e objetivos. Essa coleta pode ser feita por ferramentas de gerenciamento de monitoramento. Nesse ponto a informação que vem é bruta, ainda não está transformada e trabalhada, porém é importante que esteja estruturada de padronizada.

4 – Processamento de dados.
Nessa etapa os dados são processados de acordo com os anseios da melhora continuada do serviço e com os indicadores de desempenho. Ou seja, os dados serão processados de acordo com os objetivos de seu gerenciamento. As origens desses dados podem ser, por exemplo, de ferramentas de monitoração, relatórios, etc.

5 – Análise dos dados.
É nesse ponto que os dados são transformados em informação para identificar as lacunas nos serviços, tendências e impactos sobre os serviços.
Essa análise de dados transforma a informação em conhecimento e trás habilidades para organização.

6 – Apresentar e usar a informação.
As perguntas sobre o porquê de determinada informação foi pega e trabalhada são respondidas aqui. A idéia é apresentar exatamente os resultados que seriam obtidos com as melhorias.

7 – Implementar as ações corretivas.
O conhecimento aprendido é usado para aperfeiçoar, melhoras e corrigiradequar os serviços. O pessoal normalmente identifica os problemas e as soluções, entretanto é necessário controlaracompanhar esse processo de melhoria. As ações corretivas precisam ser tomadas para prover as melhorias necessárias ao negócio. Dessa forma cria-se uma baseline e novos ciclos são iniciados.

A melhora continuada dos serviços, trás diversas oportunidades a organização. Baseado em suas metas, objetivos e tipos de serviços prestados, você pode priorizar as atividades e iniciativas de melhorias.

Cada uma dessas etapas, integradas foram um ciclo, conforme a OGC no livro Continual Service Improvement, elas constituem uma espiral do conhecimento. Nas práticas atuais, conhecimento acumulado e sabedoria derivam desse conhecimento.

Alexsander Oliveira

Automatizar o Gerenciamento de Incidentes significa registro e monitoramento de incidentes, verificação de status de recursos de sistemas, preenchimento de pedidos de serviço padrão e gerenciamento de conhecimento.

A Gerência de Incidentes tem como principal objetivo colocar o serviço do usuário on-line o mais rápido possível, minimizando Impactos na operação do negócio dentro dos níveis de SLA (Service Level Agreement) estabelecidos.

“ Nos conceitos do ITIL, um incidente representa qualquer evento que: não é parte da operação de um serviço que causa ou pode causar um interrupção ou redução de qualidade de serviço”.

(TSO ITIL Service Support)

Alguns posts a respeito são enfáticos em dizer que um CMDB não pode ser construído conforme a ITIL preconiza. Não quero concordar nem discordar. Apenas relatar que uma iniciativa que pretende contruir uma base de dados relevante e ágil realmente pode consumir muito investimento (e talvez não alcançar os benefícios esperados).

A Wikipedia no artigo referente a CMDB tenta resumir uma definição a respeito em apenas duas porções: Introdução e propósito e na verdade não consegue. Mas então? Como eu posso resumir um CMDB?

Para responder a este questionamento vou tomar como base um material criado pela Evergreen entitulado “Nine Steps to Implement a Successful CMDB Project” que disponibilizo aqui para download.

Considere uma boa definição de um CMDB os seguintes itens:

1. Trata-se de uma aplicação de suporte que propicie a visualização sobre o que há e como (se?) ocorrem interações entre os elementos de um parque tecnológico
2. Deve monitorar e reportar os eventos de configuração
3. Deve padronizar os componentes atribuindo uma identidade, propriedade e estruturação
4. Deve reconhecer diversos tipos de componentes (CIs – Configuration Items) e seus relacionamentos a exemplo de: redes, servidores, softwares, arquivos etc.

Parece fazer bastante sentido o exposto acima? A mim ainda não. Então tentemos seguir por um jeito mais pragmático: exclusão de possibilidades.

O que um CMDB NÃO É:

• Uma base de dados complexa ou especialmente desenvolvida para esta finalidade
• Uma aplicação orientada a processo como Mudanças ou Liberações
• Apenas uma aplicação de monitoramento, apesar de incluir o gerenciamento de alguns tipos de eventos (isto me lembra Nagios, por que será?)
• Um software para controle de versão
• Um Catálogo de Serviços (apesar de que ambos devem usar a mesma estrutura de CI)

Ainda parece confusa a definição de um CMDB? Se sim, avalie a figura abaixo:

Figura 1: Resumindo a relação do CMDB na ITIL

Parece ser claro que o CMDB deve fornecer informações às diversas disciplinas da ITIL com intuito lógico de municiar todas com dados que direcionem seus esforços no alcance de suas atribuições.

Antes de continuar, deixe-me comentar um pouco sobre o que é um CI (Configuration Items). A melhor definição de um CI em si é muito simples: “Determinado objeto ou elemento no ambiente de TI que seja gerenciável.” Um CI, por definição, está sob a Gerência de Mudanças. Um ciclo de vida de um CI pode ter vários estágios, e muito frequentemente é indefinida, em termos de tempo – ao contrário de um projeto ou incidentes, que são geridos principalmente em termos de progresso através da sua vida e último encerramento.

Assim exposto, faz sentido pensarmos em CI como uma vasta gama de possibilidades abrangendo desde o mais óbvio (desktop) até o nem tão óbvio (processador de uma máquina) não esquecendo é claro de impressoras, switches, aplicações (sim softwares) e afins.

Bem, a intenção deste post é despertar o interesse sobre esta função da Biblioteca ITIL e recomendar a avaliação de pelo menos uma ferramenta de mercado que pode ser utilizada de forma gratuíta por até um ano: o CMDB Discovery.

O CMDB Discovery tem uma concepção interessante já que ele foi desenvolvido a partir de duas iniciativas:

1. Das necessidades que a Teclógica tinha em montar uma base de dados consistente sobre sua própria infra-estrutura de TI e de seus clientes
2. Da minha necessidade em estudar a função e desenvolver uma monografia que pudesse ser implementada e transformada em algo palpável

Desta primeira iniciativa só tenho a recomendar: avalie o software e entenda como o CMDB pode auxiliar.

Da segunda, faça o download da minha monografia em Engenharia de Sistemas e saiba mais sobre a ITIL e a função CMDB.

Por fim, agradeço os feedbacks.

Marco Aurélio Neuwiem