Respondendo a um incidente

Detecção

As pessoas da sua empresa podem tomar conhecimento de incidentes de várias maneiras. Elas podem ser alertadas pelo monitoramento, por meio de relatórios do cliente ou pela observação. Não importa como o incidente ocorra, a primeira etapa que a equipe segue é registrar um ticket para o incidente (para a gente, um item do Jira).

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 ação que o GI faz quando fica on-line é atribuir o item do incidente a ele mesmo e mudar o item para o estado corrigindo. O campo do responsável pelo item no Jira também mostra quem é o GI atual. Em uma resposta emergencial, é muito importante deixar claro quem está no comando, então a gente é muito rígido quanto à garantia da precisão deste campo.

A seguir, o IM define os canais de comunicação da equipe do incidente. O objetivo neste momento é estabelecer e focar todas comunicações da equipe de incidentes em lugares conhecidos. Nós geralmente usamos três métodos de comunicação de equipe, cada um deles representado por um campo no item Jira, para cada incidente:

• Sala de bate-papo no Slack ou em outro serviço de mensagens. Permite que a equipe se comunique, compartilhe observações, links e capturas de tela de um jeito preservado, mantendo a data e hora. Dar ao canal de bate-papo o mesmo nome da chave do item (por exemplo, HOT-1234) facilita para as pessoas que precisam estar envolvidas 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.

Descobrimos que usar tanto chat de vídeo quanto salas de chat funciona melhor durante um incidente, já que ambos são otimizados para coisas diferentes. O chat de vídeo se destaca na criação de uma imagem mental compartilhada do incidente rapidamente pela discussão do grupo, enquanto o chat de texto é ótimo para manter um registro com data e hora do incidente, links compartilhados de 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 um recurso 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.

Isto permite que qualquer pessoa com a chave de item do incidente entre no chat e acelere o incidente (lembre-se que nós nomeamos o canal do chat com base na chave de 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 é uma boa hora para começar a escrever na linha do tempo do incidente. Registre os observações da equipe para que as pessoas que estão entrando possam acelerar o processo. Isto também é importante depois, no processo de autópsia. Certifique-se de observar se o horário de início do incidente corresponde a uma mudança (por exemplo, uma implementação do Bamboo) para que a mudança possa ser revertida para possivelmente 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:

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 modelos:

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 trazer outro gestor de incidentes qualificado como backup de "verificação de integridade" para o IM. Eles podem focar em tarefas específicas que libertem o IM, como alimentar 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 os agentes internos é importante, porque cria uma verdade compartilhada com uniformidade sobre o incidente. Quando algo dá errado, as informações são escassas, em especial durante os estágios iniciais, e se você não estabelecer uma fonte confiável de informações sobre o que ocorreu e como você está respondendo, as pessoas tendem a tirar suas 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.
• Usamos a mesma convenção para o formato do nome do incidente e 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 construir a confiança. Embora eles possam ser afetados, eles poderão fazer outras coisas, contanto que saibam que você os manterá atualizados.

Para as comunicações externas , simplesmente atualizamos o incidente que abrimos no Statuspage externo anteriormente, mudando seu status conforme adequado. Nós tentamos manter as atualizações "curtas e gentis", porque os clientes externos não estão interessados nos detalhes técnicos do incidente; eles apenas querem saber se ele já foi corrigido ou quando será corrigido. Geralmente, 1 ou 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 - isto não ajuda. Fique calmo e o resto da equipe irá se inspirar em você.

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.