ITIL major incident management process with real-life examples

Transcrição do vídeo

Eleve o nível de seu processo de gerenciamento de incidentes graves (MIM)

Agora, vamos para o nosso segundo cenário, que é lidar com o incidente grave e colocar seus serviços novamente no ar. Como organização, não gostamos nada de incidentes graves, certo? Tentamos ficar longe deles, mas é sempre melhor prever quando eles ocorrerão e ter uma estratégia para lidar com eles para que não gerem caos e confusão. Portanto, nesta situação da vida real, analisamos uma organização que não tinha uma estratégia de gerenciamento de incidentes e vamos ver como ela reagiu a um incidente grave.

Estudo de caso: Um grave incidente de disponibilidade afeta uma empresa de desempenho de websites

Então, este é o nosso estudo de caso. Temos uma empresa de desempenho e segurança na web que oferece proteção CDN, DNS e DDoS para muitos websites. Como um processo operacional padrão, a equipe implementava regularmente novas regras em seu firewall de aplicações da web para reagir a novas vulnerabilidades de segurança na internet. Assim, durante uma dessas atualizações de rotina, uma pequena alteração feita por um de seus engenheiros aumentou significativamente o uso das CPUs em seus servidores e derrubou metade dos websites de todo o mundo, fazendo com que os clientes recebessem a mensagem "502 bad gateway". Como você pode perceber, esse é um incidente grave de magnitude máxima.

A equipe de incidentes depura a situação

Vamos dividir a sequência de eventos em uma linha do tempo para analisar como a organização realmente trabalhou nessa situação. Às 13:42, a interrupção de fato ocorreu e os serviços falharam. Imediatamente, recebem alertas de diferentes ferramentas de monitoramento e diferentes alertas são criados, como alertas de inatividade do serviço, alertas de erros financeiros etc. Oito minutos após o incidente, a equipe de SRE percebe que algo está errado e, nesse momento, 80% do tráfego já está inoperante.

Desconfiam que seja um ataque externo e, quando percebem o impacto, declaram um incidente grave. Em seguida, a equipe de engenharia de Londres é alertada sobre a interrupção global e, durante todo esse tempo, a equipe de suporte recebe inúmeras ligações. Os telefones não param de tocar e muitos chamados estão sendo abertos. Trinta e três minutos após o incidente, é formada uma equipe de resposta a incidentes com membros de várias equipes. Sim, vou repetir. No auge do caos e da confusão, 33 minutos após o incidente principal, uma equipe de resposta a incidentes está sendo formada. Temos um grande gargalo aqui.

Essa equipe de IRT estava sob intensa pressão do gerenciamento e ainda não identificou a causa raiz. E quase uma hora depois, ela descartou a possibilidade de um ataque externo e, finalmente, descobriu que o problema era com o WAF. Então, eliminam o WAF e, finalmente, os sites voltam a ficar online. Como você pode ver, ao longo dessa linha do tempo, houve grandes obstáculos, como o reconhecimento de um incidente, a formação de uma equipe, a comunicação com as partes interessadas e a triagem. Então, como eliminar todos esses gargalos para que sua empresa não seja afetada?

Estrutura de gerenciamento de incidentes graves de disponibilidade

Aqui está um workflow de práticas recomendadas que usamos na Zoho para combater incidentes graves. Portanto, tudo começa com a detecção de um alerta da ferramenta de monitoramento e sua conversão em um ticket em sua ferramenta de service desk. Assim que isso acontece, você reconhece que há um incidente grave e se comunica com as partes interessadas, como CIOs, CTOs ou gerentes de IRTs para reunir todas e dar início ao processo de triagem. Nesse caso, você avalia o impacto do incidente e decide se deve ou não declarar um incidente grave. A esta altura, seus usuários finais estariam em pânico por não conseguirem acessar serviços essenciais do negócio.

Depois, você se comunica externamente com eles, faz um anúncio dizendo que há um incidente e que está trabalhando nele. Agora você cria tarefas diferentes que devem ser delegadas aos devidos grupos de resolução que, por sua vez, fornecem soluções temporárias e garantem que seus serviços sejam colocados novamente online, encerrando os limites do gerenciamento de incidentes.

Agora precisamos realizar uma análise da causa raiz e garantir que não ocorra um novo incidente grave. Para isso, precisamos criar um ticket de problema.

Estrutura de gerenciamento de incidentes graves de disponibilidade com o ServiceDesk Plus

É assim que se lida com um incidente grave de forma eficiente. Agora, vamos ver como você pode aproveitar o ServiceDesk Plus para isso.

O que você está vendo na tela agora é o OpManager, que é o software de monitoramento de rede da ManageEngine. Você pode integrar o OpManager ao ServiceDesk Plus e garantir que, sempre que um alerta de monitoramento for criado, você poderá convertê-lo automaticamente em um ticket no ServiceDesk Plus. Agora, você está vendo exatamente essa implementação e, assim que o alerta de monitoramento for criado, é assim que o ticket é aparece no ServiceDesk Plus. Como você pode ver, há uma breve descrição do incidente e praticamente tudo o que você vê é o que vimos antes na solicitação de serviço.

O próximo processo é comunicar-se com as partes interessadas e informá-las sobre esse incidente grave. Para isso, usaremos a automação novamente, mas desta vez com as regras dos negócios. Portanto, as regras de negócios são ações baseadas em condições, que garantem que não haja atraso na comunicação de incidentes graves. Assim que um ticket é registrado com o assunto como "edificado", "não detectado" ou "site fora do ar", um conjunto de ações seria executado, como definir a prioridade como incidente crítico e colocá-lo no grupo de suporte apropriado, para que possam iniciar o processo de solução de problemas. Você também pode enviar notificações para partes interessadas específicas na forma de e-mail ou SMS o que facilita a comunicação com as partes interessadas em tempo real e elimina um grande gargalo.

Então, deixe-me voltar ao workflow de práticas recomendadas novamente e mostrar onde estamos. Detectamos o incidente grave e nos comunicamos imediatamente com as partes interessadas. A próxima etapa é avaliar os danos ocorridos e declarar um incidente grave. Vimos como vários tickets estão sendo criados e múltiplos alertas de monitoramento estão sendo gerados, o que se traduz em vários tickets. Logo, você pode vincular todos esses tickets e garantir que o incidente grave seja solucionado.

Como você pode ver, no lado direito, todos os ativos afetados também estão associados a esses tickets de incidente. Se eu clicar nesses ativos, todos os detalhes do ativo serão exibidos. Dessa forma, as informações detalhadas de CI, as informações de hardware e software e os relacionamentos são obtidos a partir do CMDB. o que ajuda você a verificar se os principais serviços serão afetados ou não. Como você pode ver, os serviços administrativos de uma localidade geográfica completa (Delhi neste caso) seriam afetados porque este servidor hospeda esses dois serviços.

Em seguida, comunicaremos esse incidente às partes interessadas. Para isso, vou até a página inicial do técnico e clico em Adicionar novo anúncio. Desta forma, é possível criar um novo anúncio aqui e garantir que ele seja exibido dentro de um período específico. Além disso, você pode optar por mostrá-lo apenas para o grupo certo de usuários afetados. Nesse caso, vimos que havia usuários de uma localidade e de um departamento específicos que seriam afetados. Assim, você pode garantir que o restante dos usuários finais continue com suas atividades e que sejam comunicados.

Vamos voltar ao nosso workflow de práticas recomendadas e ver onde chegamos. Detectamos a ocorrência do incidente grave, comunicamos o fato, avaliamos o impacto e o informamos por meio de anúncios. Agora, tudo o que resta a fazer é delegar diferentes tarefas, iniciar o processo de solução de problemas, que consiste em fornecer uma solução alternativa. Para isso, voltaremos ao ticket do incidente e clicaremos em tarefas. Discutimos muito sobre tarefas anteriormente na solicitação de serviço.

Da mesma forma, você pode criar diferentes tarefas associadas a diferentes grupos e garantir que você configure as dependências corretas que são muito importantes porque a triagem é realmente necessária e, em um incidente grave, é preciso seguir um procedimento definido. Depois que as tarefas forem realizadas e uma solução alternativa for fornecida, você precisará adicioná-la à sua resolução que pode ser adicionada aqui. Se for a primeira ocorrência, você poderá adicioná-la à sua base de conhecimento para que ajude a combater futuras ocorrências do mesmo incidente.

Concluímos os limites ou o domínio do gerenciamento de incidentes. Neste momento, tudo o que resta é criar um ticket de problema e iniciar uma análise da causa raiz para entender o motivo desse incidente em primeiro lugar. Para isso, você pode ir em Associações e clicar em Criar um novo problema. Aqui, todos os detalhes são transferidos, você pode criar um novo problema e seu técnico ou um grupo de técnicos apropriado realizaria uma análise da causa raiz. É simples assim. Agora parece muito fácil, certo? Eliminamos todos os gargalos enfrentados pela empresa de desempenho de web. Garantimos que entendemos as práticas recomendadas e as aplicamos em sua abordagem de ITSM com os recursos.

Agora, assim como na solicitação de serviço anterior, precisamos manter o controle de algumas matrizes essenciais. Isso é muito importante, pois só assim você saberá quais são as lacunas existentes em sua estratégia e como poderá eliminá-las.

Aqui, você tem a quantidade de tickets, a produtividade dos técnicos, o tempo de resolução e, novamente, o índice de rotatividade de tickets. Então, aconselho você a criar dashboards exclusivos e completos para lidar com os incidentes graves. Eu criei um dashboard de gerenciamento de incidentes graves aqui que faz a representação em tempo real, classificados por categoria, técnico e o número de incidentes encerrados por técnico. Com isso, chegamos ao final de nossa segunda situação. A esta altura, você deve estar confiante para lidar com qualquer incidente grave no futuro.