Processos e Funções do Ciclo Operação de Serviço

É na “Operação de Serviço” que se coordena e realiza as atividades e proces- sos necessários para fornecer e gerenciar serviços em níveis acordados com o usuário e clientes do negócio.

Conceitos e Definições associados ao Ciclo Operação de Serviço:

Obs.: Estes conceitos e definições são apresentados pelo Autor Marcos André dos Santos Freitas em seu livro Fundamentos do Gerenciamento de Serviços de TI, que são: Evento: Um evento é uma mudança de status significante para o gerenciamento de um Serviço de TI. É um alerta de notificação criado por qualquer Serviço de TI, Item de Configuração ou ferramenta de monitoração. Eventos geralmente requerem ações das equipes de Operações de TI e podem iniciar um registro de incidente.

Incidente: Uma interrupção não planejada de um Serviço de TI ou a redução de sua qualidade.

Problema: Causa Raiz de um ou mais incidentes. A Causa Raiz não é conhecida no momento em que o Registro de Problema é criado e o Gerenciamento de Problemas é responsável pela investigação inicial.

Registro de Incidente: Registro contendo os detalhes de um Incidente. Cada Registro de Incidente documenta o Ciclo de Vida de um único incidente.

Registro de Problema: Registro contendo os detalhes de um Problema. Cada Regis- tro de Problema documenta o Ciclo de Vida de um único Problema.

Solicitação de Serviço: Uma solicitação de um usuário para informação, aconselha- mento, para a realização de uma Mudança Padrão ou Acesso a um Serviço de TI é importante diferenciar Solicitações de Serviço de Solicitações de Atendimento de Inci- dentes. Incidentes são falhas na operação normal de um serviço, enquanto solicitações são atividades previstas para serem realizadas pelas equipes de TI e que não estão relacionadas com falhas na operação padrão dos serviços nem requerem mudanças nos ambientes de TI (RDM)..

Mudanças Padrão são exemplos de Solicitações de Serviços. Como já visto no Geren- ciamento de Mudanças, uma Mudança Padrão são tipos de Mudanças pré-aprovadas, para as quais já há procedimentos de execução predefinidos, testados e aprovados, e que possuem baixo risco de execução.

Solicitações de usuários como dúvidas, informações ou execução de rotinas como reset de senhas de usuário ou qualquer solicitação de TI que não necessite de análise, teste e aprovação, e que não possua risco de impacto na operação. Solicitações de Serviços são realizadas pelo processo de Cumprimento de Requisição, enquanto Incidentes são direcionados para o Gerenciamento de Incidentes. Solução de Contorno: Solução para reduzir ou eliminar o impacto de um Incidente ou Problema para o qual a Resolu- ção Completa ainda não está disponível.

Causa Raiz: A causa desconhecida de um Incidente ou Problema.

Erro Conhecido: Um Problema que possui Causa Raiz e Soluções documentadas. Erros Conhecidos são criados e gerenciados por todo o seu Ciclo de Vida pelo Geren- ciamento de Problemas. Erros Conhecidos também podem ser IDENTIFICADOS PELO Desenvolvimento ou por Fornecedores.

Resolução: Ação tomada para reparar a Causa Raiz de um Incidente ou Problema, ou para implementar uma Solução de Contorno (FREITAS, 2010).

O principal objetivo da Operação de Serviço é manter, conduzir, operar, controlar e gerenciar as operações no dia a dia, sendo responsável pela tecnolo- gia utilizada para entregar os serviços, entregando a estabilidade na estrutura de TI, a um custo justificável.

Os processos do ciclo de Operações de Serviço são: • Gerenciamento de Eventos. • Gerenciamento de Incidentes. • Gerenciamento de Problemas. • Cumprimento de Requisições. • Gerenciamento de Acesso. 4.2.1 Gerenciamento de Eventos

O objetivo do Gerenciamento de Eventos é monitorar e gerar alertas ou notifi- cações de um Serviço de TI ou Item de Configuração

capítulo 4

• 93

Evento: um evento pode indicar que algo não está de acordo com a operação normal do serviço ou descumprindo um nível de serviço acordado. Eventos também podem indicar uma determinada informação vital para a operação de um serviço, como uma confirmação de que um job rodou com êxito, ou podem indicar uma necessidade de intervenção, como a troca da mídia de backup ou atualização de patch, por exemplo (FREITAS, 2010 p. 261).

Segundo Freitas (2010) há uma grande diferença entre Gerenciamento de Eventos e monitoramento. Muitas empresas investem em soluções de monito- ramento e montam estruturas com televisores de plasma, LCD ou telões com a imagem da ferramenta de monitoramento projetada. Porém, quando uma falha é identificada pelo monitoramento, não há um processo definido sobre o que fazer a seguir. O Gerenciamento de Eventos necessita do monitoramento e com- plementa essas soluções ao indicar os passos seguintes. O monitoramento pode acontecer de forma ativa, quando identificamos o status e tendências dos Servi- ços de TI ou ICs e podemos configurar alertas para identificar possíveis inciden- tes, antes mesmo que eles impactem os serviços. Exemplo: podemos configurar um alerta para quando a utilização de disco, CPU ou memória de um servidor crítico alcance um limite máximo de 80% de uso, para que seja tomada alguma ação antes da parada do servidor por falta de recursos. Um alerta é reativo quando ele detecta uma falha que já ocorreu, por exemplo, alerta de queda de link de co- municação, ou seja, o alerta “reagiu” a um problema que já aconteceu.

Podemos citar como exemplos de eventos a serem monitorados: • Detecção de intrusão na rede.

• Alertas de vírus.

• Controle de uso de licença de software.

• Performance de sistemas, aplicações, banco de dados e rede. • Alertas de falhas em ICs.

• Condições predeterminadas como identificação de erros em log ou Jobs que não rodaram em determinado momento.

As atividades do Gerenciamento de Eventos são:

• Ocorrência do Evento: muitos Eventos acontecem no ambiente de TI o

tempo todo. É de vital importância que no Desenho dos Serviços sejam definidos os eventos que precisam ser detectados.

• Notificação do Evento: as notificações podem ser coletadas através de in-

terrogações de status ou respostas como, por exemplo: “up” ou “down”, “running” ou “stoped” e “completed” ou “idle”. Também podem gerar no- tificações através de programas de monitoramento (agentes) instalados nos ICs para coletar determinadas informações e gerar alertas especí- ficos. Existem agentes de monitoramento proprietários dos fabrican- tes dos ICs ou agentes baseados em software livre. Após a definição dos Eventos a serem monitorados no Desenho de Serviço, as ferramentas de monitoramento e notificação devem ser escolhidas e testadas em pro- cessos como Ciclo de Transição do Serviço.

• Detecção do Evento: após uma notificação de Evento ser gerada, ela deve ser

detectada por um sistema de gerenciamento de Eventos com capacidade para concentrar os Eventos coletados e interpretar o significado do Evento.

• Filtro do Evento: decide se o Evento deve ser comunicado à Operação de

TI ou deve ser ignorado. Se for ignorado, será registrado em uma base de informações sobre os Eventos, mas nenhuma ação será tomada. O moti- vo da filtragem é porque muitas ferramentas de monitoramento geram alertas desnecessários que não podem ser facilmente desabilitados. Por exemplo, se monitorarmos os processos de um sistema operacional para sabermos quando uma operação crítica estiver consumindo muita CPU ou quando estiver parada, podermos também receber notificações de processos que não são críticos. Também podemos filtrar que somente o primeiro Evento de uma série de Eventos repetitivos serão considerados. Outro exemplo: se um IC está desligado e o monitoramento gera alertas a cada 5 minutos, receberemos alertas enquanto o IC não for ligado no- vamente. Porém, esta análise depende de IC para IC e de serviço para ser- viço. Pode ser necessário que, em determinadas situações todos os Even- tos repetidos sejam analisados, como por exemplo um alerta do firewall.

Significância do Evento: categorização dos Eventos com base em três cate-

capítulo 4

• 95

• Informativos: eventos que não requerem ações. São armazenados e man-

tidos por um período determinado. São normalmente utilizados para verificar o status de um IC ou confirmar se uma situação foi atendida ou executada. Também podem ser utilizados como insumos para monito- rar a performance de ICs ou serviços como quantidade de transações em um período ou para identificar desvios nos níveis de serviços acordados.

• Aviso: evento gerado quando um serviço ou um IC está se aproximando

de uma situação limite. Podemos citar como exemplos de aviso: taxa alta de colisões na rede, Time to Live acima do limite ou uso de swap em disco do servidor, etc.

• Exceção: identifica que uma determinada situação predefinida não está

funcionando conforme previsto. Pode estar associada a metas de níveis de serviços, perdas de funcionalidades ou baixa performance que impac- tem os serviços e possam vir a causar um Incidente eminente.

Correlação do Evento: a correlação do evento geralmente está ligada aos ní-

veis de serviços e às categorias de risco do impacto para o negócio definidas no Desenho do Serviço. De acordo com as categorias do Evento, são atribuí- das informações de impacto e priorização do Evento para os serviços.

Direcionar: de acordo com a correlação dos Eventos, determinadas ações

devem ser tomadas. O direcionamento deve indicar exatamente para quem ou para onde os Eventos devem ser informados. Os Eventos podem gerar Registros de Incidentes, gerar Requisições de Mudança ou, em situações específicas predeterminadas, podem ser iniciados programas específicos como, por exemplo, scripts que reiniciem processos ou executar jobs.

Selecionar Reação; selecionar entre as opções disponíveis de reação como:

• Simplesmente arquivar as informações do Evento em um arquivo de log para análise.

• Responder automaticamente ao Evento com ações automatizadas como reiniciar um sistema ou processo, iniciar um job, alterar um parâmetro de configuração de um IC ou bloqueio temporário de acesso.

• Intervenção humana para tratar o Evento.

• Abrir um Registro de Incidente quando foi identificada uma Exceção ou quando uma quantidade considerável de Avisos indica uma falha emi-

nente ou a perda de qualidade significativa de um serviço ou IC.

• Abrir uma Requisição de Mudança quando uma Exceção indica que é ne- cessário uma mudança imediata. Via de regra, uma Exceção sempre deve ser encaminhada via Registro de Incidente para a Central de Serviços para análise e decisão se é necessário abrir uma RDM, porém, para Eventos bem conhecidos em que a solução já é bem conhecida e sabe-se com cer- teza que haverá a necessidade de abertura de RDM com as devidas infor- mações de significância e correlação para agilizar a solução da Exceção. • Abrir um Registro de Problema ou relacionar o Incidente com um Re-

gistro de Problema já criado. Utilizado quando a Operação de TI já está madura o suficiente para automatizar as análises de falha e análise de causa raiz do Incidente.

Revisar Ações: verificar se os Eventos significantes e Exceções estão sendo

direcionados corretamente. Pode ser analisada a rastreabilidade de um de- terminado Evento como informações do Registro de Incidente gerado ou RDM e seus resultados, ou então podem ser feitos testes esporádicos de si- mulação de Eventos para acompanhar a notificação, a detecção, o filtro, a significância, a correlação e o direcionamento. A revisão de Eventos tam- bém é uma atividade do ciclo de Melhoria Continuada de Serviço para ga- rantir a execução do processo de Gerenciamento de Eventos.

• Fechar Evento: muitas vezes é difícil associar o fechamento da reação de

um Evento com o fechamento do Evento propriamente dito. Um Evento pode ser simplesmente um log que não possui status de “aberto” ou “fe- chado”. No entanto, é importante que haja alguma identificação do Even- to com associação do direcionamento dado a ele. Podem ser gerados regis- tros do Evento, se possível na própria informação do Evento ou em outra forma de acompanhamento adequada, para identificar a rastreabilidade do Evento, por exemplo, Evento A foi tratado pelo Incidente 123.

A figura a seguir, mostra o fluxograma das atividades do gerenciamento de eventos:

capítulo 4

• 97

Evento Notificação_{do Evento do Evento}Detecção Filtro do_Evento

Significância Correlação do Evento Aviso Direcionar Evento Selecionar Reação Arquivar em log Resposta Automática Alerta Intervenção Humana Registro de Mudanças Registro de Problemas Registro de Incidente Revisar Ações Fechar Eventos

Figura 4 – Fluxograma do gerenciamento de eventos

Disponível em: <http://estaciodocente.webaula.com.br/salaframe.asp?curso=1002&A- cessoSomenteLeitura=S&origem=lista>.

O gerenciamento de eventos se relaciona com os demais processos da ges- tão de serviços de TI por meio de entradas, processamento e saídas para outros processos, conforme esquema a seguir:

Entradas • Informações sobre Níveis de Serviços (Gerenciamento de níveis de serviço). • Informações sobre Serviços de Negócio (Gerenciamento de Catálogo de Serviços). • Informações de Monitoramento de Disponibilidade

(Gerenciamento de Disponibilidade). • Informações de Monitoramento de Capacidade

(Gerenciamento de Capacidade). • Informações de Segurança da Informação (Gerenciamento da Segurança da Informação). • Informação dos Serviços de TI e ICs (Gerenciamento

de Configuração).

Saídas • Abertura de Registros de Incidentes

(Gerenciamento de Incidentes). • Abertura de Registros de Problemas

(Gerenciamento de Problemas). • Informações sobre Eventos para: • Analise de Riscos, Analise de Tendências ou • Atualização de Status de um Serviço de TI. • Informações sobre Eventos (Gerenciamento de

Conhecimento) Gerenciamento

4.2.2 Gerenciamento de Incidentes

Incidentes ocorrem a todo momento, em qualquer setor, em qualquer proces- so e em qualquer empresa.

É impossível uma área de TI não passar por incidentes. O objetivo do Geren- ciamento de Serviços de TI é estar pronto para atender os Incidentes no menor prazo possível e minimizar o seu impacto. Para tentar reduzir a quantidade de incidentes, necessitamos planejar proativamente ações que busquem a causa raiz dos Incidentes (Gerenciamento de Problemas) e implemente melhorias nos Serviços de TI (Transição de Serviço). Um Incidente é um evento indesejá- vel que não faz parte do comportamento padrão esperado pelos Serviços de TI e que pode ocasionar uma interrupção ou redução significativa na qualidade dos mesmos nas operações diárias dos usuários.

O Gerenciamento de Incidentes é o processo mais visível entre os usuários dos Servi- ços de TI, por ser responsável diretamente pelo primeiro atendimento de falhas na ope- ração normal dos Serviços de TI. O objetivo do Gerenciamento de Incidentes é restaurar a “operação normal” dos serviços o mais rápido possível, para minimizar o impacto no negócio. Tem-se como “operação normal” do serviço, os níveis de serviço acordados nos Acordos e Contratos de Nível de Serviço. O Gerenciamento de Incidentes é responsável por tratar as Exceções que causam falhas na operação normal dos serviços ou qualquer interrupção não planejada que seja identificada pelas equipes de TI ou reportada pelos usuários dos Serviços de TI.

Estabelecidas as prioridades de atendimento de Incidentes e as metas acordadas dos níveis de serviços, as equipes de atendimento de Incidentes devem planejar seus horá- rios de atendimento e prazos de resolução para atender às demandas acordadas.

No entanto, Incidentes não são novidade para TI, e muitas vezes um Inci- dente se repete ou é parecido. Muitas equipes de suporte não documentam os procedimentos nem trocam informações e o resultado são horas e horas gas- tas inutilmente tentando achar soluções que já foram aplicadas anteriormen- te. Para resolver essa questão, é sugerida a criação de modelos predefinidos de padrões de atendimento para Incidentes que já são conhecidos. Os modelos auxiliam na rápida identificação de ações a serem tomadas ou orientam no di- recionamento de determinado Incidente a equipe competente. A análise da Ár- vore de Falhas, do Gerenciamento da Disponibilidade, pode ser um indicador

capítulo 4

• 99

para ações ou encaminhamentos dos Incidentes. Geralmente encontramos os Modelos de Incidentes no formato de scripts de atendimento. Exemplo: usuário relata que não consegue cadastrar pedidos no sistema de vendas. Uma área de TI pode ter o seguinte Modelo de Incidentes para o sistema de vendas:

Verificar Acesso ao sistema Acesso OK?

SimSim Não

SimSim Não

O sistema está

disponível? Acessar remotamente desktopdo usuário e simular o erro.

Encaminhar para equipe especializada do sistema Encaminhar para equipe de suporte local do desktop

Erro por falta de perfil?

SimSim Não

Procedimentos e políticas operacionais estão

sendo seguidas?

Orientar usuário

SimSim Não

Simular falha Orientar usuário Coletar evidências (debug)

Figura 5 – Modelo de Incidentes para falha no sistema de vendas.

Fonte: Freitas (2010).

O esquema acima nos mostra um script de atendimento de Incidentes no sistema de vendas. O tipo de Incidente é rapidamente identificado e pode ser tratado através de orientações ao usuário, encaminhamento para a equipe de infraestrutura de rede e desktop, ou através de intervenção da equipe especiali- zada do sistema de vendas. Sem Modelos de Incidentes definidos, geralmente temos as seguintes situações:

• Incidentes órfãos sem atendimento largados na fila de atendimento. • Conflitos de responsabilidade: o famoso “deixa que eu chuto!”.

• Incidentes parados na fila de atendimento porque estão esperando al- gum sinal do céu para solucioná-los.

• Equipes realizando as mesmas atividades repetidamente, por exemplo: entrando em contato com o usuário pela terceira vez e perguntando o que está ocorrendo.

Um Modelo de Incidentes, portanto deve possuir claramente, os passos pre- definidos para o atendimento dos tipos de Incidentes que o processo opera- cional possa ter em seu desenho de processo; definição da ordem cronológica dos passos; responsabilidades definidas e desenhadas; prazos de atendimento pré-estabelecidos; definidos os processos de escalonamento entre as equipes responsáveis; levantamento de todas as evidências necessárias sobre o Inciden- te. Os Sistemas de Registro de Incidentes devem possuir capacidade de auto- mação dos Modelos de Incidentes.

CONCEITO

Incidentes Graves!

Dentro do universo de possibilidades de Incidentes, existem os Incidentes graves. Estes ne- cessitam ser planejados para serem atendidos com a máxima urgência por causarem im- pactos significativos no negócio. Nesses casos, devem ser criados procedimentos de aten- dimento diferenciados para os Incidentes considerados graves. A definição de gravidade e urgência dos Incidentes não é definida pelo usuário, mas sim por acordos predefinidos no Desenho e Serviços onde são identificados os cenários de riscos para os Serviços de TI (FREITAS, 2010).

Atividades do Gerenciamento de Incidentes

As atividades do Gerenciamento de Incidentes são:

2. Identificação do Incidente: os incidentes podem ser identificados atra- vés do Gerenciamento de Eventos, da identificação da própria equipe de TI ou pela solicitação de atendimento de Incidentes feita pelo usuá- rio através de ligação, abertura de Registro de Incidentes pelo sistema disponível na Intranet ou Internet ou qualquer outro canal de solicita- ção disponibilizado pela Função Central de Serviços.

capítulo 4

• 101

3. Registro do Incidente: todos os Incidentes devem ser registrados em um sistema de Registro e Acompanhamento de Incidentes. Todas as informações relevantes para o atendimento do Incidente devem ser registradas e devem ser mantidos os históricos dos Incidentes para posterior análise, se necessário. Essas informações podem incluir, por exemplo: número de identificação único para o Incidente; categoria do Incidente; urgência do Incidente; Impacto do Incidente; Priorização do Incidente; datas de abertura e de cada atualização; identificação do técnico e grupo de suporte que está atendendo o Incidente; fonte de ori- gem do Registro (e-mail, por exemplo); dados do solicitante com infor- mações para contato; descrição do evento; status do Incidente (aberto, aguardando, atendido); item de configuração relacionado; atividades realizadas para resolver o Incidente; resolução aplicada; metas de aten- dimento do Acordo de Nível de Serviço.

4. Categorização do Incidente: os incidentes devem ser categorizados de acordo com critérios predefinidos de cada organização, podendo se ba- sear no Catálogo de Serviços de Negócio, Catálogo de Serviços de TI, Pacotes de Serviços, Linhas Base de Serviços, Sistema de Gerenciamen- to da Configuração, etc., estipulando níveis de categorização do Inci- dente. Não é recomendada a criação de mais de 3 ou 4 níveis de cate-

No documento Gestao de Serviço Em Ti (páginas 91-102)