Gerenciamento de Incidentes
Escrito por Andrew Stribblehill
Editado por Kavita Guliani
O gerenciamento eficaz de incidentes é fundamental para limitar a interrupção causada por um incidente e restaurar as operações normais de negócios o mais rápido possível. Se você não analisou antecipadamente sua resposta a possíveis incidentes, o gerenciamento de incidentes pode ir pela janela em situações da vida real.
Este capítulo apresenta um retrato de um incidente que foge do controle devido a práticas de gerenciamento de incidentes ad hoc, descreve uma abordagem bem gerenciada para o incidente e analisa como o mesmo incidente pode ter ocorrido se tratado com um gerenciamento de incidentes que funcione bem.
Incidentes não gerenciados
Coloque-se no lugar de Mary, a engenheira de plantão na “The Firm”. São 14h de uma quinta-feira e seu pager acabou de explodir. O monitoramento de caixa preta informa que seu serviço parou de atender a qualquer tráfego em um datacenter inteiro. Com um suspiro, você largou o café e começou a consertá-lo. Após alguns minutos de execução da tarefa, outro alerta informa que um segundo datacenter parou de funcionar. Então, o terceiro de seus cinco datacenters falha. Para agravar a situação, há mais tráfego do que os datacenters restantes podem suportar, então eles começam a sobrecarregar. Antes que você perceba, o serviço está sobrecarregado e sem capacidade de atender a quaisquer solicitações.
Você fica olhando para os logs no que parece ser uma eternidade. Milhares de linhas de log sugerem que há um erro em um dos módulos atualizados recentemente, então você decide reverter os servidores para a versão anterior. Quando observa que o rollback não ajudou, você liga para Josephine, que escreveu a maior parte do código para o serviço que está com problemas. Lembrando que são 3h30 no fuso horário dela, ela concorda em fazer login e dar uma olhada. Seus colegas Sabrina e Robin começam a mexer em seus próprios terminais. “Só estou dando uma olhada”, dizem eles.
Agora, um dos processos acionou seu chefe, que furiosamente exige saber por que não foi informado sobre o “colapso total deste serviço essencial para os negócios”. De forma independente, os VPs estão importunando você para um ETA – Estimated Time of Arrival ou, em português claro, quando as coisas voltarão ao normal – perguntando repetidamente: “Como isso pode ter acontecido?” Você compreenderia a situação, mas isso exigiria um esforço cognitivo que você está reservando para fazer o seu trabalho. Os VPs contam com sua experiência anterior em engenharia e fazem comentários irrelevantes, mas difíceis de refutar, como “Aumente o tamanho da página!”
O tempo passa; os dois datacenters restantes falham completamente. Sem que você saiba, Josephine, perturbada pelo sono, ligou para Malcolm. Ele teve uma ideia: algo sobre afinidade com a CPU. Ele tinha certeza de que poderia otimizar os processos restantes do servidor se pudesse apenas implementar essa mudança simples no ambiente de produção, então o fez. Em segundos, os servidores foram reiniciados, levando à alteração esperada. E então morreram.
A anatomia de um incidente não gerenciado
Note que todos no cenário anterior estavam fazendo seu trabalho, como o observavam. Como as coisas podem dar tão errado? Mas alguns perigos comuns fizeram com que esse incidente saísse do controle.
Foco nítido no problema técnico
Temos a tendência de contratar pessoas como Maria por suas proezas técnicas. Portanto, não é surpreendente que ela estivesse ocupada fazendo alterações operacionais no sistema, tentando corajosamente resolver o problema. Ela não estava em posição de pensar sobre o panorama geral de como mitigar o problema porque a tarefa técnica em mãos era pesada o suficiente.
Falta de clareza na comunicação
Pelo mesmo motivo, Mary estava ocupada demais para se comunicar com clareza. Ninguém sabia quais ações seus colegas de trabalho estavam realizando. Os líderes de negócios ficaram irritados, os clientes ficaram frustrados e outros engenheiros que poderiam ter ajudado no debug ou correção do problema não foram acionados de forma eficaz.
Trabalho autônomo
Malcolm estava fazendo alterações no sistema com a melhor das intenções. No entanto, ele não coordenou com seus colegas de trabalho, nem mesmo com Mary, que era tecnicamente responsável pela solução de problemas. Suas alterações tornaram uma situação ruim muito pior.
Elementos do processo de gerenciamento de incidentes
Habilidades e práticas de gerenciamento de incidentes existem para canalizar as energias de indivíduos entusiasmados. O sistema de gerenciamento de incidentes do Google é baseado no Incident Command System, que é conhecido por sua clareza e escalabilidade.
Um processo de gerenciamento de incidentes bem projetado possui os seguintes recursos:
Separação recursiva de responsabilidades
É importante garantir que todos os envolvidos no incidente reconheçam seu papel e não se desviem para o território de outra pessoa. De forma um tanto contraintuitiva, uma separação clara de responsabilidades permite aos indivíduos mais autonomia do que poderiam ter, uma vez que não precisam questionar seus colegas.
Se a carga de um determinado membro se tornar excessiva, essa pessoa precisará solicitar ao líder de planejamento mais funcionários. Eles devem, então, delegar trabalho a outras pessoas, uma tarefa que pode envolver a criação de subincidentes. Como alternativa, um líder de função pode delegar componentes do sistema a colegas, que relatam informações de alto nível aos líderes.
Várias funções distintas devem ser delegadas a indivíduos específicos:
Comando de incidente
O comandante do incidente mantém o estado de alto nível sobre o incidente. Eles estruturam a força-tarefa de resposta a incidentes, atribuindo responsabilidades de acordo com a necessidade e prioridade. De fato, o comandante ocupa todos os cargos que não delegou. Se apropriado, eles podem remover bloqueios que impedem o Ops de funcionar de maneira mais eficaz.
Trabalho operacional
O líder de operações trabalha com o comandante do incidente para responder ao incidente aplicando ferramentas operacionais à tarefa em questão. A equipe de operações deve ser o único grupo modificando o sistema durante um incidente.
Comunicação
Essa pessoa é a face pública da força-tarefa de resposta a incidentes. Suas funções definitivamente incluem a emissão de atualizações periódicas para a equipe de resposta a incidentes e partes interessadas (geralmente por e-mail), e podem se estender a tarefas como manter o documento do incidente preciso e atualizado.
Planejamento
A função de planejamento suporta o Ops lidando com problemas de longo prazo, como arquivamento e classificação de bugs, agrupamentos e transferência de ordens e rastreamento de como o sistema divergiu da norma para que possa ser revertido assim que o incidente for resolvido.
Emergência induzida por processo
As partes interessadas precisam entender onde podem interagir com o comandante do incidente. Em muitas situações, localizar os membros da força-tarefa do incidente em uma “Sala de Guerra” central designada é o mais apropriado. Outras equipes podem preferir trabalhar em suas mesas, mantendo-se em alerta para atualizações de incidentes por e-mail e IRC.
O Google descobriu que o IRC é uma grande vantagem na resposta a incidentes. O IRC é muito confiável e pode ser usado como um log de comunicações sobre este tipo evento, e tal registro é inestimável para manter em mente as alterações detalhadas de estado. Também escrevemos bots que registram o tráfego relacionado a incidentes (o que é útil para análises post-mortem) e outros que registram eventos, como alertas para o canal. O IRC também é um meio conveniente onde equipes distribuídas geograficamente podem se coordenar.
Documento vivo do estado de incidente
A responsabilidade mais importante do comandante do incidente é manter um documento vivo do incidente. Este pode constar em uma wiki, mas idealmente deve ser editável por várias pessoas ao mesmo tempo. A maioria de nossas equipes usa o Google Docs, embora o Google Docs SRE use o Google Sites: afinal, dependendo do software que você está tentando consertar como parte do seu sistema de gerenciamento de incidentes, é improvável que termine bem.
Consulte no Apêndice C, em “Exemplo de documento de estado de incidente”, para obter um exemplo de documento de incidente. Este documento vivo pode ser bagunçado, mas deve ser funcional. Usar um modelo facilita a geração desta documentação e manter as informações mais importantes no topo a torna mais utilizável. Guarde esta documentação para análise post-mortem e, se necessário, para meta-análise.
Transferências claras e imediatas
É essencial que o posto de comandante do incidente seja claramente transferido ao final de um dia de trabalho. Se você estiver transferindo o comando para alguém em outro local, pode atualizar de forma simples e segura o novo comandante de incidente por telefone ou por uma chamada de vídeo. Uma vez que o novo comandante de incidente seja totalmente informado, o comandante que está de saída deve ser explícito em sua transferência, especificamente afirmando: “Você agora é o comandante do incidente, ok?”. E não deve deixar a ligação até receber uma confirmação clara da transferência. A transferência deve ser comunicada a outras pessoas que trabalham no incidente para que fique claro quem está liderando os esforços de gerenciamento de incidentes em todos os momentos.
Um incidente gerenciado
Agora, vamos examinar como esse incidente poderia ter se desenrolado se fosse tratado usando os princípios de gerenciamento de incidentes.
São 14h e Mary está em seu terceiro café do dia. O tom áspero do pager a surpreende e ela engole a bebida. Problema: um datacenter parou de atender ao tráfego. Ela começa a investigar. Em breve, outro alerta é disparado e o segundo datacenter de cinco está fora de serviço. Por ser um problema que cresce rapidamente, ela sabe que se beneficiará com a estrutura de seu framework para gerenciamento de incidentes.
Mary aperta Sabrina. “Você pode assumir o comando?” Acenando com a cabeça, Sabrina rapidamente faz um resumo do que aconteceu até agora para Mary. Ela pega esses detalhes de um e-mail que envia para uma lista de mala direta previamente combinada. Sabrina reconhece que ainda não pode avaliar o impacto do incidente, então ela pede a avaliação de Mary. Mary responde: “Os usuários ainda não foram afetados; vamos apenas esperar não perder um terceiro datacenter.” Sabrina registra a resposta de Mary em um documento vivo do incidente.
Quando o terceiro alerta dispara, Sabrina o visualiza em meio à conversa de debug no IRC e rapidamente vai até o tópico do email com uma atualização. O tópico mantém os VPs informados sobre o status de alto nível sem alarmá-los com minúcias. Sabrina pede a um representante de comunicação externa para começar a redigir as mensagens de usuário. Ela então entra em contato com Mary para ver se devem entrar em contato com o desenvolvedor de plantão (atualmente Josephine). Recebendo a aprovação de Mary, Sabrina faz contato com Josephine.
No momento em que Josephine se conecta, Robin já se ofereceu para ajudar. Sabrina lembra a Robin e Josephine que devem priorizar qualquer tarefa delegada a eles por Mary, e que eles devem manter Mary informada de quaisquer ações adicionais que tomem. Robin e Josephine se familiarizam rapidamente com a situação atual lendo o documento do incidente.
A esta altura, Mary buscou o antigo release do binário e observou que estava em falta: ela então comunica o fato a Robin, que atualiza o IRC para dizer que essa tentativa de correção não funcionou. Sabrina cola essa atualização no documento vivo de gerenciamento de incidentes.
Às 17h, Sabrina começa a buscar substitutos para cuidar do incidente, pois ela e seus colegas estão prestes a voltar para casa. Ela atualiza o documento do incidente. Uma breve conferência telefônica ocorre às 5:45 para que todos estejam cientes da situação atual. Às 18h, eles transferem suas responsabilidades para os colegas seguintes que estarão disponíveis no escritório.
Mary retorna ao trabalho na manhã seguinte e descobre que seus colegas transatlânticos assumiram a responsabilidade pelo bug, mitigaram o problema, encerraram o incidente e começaram a trabalhar no postmortem. Problema resolvido, ela prepara um pouco de café quentinho e se recompõe para planejar melhorias estruturais a fim de que problemas desta categoria não afetem a equipe novamente.
Quando declarar um incidente
É melhor declarar um incidente com antecedência e, em seguida, encontrar uma solução simples para encerrar o incidente do que ter que transformar o framework de gerenciamento de incidentes em um problema crescente. Defina condições claras para declarar um incidente. Minha equipe segue essas diretrizes gerais – se alguma das afirmações a seguir for verdadeira, o evento é um incidente:
- Você precisa envolver uma segunda equipe para resolver o problema?
- A interrupção é visível para os clientes?
- O problema não foi resolvido mesmo depois de uma análise concentrada de uma hora?
A proficiência em gerenciamento de incidentes se atrofia rapidamente quando não está em uso constante. Então, como os engenheiros podem manter suas habilidades de gerenciamento de incidentes atualizadas – vulgo lidar com mais incidentes? Felizmente, o framework para gerenciamento de incidentes pode ser aplicado a outras mudanças operacionais que precisam abranger fusos horários e/ou equipes. Se você usa o framework com frequência como parte regular dos procedimentos de gerenciamento de mudanças, pode facilmente seguir este framework quando ocorrer um incidente real. Se sua organização realiza testes de recuperação de desastres (o que deveria fazer, é divertido), o gerenciamento de incidentes deve fazer parte desse processo de teste. Com frequência encenamos a resposta a um problema de plantão que já foi resolvido, talvez por colegas em outro local, para nos familiarizarmos ainda mais com o gerenciamento de incidentes.
Resumindo
Descobrimos que, ao formular uma estratégia de gerenciamento de incidentes com antecedência, estruturar esse plano para escalar sem problemas e colocar o plano em uso regularmente, fomos capazes de reduzir nosso tempo médio de recuperação e fornecer à equipe uma maneira menos estressante de trabalhar em problemas emergentes. Qualquer organização preocupada com a confiabilidade de seus sistemas se beneficiaria com uma estratégia semelhante.
Melhores práticas para gerenciamento de incidentes
Priorize. Interrompa o sangramento, restaure o serviço e preserve as evidências da causa raiz.
Prepare. Desenvolva e documente seus procedimentos de gerenciamento de incidentes com antecedência, em consulta com os participantes do incidente.
Confie. Dê autonomia total dentro da função atribuída a todos os participantes do incidente.
Faça uma introspecção. Preste atenção ao seu estado emocional enquanto responde a um incidente. Se você começar a se sentir sobrecarregado ou em pânico, peça mais apoio.
Considere alternativas. Considere periodicamente suas opções e reavalie se ainda faz sentido continuar o que você está fazendo ou se você deve adotar outra abordagem na resposta a incidentes.
Pratique. Use o processo rotineiramente para que se torne uma segunda natureza no dia a dia.
Influencie o seu redor. Você foi o comandante do incidente da última vez? Assuma uma função diferente na próxima vez. Incentive cada membro da equipe a adquirir familiaridade com cada função.
Fonte: Google SRE Book