Seu objetivo é desenhar os aspetos relacionados aos planos de continuidade e recuperação dos serviços e tem relacionamento direto os gerenciamentos de: Risco, Disponibilidade e Segurança.

Com ajuda da área de negócio deve ser definido o que é crucial para empresa (tal análise é conhecida como Análise de Impacto de Negócio) continuar operando caso ocorra um desastre. Entenda-se que desastres seriam situações onde a empresa pode simplesmente “morrer” se o risco do desastre for realmente efetivado e não houver tais planos de continuidade.

O assunto do momento é o Cloud Computer (Computação na Nuvem) que é basicamente usar recursos (serviços) computacionais fornecidos através da internet.

A Cloud pode ser uma opção para alguns aspectos da continuidade dos serviços de TI. Você pode, por exemplo, manter serviços como: Software, Infraestrutura, Armazenamento, Plataforma de Desenvolvimento na nuvem.  Ou até mesmo usar o conceito de nuvens híbridas, que seria unir o convencional com o Cloud Computer solicitando recursos na nuvem de acordo com a demanda.

Um bom exemplo de empresa que entrega serviços na nuvem é o Google com suas ferramentas de escritório online, Google Docs.

O fato é que ter tais serviços na nuvem pode facilitar ou melhorar cenários de grandes desastres, além de poder ajudar no gerenciamento da demanda. Muitos CIOs observam esse “novidade” com cautela, e com razão. Devido ao fato dessa tecnologia estar em processo de amadurecimento e ainda existem muitas dúvidas no ar referente principalmente a segurança desses serviços. Entretanto existem outros CIOs apostam nessa “revolução”, afinal é atráves disso empresas inovadoras e que saem na frente, assumem riscos.

Toquei no assunto de forma sucinta sobre a continuidade, mas existem outros aspectos interessantes do Cloud Computer correlacionados com a biblioteca de boas práticas. Para prover tais serviços é necessário um nível altíssimo em gerenciamento de serviços de TI, posso citar como cruciais por exemplo: gerenciamento de: risco, evento, disponibilidade, capacidade segurança e por ai vai.

É isso pessoal, um abraço e comentem.

Alexsander Oliveira

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

Tem como principais objetivos:

1. Fazer seu dinheiro ter o valor adequado e justo
2. Ajustar o arcabouço jurídico (contratos) em conformidade com as demandas do negócio
3. Gerenciar o relacionamento e a performance dos fornecedores

O Processo de Gerenciamento de Fornecedores presta atenção aos fornecedores e aos contratos de fornecimento de serviços recebidos pelo comprador. Via de regra, quanto maior a contribuição de um Fornecedor ao negócio maior o esforço dispendido no gerenciamento da relação – nao poderia ser diferente.

Resumidamente, os seguintes aspectos devem ser considerados:

• Políticas de inclusão e manutenção dos fornecedores
• Centralização (base de dados) para os contratos
• Categoriação dos fornecedores e o risco de invesitmento
• Avaliação de Contratos
• Negociação e Aprovação de Contratos
• Revisão, Renovação e Término dos Contratos

Tudo tem um começo

Parece simples quando assim descrito, mas como fazer para manter um bom ciclo de vida de um contrato? A proposição da ITIL é a de se seguir e armazenar os seguintes itens:

1. Identificação dos Requisitos
2. Seleção dos fornecedores
3. Categorização
4. Regulação
5. Gerenciamento
6. Renovação ou Término

Para que se alcance os objetivos da relação, ambas as partes devem estabelecer diretrizes com base em informações mútuas que permitam um relacionamento franco e produtivo e, para que isto se torne verdadeiro, algumas informações importantes devem ser compartilhadas, a  saber:

1. Informações sobres os negócios (Planos, Estratégias e Horizontes)
2. Estratégias de suprimento e contratos
3. Plano de Negócios Detalhado
4. Informações de Performance

Fica a breve visão a respeito, na certeza de que muito há de se explorar no tema.

Forte abraço!

É um momento triste, mas que abre espaço para uma reflexão sobre planos de continuidade para o negócio. Cito o negócio, pois a continuidade dos serviços de T.I. somente existirá se houver um plano para continuidade do negócio.

A exemplo o porto de Itajaí que está tendo um prejuízo diário de 33,5 milhões. Um impacto enorme para o negócio e economia do Brasil.  Será que na avaliação de riscos, foi levantado como possibilidade a combinação da chuva intensa e outros fenômenos bem específicos da região que levariam a esse cenário? Essa combinação de chuvas com outras catástrofes diminui ainda mais as chances matemáticas do desastre. Apesar disso, o plano da continuidade não perde sua importância.  Além do que, imagino que um porto desse tamanho e com essa importância, deve ter planos de continuidade do negócio. Não é o foco aqui discutir isso, mas sim evidenciar a importância do tema, pois,  o quanto antes for feito restabelecido as atividades do negocio, menores serão as perdas. Parece obvio dizer isso, não é? Mas o que pode ser feito para voltar as atividades de forma mais rápida? A resposta também é obvia,  planejamento da continuidade do negócio. Um luxo ou o mínimo esperado?

Ainda a exemplo da catástrofe em SC. Em muitos casos a infra-estrutura das empresas permaneceu intacta, mas o que acontece se seus colaboradores não conseguem chegar até lá? Muitos ficaram isolados, sistemas de transporte parado, entre outros problemas. Dessa forma as pessoas não conseguem chegar ao local de trabalho. E o que vale uma empresa sem as pessoas?Pode valer muito se essa empresa permitir que seus funcionários trabalhem remotamente. Essas e outras questões devem previstas,  discutidas e documentadas no plano de continuidade.

Abaixo um diagrama que explica resumidamente esse processo.

Esse é um assunto muito interessante e o momento é sugestivo para pensar em novos planejamentos para futuros planos de continuidade, já que o que aconteceu recentemente foram situações inesperadas e de baixas probabilidades, logo fica o convite para “blogarmos” a respeito.

Alexsander Oliveira

O Gerenciamento de Nível de Serviços é o processo que forma o vínculo entre o departamento de TI e os clientes. Para implementar este processo com sucesso é necessário que os outros processos da ITIL já tenham sido implementados.

O foco principal deste processo é assegurar a qualidade dos Serviços em TI que são fornecidos, ao um custo aceitável ao negócio.

Mas a questão que permanece é: quando este acordo tem de ser revisto? Até que ponto sua redação e entendimento atendem as necessidades da empresa do ponto de vista do negócio e financeiro? E mais, quem são os responsáveis por entregar idéias para seu aprimoramento?

Ser Gerente Comercial tem uma característica que me agrada muito: conhecer pessoas de diversas corporações, normalmente da área de TI, que expõem suas dificuldades e conquistas na gestão de serviços de TI. Essas trocas de experiências são fundamentais já que que ambos se beneficiam do conhecimento que partilham.

Bem, numa dessas ocasiões, visitando uma grande corporação nacional me deparei com um caos bastante interessante, que partilho nesse post.

A Coporação X (sim, o nome é fictício mesmo) o Sr. CIO (acrônimo do nome para preservar sua identidade) relatou que ainda que sua corporação dispusesse de um SLA muito bem definido, e que atendia boa parte das necessidades das partes envovlidas, o acordo havia criado uma situação bastante capciosa, explicando:

Sr. CIO: Marco, meu SLA é bastante claro para todos os envolvidos e rege a disponibilidade dos serviços dentro das minhas necessidades financeiras (custos). Porém, há momentos em que eu penso que o rigor que ele propiciou me deixa em situações complicadas.

Eu: Desta forma assertiva que expõens, parece que realmente o SLA cumpre seu papel, mas o que lhe incomoda?

Sr. CIO: Olha, desde que o serviço não necessite de melhorias (aprimoramentos no sistema) tudo funciona muito bem.

Eu: Me explique melhor.

Sr. CIO: Veja o caso de meu sistema de telefonia. Mantê-lo em funcionamento é mandatório para meu negócio, e realmente o sistema se mantêm muito estável já optamos por uma plataforma aberta (Asterisk). Todavia, quando ocorre uma mudança física, por exemplo, alguém muda-se de lugar, preciso mudar o comportamento do sistema a fim de efetivar logicamente a mudança e isto é tratado como uma melhoria.

Eu: Entendo, mas, onde está o problema? Parece-me que realmente trata-se de uma melhoria que deve precisar do apoio do CAB (Change Advisory Board)*, correto?

Sr. CIO: Pois é isto mesmo. E é aí que sinto que temos de dar muito atenção para melhorarmos. Veja, o CAB reune-se mensalmente para aprovar (ou reprovar) quais mudanças devem ser implementadas. No caso de comentei contigo veja o paradoxo que criamos: pense que quando uma nova pessoa entrar na área de contato com cliente (Comercial, por exemplo) ela terá de aguardar a reunião para que possamos modificar nosso sistema de telefonia para contemplar a entrada desta pessoa. Este trabalho, modificar o sistema de telefonia, não leva mais do que 10 minutos para ser executado. E fica a questão: por quê esperar até um mês para executar uma situação crítica sendo que em minutos ela se resolverá?

Eu: Entendi, mas porque simplesmente não muda-se a forma como as atividades foram priorizadas? Digo, porque não tratam estas ocorrências como rotineiras já que a mudança de lugar físico parece fazer parte da rotina da empresa?

Sr. CIO: Porque simplesmente nosso SLA foi constituído desta forma e até o momento não temos como modificá-lo em tempo de voo.

Eu: Entendo… (preferi não continuar o assunto já que ele parecia ficar cada vez mais irritado com o fato ocorrer mesmo após ter empregado muito fosfato para empreender o melhor para a corporação).

Resumindo: não há mágica para encontrar a melhor solução, a experiência é fundamental (e a agilidade também).

Até a próxima, Marco Aurélio.

* Change Advisory Board pode ser definido como um grupo de pessoas que aconselha a mudança, priorização e agendamento. Este conselho é normalmente constituído por representantes de todas as áreas, incluindo fornecedores.

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