Fechar
Manual de incidentes da Atlassian

Respondendo a um incidente

Caution alert exclamation point

Respondendo a um incidente

As seções a seguir descrevem o processo da Atlassian para reagir aos incidentes. O Gestor de incidentes (IM) segue esta série de etapas para orientar o incidente, desde a detecção até a resolução.

Workflow of Atlassian incident response from new to fixing to resolved
Book illustration with a light bulb over it

Visão geral

Definindo incidentes e os valores relacionados a incidentes. Conheça as ferramentas corretas e as funções da equipe.

Illustration of different kinds of charts

Autópsia dos incidentes

Como executar uma autópsia sem culpa, identificar as causas-raiz e planejar o trabalho de remediação.

Detecção

As pessoas da sua empresa podem se conscientizar sobre os incidentes de várias maneiras. Elas podem ser alertadas pelo monitoramento, através de relatórios do cliente ou pela observação. Independentemente de como o incidente ocorra, a primeira etapa que a equipe segue é registrar um chamado para o incidente (no nosso caso, um item Jira). 

Nós usamos uma URL curta fácil de lembrar que redireciona a equipe da Atlassian para um portal interno do Jira Service Desk. A equipe da Atlassian pode verificar se já existe um incidente em andamento, observando o painel Jira ou uma macro Jira no Confluence. As equipes como nossas equipes de suporte ao cliente possuem painéis configurados em locais conhecidos para monitorar os incidentes em andamento.

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

Campo Jira

Tipo

Texto de ajuda

Resumo

Texto

Qual é a emergência?

Description

Texto

Qual é o impacto para o cliente? Inclua seus detalhes de contato para que os respondentes possam falar com você.

Gravidade

Seleção única

(Hiperlink para uma página do Confluence com nossa escala de gravidade) Escolher a Grav. 2 ou 1 significa que você acha que isto deve ser resolvido imediatamente - pessoas serão chamadas.

Serviço com falha

Seleção única

O serviço que tem a falha que está causando o incidente. Use seu melhor palpite se não tiver certeza. Selecione "Desconhecido" se não tiver ideia.

Produtos afetados

Caixas de seleção

Quais produtos são afetados por este incidente? Selecione os que se aplicam.

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

Os clientes abrirão casos de suporte com frequência sobre um incidente que os afeta. Depois que as equipes de suporte ao cliente determinarem que todos estes casos estão relacionados a um incidente, elas rotulam estes casos com a chave de item do incidente para poder rastrear o impacto no cliente e acompanhar com mais facilidade os clientes afetados quando o incidente é 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 IM faz quando fica online é designar o item do incidente a ele mesmo e mudar o item para o estado corrigindo. O campo de destinatário do Item Jira também mostra quem é o IM atual. Em uma resposta emergencial, é muito importante deixar claro quem está no comando, então somos muito rígidos quando à garantia de 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 chat no Slack ou outro serviço de mensagens. Isto permite que a equipe se comunique, compartilhe observações, links e capturas de tela de forma preservada, mantendo a data e hora. Dar ao canal de chat o mesmo nome da chave de item (ex. HOT-1234) torna mais fácil para as pessoas que precisam estar envolvidas para participar da 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.

Estes métodos também podem ser usados para gravar observações, mudanças e decisões importantes que acontecem nas conversas não gravadas. O IM ou qualquer pessoa na equipe do incidente faz isto simplesmente anotando as observações, mudanças e decisões na sala de chat dedicada à medida que elas ocorrem em tempo real. Tudo bem se parecer que as pessoas estão falando sozinhas! Estas anotações são incrivelmente valiosas durante a autópsia, 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 IM define seu próprio status pessoal do chatpara a chave de item do incidente que ele está gerenciando. Isto permite que seus colegas saibam que eles estão ocupados 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 corrigi-lo. 

Temos o seguinte conjunto de perguntas que os IMs fazem às suas 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 nossas equipes acreditam que levará para resolver, atribuímos itens com um dos níveis de gravidadea seguir: 

Gravidade

Description

Examples

1

Um incidente crítico com impacto muito alto

  • Um serviço voltado para o cliente, como o Jira Cloud, está indisponível a todos os clientes

  • A confidencialidade ou privacidade foi violada.

  • Perda de dados do cliente.


2

Um incidente grande com impacto significativo

  • Um serviço voltado para o cliente está indisponível a um subconjunto de clientes

  • Funcionalidade principal (p. ex., git push, criação de item) foi afetada significativamente.

3

Um incidente menor com impacto baixo

  • Uma pequena inconveniência aos clientes, com uma solução alternativa disponível.

  • Degradação do desempenho de uso.

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.

Sua matriz de gravidade deve ser documentada e acordada entre todas as suas 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 modelos:

 

Statuspage interna

Statuspage externa

Nome do incidente

<Chave de item do incidente> - <Gravidade> - <Resumo do incidente>

Investigando problemas com o <produto>

Mensagem

Estamos investigando um incidente que afeta o <produto x>, <produto y> e <produto z>. Forneceremos atualizações por e-mail e pelo Statuspage em breve.

Estamos investigando problemas com o <produto> e forneceremos atualização aqui em breve.

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 nós sempre incluímos a chave de item Jira do incidente em todas as comunicações internas sobre o incidente, para que os agentes saibam em qual sala de chat 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:

  • Gestor 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 consistência sobre o incidente. Quando algo dá errado, as informações são escassas, especialmente durante os estágios iniciais e se você não estabelecer uma fonte de verdade confiável sobre o que ocorreu e como você está respondendo a isso, 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 (<Chave de item do incidente> - <Gravidade> - <Resumo do incidente>)

  • 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.

Usamos 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 resolverá todos os incidentes - se houvesse, nós simplesmente iríamos automatizá-lo e pronto. Em vez disso, podemos iterar o processo a seguir para adaptá-lo rapidamente a uma variedade de cenários de resposta a incidentes. 

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

  • Desenvolver teorias sobre o 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?

  • Estamos fazendo mudanças intencionalmente e com cuidado? Nós sabemos quais mudanças estamos 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 autópsia.

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.

Book illustration with a light bulb over it

Visão geral

Definindo incidentes e os valores relacionados a incidentes. Conheça as ferramentas corretas e as funções da equipe.

Illustration of different kinds of charts

Autópsia dos incidentes

Como executar uma autópsia sem culpa, identificar as causas-raiz e planejar o trabalho de remediação.

Está procurando uma ferramenta para auxiliar na execução de um processo de gerenciamento de incidentes?