Última atualização: 24 de outubro, 2023
No atual cenário empresarial acelerado, incidentes graves podem ocorrer inesperadamente, afetando a produtividade e a satisfação do cliente. Independentemente do setor, a definição de planos de recuperação e a construção de uma cultura de resiliência são essenciais para garantir a continuidade dos negócios em tempos de crise. Vamos considerar as operações aéreas. As operações das companhias aéreas são complexas e a eficiência é alcançada através do esforço concertado de muitas pessoas. Os sistemas de TI, no entanto, tornaram-se essenciais para o cumprimento dos horários das companhias aéreas. Portanto, os colapsos de TI perturbam muitos usuários. Por exemplo, a Zylker Airlines passou recentemente por uma interrupção de TI, que incomodou milhares de passageiros.
Vamos dar uma olhada na causa e nos eventos da interrupção do Zylker.
Causa da interrupção
As operações aéreas da Zylker foram prejudicadas devido a uma interrupção de TI. O site da companhia aérea agora exibia um erro 502: Bad Gateway, causando problemas com reservas, check-in, cancelamentos e outras operações. A causa raiz da interrupção de TI foi atribuída a uma falha no firewall fornecido pelo fornecedor.
Para responder a novas vulnerabilidades e ameaças, a equipe de firewall do fornecedor lança regularmente novas regras para as regras gerenciadas existentes do firewall de aplicativo da Web (WAF) e, em seguida, envia a atualização globalmente. Durante uma dessas atualizações, um dos engenheiros da equipe de firewall fez uma pequena modificação que inadvertidamente aumentou o uso das CPUs dedicadas a servir o tráfego HTTP e HTTPS em toda a rede para quase 100%. Isso fez com que o site e os principais sistemas da companhia aérea ficassem inacessíveis por algumas horas.
Eventos que levaram à interrupção
Durante a janela de manutenção, as regras atualizadas do WAF foram aplicadas e o sistema pareceu funcionar normalmente. Várias horas após a atualização das regras, os usuários começaram a relatar problemas de acesso ao site da companhia aérea. A equipe de TI começou a investigar a causa e, após 13 minutos, foi declarado um incidente grave e as partes interessadas foram notificadas. Enquanto isso, houve um grande volume de ligações relatando o problema.
Membros de diversas equipes foram reunidos para formar uma equipe de resposta a incidentes 33 minutos após a ocorrência do incidente. A equipe investigou hipóteses de ataque cibernético. Demorou 53 minutos para descartar a possibilidade de um ataque cibernético, e a causa raiz ainda não foi identificada.
Após uma investigação mais aprofundada, a equipe identificou que a causa da interrupção de TI poderia ser atribuída à atualização da regra gerenciada do WAF e começou a reverter a atualização da regra gerenciada para restaurar o serviço. As operações normais foram retomadas 78 minutos após a interrupção do aplicativo web da companhia aérea.
Apesar do uso de várias aplicações e ferramentas de monitoramento, a Zylker cometeu vários erros e não conseguiu lidar com as grandes interrupções com eficiência. Este incidente destacou a necessidade de um processo robusto de gestão de incidentes graves e de protocolos de comunicação eficazes para mitigar o impacto de interrupções futuras.
Construindo um ciclo de vida de solicitação para lidar com incidentes graves no ServiceDesk Plus
Agora, vamos ver o que poderia ter acontecido se a Zylker Airlines tivesse contado com um processo simplificado de gerenciamento de incidentes e o implementado com o ServiceDesk Plus, que teria contido a interrupção criada pela atualização da regra WAF e minimizado a interrupção para seus clientes de forma muito mais eficaz.
- O ServiceDesk Plus pode ajudar a Zylker a seguir uma estrutura de práticas recomendadas (Fig. 1) para garantir que a empresa combata incidentes graves com eficiência.
Fig. 1: Best practice framework
Para implementar esta estrutura em tempo real, o ServiceDesk Plus usa o recurso Request Life Cycle (RLC). Os RLCs permitem projetar visualmente o ciclo de vida completo de um ticket usando uma tela simples de arrastar e soltar. Além disso, divide o ciclo de vida de um ticket em vários status e transições. Cada ticket no ServiceDesk Plus passa por vários status, como Aberto, Em espera, Resolvido e Fechado. Com RLCs, você pode projetar a sequência dos status junto com as condições e ações (transições) necessárias para cada mudança de status simplesmente arrastando e soltando os status na tela (Fig. 1.1).
Figura 1.1: Tela de arrastar e soltar RLC
Transições são ações necessárias para mover o ticket de um status para outro. Em cada status, as transições orientam os técnicos através de ações condicionais para avançar para o próximo status. Os técnicos podem alterar o status apenas através das transições disponíveis na página Detalhes do ticket de incidente (Fig. 1.2). Existem três estágios de transição: ANTES, DURANTE e DEPOIS, que permitem definir inúmeras opções para controlar o movimento de status com base no cumprimento de condições especificadas (Fig. 1.3). Este RLC pode ser associado a um ou mais modelos de incidente.
Fig. 1.2: Página Detalhes do Incidente
Fig. 1.3: Estágios de transição
Vamos dar uma olhada em como o recurso RLC poderia ter ajudado Zylker a conter o incidente grave.
- Durante a janela de manutenção, uma atualização de regra WAF é aplicada. ServiceDesk Plus integra-se com vários produtos ITOM, incluindo ManageEngine OpManager, para monitoramento de redes e serviços. Quando o OpManager identifica uma anomalia nos serviços, um alerta é automaticamente registrado como um ticket de incidente no ServiceDesk Plus com todos os detalhes relevantes, como data e hora da interrupção, sistemas ou aplicativos afetados e mensagens de erro recebidas.
- Este ticket usa automaticamente o modelo de incidente grave por meio de uma automação simples, sem código e baseada em regras. Depois que o ticket é registrado com o modelo de incidente grave, o RLC de incidente grave associado a esse modelo é ativado instantaneamente e começa a orientar o processo.
- Nos próximos três minutos, o representante da central de atendimento da Zylker avalia o impacto do incidente para evitar alarmes falsos e sinaliza o ticket de incidente como um incidente grave clicando na ação de transição Reportar na página Detalhes do ticket de incidente; isso atualiza o status do ticket e atribui o ticket à equipe de resposta a incidentes (IRT) automaticamente. Em seguida, uma notificação instantânea é enviada a todos os interessados. Estas ações são configuradas utilizando os três estágios de transição em um RLC, explicados abaixo.
ANTES da ação:
Zylker restringiu o acesso do botão de transição de relatório a representantes da central de serviços com funções específicas para os quais o botão de transição deve ser exibido e adicionou condições para determinar se esse botão de transição deve ou não ser exibido na página de detalhes do incidente (Fig. 2). Se o tipo de solicitação for um incidente, o botão de transição Reportar será exibido na página Detalhes do incidente apenas para técnicos com funções de TI ou Técnico de IRT.
Fig.2. ANTES da ação
DURANTE a ação:
Ao executar a transição do Relatório, a mensagem É um incidente grave? O campo é obrigatório, onde o representante da central de atendimento sinaliza o incidente como um incidente grave ou não. Se for sinalizado como um incidente grave, o campo Grupo na página Detalhes do incidente será atualizado para IRT (Fig. 3), que transfere o ticket para o bucket do IRT.
Fig 3: DURANTE a ação
DEPOIS da ação:
Após executar a transição do Relatório, uma notificação personalizada é enviada automaticamente ao IRT (Fig. 4) notificando-o sobre a ocorrência de um incidente grave. Além de notificações, webhooks, tarefas e funções personalizadas também podem ser acionadas com base nas condições. Na execução desta transição, o status do ticket de incidente é movido para WIP.
Fig.4: Depois da ação
Como próximo passo, um processo de triagem é realizado. Na transição Collaborate IRT, Zylker configurou uma notificação e adicionou uma função personalizada (Fig. 5) na ação de transição AFTER, que permite que o ServiceDesk Plus se integre ao Microsoft Teams para criar um link de sala de guerra virtual. Clicar nesta transição na página Detalhes do incidente aciona a notificação personalizada com o link da sala de guerra virtual a ser enviada ao IRT distribuído, facilitando a colaboração entre equipes que trabalham em um modelo de trabalho híbrido. Em seguida, o status do ticket é atualizado automaticamente para Triagem.
Fig. 5: Funções personalizadas
- À medida que a triagem ocorre, os clientes são informados sobre a interrupção usando o recurso Anúncio no ServiceDesk Plus para evitar que inundem a central de atendimento com novos tickets.
- Agora, começa a análise de causa raiz (RCA). Na transição Análise RCA (Fig. 6), são adicionadas tarefas à ação AFTER que já estão atribuídas a um grupo de técnicos ou técnico específico para analisar a causa raiz.
Fig. 6: Transição da Análise RCA
- Em cinco minutos, o IRT identifica a causa raiz como a atualização da regra WAF e notifica as partes interessadas apropriadas. Da mesma forma, a Zylker configurou três ações de transição para vários status no ciclo de vida de incidentes graves (Fig. 7) de acordo com seus requisitos.
Fig. 7: Ciclo de vida de incidentes graves de Zylker
- Ao encontrar a causa raiz, o ticket do incidente é delegado à equipe em questão para reverter a atualização da regra WAF. Um dos técnicos da Zylker implementa uma reversão na atualização da regra WAF e restaura os serviços em 28 minutos. Toda a equipe conseguiu identificar a causa raiz e resolvê-la antes de qualquer interrupção significativa.
- Assim que o problema for resolvido, as partes interessadas serão notificadas e a resolução será atualizada na base de conhecimento para ajudar os técnicos no futuro.
Assim, os RLC no âmbito da gestão de incidentes graves fornecem uma abordagem estruturada para lidar com incidentes críticos, salvaguardando as empresas contra as consequências potencialmente catastróficas de quaisquer interrupções. Descubra mais sobre o recurso RLC do ServiceDesk Plus aqui.
