UM GUIA ABRANGENTE SOBRE O GERENCIAMENTO DE INCIDENTES GRAVES

É segunda-feira de manhã e as coisas estão bastante normais no seu service desk. De repente, você recebe um ticket de alerta de que um serviço crítico está inativo e, nos próximos 15 minutos, começa a receber um influxo de tickets relatando o mesmo problema. Pode ser que seu site esteja fora do ar, seu software de ponto de venda tenha parado de funcionar ou algo ainda mais abrangente, como a bolsa de valores caindo ou os aviões sendo aterrados. Quando sua empresa é severamente afetada por um problema de TI que causa perda de receita e/ou reputação, você tem um incidente grave em suas mãos.

Como você reage a um incidente grave faz toda a diferença para minimizar o impacto dele e trazer os serviços de volta. Como se costuma dizer, tempo é dinheiro e, neste caso, isso não poderia ser mais verdade. Se a sua organização tiver um processo de Gerenciamento de Incidentes Graves (major incident management - MIM) em vigor, você pode responder rapidamente e resolve-los. Se você não tiver esse processo em vigor, é hora de elaborar um plano de resposta a emergências, também conhecido como um grande processo de resposta a incidentes.

As apostas de um incidente grave são maiores do que nunca e, de acordo com um estudo da Information Technology Intelligence Consulting, 98% das organizações perdem pelo menos US $ 100.000 de uma hora de tempo de inatividade. Isso reforça a importância de estabelecer um processo de MIM que possa lidar de forma eficaz e eficiente com eles.

Toda organização tem como objetivo eliminar incidentes graves, mas o resultado final é que eles são impossíveis de prevenir completamente e a única coisa que você pode fazer é estar preparado para quando surgirem.

Neste guia, veremos como configurar um processo de Gerenciamento de Incidentes Graves (MIM) eficaz, erros comuns que podem afetar o MIM da sua organização e práticas recomendadas para melhorar seu processo.

Mas primeiro, o que torna um incidente um incidente grave?

Um incidente grave é uma questão urgente de alto impacto que geralmente afeta toda a organização ou uma grande parte dela. Ele quase sempre resulta na indisponibilidade dos serviços de uma organização, o que faz com que os negócios sofra um golpe e afete sua posição financeira. Há duas maneiras pelas quais um incidente grave pode afetar os serviços de uma organização:

• Impedindo que os clientes acessem os serviços da organização. A interrupção da Cloudflare em julho de 2019 é um exemplo de clientes afetados por um incidente grave. Esta grande interrupção afetou quase metade da internet e deixou milhões de utilizadores incapazes de aceder a vários serviços.
• Ao interromper a capacidade dos funcionários de concluir seu trabalho no prazo, levando a uma interrupção dos negócios. A interrupção da IndiGo em novembro de 2019 afetou o processo de check-in da companhia aérea, o que levou a longos atrasos e afetou milhares de passageiros.

Uma central de serviços bem preparada está equipada para avaliar incidentes graves e criar soluções alternativas para reduzi-los e controlar o impacto deles.

Um grande processo de gerenciamento de incidentes é essencial para as organizações, pois as ajuda a minimizar o impacto comercial de um incidente grave. O processo de Gerenciamento de Incidentes Graves consiste principalmente nas seguintes etapas:

Stage 1: Identification

Declarando o incidente grave:

O primeiro passo é identificar possíveis incidentes graves. É importante que as organizações configurem vários métodos de identificação de ameaças. Incidentes graves podem ser sinalizados pelos técnicos quando se deparam com tickets incomuns, ou eles pode ser detectados por soluções como ferramentas de monitoramento de rede que podem sinalizar automaticamente um problema de rede e criar um ticket para alertar o service desk. As organizações também podem configurar uma linha direta dedicada para o pessoal do service desk para sinalizar suspeitas de incidentes graves.

Informe os stakeholders:

Uma vez que um incidente grave tenha sido identificado, ele precisa ser comunicado aos stakeholders. Existem quatro grupos principais que precisam ser informados sobre incidentes graves:

• Time técnico: É importante informar o time técnico imediatamente para que eles comecem a decidir uma ação para resolver o problema.
• Gestão: Manter a alta administração, como o CIO, informada sobre os principais incidentes ajuda na prestação de contas. As organizações também devem manter a gerência informada de todas as medidas tomadas para corrigir incidentes graves.
• Stakeholders-chave: Os chefes de departamento e a equipe de gerenciamento de negócios de nível de serviço também precisam ser informados sobre incidentes graves e receber atualizações regulares de status.
• Usuários: Os usuários precisam saber quais serviços podem estar indisponíveis devido a um incidente grave.

Estágio 2: Contenção

Montagem da equipe de incidentes graves

Uma Equipe de Incidentes Graves (Major Incident Team - MIT), consiste em técnicos, chefes de gerenciamento de nível de serviço e outros Stakeholders-chave; por vezes, é contratado pessoal externo altamente qualificado para enfrentar um incidente grave. O MIT trabalha em conjunto para encontrar uma solução para o incidente e trazer as operações de volta ao normal.

Configurando uma ponte de conferência

Uma ponte de conferência, mais comumente conhecida como chamada em conferência, ajuda na solução de problemas eficaz e na comunicação centralizada. Ele atua como um canal claro e rápido de comunicação entre os membros do MIT.

Preparando uma War Room designada

Ter uma War Room designada permite que todos os membros do MIT se reúnam e solucionem o incidente. Isso aumenta os esforços de colaboração, ajudando-os a encontrar uma solução mais rápida.

Criando um Problem Ticket para identificar os que estão ocultos

Um Problem Ticket pode ser criado para descobrir e entender a causa raiz do incidente grave. Isso pode ajudar a evitar os que são semelhantes no futuro, abordando as suas causas.

Etapa 4: Manutenção

Realizando uma revisão pós-implementação

É importante fazer um balanço do incidente durante um período de tempo para garantir que ele seja realmente resolvido. Se os problemas ocultos não forem resolvidos, eles podem levar a outro incidente grave.

Produzir documentação clara

Documentar todo o processo de resolução do incidente ajuda a organização a se preparar para os que forem semelhantes no futuro. Com a documentação adequada de incidentes passados, a organização pode implementar a solução testada e comprovada imediatamente quando confrontado um próximo semelhante, reduzindo o seu impacto.

Métricas de medição

Medir o desempenho do service desk ajuda a avaliar a sua eficácia e do processo de MIM. Algumas métricas importantes para medir são o Tempo Médio de Reconhecimento (Mean Time To Acknowledge - MTTA), o Tempo Médio de Resolução (Mean Time To Resolve - MTTR), o número total de incidentes graves e tempo médio de inatividade para eles.

Um incidente grave exige que um grupo especial de pessoal resolva o incidente e o resolva. As funções do MIM incluem:

Técnicos de Service Desk

Os técnicos de Service Desk são a primeira linha de defesa contra incidentes graves. Eles analisam os tickets de incidentes e os encaminham para o gerente de incidentes. Os técnicos de Service Desk também estão envolvidos na implementação de resoluções.

Gerente de incidentes graves

O gerente do incidente grave é o proprietário dele. Seu papel inclui declarar o incidente como um grave e garantir que o processo de MIM seja seguido e o incidente seja resolvido o mais cedo possível. Eles agem como o principal ponto de contato para qualquer informação sobre o incidente grave e gerenciar o MIT.

MIT

Um MIT é uma equipe especializada que é responsável por analisar o incidente grave e formular um plano de ação para lidar com a ameaça. O MIT idealmente consiste em técnicos de Service Desk, pessoal de gerenciamento de nível de Service, técnico pessoal, outros Stakeholders relevantes e consultores externos, se a situação o exigir.

Equipe técnica

O pessoal especializado que é responsável pela manutenção da infraestrutura e operações, incluindo administradores de sistemas, administradores de rede e pessoal de segurança da informação, que compõem a equipe técnica de uma organização. O técnico da equipe ajuda a solucionar o incidente grave e é o principal responsável pela implementação da resolução.

Gerenciador de mudanças

O gerenciador de alterações é o proprietário da alteração criada para implementar a correção para o incidente grave. O gerente de alterações assume a propriedade total do ticket de alteração e é responsável por ele.

Gerenciador de problemas

Se um problema for criado em resposta ao incidente, o gerenciador de problemas será o proprietário do ticket do problema. O gerente do problema tenta determinar as causas raiz do incidente e garantir que ele não ocorra novamente ou que a organização está pelo menos preparado para a próxima vez que o incidente ocorrer.

Consultores externos ou fornecedores terceirizados

Em alguns casos, o incidente grave pode exigir um pessoal altamente especializado para ajudar a entender e solucionar o incidente. O gerente de incidentes graves identifica o pessoal necessário e os adiciona ao MIT para ajudar a reduzir o impacto do incidente grave.

Aqui estão 5 erros comuns que podem dificultar seu processo de MIM:

1. Comunicação manual e escalonamento

   De longe, o maior desafio para a MIM é a comunicação. No caso de um incidente grave, vários stakeholders precisam ser informadas sobre o status do incidente, sua gravidade e qual solução de problemas foi feita para corrigi-lo. Comunicar tudo isso manualmente é uma tarefa árdua e pode levar a uma comunicação inconsistente, o que só piora as coisas. Ao automatizar o processo, os principais stakeholders são notificadas durante toda a vida útil do ticket e o gerente de incidentes graves pode concentrar toda a sua atenção na correção do problema.

2. Canais ineficazes para relatar incidentes graves

   Todo service desk recebe dezenas ou até centenas de tickets por dia, que vão desde problemas com laptops até solicitações de serviço, entre essa montanha de tickets, pode haver alguns possíveis incidentes graves. Não configurando um canal separado a comunicação de incidentes, atrasa a identificação deles.

3. Duplicação de esforços

   A falha em delegar tarefas de maneira organizada pode causar duplicação de esforços dentro do MIT. É importante atribuir tarefas e manter o MIT informado sobre o que cada membro é encarregado.

4. Documentação deficiente

   A falta de documentação adequada forçará o MIT a "reinventar a roda" toda vez que ocorrer um incidente grave semelhante, levando a atrasos na sua resolução e causando tempo de inatividade desnecessário.

5. Falha ao analisar a causa raiz

   Semelhante ao Gerenciamento de Incidentes, O MIM pode ser míope em escopo, pois seu foco principal é corrigir o problema e colocar os serviços em funcionamento no menor tempo possível. Se não for combinada com o Gerenciamento de Problemas para identificar problemas ocultos, a causa deles continuará a tornar a organização vulnerável a incidentes graves.

Aqui estão as melhores maneiras de abordar o processo de MIM

1. Habilite vários canais para relatar incidentes graves

   Quando se trata de lidar com incidentes graves, o tempo é essencial. É vital que as organizações identifiquem e classifiquem os principais incidentes assim que forem detectados. Oferecer aos usuários várias maneiras de relatar incidentes fará com que todo o processo mais rápido e acessível. Você pode habilitar a criação de tickets por e-mail ou um portal da Web, ou até mesmo configurar uma linha direta dedicada para relatar suspeitas de incidentes graves. Configurando o software de monitoramento de rede para detectar anomalias pode ajudá-lo a lidar proativamente com os incidentes.

2. Automatize os processos do Service Desk

   A velocidade e a eficiência desempenham um papel vital no controle do impacto de um incidente grave, e a automação de vários processos de service desk ajuda a conseguir isso, liberando seus técnicos de tarefas repetitivas, como notificar os Stakeholders. Automatizar o sistema de notificação e configurar fluxos de trabalho de incidentes graves são boas maneiras de automatizar os processos do Service Desk para melhorar o tempo de resolução e trazer estrutura ao seu processo de MIM.

3. Esforce-se para uma comunicação rápida e relevante

   É importante manter a gerência da sua organização e os Stakeholders informados sobre cada incidente grave. Manter o gerenciamento informado ajudará a obter as aprovações e permissões necessárias para corrigir o incidente grave. A comunicação rápida garante que todo o time de incidentes graves esteja na mesma página e permite uma colaboração suave e eficaz, também mantém os usuários finais informados sobre qualquer possível tempo de inatividade para que possam prepare-se para isso.

4. Criar uma documentação clara

   A documentação clara ajuda o gerente de incidentes graves a registrar todo o trabalho feito para corrigir o incidente principal, seu impacto, os serviços afetados e outras informações importantes sobre ele. Esta documentação é importante para mostrar à gerência o benefício de ter um processo de MIM, incluindo seu ROI. Uma documentação clara também ajudará com qualquer incidente grave semelhante no futuro.

5. Utilize integrações profundas com o software ITOM

   Fortes integrações com o software ITOM permitem que o departamento de TI lide proativamente com incidentes graves. A identificação reativa de incidentes graves depende de um influxo de tickets para levantar uma bandeira vermelha de que um incidente grave está em andamento. Por outro lado, um processo proativo de MIM que utiliza integrações ITOM possui sistemas para monitorar redes e serviços e pode sinalizar automaticamente anomalias que podem ser possíveis incidentes graves.

IÉ importante lembrar que nem todos os incidentes de alta prioridade são incidentes graves. Como o processo de MIM envolve um compromisso considerável de recursos, como a implementação de um MIT separado, é importante classificar cuidadosamente os incidentes graves.

Fonte: https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/

A interrupção da Cloudflare de 2019 é um bom exemplo do que define um incidente grave. Nesse caso, um procedimento operacional padrão de atualização de uma regra gerenciada para o firewall de aplicativo da Web (WAF) aumentou o uso de CPUs dedicadas a servindo o tráfego HTTP/HTTPS para quase 100% em todos os servidores na rede da Cloudflare. A interrupção que se seguiu resultou em uma redução de 80% do tráfego da Cloudflare e afetou milhões de usuários da Internet em todo o mundo.

Impacto: Grande

A interrupção resultou em clientes da Cloudflare (e seus clientes) vendo uma página de erro 502 ao visitar qualquer domínio da Cloudflare. Os erros 502 foram gerados pelos servidores web front-end Cloudflare que ainda tinham núcleos de CPU disponíveis mas não foi possível acessar os processos que servem o tráfego HTTP/HTTPS. Estima-se que pelo menos metade de toda a internet estava inacessível durante os vinte e sete minutos de tempo de inatividade.

Urgência: Alta

Todos os sites da Cloudflare estavam inacessíveis, causando interrupções de serviço para milhares de organizações e milhões de usuários. A interrupção também afetou as operações internas da Cloudflare, impedindo que os funcionários da Cloudflare acessassem vários serviços, como a ferramenta de gerenciamento de mudanças da empresa e o painel de controle interno. A interrupção teve que ser tratada para retomar as operações normais de serviço.

Linha do tempo de eventos desde a detecção até a resolução:

A regra gerenciada do WAF foi implementada às 13:42, três minutos depois, as ferramentas de operação de rede da Cloudflare começaram a sinalizar a queda no tráfego, muitos outros testes de ponta a ponta dos serviços da Cloudflare começaram a falhar, os usuários finais notaram vários 502 erros, e Cloudflare recebeu muitos relatórios de esgotamento da CPU de seus pontos de presença em cidades em todo o mundo.

A equipe de engenharia de confiabilidade do local, a equipe de engenharia de Londres e outras equipes relevantes foram reunidas para solucionar problemas e chegar a uma correção. Às 14:00, o WAF foi identificado como a causa do incidente. E às 14:07, um O WAF kill foi implementado para trazer os níveis de tráfego de volta ao normal.

Às 14:52, a Cloudflare estava 100% satisfeita por entender a causa da interrupção e ter uma correção em vigor, então o WAF foi reativado globalmente.

Mudar

A adição, modificação ou remoção de qualquer coisa que possa ter um efeito direto ou indireto sobre os serviços.

Gerenciamento de mudanças

O processo de levar as alterações à conclusão com o mínimo de interrupções e colisões.

Escalada

O ato de transferir a propriedade de um ticket com base em uma necessidade funcional ou hierárquica.

Acontecimento

Uma ocorrência que tem significado para o gerenciamento de um serviço ou ativo.

Fracasso

Uma ocorrência em que um serviço ou ativo não funciona de acordo com o SLA acordado.

Escalonamento hierárquico

O ato de transferir a propriedade verticalmente para um técnico de Service Desk de nível superior ou autoridade relevante.

Impacto

Uma medida da gravidade de um incidente.

Incidente

Uma interrupção não planejada de um serviço de TI ou uma redução na qualidade de um serviço de TI. A falha de um item de configuração, mesmo que ainda não tenha afetado um serviço, também é um incidente (por exemplo, falha de um disco de um conjunto de espelhos).

Gerenciamento de incidentes

O processo de gerenciamento do ciclo de vida de todos os incidentes para restaurar as operações normais de serviço o mais rápido possível e minimizar o impacto nos negócios.

Priorização de incidentes

Atribuir prioridades a incidentes e definir o que constitui um incidente grave.

Incidente grave

Um incidente que tem um alto impacto e alta urgência, exigindo um processo separado do gerenciamento de incidentes.

Gerente de incidentes graves

A pessoa que é responsável pelo MIT e pela implementação do processo de MIM.

Tempo médio de reconhecimento (MTTA)

Uma medida da rapidez com que um incidente é reconhecido pelo service desk.

Tempo médio de detecção (MTTD)

Uma medida da rapidez com que uma ameaça potencial a um serviço ou item de configuração é detectada.

Tempo médio entre falhas (MTBF)

Uma medida da frequência com que um serviço ou ativo falha.

Tempo médio para reparar/resolver/responder/recuperar (MTTR)

Uma medida da rapidez com que um serviço é restaurado após a falha.

Funcionamento normal do serviço

Uma operação de serviço que adere ao contrato de nível de serviço (SLA).

Problema

Uma causa ou causa potencial de um ou mais incidentes.

Matriz RACI

Ele define as funções e responsabilidades em projetos e processos multifuncionais ou departamentais.

Balcão de serviços

O ponto de comunicação entre os provedores de serviços e os usuários da organização.

Gerente de service desk

Aquele que supervisiona as atividades do dia-a-dia do service desk e é responsável pelo seu desempenho.

Objetivo de nível de serviço (SLO)

Define o objetivo dos prestadores de serviços e é um meio de medir o seu desempenho.

SLA

Um acordo entre o provedor de serviços e o cliente sobre o nível esperado de serviço e o tempo esperado em que ele é entregue.

Urgência

Uma medida da rapidez com que um incidente precisa ser resolvido.