Respondendo a um incidente

Principais aprendizados: o processo de resposta a incidentes da Atlassian ocorre em dez etapas — detectar, criar, abrir comunicações, avaliar, enviar comunicações iniciais, escalonar, delegar, enviar comunicações de acompanhamento, revisar, resolver —, conduzido por um gerenciador de incidentes desde o momento em que um ticket é registrado até o fim do impacto nos negócios.

• O que é: um esquema tático repetível baseado em um ticket de incidente do Jira como a fonte de informações, um canal de bate-papo e uma ponte de vídeo com o mesmo nome, um documento compartilhado de estado do incidente, níveis de gravidade que definem quem é acionado e o Statuspage para comunicações internas e externas.

• Por que é importante: um comando claro, canais nomeados e uma linha do tempo por escrito são o que mantêm a resposta coordenada sob pressão e dão ao post-mortem uma base para trabalhar.

• Como o Jira Service Management ajuda: ele apresenta registros de incidentes, alertas de plantão e escalonamento, integração de bate-papo e vídeo e links para o Statuspage e post-mortem, para que o processo seja executado em uma única plataforma.

As seções a seguir descrevem o processo da Atlassian para responder a incidentes. O gerenciador de incidentes (GI) segue esta série de etapas para conduzir o incidente desde a detecção até a resolução. Cada etapa abaixo é uma seção independente. Juntas, elas formam o esquema tático que os gerenciadores de incidentes da Atlassian seguem.

Detecção

As pessoas da sua empresa podem tomar conhecimento de incidentes de várias maneiras. Elas podem ser alertadas por meio de monitoramento, relatos de clientes ou observação própria. No entanto, quando ocorre um incidente, o primeiro passo da equipe é registrar um ticket de incidente (no caso, um item do Jira). 

A gente usa URLs curtas e fáceis de lembrar que redirecionam a equipe da Atlassian para o portal interno do Jira Service Management. A equipe da Atlassian pode verificar se um incidente já está em andamento visualizando um painel do Jira ou uma macro do Jira no Confluence. As equipes, como as equipes de suporte ao cliente da Atlassian, têm painéis configurados em locais conhecidos para monitorar os incidentes em andamento.

Nós preenchemos os campos a seguir para cada incidente:

Depois que o incidente é criado, sua chave de item é usada em todas as comunicações internas sobre ele.

Os clientes costumam abrir casos de suporte sobre incidentes que os afetam. Assim que as equipes de suporte ao cliente determinam que todos esses casos estão relacionados a um incidente, elas rotulam esses casos com a chave do item do incidente para monitorar o impacto no cliente e facilitar o contato com os clientes afetados quando o incidente for resolvido.

Criar um novo incidente

Quando o item do incidente tiver sido criado, mas ainda não tiver sido designado a um Gestor de incidentes (IM), ele permanece no estado novo. Este é o status inicial no nosso fluxo de trabalho de incidentes do Jira.

Temos um serviço que usa webhooks Jira para disparar um alerta de página quando é criado um novo incidente grande. Isto alerta um IM de plantão, com base no serviço que foi selecionado. Por exemplo, um incidente com o Bitbucket chama um gerente de incidentes do Bitbucket. Também tempos uma lista global de gestores de incidentes grandes, conhecida como "gestor de incidentes de plantão" ou IMOC.

O alerta de página inclui a chave de item do incidente, a gravidade e o resumo, que contam ao gestor de incidentes onde começar a gerenciar o incidente (o item Jira), o que está errado em geral e qual a gravidade.

Comunicação aberta

A primeira coisa que o GI faz ao ficar on-line é atribuir o item de incidente a si mesmo e colocar o item para no estado em correção . O campo de responsável pelo item do Jira também mostra quem é o GI atual. Em uma resposta a emergências, é muito importante deixar claro quem está no comando, por isso a gente é bem rigoroso em garantir que este campo esteja correto. 

Em seguida, o GI configura os canais de comunicação da equipe de incidentes. A meta neste momento é estabelecer e concentrar todas as comunicações da equipe de incidentes em locais conhecidos. A gente costuma usar três métodos de comunicação da equipe, cada um representado por um campo no item do Jira, para cada incidente:

• Sala de bate-papo no Slack ou outro serviço de mensagens. Elas permitem que a equipe se comunique, compartilhe observações, links e capturas de tela de forma preservada e com registro de data e hora. Dar ao canal de bate-papo o mesmo nome da chave do item (por exemplo, HOT-1234) torna mais fácil para as pessoas que precisam se envolver entrar na conversa. 

• Chat de vídeo em um app de conferência, como o Skype, Blue Jeans ou semelhante; ou se vocês estiverem no mesmo local, reúna a equipe em uma sala. Nós acreditamos que a comunicação presencial ajuda as equipes a trabalharem para descobrir coisas mais rápido e com menos idas e vindas.

• Uma página do Confluence chamada de "documento de declaração do incidente". Quando as pessoas editam a mesma página simultaneamente, elas podem ver quais informações foram reunidas em tempo real. Esta é uma excelente forma de acompanhar as mudanças (por exemplo, uma tabela de quem mudou o quê, quando, como, porquê, como reverter, etc.), vários fluxos de trabalho ou uma linha do tempo estendida. Um documento de declaração do incidente é muito útil como fonte de verdade durante incidentes complexos e extensos.

A gente descobriu que usar tanto o bate-papo por vídeo quanto as salas de bate-papo funciona melhor durante um incidente, pois ambos são otimizados para coisas diferentes. O bate-papo por vídeo é excelente para criar com rapidez uma visão mental compartilhada do incidente por meio de discussões em grupo, enquanto o bate-papo por texto é ótimo para manter um registro com data e hora do incidente, links compartilhados para painéis, capturas de tela e outras URLs.

Esses métodos também podem ser usados para registrar observações importantes, mudanças e decisões que acontecem em conversas não gravadas. O GI ou qualquer pessoa na equipe do incidente registra fazendo observações, mudanças e decisões na sala de bate-papo dedicada conforme acontecem em tempo real. Tudo bem se parece que as pessoas estão falando com elas mesmas! Essas observações são muito valiosas durante a análise retrospectiva quando as equipes precisam reconstruir a linha do tempo do incidente e descobrir o que o causou. 

A maioria dos sistemas de chat possui uma função de assunto da sala. O IM atualiza o assunto da sala com informações sobre o incidente e links úteis, incluindo:

• O resumo e a gravidade do incidente.

• Quem está em qual função, começando pelo IM.

• Links para o item do incidente, a sala de chat de vídeo e o documento de declaração do incidente.

Dessa forma, qualquer pessoa com a chave do item do incidente pode entrar no bate-papo e acelerar o incidente (lembre-se que a gente nomeou o canal do bate-papo com base na chave do item do incidente, p. ex., HOT-1234).

Por último, o GI define o próprio status pessoal do bate-papo para a chave do item do incidente que ele está gerenciando. Essa ação permite que os colegas saibam que ele está ocupado gerenciando um incidente. 

Avaliar

Depois que os canais de comunicação da equipe do incidente estiverem definidos, é hora de avaliar o incidente para que a equipe possa decidir o que contar às pessoas sobre ele e quem precisa fazer a correção. 

Veja abaixo as perguntas que os GIs fazem às equipes: 

• Qual é o impacto para os clientes (internos e externos)?

• O que os clientes estão vendo?

• Quantos clientes foram afetados (alguns, todos)?

• Quando começou?

• Quantos casos de suporte os clientes abriram?

• Existem outros fatores, p. ex., Twitter, segurança ou perda de dados?

Agora é um bom momento para começar a adicionar à linha do tempo do incidente. Registre as observações da equipe para que as pessoas que entrarem possam se atualizar. Essas informações também vão ser importantes mais adiante no processo de post-mortem. Não deixe de observar se o horário de início do incidente corresponde a uma alteração (por exemplo, uma implantação do Bamboo) para que a alteração possa ser revertida para talvez resolver o incidente.

Com base no impacto do incidente e na quantidade de trabalho que as equipes acreditam que vai ser necessário para resolver, a gente atribui itens com um dos seguintes níveis de gravidade: 

Depois de estabelecer o impacto do incidente, ajuste ou confirme a gravidade do item do incidente e comunique a gravidade à equipe. Descobrimos que enumerar o nível é muito benéfico para comunicar com clareza a gravidade.

Na Atlassian, os incidentes de gravidade 3 são transmitidos às equipes de fornecimento para serem resolvidos durante o horário comercial, enquanto os de gravidade 1 e 2 exigem a chamada de membros da equipe para correção imediata. A diferença na resposta entre a gravidade 1 e 2 é mais sutil e depende do serviço afetado.

A matriz de gravidade deve ser documentada e acordada entre todas as equipes, para ter uma resposta consistente aos incidentes com base no impacto do cliente.

Enviar comunicação inicial

Quando você está razoavelmente confiante que o incidente é real, deseja comunicá-lo internamente e externamente assim que possível. O objetivo da comunicação interna inicial é focar a resposta do incidente 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. A comunicação rápida e precisa dos incidentes ajuda a construir confiança com a sua equipe e os clientes.

Usamos o Statuspage para comunicar incidentes, tanto interna quanto externamente. Nós temos páginas de status separadas para a equipe da interna da empresa e os clientes externos. Nós discutiremos mais sobre como usar cada uma delas mais tarde, mas no momento, o objetivo é fazer as comunicações da forma mais rápida possível. Para isto, nós seguimos estes templates:

Além de criar um incidente no Statuspage, enviamos um e-mail para uma lista de distribuição de comunicações sobre incidentes que inclui nosso líder de engenharia, os gestores de incidentes grandes e outros agentes interessados. Este e-mail tem o mesmo conteúdo do incidente do Statuspage interno. O e-mail permite que os agentes respondam e façam perguntas, enquanto o Statuspage é uma comunicação mais unilateral.

Observe que a gente sempre inclui a chave do item do Jira do incidente em todas as comunicações internas sobre o incidente, para que os agentes saibam em qual sala de bate-papo entrar para fazer mais perguntas.

Escalonar

Você assumiu o comando do incidente, estabeleceu comunicações à equipe, avaliou a situação e contou aos agentes e clientes que o incidente está em andamento. O que vem depois?

Seus primeiros respondentes podem ser suficientes para resolver o incidente, mas geralmente você precisará chamar outras equipes para o incidente. Nós chamamos isto de escalonamento.

O sistema principal nesta etapa é uma ferramenta de alerta e escala de chamadas como o OpsGenie. O Opsgenie e sistemas similares permitem que você defina escalas de plantão para que qualquer equipe tenha uma rotação ou agentes que devem ser contactáveis para responder a uma emergência. Isto é superior à necessidade de ter uma pessoa específica o tempo todo ("chame o Bob de novo"), porque as pessoas nem sempre estarão disponíveis (elas tendem a sair de férias de vez em quando, mudar de função ou se estressar quando você as chama com muita frequência). Também é superior aos "melhores esforços" de plantão, porque fica claro quais pessoas são responsáveis por responder.

Sempre inclua a chave de item Jira do incidente em um alerta de chamada sobre o incidente. Esta é a chave que a pessoa que recebe o alerta usa para entrar na sala de chat do incidente.

Delegar

Depois de escalar alguém e esta pessoa ficar online, o IM delega uma função a ela. Contanto que ela entenda o que é exigido da função, ela poderá trabalhar de forma rápida e eficaz como parte da equipe do incidente.

As funções que usamos na Atlassian são:

• Gerenciador de incidentes, descrito na página Visão geral.

• Líder de tecnologia, um respondente técnico sênior. Responsável por desenvolver teorias sobre o que está com problema e porquê, decidindo as mudanças e liderando a equipe técnica. Trabalha estreitamente com o IM.

• Gestor de comunicações, uma pessoa familiarizada com as comunicações públicas, possivelmente da equipe de suporte ao cliente ou relações públicas. Responsável por escrever e enviar comunicações internas e externas sobre o incidente.

Usamos o tópico da sala de chat para mostrar quem está atualmente em qual função e ele é atualizado se as funções mudarem durante um incidente.

O IM também pode criar e delegar funções conforme a necessidade do incidente, por exemplo, vários líderes de tecnologia se mais de um fluxo de trabalho estiver em andamento ou gestores diferentes de comunicação interna e externa.

Em incidentes grandes ou complicados, é aconselhável incluir outro gerenciador de incidentes qualificado como um backup de "verificação de sanidade" para o GI. Ele pode focar em tarefas específicas que liberam o GI, como manter a linha do tempo.

Enviar comunicação de acompanhamento

Você já enviou as comunicações iniciais, mas depois que a equipe do incidente estiver montada, você precisa atualizar os agentes e os clientes sobre o incidente.

Atualizar a equipe interna é importante porque cria uma verdade compartilhada e consistente sobre o incidente. Quando algo dá errado, as informações são escassas, em especial nos estágios iniciais, e se você não estabelecer uma fonte confiável de informações sobre o que aconteceu e como está respondendo, as pessoas tendem a tirar as próprias conclusões. 

Para comunicações internas, nós seguimos este padrão:

• Nos comunicamos através do nosso Statuspage interno e por e-mail, conforme descrito em "Comunicações iniciais" acima.

• Use a mesma convenção para formatação do nome do incidente e do assunto do e-mail.

• Abrimos com um resumo de 1 a 2 frases sobre o estado atual e o impacto.

• Uma seção "Status atual" com 2 a 4 marcadores de texto.

• Uma seção "Próximas etapas" com 2 a 4 marcadores de texto.

• Declaramos quando e onde a próxima rodada de comunicações será enviada.

A gente usa esta lista de verificação para revisar se as comunicações estão completas: 

• Qual é o impacto real para os clientes?

• Quantos clientes internos e externos foram afetados?

• Se a causa-raiz é conhecida, qual é?

• Se existe um ETA para restauração, qual é?

• Quando e onde será a próxima atualização?

Incentivamos nossos gestores de incidentes a serem explícitos sobre coisas desconhecidas em suas comunicações internas. Isto reduz as incertezas. Por exemplo, se você ainda não sabe qual é a causa-raiz, é muito melhor dizer "a causa-raiz ainda é desconhecida" do que simplesmente omitir mencioná-la.

Atualizar os clientes externos é importante porque ajuda a gerar confiança. Mesmo que sejam afetados, eles vão poder seguir com outras coisas desde que saibam que você vai mantê-los atualizados.

Para as comunicações externas, basta a gente atualizar o incidente aberto no Statuspage externo em uma etapa anterior, alterando seu status conforme apropriado. A gente tenta manter as atualizações "curtas e diretas" porque os clientes externos não estão interessados nos dados técnicos do incidente, eles só querem saber se já foi resolvido e, caso contrário, quando vai ser resolvido. Em geral, 1 a 2 frases são suficientes.

A comunicação de incidentes é uma arte e quanto mais prática tiver, melhor você será . No nosso treinamento de gestor de incidentes, nós encenamos um incidente hipotético, fazemos rascunhos das comunicações e as lemos para o resto da classe. Esta é uma boa forma de construir esta habilidade antes de fazê-la de verdade. Também é sempre uma boa ideia pedir que alguém revise suas comunicações, para ter uma "segunda opinião", antes de enviá-las.

Análise

Não existe um processo prescritivo único que vai resolver todos os incidentes — se houvesse, a gente faria a automação e estaria tudo pronto. Em vez disso, a gente pode iterar o processo a seguir para fazer uma adaptação rápida a uma variedade de cenários de resposta a incidentes: 

• Observar o que está acontecendo. Compartilhar e confirmar as observações.

• Desenvolver teorias sobre por que está acontecendo. 

• Desenvolver experimentos que provem ou refutem essas teorias. Realizá-los.

• Repetir.

Por exemplo, você pode observar uma índice elevado de erros em um serviço correspondente a uma falha que o seu provedor de infraestrutura regional postou em seu Statuspage. Você pode criar uma teoria de que a falha é isolada a esta região, decidir fazer failover para outra região e observar os resultados.

Os maiores desafios para o IM neste momento envolvem manter a disciplina da equipe:

• A equipe está se comunicando de forma eficaz?

• Quais são as observações, teorias e fluxos de trabalho atuais?

• Estamos tomando decisões de forma eficaz?

• A gente está fazendo mudanças com intenção e cuidado? A gente sabe quais mudanças está fazendo?  

• As funções são claras? As pessoas estão fazendo seus trabalhos? Precisamos escalonar para mais equipes?

De qualquer forma, não entre em pânico — isso não ajuda. Mantenha a calma e o resto da equipe vai seguir o seu exemplo.

O IM precisa ficar de olho na fadiga da equipe e planejar transições. Uma equipe dedicada pode se arriscar a estressar-se ao resolver incidentes complexos - os IMs devem procurar saber por quanto tempo os membros estão acordados e por quanto tempo estão trabalho no incidente e decidir quem realizará as funções em seguida.

Resolver

Um incidente é resolvido quando o impacto atual ou iminente nos negócios estiver encerrado. Neste momento, a resposta emergencial é encerrada e a equipe muda para qualquer tarefa de limpeza e análise retrospectiva.

As tarefas de limpeza podem ser vinculadas e rastreadas facilmente como links do item do item Jira do incidente.

Na Atlassian, usamos os campos personalizados do Jira para rastrear o horário do início do impacto, o horário de detecção e o horário do final do impacto de cada incidente. Nós usamos estes campos para calcular o tempo de recuperação (TTR), que é o intervalo entre o início e o final, e o tempo até a detecção (TTD), que é o intervalo entre o início e a detecção. A distribuição do TTD e TTR do seu incidente geralmente é uma métrica de negócios importante.

Enviamos comunicações finais internas e externas quando o incidente estiver resolvido. As comunicações internas têm uma recapitulação do impacto e da duração do incidente, incluindo quantos casos de suporte foram criados e outras dimensões importantes do incidente e dizem de forma clara que o incidente foi resolvido e que não existirão mais comunicações sobre ele. As comunicações externas geralmente são breves, contando aos clientes que o serviço foi restaurado e nós os acompanharemos com uma autópsia.

Para saber como o Jira Service Management ajuda as equipes a executar cada etapa do processo de resposta — desde a centralização dos alertas e a organização da comunicação de incidentes até a unificação das equipes para melhor colaboração, até a execução de análise retrospectiva de incidentes para análise da causa raiz — siga o botão abaixo. 

Obtenha o manual em formato impresso ou PDF

Quantidade limitada de versões impressas do Manual de gerenciamento de incidentes com envio grátis ou baixe a versão em PDF.

Leia o manual