Como Implementar ITIL nas pequenas e médias empresas – Parte 7

 

 

Salve, salve pessoal do Cooperati, vamos prosseguir com a nossa série de Como implementar ITIL nas Pequenas e Medias empresas, no nosso post anterior finalizamos a fase de Transição de Serviços, que discute como deve ser feito os testes e a documentação de todo o processo que foi desenhado para que na hora da real implementação nada fique despercebido ou que as chances disso ocorrer sejam a menor possível e principalmente que quando ocorrer falhas no sistema a sua empresa esteja munida de ferramentas para solucioná-los o mais rápido possível.

Mas e se algo passar em branco ou se um dos problemas que foram diagnosticados na fase anterior acontecer, como proceder? É pensando nessa questão que entra a Fase de Operação de Serviços, nela é citado tudo o que ocorre na parte operacional dos sistemas de TI, e normalmente muitos resumem a ITIL a essa etapa ou começam a implementa-la por aqui, sem verificar as etapas anteriores que como visto são tão importante quanto ela.

Então vamos lá, o primeiro processo dessa fase que entra em ação quando algo acontece fora dos padrões é o Gerenciamento de Eventos. Esse processo emite alertas de 3 tipos: Informação, Aviso e Erro.

O primeiro como dito é alguma informação do tipo, um serviço iniciou ou parou, que alguma tarefa foi realizada com sucesso entre ações similares, como o nome disse é uma informação onde você pode tomar alguma ação ou ignora-la. O segundo tipo, que é o aviso, já merece um pouco mais de atenção, pois ele serve como um alerta de que algo talvez não esteja funcionando da maneira correta e que pode interferir ou não no andamento do sistema, um exemplo de aviso é: a memória do servidor está chegando ao seu limite ou o espaço em disco está chegando perto de um nível critico, você pode tomar uma ação ou não, vai depender de como você achar que deve proceder. Já o terceiro tipo pode-se resumir em “A casa caiu”, pois como o próprio nome diz, ocorreu um erro ou exceção e alguma coisa do sistema não está funcionando e isso vai acarretar em mau funcionamento do próprio, esse tipo deve ser tratado com todo o carinho possível, pois quando ele acontece ou algo vai parar ou já parou e sua situação está delicada.

O Gerenciamento de Evento também é um ótimo auxilio para o Gerenciamento de Problemas e o Gerenciamento de Incidentes que serão falados posteriormente, pois como foi dito, eles dão a ideia exata de onde a exceção está ocorrendo (ou pelo menos essa devia ser a função, por essa questão que um sistema deve ser bem documentado e principalmente mostrar as suas exceções ou erros bem detalhadas para que a detecção e a resolução da anomalia possam ser rápidas e indolores).

Essa etapa também tem alguns extras que merecem ser mencionados, como falado a base para que esse processo ocorra é ter um sistema de eventos bem detalhado ou pelo menos de fácil entendimento e isso pode variar de sistema para sistema, se for um sistema pequeno talvez aparecer um pop-up na tela passando a informação que deseja seja o suficiente, mas se você quer incrementar o seu gerenciamento de evento dependo da ação que o usuário tome deva ser registrado em logs, que são a forma mais difundida de gravação de eventos e que muitos de nós já utilizou ou utiliza frequentemente, mas não caia na tentação de querer gravar tudo o que ocorre, pois você terá tanta informação que acabará se perdendo ou cansando de procurar o que precisa, então tenha como meta: guarde somente aquilo que será realmente necessário para você ou para quem for dar assistência ao sistema.

Porém um bom Gerenciamento de Eventos é aquele que possa ser programado para emitir um alerta assim que algo de importante aconteça e para quem programa isso tenha que por em mente que essa informação tem que chegar a quem realmente necessita saber, não adianta disparar um e-mail para N pessoas e nenhuma delas dará confiança ou até precise saber, mas pensa a outra pessoa também recebe e vai verificar isso e vice-versa, como diz um ditado “Cachorro com 2 donos morre de fome”.

E para exemplificar um sistema de Gerenciamento de Eventos no lado Windows temos o nosso bom e velho Visualizador de Eventos que armazena várias informações por tipos e se bem configurado guarda aquilo que realmente interessa, além de ter filtros para verificar somente um tipo de evento ou quais eventos ocorreram em uma determinada data, além de ser integrado com o Perfmon que fica verifica se um determinado evento ocorre e dispara um aviso a quem interessa. Juntos essas ferramentas podem evitar várias dores de cabeça futuras.

E do lado Linux temos o arquivo messages que fica dentro /var/log/messages que informa as mensagens de sistema e as armazenam nele, e que podem ser gerados scripts para verificar e filtrar determinados eventos e executar as devidas ações, no Linux geralmente os sistemas possuem seu próprio arquivo de eventos e cada um tem a sua localização, mas na documentação do produto possui o arquivo (pelo menos nos programas que se prezem) e também podem ser tratados da mesma maneira.

Porém existem eventos que já são conhecidos e podem ser tratados sem ter que passar por uma intervenção de nível superior e que podem ser resolvidos pelos níveis inferiores de atendimento e nessa etapa possuem pessoas que seguem alguns roteiros para poder tratar esses eventos de uma maneira mais rápida.

Esse tipo de atendimento também possui um processo chamado de Cumprimento de Requisição, neste processo são tratadas todas as requisições que podem ser atendidas de uma forma rápida e que não comprometem ao bom andamento dos negócios e funcionamento da empresa, dentre essas requisições estão troca de senha de usuário, instalação de softwares pré-aprovados e etc.

Uma característica especifica desse processo é que geralmente quem trabalha nessa parte, tem um roteiro
a ser seguido e são o primeiro contato do usuário com a resolução de problemas e em alguns locais são eles que escalonam para onde o problema vai ser direcionado, se caso eles não conseguirem resolver a requisição.

Este processo, repetindo, por poder ser um ponto de contato primário ele também age como um ponto de tira-dúvidas do sistema da empresa.

Geralmente, o setor que cumpre o papel de Cumprimento de Requisição possui mais pessoas que os outros setores, por justamente serem mais demandados e um outro ponto é que a pessoa para estar nesse setor não precisa ser totalmente técnica, sabendo operar um sistema que o guia para instruir o usuário já é o suficiente.

Para elucidar melhor o que digo, todo mundo aqui já ligou para uma empresa de algum sistema para poder reativa-lo ou tirar alguma dúvida, então quem te atendeu você não sabe se era alguém técnico ou não, mas que provavelmente resolveu a sua requisição ou dúvida, este processo é muito importante dentro de uma empresa, pois ele alivia os outros setores, mas como no nosso caso estamos falando de pequenas e medias empresas, então no caso das empresas que possuem o EU-TI-SMO, geralmente é uma pessoa para realizar tudo, mas uma dica para esse tipo é investir em treinamento no sistema para que as requisições que chegarem a você sejam aquelas que realmente precisariam chegar e não aquelas dúvidas que com um simples treinamento poderia ser esclarecida.

Mas se possuir mais de uma pessoa no setor pode haver um revezamento entre elas para que cada um possa realizar as outras tarefas ou se haver uma disparidade grande de conhecimento, deixe a que possui um pouco menos de conhecimento fazer esse procedimento e a outra para resolver os problemas mais sérios, e não é desmerecimento, já que quem está realizando a função de Cumprimento de Requisição pode aprender muito com algumas dúvidas dos usuários.

E para auxiliar mais o processo de Cumprimento de Requisição, uma parte da documentação gerada no processo de Gerenciamento do Conhecimento pode ser liberada para ele, assim a informação é passada de forma mais rápida e com isso uma boa ferramenta para isso continua sendo o Sharepoint Foundation ou o GLPI que possui uma sessão somente para soluções de problemas, onde as soluções conhecidas são liberadas.

Mas e se caso o Cumprimento de Requisição não conseguir sanar a requisição do usuário? Como foi dito passa-se o problema para o Gerenciamento de Incidentes ou o Gerenciamento de Problemas, e este será o assunto do nosso próximo post dessa série, espero que possam tirar algo de proveito do que foi passado aqui, até a próxima.

Share

    Comments

    1. Laerte, ta mandando bem nestes artigos parabéns…

    2. Parabéns pela sequências de posts, todos execelente aguardando o proximo,
      Valeu…

    Deixe um comentário

    O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

    © 2019 All Rights Reserved. Cooperati. 

    %d blogueiros gostam disto: