Como executar um processo de gerenciamento de incidentes graves

Gerenciando e resolvendo incidentes de alto impacto

Gerenciamento de incidentes graves (muitas vezes conhecido aqui na Atlassian apenas como gerenciamento de incidentes) é o processo usado pelas equipes de DevOps e de Operações de TI para responder a um evento não planejado ou à interrupção de serviço e restaurar o serviço ao estado operacional.

O que é um incidente grave?

Então, o que é incidente grave? Incidente grave é uma interrupção ou perda de serviço em nível emergencial. 

A definição de nível de emergência varia entre as empresas. Na Atlassian, temos três níveis de severidade e os dois primeiros (SEV 1 e SEV 2) são considerados incidentes graves.

Se um serviço voltado para o cliente estiver inativo para todos os clientes da Atlassian, é considerado um incidente SEV 1. Se o mesmo serviço estiver inativo para um subconjunto de clientes, é SEV 2. Ambos se enquadram na categoria de incidentes graves e exigem uma resposta imediata das equipes de gerenciamento de incidentes.

Qualquer item que não interfira com as tarefas essenciais é considerado um SEV 3 e não é um incidente grave.

Definindo o processo de gerenciamento de incidentes graves

O ciclo de vida do incidente (também conhecido às vezes como processo de gerenciamento de incidentes) é o caminho que percorremos para identificar, resolver, entender e evitar incidentes repetidos. 

Os processos de gerenciamento de incidentes variam de empresa para empresa, mas a chave para o sucesso de qualquer equipe é definir e comunicar com clareza e antecedência níveis de gravidade, prioridades, funções e processos — antes de um incidente grave surgir. 

Para obter uma compreensão compartilhada das prioridades, funções e processos, toda equipe que estiver começando ou revisitando o processo de gerenciamento de incidentes graves deve começar se esclarecendo sobre as respostas de perguntas como:

• O que constitui um incidente grave para a empresa/produto?

• Como vamos definir severidade e níveis de prioridade de incidentes? Se mais que um incidente grave ocorrer ao mesmo tempo, como saber qual solucionar primeiro?

• Quem é responsável por gerenciar incidentes graves? Quais papéis os membros da equipe vão ter? Como estes papéis vão ser definidos e comunicados?

• Qual processo as equipes vão seguir no evento de um incidente grave? Existe mais de um processo, dependendo do tipo de incidente?

• Com que frequência vamos nos comunicar com partes interessadas, tanto internos quanto externos? Qual é o plano de comunicação?

• Como vai ser cronograma de plantão para incidentes graves? Quem é responsável por um incidente às 2 da manhã? E em um final de semana? E nos feriados?

• Quando e como devemos alertar o gerenciador de incidentes de plantão, priorizando resolução para incidentes graves enquanto também se evita fadiga de alertas?

O processo de gerenciamento de incidentes graves da Atlassian

Na Atlassian, o processo de gerenciamento de incidentes inclui detecção, levantamento de um novo incidente, abertura de comunicações, avaliação, envio de comunicações iniciais, escalonamento, delegação, envio de comunicações de acompanhamento, revisão e resolução.

Detecção

Primeiro, um incidente é detectado pela tecnologia, pelo relatório de cliente ou pelo pessoal. Quem detectar o incidente (seja um técnico que notar o item ou um representante de atendimento ao cliente que recebeu uma ligação de um cliente frustrado) é responsável por registrar o incidente no sistema e por identificar um nível de severidade. 

No momento em que um incidente chega às equipes, ele já tem um nível de severidade 1, 2 ou 3 atrelado. Consideramos os níveis de severidade 1 e 2 incidentes importantes, enquanto um nível de severidade 3 indica um incidente de menor impacto.

Levantando um novo incidente

Depois que um ticket de incidente é criado, uma notificação será enviada para o profissional de plantão responsável por esse serviço. 

O alerta de página que enviamos na Atlassian inclui informações sobre a gravidade e a prioridade do incidente, bem como um resumo, deixando claro — de relance — se essa é a prioridade máxima ou se pode esperar se outro incidente estiver em andamento.

Abertura de comunicações

Uma vez que o gerenciador de incidentes recebe um alerta, sua primeira ordem de negócios é comunicar que a correção do incidente está em andamento. Ele muda o status do incidente para corrigir e configurar os canais de comunicação da equipe.

É fundamental oferecer canais de comunicação flexíveis em todo o processo de resposta a incidentes que permitam que as equipes mantenham contato pelo método que preferirem. O Jira Service Management integra vários canais de comunicação para minimizar o tempo de inatividade, como widget de status integrado, página de status dedicada, e-mail, ferramentas de bate-papo, redes sociais e SMS.

Avaliação

O gerenciador de incidentes foi alertado e os canais de comunicação estão abertos. Próximo passo: avaliar o incidente em si. 

Para as equipes, este processo começa com uma série de perguntas que a equipe precisa responder:

• Qual o impacto em clientes e funcionários da Atlassian?

• O que os clientes estão vendo?

• Quantos clientes foram afetados? (alguns? todos?)

• Quando o incidente teve início?

• Quantos casos de suporte foram abertos para este incidente?

• Existem outros fatores em jogo que afetam o nível de severidade ou prioridade ou alteram a maneira como abordamos o incidente? (tais como preocupações de segurança, crises de relações públicas nas redes sociais, etc.)

Depois de respondermos a essas perguntas, podemos avançar com confiança com diagnósticos e correções propostas ou alterar o nível de SEV e o nível de prioridade de um incidente conforme necessário.

Enviando comunicações iniciais

Uma vez confirmados que o incidente é real, a comunicação com os clientes e funcionários torna-se prioridade máxima. Como dizemos no manual:

"O objetivo da comunicação interna inicial é focar a resposta a incidentes em um só lugar e reduzir a confusão. O objetivo da comunicação externa é contar aos clientes que você sabe que algo está com problema e que está trabalhando nisso com urgência.

Comunicação veloz e precisa ajuda a criar e manter confiança do cliente.

Temos planos estratégicos de comunicação de incidentes e oferecemos atualizações regulares de status que seguem formatos simples. Também enviamos e-mails para uma lista de partes interessadas que incluem a liderança de engenharia, gestores de incidentes graves e outros funcionários internos importantes. Como já mencionado, todos esses métodos de comunicação são personalizáveis no Jira Service Management e podem ser adaptados ao plano de resposta a incidentes de qualquer empresa.

Escalonamento

Às vezes, um incidente é resolvido com rapidez pela equipe de plantão. Mas nos casos que não são assim, o próximo passo é escalar o item para outro especialista ou equipe de especialistas mais adequados para resolver esse incidente específico.

No Jira Service Management, os respondentes podem agrupar tickets relacionados e adicionar colaboradores ao item para coordenar os alertas. Os respondentes também podem fazer registros automáticos de todas as ações com cronograma de incidentes completo e acessar artigos sobre automação e base de conhecimento para investigar e corrigir incidentes com rapidez.

Delegação

Depois que o item foi escalonado a alguém novo, o gerenciador de incidentes delega uma função a ele. Na Atlassian, essas funções são predeterminadas para que os membros da equipe possam entender com rapidez o que é esperado deles.

Às vezes, incidentes graves exigem um único gerenciador de incidentes e uma equipe pequena. Outras vezes, uma situação pode exigir vários líderes de tecnologia ou até mesmo vários gerenciadores de incidentes. O gerenciador de incidentes original tem a tarefa de descobrir quando esse é o caso e trazer as pessoas certas.

Enviando comunicações de acompanhamento

À medida que o incidente continua a progredir, outra rodada de comunicação fora da equipe de tecnologia vai ajudar a manter os clientes e funcionários calmos, confiantes e atualizados. Isso é fácil quando os colaboradores podem gerenciar alertas em diferentes plataformas de comunicação para ficar por dentro da resposta a incidentes.

Análise

É uma pena, mas quando se trata de resolução de incidentes, não há uma solução única. É por esse motivo que, nesta fase do processo, a gente toma um tempo para:

• Observar o que está acontecendo, compartilhando e confirmando as observações com a equipe

• Desenvolver teorias sobre o que está acontecendo (e sobre como consertar o incidente)

• Desenvolver e executar experimentos para provar ou refutar teorias

• Repetir

Ao longo deste processo, o gerenciador de incidentes mantém um olho atento em como as coisas estão indo. Há algum membro da equipe sobrecarregado? Alguém precisa de um intervalo? Precisamos trazer uma perspectiva nova e fresca? Mais delegações ocorrem conforme necessário.

Resolução

O manual de incidentes define uma resolução como "quando o impacto de negócios atual ou iminente é encerrado". 

Neste momento, a emergência passou e a equipe passa para limpezas e análises retrospectivas.

Análises retrospectivas

O ciclo de vida do incidente termina quando ele é resolvido, mas esse não é o fim do processo na Atlassian. Também queremos fazer tudo o que estiver ao alcance para garantir que um incidente não se repita. É por esse motivo que a próxima etapa é a análise retrospectiva sem atribuição de culpa projetado para identificar a causa do incidente e nos ajudar a mitigar o risco no futuro.

Use templates de análise retrospectiva com o Jira Service Management para criar e exportar com facilidade relatórios de análise retrospectiva, junto dos cronogramas de incidentes associados, para o Confluence para que os respondentes possam continuar colaborando com equipes multifuncionais para rastrear ações de acompanhamento e evitar incidentes semelhantes no futuro.

Funções e responsabilidades

As funções e as responsabilidades variam de acordo com a cultura da empresa, tamanho da equipe, cronogramas de plantão e muito mais. Algumas funções comuns de incidentes graves incluem:

Gerenciador de incidentes: a pessoa responsável por supervisionar a resolução do incidente.

Líder técnico: um profissional de tecnologia de nível sênior encarregado de descobrir o que está quebrado e por que, determinar o melhor curso de ação e dirigir a equipe de tecnologia.

Gestor de comunicações: um profissional de comunicações (geralmente das equipes de RP ou suporte ao cliente) responsável pela comunicação com clientes internos e externos afetados pelo incidente. 

Lead de suporte ao cliente: a pessoa encarregada de garantir que os tickets recebidos, telefonemas e tweets sobre o incidente receba uma resposta oportuna e apropriada.

Mídia social: um profissional de mídias sociais encarregado de comunicar o incidente nos canais sociais.

Outras funções comuns incluem: 

Analista de causa raiz ou gerente de problemas: pessoa responsável por ir além da resolução do incidente para identificar a causa raiz e quaisquer alterações que precisem ser feitas para evitar o item no futuro.

Conselho de investigação de incidentes graves: um grupo responsável pela investigação e gerenciamento de mudanças.

A solução de gerenciamento de incidentes do Jira Service Management ajuda em cada etapa do processo de resposta, da organização do cronograma de plantão e dos alertas até a unificação das equipes para melhor colaboração até a análise retrospectiva de incidentes.