A06GerenciamentoIncidentes - Copia

Prévia do material em texto

Atividades do Gerenciamento de Incidentes: 
 
• (1) Identificação do Incidente: os incidentes podem ser identificados 
atravé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 telefônica, 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. 
 
• (2) 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: 
 
o Número de identificação único para o Incidente. 
o Categoria do Incidente. 
o Urgência do Incidente. 
o Impacto do Incidente. 
o Priorização do Incidente. 
o Datas de abertura e de cada atualização. 
o Identificação do técnico e grupo de suporte que está atendendo o 
Incidente. 
o Fonte de origem do Registro (e-mail, telefone, Intranet, etc.). 
o Dados do solicitante com informações para contato. 
o Descrição dos sintomas. 
o Status do Incidente (aberto, aguardando em fila, sendo atendido, 
fechado, cancelado, etc.). 
o Item de Configuração relacionado. 
o Atividades realizadas para resolver o Incidente. 
o Resolução aplicada. 
o Metas de atendimento do Acordo de Nível de Serviço. 
 
• (3) Categorização do Incidente: os incide'ntes devem ser categorizados 
de acordo com critérios predefinidos de cada organização, podendo se 
basear 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 Gerenciamento 
da Configuração, etc. Por exemplo, tomando corno base o exemplo do 
sistema de vendas relatado anteriormente, uma possível categorização do 
incidente poderia ser: 
 
o Nível 1: Serviço de TI (Sistema de Vendas). 
o Nível 2: Tipos de Solicitações para esse Serviço de TI: (Acesso ao 
Sistema, Dúvidas Operacionais, Falhas do Sistema). 
o Nível 3: Tipos de atividades requeridas para cada tipo de 
solicitação: (Em caso de Falhas do Sistema, podem ser: erros da 
aplicação ou falhas de banco de dados). Para cada uma das 
classificações descritas, o Incidente deverá ser encaminhado para a 
 
 
equipe relacionada (equipe da aplicação ou equipe do banco de 
dados). 
 
Fique Ligado: Não é recomendada a criação de mais de 3 ou 4 níveis de categorização, 
sob o risco de muitas possibilidades induzirem ao erro nas categorizações. A 
categorização deve deixar claro o tipo de atendimento requerido e para que equipe o 
Incidente deve ser encaminhado. A categorização também é um elemento importante 
para a geração de relatórios de acompanhamento do ciclo de vida dos Incidentes e para 
análise de causa raiz do Gerenciamento de Problemas. 
 
 
 
• (4) Priorização do Incidente: a priorização é definida baseada em uma 
matriz de risco entre a urgência do tratamento do Incidente e o impacto 
que o Incidente causa na operação da empresa. O impacto pode ser 
definido de acordo com alguns dos critérios a seguir: 
 
o Quantidade de áreas afetadas na empresa. 
o Quantidade de serviços impactados. 
o Nível de exposição da imagem da empresa. 
o Risco de perdas financeiras. 
o Conformidade com leis e regulamentações. 
 
A urgência é a determinação do tempo máximo que uma empresa pode suportar esses 
impactos sem solução. Pode ser determinada pela taxa de Sustentabilidade (Tempo 
Médio para Restauração de Serviço) definida pelo Gerenciamento de Disponibilidade no 
ciclo de Desenho de Serviço e acordada no Acordo ou Contrato de Nível de Serviço. 
Como exemplo de matriz de definição de prioridade podemos utilizar a Matriz GUT 
(Gravidade, Urgência e Tendência): 
 
 
 
 
 
 
 
 
 
 
Como resultado da escala de priorização, um Acordo de Nível de Serviço pode definir, 
por exemplo, que os serviços devem ser atendidos de acordo com a seguinte escala de 
metas de atendimento de prioridade: 
 
• Prioridade 1: TMPRS = 1 hora. 
• Prioridade 2: TMPRS = 4 horas. 
• Prioridade 3: TMPRS = 8 horas. 
• Prioridade 4: TMPRS = 24 horas. 
• Prioridade 5: TMPRS = 40 horas. 
 
 
 
Lembrando que os prazos devem estar refletidos nos Prazos de Atendimento. Se por 
exemplo foi definido no Prazo de Atendimento que a Central de Serviços e o 
Gerenciamento de Incidentes somente operam em horário comercial, de segunda a 
sexta-feira, então os prazos são os seguintes: 
 
 
 
 
 
• Prioridade 1: TMPRS = 1 hora. 
• Prioridade 2: TMPRS = 4 horas. 
• Prioridade S: TMPRS = 1 dia útil. 
• Prioridade 4: TMPRS = S dias úteis. 
• Prioridade 5: TMPRS = 5 dias úteis. 
 
Em função de conflitos hierárquicos por "entendimentos" de prioridade por parte dos 
clientes, gerentes e a equipe de TI, é recomendado que sejam identificados os clientes 
VIP (Very Important Person) da organização. Esses usuários podem-ter níveis de 
priorizações diferenciadas em relação aos usuários comuns dos Serviços de TI. Exemplos 
de usuários VIPs: usuários que trabalham com operações críticas de negócio como 
fechamento financeiro, aprovações de grandes pagamentos, gerentes seniores da 
empresa, etc. 
 
• (5) Diagnóstico Inicial do Incidente: consiste na análise do sintoma do 
incidente e identificação do Modelo de Incidente, se houver. Podem ser 
consultadas bases de informações de Incidentes anteriores e Bases de 
Dados de Erros Conhecidos para auxílio no diagnóstico do Incidente. 
 
• (6) Escalação do Incidente: após o diagnóstico, se o técnico não 
conseguir aplicar a Solução de Contorno ou Resolução, o Incidente deve 
ser encaminhado para uma equipe capaz de resolver o Incidente. Existem 
dois tipos de Escalações previstos: 
 
o Escalação Funcional: escalação para equipe com capacidade para 
resolver o Incidente. Geralmente são equipes especializadas com 
mais experiência e perfis de acesso dos serviços diferenciados das 
equipes de níveis inferiores. Requer Acordos de Nível Operacional 
entre as equipes para garantir o atendimento do Acordo de Nível de 
Serviço. Exemplo: equipe nível 1 de suporte a desktop, equipe nível 
2 de suporte à rede, equipe nível S de suporte a servidores 
(Hardware e Sistema Operacional), equipe nível 4 de suporte 
especializado de sistemas e aplicações. 
 
o Escalação Hierárquica: Incidentes que requerem ações de resolução 
mais complicadas como aquisição de recursos adicionais, 
acionamento de Fornecedores ou Incidentes de prioridade 1. Devem 
ser notificados para o Gerente de TI e outros Gerentes, se 
previamente definido no Acordo de Nível de Serviço, para a devida 
tomada de decisão sobre os melhores procedimentos de resolução do 
Incidente. Outro tipo muito comum de Escalação Hierárquica é a 
 
 
resolução de conflitos no atendimento de Incidentes sobre 
prioridades de atendimento de Incidentes com a mesma 
classificação. Supondo que há três Incidentes na fila de atendimento 
com classificação de prioridade 2, o Gerente do processo de 
Incidentes poderá ser acionado para definir a ordem de atendimento 
dos Incidentes com mesma classificação de prioridade. 
 
• (7) Investigação e Diagnóstico do Incidente consiste nas atividades de: 
 
o Identificar o que está fora da operação padrão de um serviço. 
o Entender a cronologia dos eventos que levaram ao Incidente. 
o Confirmar as informações que levem à classificação de priorização. 
o Identificar os eventos que podem ter iniciado o Incidente. 
o Analisar informações do Sistema de Gerenciamento de 
Conhecimento de Serviço para identificar Incidentes anteriores, 
registros de Problemas, Base de Erros Conhecidos, informações de 
Fornecedores, informações de Eventos ou Requisições de Mudanças. 
 
• (8) Resolução e Recuperação do Incidente: se for identificada uma 
Solução de Contorno ou Resolução para o Incidente, deve ser avaliado se 
essa soluçãoaltera os atributos do IC no BDGC. Se esse tipo de alteração 
for escopo do Gerenciamento de Mudanças, deverá ser aberta uma RDM 
para resolução da falha. Se essa solução pode ser aplicada sem a 
necessidade de abertura de RDM, a solução é aplicada, o Registro de 
Incidente atualizado e o Incidente é encaminhado para a Central de 
Serviços para fechamento do Incidente. 
 
• (9) Fechamento do Incidente: após a resolução do Incidente pelo 
Gerenciamento de Incidentes ou através de uma RDM, a Função Central 
de Serviços verifica se o Incidente foi realmente resolvido e se o usuário 
está satisfeito com a solução aplicada. A Central de Serviços também 
verifica se todas as informações relevantes do Incidente estão 
preenchidas e se os níveis de detalhamento do histórico do Incidente 
estão de acordo com as políticas de registro de Incidentes. Caso o 
Incidente não esteja de acordo com a política de registro de Incidentes ou 
o usuário informe que o Incidente não foi resolvido, a Central de Serviços 
escala o Incidente de volta para a equipe que estava tratando o 
Incidente. 
 
	Atividades do Gerenciamento de Incidentes: