AGÊNCIA NACIONAL DE TELECOMUNICAÇÕES

Portaria Anatel nº 2789, de 08 de março de 2024

O GERENTE DE PLANEJAMENTO, OPERAÇÃO E MANUTENÇÃO DE REDES DA AGÊNCIA NACIONAL DE TELECOMUNICAÇÕES, no uso das atribuições que lhe confere o art. 227, do Regimento Interno da Agência, aprovado pela resolução nº 612, de 29 de abril de 2013;

CONSIDERANDO a necessidade de implantar o Procedimento de Gerenciamento de Incidentes de TI;

CONSIDERANDO o constante da Portaria 2722, de 01 de novembro de 2023;

CONSIDERANDO o constante dos autos do processo nº 53500.087447/2023-13,

RESOLVE:

Art. 1º Aprovar o Procedimento de Gerenciamento de Incidentes de Tecnologia da Informação da Agência Nacional de Telecomunicações, na forma do Anexo a esta Portaria.

Art. 2º Esta portaria entra em vigor na data de sua publicação no Boletim de Serviço.

---

Documento assinado eletronicamente por Adriano Cesar Dias, Gerente de Planejamento, Operação e Manutenção de Redes, Substituto(a), em 08/03/2024, às 15:02, conforme horário oficial de Brasília, com fundamento no art. 23, inciso II, da Portaria nº 912/2017 da Anatel.

---

A autenticidade deste documento pode ser conferida em https://www.anatel.gov.br/autenticidade, informando o código verificador 11629423 e o código CRC 68A3EB90.

---

ANEXO

Procedimento de Gerenciamento de Incidentes de TI da Agência Nacional de Telecomunicações (ANATEL)

1. OBJETIVO

1.1. O Procedimento de Gerenciamento de Incidentes de TI objetiva controlar o ciclo de vida dos incidentes de TI, para garantir que sejam registrados, analisados, priorizados, testados, documentados, revisados e que as atividades do negócio se mantenham estáveis, estabelecendo os procedimentos a serem seguidos na execução do Processo de Gerenciamento de Incidentes de TI.

1.2. O Gerenciamento de Incidentes de TI será realizado por meio de solução de gerenciamento de serviços de TI.

2. APLICAÇÃO

2.1. Este Procedimento se destina aos servidores e empregados públicos, estagiários, terceirizados e demais colaboradores da Agência Nacional de Telecomunicações que participam do processo de Gerenciamento de Incidentes de TI.

3. DEFINIÇÕES GERAIS

3.1. Para fins deste Procedimento, entende-se por:

I. Acionamento – ação de iniciar o processo de Gerenciamento de Incidentes de TI, seja por meio de chamada telefônica, e-mail, chatbot, autoatendimento, alerta (monitoramento) ou outro meio de comunicação. O acionamento pode ser feito pelo usuário afetado pelo incidente ou por outra pessoa que detecte o incidente;

II. Acordo de Nível Operacional – ANO: acordo estabelecido entre as equipes internas de TI ou entre as equipes de TI e outras áreas provedoras de serviço, sejam fornecedores ou qualquer área interna da TI que dá suporte a algum SLA, para execução de atividades de suporte. Não se trata de acordo entre a área de TI e usuários finais da organização;

III. Alerta – notificação gerada por um evento, que indica que algo não está funcionando conforme o esperado ou que pode causar uma interrupção ou degradação do serviço de TI. Um alerta pode se tornar um incidente se não for tratado adequadamente e geralmente são gerados através de ferramentas de monitoramento;

IV. Banco de Dados de Erros Conhecidos – BDEC: base de conhecimento usada como referência de conhecimento na busca de soluções de contorno ou definitivas, nos primeiros níveis de atendimento, garantindo os NMSEs dos serviços de TI afetados;

V. Catálogo de Serviço de TI – CSTI: documento/ferramenta que reúne todos os serviços que a área de tecnologia da informação oferece e as principais informações sobre eles;

VI. Chatbot - programa de computador projetado para simular conversas humanas por meio de mensagens ou voz, visando apoiar os usuários na resolução de seus problemas;

VII. Escalação – ação de transferir o incidente para um nível de suporte superior, quando o nível atual não tem capacidade ou competência para resolvê-lo. A escalação pode ser funcional (quando o incidente é encaminhado para outra equipe ou especialista) ou hierárquica (quando o incidente é encaminhado para um gerente ou supervisor);

VIII. Gerenciamento de Serviços de TI – GSTI: conjunto de processos que envolve planejamento, execução e monitoramento dos serviços de TI;

IX. Incidente de TI – todo evento que causa indisponibilidade ou grave perda de qualidade de um ou mais serviços de TI;

X. Incidente grave de TI– incidentes que causam grande impacto e exigem máxima urgência no atendimento;

XI. Indicadores de desempenho de processo: métricas adotadas para medir a eficiência de um processo ao longo do tempo de sua aplicação;

XII. Item de Configuração – IC: qualquer componente necessário para a entrega de um serviço que precisa ser gerido, com a finalidade de entregar um serviço de TI. Exemplo: redes, servidores virtuais, armazenamento virtual, contratos, ferramentas e documentação;

XIII. Matriz RACI: ferramenta de gestão para definição de responsabilidades para os participantes do processo;

XIV. Mudança de TI: qualquer adição, alteração ou remoção de componentes dos serviços de TI, bem como intervenções em ambiente operacional de TI que precisam ser gerenciadas;

XV. Nível Mínimo de Serviço Exigido – NMSE: exigência da CONTRATANTE que determina o tempo para atendimento, pela CONTRATADA, de solicitações relacionadas a serviços de TI;

XVI. Processo de Cumprimento de Requisição de Serviço de TI - processo responsável por gerenciar o ciclo de vida das solicitações de serviços de TI pelos usuários;

XVII. Processo de Gerenciamento de mudanças de TI: conjunto de medidas responsável pelo controle do ciclo de vida das mudanças de TI, com o objetivo de gerar o mínimo de interrupção nos serviços de TI e manter a operação de TI estável;

XVIII. Requisição de Mudança – RDM: registro das informações de uma mudança de TI durante todo seu ciclo de vida, desde a apresentação da necessidade até as ocorrências durante o processo de execução; e,

XIX. Requisição de Mudança Emergencial – RDME: registro das informações de uma mudança emergencial de TI durante todo seu ciclo de vida, desde a apresentação da necessidade até as ocorrências durante o processo de execução;

XX. Solução de Information Technology Service Management – ITSM: solução utilizada para Gerenciamento de Serviços de TI; e,

XXI. Stakeholders – todos os grupos de pessoas ou organizações que podem ter algum tipo de interesse pelas ações do processo.

4. DIRETRIZES DO PROCESSO DE GERENCIAMENTO DE INCIDENTE DE TI

4.1. Estabelecimento de equipe Especializada de TI

4.1.1. Formação de equipe de especialistas nas tecnologias utilizadas para suportar os serviços de TI, para, mediante o uso de Solução de Gerenciamento de Serviços de TI – GSTI, garantir o atendimento correto e a execução efetiva do Processo de Gerenciamento de Incidentes de TI com o mínimo de risco e impacto para o negócio. Esta atividade pode ser delegada a colaboradores terceirizados, conforme o interesse da Administração Pública e possui os seguintes benefícios:

I. Garantir que as necessidades técnicas e de negócio sejam levadas em conta, para o atendimento de um incidente nos serviços de TI;

II. Garantir o envolvimento de todas as partes interessadas no atendimento, execução e revisão dos incidentes de TI; e,

III. Garantir a eficiência e efetividade deste processo.

4.2. Detecção de incidentes de TI

4.2.1. Detecção do incidente é caracterizada pela interrupção não planejada de um serviço de TI ou uma redução na qualidade desse serviço.

4.2.2. A identificação de incidentes de TI tem caráter reativo e deve fazer parte do dia a dia de toda a Anatel. É obrigatório a TODOS, o reporte dos incidentes de TI identificados, de forma imediata por meio dos seguintes canais:

I. Central de Serviços;

II. Solução de ITSM;

III. Ferramentas de mensageria; e,

IV. Ferramentas de monitoramento.

4.2.3. Esta atividade possui os seguintes benefícios:

I. Garantir o maior tempo de operação de um serviço de TI; e,

II. Formalizar e dar início ao trâmite de identificação de incidentes de TI.

4.3. Registro de Incidentes de TI

4.3.1. Registro de incidentes nos serviços de TI, contendo informações precisas e detalhadas em relação ao incidente de TI ocorrido.

4.3.2. As informações mínimas para o registro de incidentes de TI são:

I. “ID do incidente”, campo preenchido automaticamente pela solução de ITSM;

II. “Criado por”, usuário que registrou o incidente de TI. Quando o registro é realizado pela solução de ITSM, a identificação do usuário é proveniente do login. Não é permitido alterar;

III. “Cliente”, a solução de ITSM deve trazer o usuário proveniente do login na solução, quando possível. Entretanto, é permitido que o usuário solicitante seja alterado, simulando o caso em que um usuário abre o chamado por outro. O campo usuário é de texto livre, mas é permitido buscar na lista de usuários;

IV. “Sumário”, cabeçalho do incidente;

V. “Setor”, área em que o solicitante se encontra lotado;

VI. “Prédio”, nome do prédio em que o usuário se encontra;

VII. “Sala”, sala em que em o usuário se encontra. Aproveitado das informações da área identificadora;

VIII. “Andar”, andar em que o usuário se encontra. Aproveitado das informações da área identificadora;

IX. “Telefone”, telefone de contato. Aproveitado das informações do usuário solicitante;

X. “E-mail”, e-mail de contato. Aproveitado das informações do usuário solicitante;

XI. “IC”, item de configuração afetado pelo incidente de TI;

XII. “Descrição”, descrição detalhada do incidente de TI;

XIII. “Data Informada”, data e hora do registro do incidente de TI. Salvo automaticamente após o usuário registrar o incidente de TI ou após o registro automático pelas ferramentas de monitoramento do ambiente de TI;

XIV. “Data e hora de Resolução Requerida”, data e hora requerida para início da resolução do incidente de TI, quando em casos de agendamentos futuros;

XV. “Data de Resposta”, data em que o incidente de TI foi resolvido e a restauração da operação normal do serviço de TI ocorreu;

XVI. “Data de Fechamento”, data em que o incidente foi fechado. Nenhuma alteração posterior será possível em seu registro;

XVII. “Serviço”, serviço de TI afetado pelo incidente de TI;

XVIII. “Impacto”, grau em que o incidente de TI afeta os processos, serviços e as operações de negócio. Geralmente pode ser calculado pela criticidade do serviço do negócio afetado, ou número de usuários afetados, ou ainda, pelo grau do dano causado à organização;

XIX. “Urgência”, velocidade em que o negócio necessita que o incidente de TI seja solucionado e a operação normal dos serviços de TI seja reestabelecida;

XX. “Prioridade”, conforme tabela de priorização dos incidentes da ANATEL, apresentada adiante;

XXI. “Grupo solucionador”, grupo solucionador do incidente de TI;

XXII. “Status”, descreve a atual situação de um incidente de TI, registrado e acompanhado por meio da solução de ITSM, ao longo do seu ciclo de vida; e,

XXIII. “Prazo de Resolução”, prazo máximo para resolver o incidente de TI.

4.3.3. Incidentes de TI identificados pelo monitoramento de IC’s terão um registro para cada evento de exceção do monitoramento, formado por eventos de alerta e informações. Estes serão registrados como “registro de eventos”, para possível atuação pelas equipes técnicas de TI, quando entenderem que o registrado é importante para o adequado funcionamento do ambiente de TI.

4.3.4. Esta atividade possui os seguintes benefícios:

I. Formalizar e acompanhar a solução dos incidentes de TI;

II. Permitir a análise das medidas tomadas na solução do incidente de TI;

III. Classificar e priorizar o registro do incidente, permitindo ordenar e escalonar o atendimento de TI; e

IV. Permitir uma previsão de resolução, visando não violar o NMSE do serviço de TI afetado.

4.3.5.O controle e armazenamento das informações relativas ao ciclo de vida do incidente de TI será feito pela solução de ITSM.

4.4. Relacionamento entre incidentes de TI

4.4.1. Relacionamentos entre incidentes de TI devem ser criados para estabelecer a ordem de execução de atendimento ou a dependência entre os registros de incidentes de TI. O relacionamento “Pai e Filho” estabelece uma correlação de dependência que permite rastrear e conhecer amplamente como ocorreu o seu atendimento. A dependência entre os incidentes exige que para o encerramento do chamado pai, os “filhos” já devem estar resolvidos.

I. Para fins de operacionalização na solução de ITSM, a resolução do incidente “pai” aplica-se a todos os “filhos” automaticamente.

4.4.2. Incidentes de TI também podem ser relacionados, quando for o caso, com requisições de mudança de TI e com registros de problemas de TI. Nesses casos, o registro associado não deve ser concluído antes do encerramento do problema ou da mudança.

4.4.3. Todo incidente de TI deve ser associado ao menos a um IC e a um serviço do CSTI da Anatel. A ação é necessária, uma vez que a informação ajudará a identificar, dentre outras coisas, quais componentes e serviços apresentam mais incidentes de TI, permitindo o planejamento de ações para sua redução. Também se faz necessário, quando possível, relacionar os demais itens de configuração afetados pelo incidente de TI, com isso será possível mapear a cadeia de ICs que é afetada por um mesmo incidente de TI.

4.4.4. Esta atividade possui os seguintes benefícios:

I. Aumentar a qualidade e a consistência do atendimento do incidente de TI; e,

II. Agilizar o registro e fechamento dos incidentes.

4.5. Categorização de incidente de TI

4.5.1. A categorização de incidente é uma ação necessária para automatizar uma série de decisões no momento do registro do incidente de TI. A categoria define qual será o analista de TI que realizará o atendimento inicial, quais informações são obrigatórias ou opcionais, o tempo de atendimento, a prioridade, os procedimentos de resolução e demais aspectos do incidente de TI. A correta categorização também permite conhecer quais serviços de TI e seus itens geram mais incidentes de TI. Estas informações são importantes fontes de melhoria nos serviços de TI.

4.5.2. Visando facilitar a categorização de incidentes de TI, fica estabelecida a seguinte estrutura de categorização:

I. Categorização do produto: permite uma visão macro de categorização do incidente de TI com a estrutura do produto afetado. Ficam determinadas as seguintes naturezas:

a. Escopo - abrangência da quantidade dos serviços de TI ou ICs potencialmente afetados;

b. Classe – é a classificação do produto afetado. Exemplo de classe: documentação, hardware, localização, software, etc; e

c. Tipo – é a categorização do serviço ou IC afetado. São os elementos que compõem a classe. Exemplo de tipo: manual, contratos, servidores, sala do presidente, auditório, switches, sistemas e aplicativos.

II. Categorização operacional: Trata-se de uma visão mais técnica da categorização do incidente em relação ao produto afetado. Ficam determinadas as seguintes naturezas:

a. Ação - indicação de qual ação é necessária para o atendimento dos incidentes de TI;

b. Escopo - especificação dos serviços em que a ação será realizada; e,

c. Componente - indica em qual IC será realizada a ação.

4.5.3. Como a categorização é obrigatória, uma categoria genérica existirá para quando um determinado chamado não se encaixar em nenhuma outra opção preexistente.

4.5.4. Demais categorizações do processo de Gerenciamento de Incidentes poderão ser criadas no processo de Gerenciamento de CSTI.

4.5.5. Esta atividade possui os seguintes benefícios:

I. Priorizar e encaminhar automaticamente os incidentes de TI aos respectivos grupos solucionadores;

II. Associar procedimentos e informações essenciais para o atendimento do incidente de TI;

III. Estabelecer uma organização lógica e intuitiva dos incidentes de TI; e,

IV. Fornecer informações sobre as categorias de incidentes de TI mais frequentes.

4.6. Priorização dos Incidentes de TI

4.6.1. Os Incidentes de TI são priorizados, para que sejam atendidos na ordem adequada de importância, sendo baseados nas necessidades e objetivos de negócio.

4.6.2. Todos os incidentes de TI devem receber uma priorização, que pode ocorrer por 3 (três) diferentes meios:

I. Pela categorização definida no NMSE, de acordo com o CSTI;

II. Por intervenção do Gerente de Incidentes; e,

III. Pela matriz de impacto e urgência.

4.6.3. Os incidentes graves de TI demandam a alocação de recursos e procedimentos excepcionais, portanto, a declaração de gravidade de um incidente de TI não deve ser automática, exceto nos casos de monitoramento de serviços de TI classificados como críticos no CSTI e em período de sazonalidade (operação crítica de serviços de TI).

4.6.4. As priorizações decorrem do resultado da relação entre impacto e urgência e são classificadas em: crítica, alta, média e baixa.

4.6.5. O impacto se refere ao efeito do incidente de TI nos processos de negócio. Normalmente baseado em como os serviços serão afetados em sua disponibilidade, continuidade, capacidade ou segurança. Deve-se também levar em conta a quantidade de usuários e clientes envolvidos, importância dos serviços e processos de negócio afetados, imagem e reputação da organização.

4.6.6. Outros fatores que também devem contribuir com os níveis de impacto são:

I. Número de serviços afetados; e

II. Descumprimentos de regulamentos ou de leis.

4.6.7. A escala de impacto possui quatro níveis:

I. Crítico - Qualquer tipo de impacto ou influência nos serviços de alta relevância para o negócio. O problema a ser corrigido pode afetar o suporte ao negócio por período considerado especialmente crítico;

II. Alto - Qualquer tipo de impacto ou influência sobre serviços de alta relevância para o negócio. O incidente afeta um conjunto grande de usuários e de serviços importantes para os processos de negócio;

III. Médio - Impacta serviços que possuem valor significativo ao negócio. Um incidente pode provocar redução na capacidade de operação ou iminentes indisponibilidades; e,

IV. Baixo - Impacta serviços de pequeno valor negocial. O problema a ser corrigido não provoca a indisponibilidade nem falhas na segurança, apenas pequenas violações na capacidade do serviço. O incidente tem baixo efeito na produtividade do órgão.

4.6.8. A urgência indica o tempo em que o incidente deve ser resolvido. Está dividida em quatro níveis:

I. Crítica - Necessita de uma ação imediata. Os incidentes podem gerar grande impacto nos processos de negócio. O usuário ou cliente precisa que o registro de incidente seja atendido imediatamente.

II. Alta - Necessita de uma ação rápida. Os incidentes podem gerar grande impacto nos processos de negócio. O usuário ou cliente precisa que o registro de incidente seja atendido rapidamente.

III. Média - Necessita de uma ação de curto prazo. Os incidentes podem degradar o serviço de forma perceptível, atingindo os processos de negócio. O atendimento do registro do incidente deve ser iniciado assim que possível.

IV. Baixa - Não necessita de ação imediata, trata-se de impacto imperceptível ou pequeno aos processos de negócio. O atendimento do registro de incidentes pode aguardar a conclusão de outros atendimentos para ser iniciado.

4.6.9. A regra de priorização de incidentes de TI está representada na tabela abaixo e deverá ser seguida para todos os incidentes.

4.6.10. Esta atividade possui o benefício de priorizar o atendimento de incidentes de forma adequada.

4.7. Medição do tempo de atendimento de incidentes de TI

4.7.1. Devido à quantidade de equipes realizando o atendimento de um incidente de TI, a medição do tempo total utilizado na sua resolução deve considerar os diferentes NMSEs envolvidos. Desta maneira, devem ser reportados os tempos individuais de cada equipe ou área envolvida. Para isso, deve ser criado um registro de incidente de TI para cada atividade a ser executada.

4.7.2. Portanto, dentro do escopo deste processo, os níveis de serviço contratados ou acordados entre equipes da Anatel serão considerados como ANO, ainda que contratualmente sejam definidos ou descritos como Nível Mínimo de Serviço Exigido.

4.7.3. O tempo de atendimento do incidente de TI não será interrompido em momento algum do seu ciclo de vida. Todo incidente de TI que não cumprir o NMSE deverá ser justificado.

4.7.4. Esta atividade possui os seguintes benefícios:

I. Garantir a correta medição do tempo decorrido no atendimento do incidente de TI;

II. Identificar em qual ponto do atendimento do registro de incidente de TI houve atraso e o que o motivou;

III. Segregar o tempo gasto por cada equipe no atendimento do registro de incidente de TI.

4.8. Diagnóstico Inicial de incidentes de TI

4.8.1. O diagnóstico inicial pode ser feito pela Central de Serviços, por meio de perguntas e um roteiro de atendimento ou pela verificação dos sintomas informados, de forma a identificar o real problema. Caso o diagnóstico identifique a solução para o incidente de TI e exista referência no BDEC, a Central de Serviços deverá iniciar a resolução, alterando o status do incidente para “Em Andamento” e atuar na recuperação do serviço.

4.8.2. Nos casos em que for necessária a escalação funcional do incidente de TI, ele deve ser registrado com o status “Designado” e deve ser transferido para o grupo solucionador adequado.

4.8.3. Para que seja possível o tratamento e resolução do incidente de TI, com o mínimo de impacto para o negócio, todo registro de incidente deve passar por um diagnóstico inicial levantando informações relevantes para que seja distribuído para o grupo solucionador correto.

4.8.4. Esta atividade possui os seguintes benefícios:

I. Resolver os incidentes de TI o mais rapidamente possível, restaurando a operação normal do serviço de TI e minimizando os impactos adversos nos processos de negócio; e,

II. Solucionar o máximo de incidentes de TI, ainda na Central de Serviços.

4.9. Banco de Dados de Erros Conhecidos para atendimento de registro de incidentes de TI

4.9.1. Todos os grupos solucionadores, para atendimento dos incidentes de TI de forma ágil e padronizada, devem utilizar o BDEC. Caso não esteja documentada a solução adotada, deve ser descrita detalhadamente e um registro de problema deverá ser criado.

4.9.2. O BDEC é fundamental e nasce com o processo de Gerenciamento de Problemas de TI. Ele é obrigatório para execução de procedimentos de solução de incidentes de TI.

4.9.3. Este banco de dados deve ser usado como referência de conhecimento na busca de soluções de contorno ou definitivas nos primeiros níveis de atendimento de incidente de TI, garantindo os NMSEs dos serviços de TI afetados.

4.9.4. Este banco de dados contribui para o alcance dos seguintes benefícios:

I. Permitir a operação do serviço de TI com impacto mínimo ou sem impacto direto para o usuário;

II. Promover atuações rápidas do primeiro nível de atendimento no qual há profissionais em desenvolvimento de suas habilidades técnicas;

III. Permitir o reestabelecimento de um serviço de TI de forma rápida e com baixo risco e impacto de insucesso na execução do procedimento de resolução; e,

IV. Registrar soluções de contorno nas quais a solução definitiva está em curso, é inalcançável ou inviável.

4.10. Tratamento de Incidentes Graves de TI

4.10.1 Incidentes graves de TI são aqueles que podem causar grande impacto e exigem máxima urgência no atendimento. Assim, são os incidentes de TI de maior prioridade possível e por este motivo demandam procedimentos excepcionais para atendimento. Para isso, possui um fluxo exclusivo para seu tratamento. Um incidente de TI pode ser considerado grave se:

I. Tiver capacidade de afetar um ou mais serviços críticos de TI para os processos de negócio da Anatel, afetando o NMSE. No CSTI possui a informação de quais serviços são críticos;

II. Puder causar impacto significativo na reputação da Anatel, na conformidade legal ou regulatória, na segurança física ou da informação. Nesses casos, é necessário que o Gerente de Incidentes declare o incidente de TI como grave;

III. Priorizar incidentes em serviços de TI que estão em período de sazonalidade.

4.10.2 De acordo com a priorização dos incidentes de TI, são considerados incidentes graves de TI os que possuem impacto alto combinado com a urgência crítica.

4.10.3 Cabe ao Gerente de Incidentes iniciar os procedimentos de tratamento de incidente grave de TI.

4.10.4 Esta atividade possui os seguintes benefícios:

I. Mobilizar rapidamente o atendimento de incidentes grave de TI;

II. Tratar o incidente de TI de forma abrangente, resolvendo todos os efeitos e causas, de forma organizada; e,

III. Reduzir o impacto do incidente de TI.

4.11 Procedimentos gerais de escalação e alerta de incidentes de TI

4.11.1 Visando garantir que os NMSEs sejam respeitados, é necessário acompanhar ativamente o tratamento dos incidentes de TI. O acionamento e a escalação dos incidentes de TI asseguram que o atendimento seja eficiente.

4.11.2 Estes procedimentos só podem ser interrompidos com autorização do Gerente de Incidentes ou do Dono do Processo.

4.11.3 Esta atividade possui os seguintes benefícios:

I. Reduzir o risco de o atendimento violar os NMSEs;

II. Intervir ativamente no atendimento dos incidentes de TI para garantir a sua celeridade; e,

III. Evitar que os NMSEs fiquem prejudicados em razão de esquecimento ou falha de comunicação.

4.12 Resolução de Incidentes de TI

4.12.1 Fica estabelecido que um incidente de TI será considerado como resolvido quando:

I. O grupo solucionador após seu atendimento bem-sucedido, recuperar a operação normal do serviço de TI; e

II. Por meio de contato telefônico, pela ferramenta de ITSM, chatbot ou contato pessoal, com o solicitante, confirmar a resolução do incidente de TI. Neste caso, caberá a Central de Serviços registrar as evidências para encerrar o incidente de TI, além de identificar o nível de satisfação do solicitante com o atendimento realizado.

4.12.2 O solicitante de um incidente de TI terá prazo de 2 dias para manifestar sua insatisfação com o atendimento prestado. Caso sua solicitação não tenha sido resolvida, o incidente poderá ser reaberto e, neste caso, o tempo de atendimento passa a ser computado novamente, do ponto onde havia sido interrompido. O chamado será transferido para o analista que havia atendido o registro de incidente de TI.

4.12.3 Após esse prazo, não será possível reabrir o incidente de TI, sendo necessário realizar um novo registro de incidente de TI.

4.12.4 Esta atividade possui os seguintes benefícios:

I. Garantir o encerramento do ciclo de vida do incidente; e

II. Garantir que os incidentes de TI não fiquem abertos indefinidamente, evitando assim, enormes filas que acabariam dificultando o seu gerenciamento.

4.13 Reabertura de incidentes de TI

4.13.1 Fica estabelecido que um incidente de TI só pode ser reaberto nos casos em que o usuário apontar falhas no serviço de TI. Porém, se o incidente de TI estiver com o status “Fechado”, não poderá ser reaberto, cabendo o registro de um novo incidente de TI.

4.13.2 Como prerrogativa, o incidente de TI só pode ser reaberto pelo mesmo usuário solicitante ou afetado que apontou a falha inicialmente.

4.13.3. Esta atividade possui os seguintes benefícios:

I. Garantir que incidentes fechados indevidamente sejam auditados e tratados com celeridade no seu atendimento;

II. Evitar o desgaste da imagem do fornecedor de serviços; e,

III. Auditar os procedimentos utilizados para identificação da solução que não causou o efeito desejado.

4.14 Organização dos agentes de solução e validação

4.14.1 A organização dos agentes de solução deve refletir a organização das equipes da TI como, por exemplo:

I. 1° nível - equipe de execução de procedimentos técnicos de baixos risco e impacto, em serviços não críticos, que recebe e/ou registra qualquer contato realizado pelos usuários. Realiza a classificação dos incidentes de acordo com o CSTI, executando a complementação das informações junto ao usuário, sempre que necessário. Realiza o diagnóstico inicial dos incidentes e executa os procedimentos de solução que são pré-aprovados.

II. 2° nível - equipe de execução de procedimentos de baixos e médios risco e impacto, em quaisquer serviços, que dependem de conhecimento técnico médio. Muitas vezes é caracterizada pela equipe que realiza o atendimento presencial para a solução dos incidentes e executa procedimentos de solução que são pré-aprovados.

III. 3° nível - equipe de execução de procedimentos de médio e alto risco e impacto, em quaisquer serviços, que dependem de conhecimento técnico avançado. Elabora procedimentos de solução para incidentes graves, problemas e/ou mudanças.

4.14.2 Agentes de solução externos à Anatel, que serão designados como “Fornecedor”. Quando for necessária a participação de uma empresa ou órgão externo, o incidente deverá ser encaminhado para o agente de solução externo adequado. Caberá aos agentes de solução do 2º e do 3º nível realizar os trâmites para a abertura de chamado com organizações externas, o acompanhamento e as escalações destes chamados.

4.14.3 Esta atividade possui os seguintes benefícios:

I. Organizar a distribuição dos incidentes para os técnicos adequados;

II. Garantir que profissionais com qualificações simples executem atividades de baixo risco, com apoio de scripts de atendimento;

III. Permitir o acionamento dos profissionais especializados somente para incidentes graves;

IV. Simplificar a visão gerencial sobre a distribuição dos incidentes de TI;

V. Identificar rapidamente quais são os grupos de especialistas disponíveis; e,

VI. Permitir a escalação funcional através do encaminhamento dos incidentes de TI, de acordo com a sua dificuldade técnica.

4.15 Validação dos Incidentes de TI

4.15.1 Para garantir que um atendimento correto e de qualidade foi realizado, é preciso validar os registros, tempos e ações relativas aos incidentes de TI. Para isso devem ser verificados os seguintes aspectos:

I. Verificar se os tempos de atendimento aconteceram dentro dos prazos contratados e exigidos;

II. Analisar se a linguagem usada foi adequada;

III. Verificar se a categoria adotada foi corretamente relacionada com o relato do solicitante;

IV. Analisar se todas as informações preenchidas no registro do incidente de TI estão corretas e são relevantes;

V. Verificar se o trâmite do incidente de TI ocorreu sem transferências desnecessárias ou atrasos; e,

VI. Analisar se os acionamentos e escalonamentos obedeceram às regras definidas.

4.15.2 A validação se dá por meio da tramitação do registro de incidente de TI, após sua resolução, para o agente de validação correspondente ao último agente de solução. Quando houver este trânsito, o incidente passará para o status “Fechado” e o motivo do status será “Validado pela Fiscalização”.

4.15.3 Se o validador não ficar satisfeito com a qualidade do atendimento ou dos seus registros, deverá indicar o motivo da insatisfação e devolver o registro do incidente de TI para o último agente de solução. Isto altera o status do incidente para “Em andamento”. O período que o registro do incidente ficar em ajuste, será somado ao tempo de atendimento. Quando o validador estiver satisfeito, ele poderá fechar o incidente. Colocando-o no status “Fechado”.

4.15.4 Esta atividade possui os seguintes benefícios:

I. Elevar a qualidade e a consistência do atendimento;

II. Obter evidências do atendimento e validá-lo; e,

III. Garantir que os procedimentos sejam seguidos, os resultados alcançados e os registros adequados.

5. CICLO DE VIDA DO INCIDENTE DE TI

5.1. Os Incidentes de TI possuem um ciclo de vida, que têm como fases:

I. Incidente registrado – status “Registrado”, indica que o incidente foi classificado e, consequentemente, recebeu a prioridade padrão ou foi priorizado e encaminhado para a fila de atendimento;

II. Incidente em atendimento – status “Em atendimento”, quando o analista inicia o atendimento da requisição do incidente de TI. Esse status é assumido, também, por incidentes que foram reabertos;

III. Incidente aguardando mudança – status “Aguardando mudança” – é utilizado para indicar que um incidente não pode ser resolvido até que uma mudança seja implementada em um serviço de TI;

IV. Incidente aguardando fornecedor – status “Aguardando fornecedor” - é utilizado para indicar que um incidente de TI não pode ser resolvido até que uma ação seja tomada por um fornecedor externo;

V. Incidente cancelado - status “Cancelado”, é utilizado para indicar que o solicitante não deseja mais a requisição ou houve algum engano na comunicação do incidente, podendo ser uma mudança ou uma ordem de serviço;

VI. Incidente resolvido, status “Resolvido”, é utilizado para indicar que o incidente foi resolvido;

VII. Incidente concluído, status “Concluído”, é utilizado para indicar que o incidente foi atendido pela equipe técnica e está aguardando a avaliação/validação do solicitante, para ser posteriormente “fechado” ou “reaberto”; e,

VIII. Incidente fechado, status “Fechado”, é utilizado para indicar que o solicitante do chamado concorda com a solução aplicada para resolução do incidente de TI.

5.2. O tempo de atendimento e a resolução do incidente de TI, para fins de contabilização do Nível Mínimo de Serviço Exigido, devem ser paralisados quando o registro de incidente assumir o status Resolvido. Caso o solicitante não concorde com a resolução do chamado e o registro do incidente de TI seja reaberto, o tempo deve voltar a contar a partir de sua reabertura, dando continuidade à contagem do tempo de atendimento.

5.2.1. O controle do ciclo de vida dos incidentes de TI possui os seguintes benefícios:

I. Permitir conhecimento por parte dos stakeholders a respeito do ponto que está o atendimento do incidente de TI;

II. Fazer uma gestão adequada do incidente de TI;

III. Controlar a evolução do atendimento dos incidentes de TI; e,

IV. Permitir a ação do gerente deste processo para evitar a violação dos indicadores do processo e dos Níveis Mínimos de Serviços Exigidos.

6. PERFIS

6.1. O processo de Gerenciamento de Incidentes conta com os seguintes perfis:

I. Requisitante - qualquer servidor, empregado público, estagiário, terceirizado e demais colaboradores da Agência que necessite que uma demanda seja atendida pelo processo de Gerenciamento da Incidentes de TI;

II. Dono do processo – servidor com perfil de gestão e autoridade funcional instituída para alocar recursos, bem como definir a visão e os objetivos de negócio do processo. Sugere-se que esse papel seja exercido pelo Gerente da GIMR. Este perfil patrocina o Processo de Gerenciamento de Incidentes;

III. Gerente de Incidentes - profissional com experiência em gerenciamento e coordenação de equipes de operações de TI. Sugere-se que este papel seja atribuído a um servidor público, porém, pode ser apoiado por colaboradores terceirizados, tendo em vista a natureza operacional, repetitiva e continuada das atividades. Este perfil acompanha e coordena a execução do processo de Gerenciamento de Incidentes;

IV. Central de Serviços - principal canal de detecção, registro e comunicação dos incidentes de TI com os servidores, terceiros e fornecedores da Anatel. Tem como objetivo, encaminhar e monitorar os acionamentos, bem como executar procedimentos técnicos básicos, de baixos risco e impacto, existentes no BDEC;

V. 2º Nível de Atendimento - atendimento generalista aos usuários dos serviços disponibilizados pela Anatel. O Objetivo neste nível é o atendimento de forma virtual e/ou presencial dos incidentes de TI repassados pela Central de Serviços, buscando, dentre outras coisas, garantir a disponibilidade dos serviços de acordo com os níveis de serviços exigidos. Deve ser prestado preferencialmente por profissional com certificação intermediária ou amplo conhecimento na área de atuação e em fundamentos da ITIL. Destaca-se que o Product Owner está incluído neste nível de atendimento;

VI. 3º Nível de Atendimento – atendimento por profissional com experiência em incidentes de TI e especialista em tecnologias específicas. Deve ser prestado preferencialmente por profissional com certificações na sua área de atuação e em fundamentos da ITIL. Para atendimento dos incidentes de TI de maior complexidade, além da equipe técnica da Anatel, são utilizados pelo 3º nível de atendimento os fornecedores.

VII. Equipe de monitoramento - Equipe que trabalha em regime 24x7 no monitoramento do ambiente e serviços de TI, com conhecimento e experiência em diagnóstico e análise de eventos e operações de infraestrutura e serviços de TI.

VIII. Líder técnico executor - profissional com sólidos conhecimentos em infraestrutura e/ou desenvolvimento de sistemas, com capacidade de coordenar as atividades necessárias para a resolução do incidente de TI. Esse perfil supervisiona as atividades de atendimento dos incidentes no âmbito da GIMR/GIDS/GIIB; e,

IX. Administrador do Chatbot (ferramenta) - profissional especialista em TI, capacitado na gestão e operação da ferramenta e dos mecanismos de Chatbot. O Administrador do Chatbot aplica seu conhecimento técnico na execução das atividades de administração do Chatbot e detém conhecimento do Processo de Gerenciamento de Incidentes de Serviço de TI.

7. RESPONSABILIDADES DOS PERFIS

7.1. Cabe ao Requisitante:

I. Identificar, reportar e/ou registrar os incidentes de TI;

II. Passar as informações, identificadas relacionadas ao incidente, para o atendente durante o registro e diagnóstico do incidente de TI;

III. Cooperar com os atendentes, da central de serviços, durante o registro e diagnóstico do incidente de TI;

IV. Aprovar o encerramento do incidente de TI; e,

V. Apoiar na avaliação dos impactos causados pelos incidentes de TI.

7.2. Cabe ao Dono do Processo:

I. Deliberar sobre a alocação de recursos no processo;

II. Deliberar sobre a visão e os objetivos de negócio do processo;

III. Patrocinar a melhoria contínua do processo e suas métricas; e,

IV. Prover os recursos para o funcionamento do processo.

7.3. Cabe ao Gerente de Incidentes:

I. Acompanhar e coordenar o atendimento de incidentes de TI que saiam do seu fluxo normal;

II. Aferir e publicar os indicadores de desempenho do processo;

III. Alocar recursos para o processo, quando da formação de sala de crise, nos incidentes graves;

IV. Analisar a necessidade de sala de crise;

V. Aumentar a visibilidade e comunicação dos incidentes de TI para o negócio e equipes de TI;

VI. Comunicar o andamento do incidente grave de TI para os stakeholders;

VII. Comunicar a solução de incidente grave de TI para os stakeholders;

VIII. Coordenar a interface entre o Gerenciamento de Incidentes e outros processos de gerenciamento de serviço de TI;

IX. Coordenar a sala de crise de incidentes graves de TI;

X. Desenvolver, apoiar e manter as políticas, os processos e procedimentos do Gerenciamento de Incidentes de TI;

XI. Garantir que o histórico do chat das salas de crise, de tratativa de incidentes graves na solução de ITSM, seja consultado, servindo como ata da reunião;

XII. Garantir que os incidentes de TI sejam registrados;

XIII. Monitorar a execução do processo de incidente de TI, visando dentre outras coisas, identificar atividades ou etapas deste processo que estão interferindo na celeridade exigida pelo negócio, propor e implementar as melhorias;

XIV. Autorizar a priorização dos incidentes de TI;

XV. Promover campanhas de divulgação do processo e capacitação dos envolvidos no processo; e

XVI. Responder pelo resultado do processo.

7.4. Cabe ao Líder técnico executor:

I. Atestar o restabelecimento/normalização do serviço de TI;

II. Auxiliar a Central de Serviços com suporte técnico especializado de TI;

III. Auxiliar e direcionar os técnicos da sua equipe no atendimento dos incidentes de TI;

IV. Definir os procedimentos de resolução de incidentes de TI;

V. Garantir que os atendimentos dos incidentes designados para sua equipe sejam realizados dentro dos padrões de qualidade e eficiência acordados;

VI. Notificar automaticamente ao Gerente de Incidentes, ao Gerente de Problemas e à Central de Serviços sobre as soluções aplicadas;

VII. Responder sobre as metas e métricas de atendimento da sua equipe; e,

VIII. Validar solução de incidente grave de TI.

7.5. Cabe à Central de Serviços:

I. Acionar o Gerenciamento de Catálogo de serviço sempre que for identificado um novo serviço ou um serviço não documentado;

II. Acionar o Gerente de Incidentes de TI todas as vezes que o incidente for categorizado como grave;

III. Acompanhar o atendimento de todos os incidentes de TI;

IV. Complementar, sempre que necessário, os incidentes de TI com informações mínimas para a execução do atendimento;

V. Comunicar, sempre que necessário, aos gestores de TI e aos usuários sobre os incidentes de TI;

VI. Escalonar, sempre que necessário, os incidentes de TI para os demais níveis de atendimento;

VII. Garantir que o acionamento dos incidentes de TI ocorra dentro do NMSE acordado;

VIII. Garantir que os incidentes de TI sejam registrados e classificados corretamente, incluindo Itens de Configuração (IC) e serviços afetados;

IX. Promover ações de melhoria na Central de Serviços;

X. Recepcionar as chamadas entrantes na Central de Serviços;

XI. Reportar ao Gerente de Incidentes a respeito das metas e métricas de atendimento da Central de Serviços;

XII. Resolver os incidentes de TI pertinentes ao 1º nível dentro da Central de Serviços, dentro dos NMSEs, apontando as soluções e contornos utilizados para restaurar o serviço; e,

XIII. Utilizar o BDEC para resolução dos incidentes de TI pertinentes à Central de Serviços.

7.6. Cabe ao 2º Nível de Atendimento:

I. Escalar os incidentes de TI quando não for possível resolvê-los em 2º nível;

II. Acompanhar o atendimento de todos os incidentes de TI em 2º nível;

III. Auxiliar a Central de Serviços com suporte técnico especializado;

IV. Comunicar aos gestores de TI sobre incidentes de TI em 2º nível;

V. Detectar possíveis problemas e encaminhar para a equipe de Gerenciamento de Problemas de TI para que eles façam o registro;

VI. Executar o atendimento dos incidentes em 2° nível, de acordo com os procedimentos existentes no BDEC, apontando a solução ou contorno utilizada para restaurar o serviço;

VII. Fornecer feedback técnico a respeito das atividades, riscos e viabilidade de resolução dos incidentes de TI em 2° nível, sempre que julgar necessário;

VIII. Garantir que todos os incidentes de TI em 2º nível sejam resolvidos de forma correta, contendo informações que o BDEC;

IX. Pesquisar e diagnosticar o incidente de TI, incluindo resolução quando possível; e,

X. Registrar os procedimentos e atividades que foram executadas no atendimento do incidente de TI em 2° nível.

7.7. Cabe ao 3º Nível de Atendimento:

I. Auxiliar a Central de Serviços com suporte técnico especializado;

II. Analisar e tratar incidente grave de TI;

III. Realizar tratativas do incidente grave de TI em Sala de Crise;

IV. Escalonar incidentes para outros especialistas ou acionar o processo de Gerenciamento de Problema de TI sempre que necessário;

V. Comunicar incidente Grave de TI ao Gerente de Incidentes;

VI. Executar o atendimento dos incidentes no 3° nível, de acordo com os procedimentos documentados no BDEC;

VII. Fornecer feedback técnico a respeito das atividades, riscos e viabilidade dos incidentes de TI tratados no 3° nível;

VIII. Garantir que os incidentes de TI sejam resolvidos dentro do NMSE;

IX. Garantir que todos os incidentes de TI do 3° nível sejam resolvidos de forma correta contendo informações que alimentem o BDEC; e,

X. Registrar os procedimentos e atividades que foram executadas no atendimento do incidente de TI em 3° nível.

7.8. Cabe à Equipe de monitoramento:

I. Executar as rotinas de monitoramento do ambiente de TI;

II. Fazer a correta comunicação dos alertas, registrando os incidentes de TI na solução de ITSM, quando não forem realizados automaticamente pela solução;

III. Garantir que os requisitos de NMSE sejam monitorados;

IV. Procurar automatizar ao máximo as atividades de monitoramento;

V. Informar à Central de Serviços eventos de exceção em serviços críticos da Anatel; e,

VI. Sugerir melhorias nas práticas tecnológicas de monitoramento.

7.9. Administrador do Chatbot (Ferramentas):

I. Configurar e manter o chatbot;

II. Treinar o chatbot;

III. Analisar e melhorar continuamente o chatbot;

IV. Gerenciar o conteúdo do chatbot;

V. Integrar o chatbot com outros sistemas e equipes; e,

VI. Suportar tecnicamente os gestores que necessitem de apoio na ferramenta do chatbot.

8. MATRIZ RACI DO PROCESSO DE GERENCIAMENTO DE INCIDENTES DE TI

8.1. A matriz RACI é uma ferramenta de gestão para definição de responsabilidades para os membros de uma equipe. No caso concreto, segrega as responsabilidades entre os papéis que atuam no Processo de Gerenciamento de Incidentes de TI. As responsabilidades do Processo em questão estão distribuídas conforme Anexo I deste documento.

9. LISTA DE ANEXOS

9.1. Segue abaixo a lista de anexos ao presente procedimento:

Anexo I – Matriz RACI.

Anexo II - Macrofluxo do Processo de Gerenciamento de Incidente de TI.

Anexo III - Elementos utilizados para o mapeamento do Processo de Gerenciamento de Incidentes de TI, presente no Anexo II.

Anexo IV - Mapeamento do Processo de Gerenciamento de Incidente de TI e ficha com atividades realizadas no processo.

Anexo V - Mapeamento do Processo de Gerenciamento de Incidente Grave de TI e fichas com atividades realizadas no processo.

Anexo VI - Indicadores e Metas do Processo de Gerenciamento de Incidente de TI.

Anexo I

Matriz RACI

Anexo II

Macrofluxo do Processo de Gerenciamento de Incidente de TI

Anexo III

Elementos utilizados para o mapeamento do Processo de Gerenciamento de Incidentes de TI

Anexo IV

Mapeamento do Subprocesso de Incidente de TI

­­Fichas de Atividades do Subprocesso de Incidente de TI

a) Reportar incidente de TI pelo autosserviço.

b) Registrar incidente de TI pela Central de Serviço.

c) Realizar diagnóstico inicial do incidente de TI

d) Inserir informações pendentes

e) Resolver incidente de TI na Central de Serviços.

f) Concluir o atendimento do incidente de TI na Central de Serviços.

g) Analisar incidente de TI no 2° nível de atendimento.

h) Resolver incidente de TI no 2° nível.

i) Concluir o atendimento de incidente de TI no 2° nível.

j) Analisar incidente de TI no 3° nível.

k) Resolver incidente de TI no 3° nível.

l) Concluir o atendimento do incidente de TI no 3° nível.

m) Validar resolução de incidentes de TI

Anexo V

Mapeamento do Subprocesso de Incidente Grave de TI

Ficha de Atividades do Subprocesso de Incidente Grave de TI

a) Analisar incidente Grave de TI

b) Comunicar incidente Grave de TI ao Gerente de Incidentes.