Olá amigos do Portal GSTI!
Este é mais um artigo para detalhar conceitos básicos relacionados a gestão de serviços de TI com base na biblioteca #ITIL.
Conforme sabemos, o major indecente é uma categoria extrema de um incidente que deve ser identificada e tratada adequadamente dentro do processo de gestão de incidentes.
Para realizar um overview sobre o tema, estruturei o artigo em 04 tópicos, conforme a seguir:
1) O que é um Major Incidente / Incidente Grave
2) O sub processo de tratamento de incidentes graves
3) Papéis e responsabilidades
4) Política de gestão de incidentes graves
1) O que é um Major Incidente / Incidente Grave
Segundo a ITIL, um Major Incidente (ou incidente grave) trata-se de um incidente com o maior grau de impacto entre os níveis previstos para a priorização de incidentes nos serviços de TI.São incidentes para quais a tolerância para para a indisponibilidade do serviço é mínima e cujos serviços estão associados a altíssimos níveis de serviço para a disponibilidade, confiabilidade e sustentabilidade.
Uma outra maneira de apresentar o conceito de incidente grave é pontuando que estes normalmente estão associados a funções vitais do negócio. Afinal, a gravidade do incidente e o impacto no negócio são medidas diretamente proporcionais quando se trata de interrupções em serviços de TI.
2) O sub processo de tratamento de incidentes graves
P ara dar atenção adequada a um major incidente, é uma boa prática utilizar-se um conjunto de atividades e responsabilidades para o tratamento destes.Estamos falando de incidentes graves, você não vai querer que algo seja conduzido de forma errada justamente no momento em que a equipe de operação mais precisa ser eficaz e ágil, vai?
Portanto, a primeira coisa a dizer é que você precisa planejar como irá agir em tais situações e cuidar para que este plano seja formalizado em um subprocesso.
Neste ponto, identificamos aqui algo curioso e paradoxal: é comum que os departamentos de TI invistam em um processo de gestão de incidentes para mais adiante começar a se preocupar com procedimentos específicos para os graves. Se fossemos refletir a respeito, o caminho oposto seria mais sensato!
A afirmação anterior pode parecer estranha ou radical, mas eu explico: para incidentes altamente impactantes, o prejuízo é enorme e a necessidade de um trabalho profissional e eficiente é maior. Situações extremas exigem um cuidado extremo.
Ora, se alguém vai inciar um trabalho de formalização de um processo em busca de melhoria de suas atividades seria conveniente/lógico começar pelo que está dando mais ou menos prejuízo?
Não seria incoerente, portanto, um departamento de TI ter já mapeado e adotado procedimentos formais para major incidentes antes mesmo de ter concluído a adoção do macro processo de gestão de incidentes.
Mas não levanto este ponto para polemizar, nem mesmo como crítica a atuação de departamentos de TI que adotam #ITIL como boas práticas. Minha intenção é apenas apontar como curiosidade para chamar atenção da relevância de um subprocesso de solução de incidentes graves, que resumo a seguir.
É necessário garantir que os procedimentos, atividades, comunicação o e quaisquer outros elementos essenciais sejam tratados de maneira correta e adequada. Para isso, é comum recorrer à elaboração de uma política específica para incidentes graves (ver item 4).
Você pode até está se perguntando neste momento: por que usar um subprocesso em vez de simplesmente mapear as atividades para incidentes graves dentro do processo de gestão de incidentes?
Apesar de não se tratar de um quesito obrigatório - aliás, nada é quando estamos falando de boas práticas - a delimitação de um subprocesso irá contribuir para a eficácia e eficiência com qual os major incidentes são tratados.
Como eu disse anteriormente, estamos falando de algo que tem grande impacto e repercussão na área de negócio. É adequando um tratamento especial e independente.
Agrupar as atividades em um sub processo permitirá um maior nível de detalhamento e atenção para este "processo dentro de um outro processo maior".
Veja alguns itens que estarão melhor definidos e detalhados com a existência de um subprocesso para gestão de incidentes graves:
- melhor definição de entradas e saídas necessárias para o sub processo de tratamento das interrupções altamente impactantes;
- possibilidade de definir indicadores e metas específicas para este sub processo e consequentemente gerenciá-lo com maior grau de transparência e controle (um indicador comum é o Tempo Médio entre Falhas classificadas como incidentes graves);
- adoção de regras diferenciadas;
- capacitações diferenciadas;
- relacionamentos adicionais com outros processos, além dos relacionamentos já definidos para a gestão de incidentes;
- atribuição de responsabilidades específicas;
- entre outros.
3) Papéis e responsabilidades
Conforme citado no final tópico 02, para o tratamento de incidentes graves é adequado que responsabilidades específicas sejam atribuídas, o que exige preparação também específica para os profissionais que executarão as tarefas de resolução do incidente e coordenação do processo.Um segundo ponto que destaco como relevante para as responsabilidades é o envolvimento do #Service Desk no sentido de fornecer feedbacks constantes ao(s) clientes(s) envolvido(s) com o serviço indisponível. Se você faz parte de uma equipe de um prestador de serviços de grande porte com centenas de milhares ou até milhões de usuários, pode considerar a possibilidade de fornecer estes feedbacks através de ferramentas sociais como Twitter e Facebook.
Ademais, tenha em sua equipe papéis especiais para a condução deste subprocesso se deseja obter bons resultados.
Lembre-se: qualquer pessoa preparada para lhe dar com emergências pode usar um extintor para apagar um pequeno foco de fogo, mas você precisa acionar os bombeiros para apagar um incêndio de grande porte.
Papéis que executam atividades de outros processos também podem ser acionados, tais como:
- o gerente ou outros membros do processo de gestão de disponibilidade precisa receber as informações sobre o downtime e pode, em alguns casos, colaborar com sugestões, graças à a experiência com técnicas como CFIA (Component Failure Impact Analisys)
- o gerente de continuidade precisa acompanhar a situação e verificar se existem razões para acionar o plano de retorno;
- o gerente de configuração prestará apoio para interpretação das informações contidas nos itens de configuração envolvidos no major incidente;
- papéis atribuídos ao gerenciamento de problemas serão acionados para identificar a causa raiz do incidente, quando esta é desconhecida.
Não custa lembrar de que a Matriz RACI ajuda na realização da tarefa de atribuição de responsabilidades.
4) Política/procedimento de gestão de incidentes graves
Já deu para notar o desafio de definir um subprocesso de gestão de major incidentes, sim? A complexidade na condução do processo aumenta.Para facilitar a sua vida, recorra a um padrão único e formal que pode ser nomeado como procedimento, norma ou política de gestão de incidentes graves (esta ultima nomenclatura é a mais utilizada).
Na política, serão mapeadas as diretrizes que cobrem tudo o que foi citado neste artigo e um pouco mais. É um fator crítico de sucesso na execução destas boas práticas. Veja a seguir um modelo.
Continue estudando gerenciamento de incidentes:
- Diferença entre Incidentes e Problemas
- A importância da atividade de classificação na gestão de incidentes
- Gerenciamento de Eventos x Gerenciamento de Incidentes
- Gestão de Incidentes de Segurança da Informação passo a passo
- Incidentes de Segurança: conceito, exemplos e cases
