Capítulo 9 - Resposta a Incidentes

Escrito por: Jennifer Mace, Jelena Oertel, Stephen Thorne,

E Arup Chakrabarti (PagerDuty)

com Jian Ma e Jessie Yang

Todos querem que os seus serviços funcionem sempre sem problemas, mas vivemos em um mundo imperfeito em que ocorrem interrupções. O que acontece quando um problema não tão comum e urgente requer vários indivíduos ou equipes para resolvê-lo? De repente, você se depara com o gerenciamento simultâneo da resposta ao incidente e a resolução do problema.

Resolver um incidente significa mitigar o impacto e/ou restaurar o serviço à sua condição anterior. Gerenciar um incidente significa coordenar os esforços das equipes de resposta de maneira eficiente e garantir que a comunicação flua tanto entre os respondentes quanto com os interessados no progresso do incidente. Muitas empresas de tecnologia, incluindo o Google, adotaram e adaptaram as melhores práticas de gestão de incidentes de organizações de resposta a emergências, que usam essas práticas há muitos anos.

A premissa básica da gestão de incidentes é responder a um incidente de uma forma estruturada. Incidentes em grande escala podem ser confusos; uma estrutura em que as equipes concordem antecipadamente pode reduzir o caos. A formulação de regras sobre como comunicar e coordenar os seus esforços antes da ocorrência de um desastre permite que sua equipe se concentre em resolver um incidente quando ele ocorrer. Se sua equipe já praticou e se familiarizou com comunicação e coordenação, eles não precisam se preocupar com esses fatores durante um incidente.

Configurar um processo de resposta a incidentes não precisa ser uma tarefa assustadora. Há vários recursos amplamente disponíveis que podem fornecer algumas orientações, como Gerenciar incidentes no primeiro Livro do SRE. Os princípios básicos da resposta a incidentes incluem o seguinte:

Manter uma linha de comando clara.
Designar papéis claramente definidos.
Manter um registro de trabalho de depuração e mitigação à medida que se avança.
Declarar incidentes cedo e com frequência.

Este capítulo mostra como o gerenciamento de incidentes é configurado no Google e no PagerDuty e dá exemplos de onde acertamos e onde não acertamos esse processo. A lista de verificação simples em “Colocando em prática as melhores práticas” pode ajudar você a começar a criar sua própria prática de resposta a incidentes, caso ainda não tenha uma.

Gerenciamento de incidentes no Google

A resposta a incidentes fornece um sistema para responder e gerenciar um incidente. Uma estrutura e um conjunto de procedimentos definidos permitem que uma equipe responda a um incidente de forma eficaz e amplie sua resposta. O sistema de resposta a incidentes da Google baseia-se no Sistema de Comando de Incidentes (SCI).

Sistema de Comando de Incidentes

O SCI foi criado em 1968 pelos bombeiros como forma de gerir os incêndios florestais. Esta estrutura fornece formas padronizadas de comunicar e preencher papéis claramente especificados durante um incidente. Com base no sucesso do modelo, as empresas adaptaram mais tarde o SCI para responder a falhas informáticas e de sistema. Este capítulo explora duas dessas estruturas: o processo de resposta a incidentes do PagerDuty e o gerenciamento de incidentes no Google (IMAG).

As estruturas de resposta a incidentes têm três objetivos comuns, também conhecidos como os “três Cs” (3Cs) de gestão de incidentes:

Coordenar o esforço de resposta.
Comunicar entre os responsáveis pela resposta a incidentes, dentro da organização, e com o mundo exterior.
Manter o controle sobre a resposta a incidentes.

Quando algo dá errado com a resposta a incidentes, o culpado provavelmente está em uma dessas áreas. Dominar os 3Cs é essencial para uma resposta eficaz a incidentes.

Principais Funções na Resposta a Incidentes

Os principais papéis na resposta a incidentes são o Comandante do Incidente (CI), o Líder de Comunicações (LC), e o Líder de Operações ou de Ops (LO). O IMAG organiza esses papéis em uma hierarquia: o CI lidera a resposta ao incidente e o LC e o LO relatam ao CI.

Quando ocorre um desastre, a pessoa que declara o incidente normalmente assume a função de CI e dirige o estado de alto nível do incidente. O CI se concentra nos 3Cs e faz o seguinte:

Comanda e coordena a resposta a incidentes, delegando funções conforme necessário. Por padrão, o CI assume todas as funções que ainda não foram delegadas.
Comunica-se com eficiência.
Permanece no controle da resposta ao incidente.
Trabalha com outros respondentes para resolver o incidente.

O CI pode transferir seu papel para outra pessoa e assumir o papel de LO, ou atribuir o papel de LO a outra pessoa. O LO trabalha para responder ao incidente aplicando ferramentas operacionais para mitigar ou resolver o incidente.

Enquanto o CI e o LO trabalham na mitigação e resolução do incidente, o LC é a face pública da equipe de resposta a incidentes. As principais funções do LC incluem fornecer atualizações periódicas à equipe de resposta a incidentes e às partes interessadas e gerenciar consultas sobre o incidente.

Tanto o LC quanto o LO podem liderar uma equipe de pessoas para ajudar a gerenciar suas áreas específicas de resposta a incidentes. Essas equipes podem expandir ou contrair conforme necessário. Se o incidente se tornar pequeno o suficiente, a função LC pode ser incluída de volta na função CI.

Estudos de casos

Os quatro incidentes de grande escala a seguir ilustram como a resposta a incidentes funciona na prática. Três desses estudos de caso são do Google, e o último é um estudo de caso do PagerDuty, que fornece uma perspectiva de como outras organizações usam estruturas derivadas de SCI. Os exemplos do Google começam com um incidente que não foi gerenciado de forma eficaz e progridem para incidentes que foram bem gerenciados.

Estudo de caso 1: Bug de Software – Estar presente, mas desatento (Google)

Este exemplo mostra como não declarar um incidente antecipadamente pode deixar uma equipe sem as ferramentas para responder a um incidente de forma rápida e eficiente. Embora esse incidente tenha sido resolvido sem grandes calamidades, a escalação precoce teria produzido uma resposta mais rápida e organizada e um resultado melhor.

Contexto

O Google Home é um alto-falante inteligente e assistente doméstico que responde a comandos de voz. Os comandos de voz interagem com o software do Google Home, chamado Google Assistant.

A interação com o Google Home começa quando um usuário diz uma hotword, uma determinada frase que aciona o Google Assistant. Vários usuários podem usar o mesmo dispositivo Google Home treinando o assistent para ouvir uma determinada hotword. O modelo de hotword que identifica os falantes é treinado no cliente, mas os dados de treinamento (ou seja, os arquivos de reconhecimento do falante) são armazenados no servidor. O servidor lida com streaming bidirecional de dados. Para lidar com a sobrecarga durante os horários de pico, o servidor tem uma política de cotas para o Google Assistant. Para proteger os servidores de valores de solicitação muito grandes, o limite de cota é significativamente maior do que o uso de linha de base do Google Assistant em um determinado dispositivo.

Um bug no Google Assistant versão 1.88 fez com que os arquivos de reconhecimento de alto-falante fossem buscados 50 vezes mais do que o esperado, excedendo essa cota. Inicialmente, os usuários do Google Home na região central dos Estados Unidos tiveram apenas pequenas perdas de tráfego. No entanto, à medida que a implementação aumentou progressivamente para todos os dispositivos Google Home, os usuários perderam metade de suas solicitações durante o fim de semana de 3 de junho de 2017.

Incidente

Às 11h48 PST na segunda-feira, 22 de maio, Jasper, o desenvolvedor de plantão do Google Home, estava olhando os gráficos de consultas por segundo (QPS) e notou algo estranho: o Google Assistant estava pingando dados de treinamento a cada 30 minutos, em vez de uma vez por dia como esperado. Ele interrompeu o lançamento da versão 1.88, que tinha sido lançada para 25% dos usuários. Ele criou um bug – vamos chamá-lo de bug 12345 – com o sistema de rastreamento de bugs do Google para explorar por que isso estava acontecendo. Sobre o bug, ele observou que o Google Assistant estava pingando dados 48 vezes por dia, fazendo com que excedesse sua capacidade de QPS.

Outro desenvolvedor, Melinda, vinculou o problema a um bug relatado anteriormente, que chamaremos de bug 67890: sempre que uma aplicação atualizava a autenticação do dispositivo e o estado de registro, o processador de fala era reiniciado. Esse bug estava programado para ser corrigido após o lançamento da versão 1.88, então a equipe solicitou um aumento temporário na cota do modelo para mitigar a sobrecarga de consultas extras.

A versão 1.88 foi iniciada novamente e continuou a ser lançada, atingindo 50% dos usuários até quarta-feira, 31 de maio. Infelizmente, a equipe descobriu mais tarde que o bug 67890, embora responsável por algum tráfego extra, não era a causa raiz real de buscas frequentes que Jasper havia notado.

Naquela mesma manhã, os clientes começaram a relatar um problema para a equipe de suporte do Google: sempre que alguém dizia “OK Google” (ou qualquer outro hotword para ativar o Google Home), o dispositivo respondia com uma mensagem de erro. Esse problema impedia os usuários de dar comandos ao Google Assistant. A equipe começou a investigar o que poderia estar causando os erros relatados pelos usuários. Eles suspeitaram de problemas de cota, então solicitaram outro aumento na cota, o que pareceu mitigar o problema.

Enquanto isso, a equipe continuou investigando o bug 12345 para ver o que estava provocando os erros. Embora a conexão de cota tenha sido estabelecida no início do processo de depuração, a falta de comunicação entre os desenvolvedores do cliente e do servidor levou os desenvolvedores ao caminho errado durante a solução de problemas, e a solução completa permaneceu fora de alcance.

A equipe também se perguntou por que o tráfego do Google Assistant continuava atingindo os limites de cota. Os desenvolvedores do cliente e do servidor ficaram confusos com os erros do lado do cliente que não pareciam ser acionados por nenhum problema no lado do servidor. Os desenvolvedores adicionaram o registro à próxima versão para ajudar a equipe a entender melhor os erros e, esperançosamente, progredir na resolução do incidente.

Na quinta-feira, 1º de junho, os usuários relataram que o problema havia sido resolvido. Nenhum novo problema foi relatado, então a versão 1.88 continuou a ser lançada. No entanto, a causa raiz do problema original ainda não havia sido identificada.

No início da manhã de sábado, 3 de junho, o lançamento da versão 1.88 ultrapassou 50%. O lançamento estava acontecendo em um fim de semana, quando os desenvolvedores não estavam prontamente disponíveis. A equipe não seguiu a prática recomendada de realizar lançamentos apenas durante os dias úteis para garantir que os desenvolvedores estejam por perto caso algo dê errado.

Quando o lançamento da versão 1.88 atingiu 100% no sábado, 3 de junho, o cliente mais uma vez atingiu os limites do servidor para o tráfego do Google Assistant. Novos relatórios de clientes começaram a chegar. Os funcionários do Google relataram que seus dispositivos Google Home estavam apresentando erros. A equipe de suporte do Google Home recebeu várias ligações de clientes, tweets e postagens do Reddit sobre o problema, e o fórum de ajuda do Google Home exibiu um tópico crescente discutindo o problema. Apesar de todos os relatórios e comentários dos usuários, o bug não foi escalado para uma prioridade mais alta.

No domingo, 4 de junho, à medida que o número de relatórios de clientes continuava a aumentar, a equipe de suporte finalmente elevou a prioridade do bug ao nível mais alto. A equipe não declarou um incidente, mas continuou a solucionar o problema por meio de métodos “normais”, usando o sistema de rastreamento de bugs para comunicação. O desenvolvedor de plantão notou taxas de erro em um dos clusters de datacenter e enviou uma mensagem ao SRE, pedindo que eles o drenassem. Ao mesmo tempo, a equipe apresentou outro pedido de aumento de cota. Depois, um engenheiro da equipe de desenvolvedores notou que a drenagem tinha empurrado erros para outras células, o que forneceu provas adicionais de problemas de cota. Às 15h33, o gerente da equipe de desenvolvedores aumentou a cota do Google Assistant mais uma vez e o impacto nos usuários parou. O incidente tinha terminado. A equipe identificou a causa raiz (consulte a seção anterior “Contexto”) logo em seguida.

Revisão

Alguns aspectos do tratamento de incidentes correram muito bem, enquanto outros tiveram margem para melhorias.

Primeiro, os desenvolvedores se reuniram no fim de semana e forneceram informações valiosas para resolver o problema. Isso era bom e ruim. Embora a equipe tenha valorizado o tempo e o esforço que esses indivíduos contribuíram no fim de semana, o gerenciamento de incidentes bem-sucedido não deve depender de esforços heróicos de indivíduos. E se os desenvolvedores estivessem inacessíveis? No final das contas, o Google oferece um bom equilíbrio entre vida profissional e pessoal – os engenheiros não devem ser chamados durante seu tempo livre para resolver problemas relacionados ao trabalho. Em vez disso, deveríamos ter realizado lançamentos durante o horário comercial ou organizado um rodízio de plantão que fornecesse cobertura paga fora do horário comercial.

Em seguida, a equipe trabalhou para mitigar o problema. O Google sempre visa primeiro interromper o impacto de um incidente e, em seguida, encontrar a causa raiz (a menos que a causa raiz seja identificada logo no início). Uma vez que o problema é mitigado, é igualmente importante compreender a causa raiz, a fim de evitar que a questão se repita. Nesse caso, a mitigação interrompeu com sucesso o impacto em três ocasiões distintas, mas a equipe só conseguiu evitar que o problema se repetisse quando descobriu a causa raiz. Após a primeira mitigação, teria sido melhor adiar o lançamento até que a causa raiz fosse totalmente determinada, evitando a grande interrupção que aconteceu no fim de semana.

Finalmente, a equipe não declarou um incidente quando os problemas apareceram pela primeira vez. Nossa experiência mostra que os incidentes gerenciados são resolvidos mais rapidamente. Declarar um incidente antecipadamente garante que:

A falha de comunicação entre os desenvolvedores do cliente e do servidor seja evitada.
A identificação da causa raiz e a resolução de incidentes ocorram mais cedo.
As equipes relevantes sejam introduzidas mais cedo, tornando as comunicações externas mais rápidas e suaves.

A comunicação centralizada é um princípio importante do protocolo IMAG. Por exemplo, quando ocorre um desastre, os SREs normalmente se reúnem em uma “sala de guerra”. A sala de guerra pode ser um local físico, como uma sala de conferências, ou pode ser virtual: as equipes podem se reunir em um canal de IRC ou Hangout. A chave aqui é reunir todos os respondentes de incidentes em um só lugar e se comunicar em tempo real para gerenciar – e finalmente resolver – um incidente.

Estudo de Caso 2: Falha de serviço – Me armazene em Cache se puder

O incidente a seguir ilustra o que acontece quando uma equipe de especialistas tenta depurar um sistema com tantas interações que nenhuma pessoa consegue entender todos os detalhes. Soa familiar?

Contexto

Kubernetes é um sistema de gerenciamento de contêineres de código aberto construído de forma colaborativa por muitas empresas e colaboradores individuais. O Google Kubernetes Engine, ou GKE, é um sistema gerenciado pelo Google que cria, hospeda e executa clusters Kubernetes para usuários. Essa versão hospedada opera o plano de controle, enquanto os usuários carregam e gerenciam cargas de trabalho da maneira que melhor lhes convier.

Quando um usuário cria um novo cluster pela primeira vez, o GKE busca e inicializa as imagens do Docker exigidas pelo cluster. Idealmente, esses componentes são buscados e construídos internamente para que possamos validá-los. Mas como o Kubernetes é um sistema de código aberto, novas dependências às vezes escapam.

Incidente

Em uma quinta-feira, às 6h41 PST, o SRE de plantão de Londres para GKE, Zara, foi chamado para falhas do prober CreateCluster em várias zonas. Nenhum novo cluster estava sendo criado com sucesso. A Zara verificou o dashboard do prober e viu que as falhas estavam acima de 60% para duas zonas. Ela verificou que esse problema estava afetando as tentativas do usuário de criar novos clusters, embora o tráfego para clusters existentes não tenha sido afetado. A Zara seguiu o procedimento documentado da GKE e declarou um incidente às 7h06.

Inicialmente, quatro pessoas estiveram envolvidas no incidente:

Zara, que primeiro notou o problema, e foi por isso o Comandante de Incidente padrão designado
Dois dos colegas de equipe da Zara
Rohit, o engenheiro de suporte ao cliente chamado pelo procedimento de incidente

Como Rohit estava sediado em Zurique, a Zara (o CI) abriu um canal GKE Panic IRC onde a equipe poderia depurar em conjunto. Enquanto os outros dois SREs investigavam monitoramento e mensagens de erro, Zara explicou a interrupção e seu impacto para Rohit. Às 7h24, Rohit postou um aviso aos usuários de que o CreateCluster estava falhando na região Europa-Oeste. Isso estava se transformando em um grande incidente.

Entre as 7h00 e as 8h20, Zara, Rohit, e os outros trabalharam na resolução do problema. Eles examinaram os logs de inicialização do cluster, que revelaram um erro:

erro: falha ao executar Kubelet: não é possível criar solicitação de assinatura de certificado: Post

https://192.0.2.53/apis/certificates.k8s.io/v1beta1/certificatesigningrequests

Eles precisavam determinar qual parte da criação do certificado falhou. Os SREs investigaram a rede, a disponibilidade de recursos e o processo de assinatura de certificados. Tudo parecia funcionar bem separadamente. Às 8h22, Zara postou um resumo da investigação no sistema de gerenciamento de incidentes e procurou um desenvolvedor que pudesse ajudá-la.

Felizmente, o GKE tinha um desenvolvedor de plantão que podia ser chamado para emergências. A desenvolvedora, Victoria, entrou no canal. Ela pediu um bug de rastreamento e solicitou que a equipe escalasse o problema para a equipe de plantão de infraestrutura.

Agora eram 8h45. O primeiro SRE de Seattle, Il-Seong, chegou ao escritório, levemente cafeinado e pronto para o dia. Il-Seong era um SRE sênior com muitos anos de experiência em resposta a incidentes. Quando ele foi informado sobre o incidente em andamento, ele saltou para ajudar. Primeiro, Il-Seong verificou o lançamento do dia em relação ao tempo dos alertas e determinou que o lançamento do dia não causou o incidente. Ele então iniciou um documento de trabalho para coletar notas. Ele sugeriu que a Zara escalasse o incidente para as equipes de infraestrutura, rede em nuvem e mecanismo de computação para possivelmente eliminar essas áreas como causas principais. Como resultado da escalada da Zara, mais pessoas se juntaram à resposta ao incidente:

O líder de desenvolvimento para os nós GKE
Rede em nuvem de plantão
Máquina de computador de plantão
Herais, outro SRE de Seattle

Às 9:10 da manhã, o canal de incidentes tinha uma dezena de participantes. O incidente tinha 2,5 horas, sem causa e sem mitigação. A comunicação estava se tornando um desafio. Normalmente, a transferência de plantão de Londres para Seattle ocorria às 10h, mas Zara decidiu entregar o comando do incidente para Il-Seong antes das 10h, já que ele tinha mais experiência com o IMAG.

Como Comandante do Incidente, Il-Seong criou uma estrutura formal para tratar do incidente. Ele então designou Zara como líder de operações e Herais como líder de comunicações (LC). Rohit permaneceu como líder de comunicações externas. Herais enviou imediatamente um e-mail “toda a ajuda possível” para várias listas GKE, incluindo todos os chefes de desenvolvimento, e pediu a peritos que se juntassem à resposta ao incidente.

Até agora, os respondentes ao incidente sabiam o seguinte:

A criação de clusters falhou onde os nós tentaram registrar-se com o mestre.

A mensagem de erro indicava o módulo de assinatura do certificado como o culpado.
Toda a criação de clusters na Europa estava falhando; todos os outros continentes estavam bem.
Nenhum outro serviço do GCP na Europa estava tendo problemas de rede ou cota.

Graças ao apelo de toda a ajuda possível, Puanani, membro da equipe de segurança do GKE, juntou-se ao esforço. Ela notou que o assinante do certificado não estava iniciando. O assinante do certificado estava tentando extrair uma imagem do DockerHub e a imagem parecia estar corrompida. Victoria (a desenvolvedora de plantão do GKE) executou o comando pull do Docker para a imagem em duas localizações geográficas. Ele falhou quando foi executado em um cluster na Europa e teve sucesso em um cluster nos EUA. Isto indicava que o cluster europeu era o problema. Às 9:56 da manhã, a equipe tinha identificado uma causa raiz plausível.

Como o DockerHub era uma dependência externa, a mitigação e a causa raiz seriam especialmente desafiadoras. A primeira opção de mitigação era que alguém do Docker corrigisse rapidamente a imagem. A segunda opção foi reconfigurar os clusters para buscar a imagem de um local diferente, como o Google Container Registry (GCR), sistema de hospedagem de imagens segura do Google. Todas as outras dependências, incluindo outras referências à imagem, estavam localizadas no GCR.

Il-Seong designou proprietários para buscar ambas as opções. Ele então delegou uma equipe para investigar como consertar o cluster com problema. A discussão tornou-se muito densa para o IRC, então a depuração detalhada mudou para o documento compartilhado, e o IRC se tornou o centro para a tomada de decisões.

Para a segunda opção, enviar uma nova configuração significava reconstruir os binários, o que levou cerca de uma hora. Às 10h59, quando a equipe estava 90% reconstruída, eles descobriram outro local que estava usando o caminho de busca de imagem incorreto. Em resposta, eles tiveram que reiniciar a construção.

Enquanto os engenheiros do IRC trabalhavam nas duas opções de mitigação, Tugay, um SRE, teve uma ideia. Em vez de reconstruir a configuração e enviá-la para fora (um processo complicado e arriscado), e se eles interceptassem as solicitações de puxar do Docker e substituíssem a resposta do Docker por uma imagem em cache interna? O GCR tinha um espelho para fazer precisamente isto. Tugay entrou em contato com a equipe de SRE do GCR e eles confirmaram que a equipe poderia colocar –registry-mirror=https://mirror.gcr.io na configuração do Docker. Tugay começou a configurar esta funcionalidade e descobriu que o espelho já estava no lugar!

Às 11h29, Tugay informou ao IRC que essas imagens estavam sendo extraídas do espelho GCR, não do DockerHub. Às 11h37, o Comandante do Incidente chamou o GCR de plantão. Às 11h59, o GCR de plantão limpou a imagem corrompida de sua camada de armazenamento europeia. Às 12h11, todas as zonas europeias caíram para 0% de erro.

A interrupção acabou. Tudo o que restava era a limpeza e escrever um postmortem verdadeiramente épico.

O CreateCluster falhou na Europa por 6 horas e 40 minutos antes de ser corrigido. No IRC, 41 usuários únicos apareceram durante o incidente, e os logs do IRC chegaram a 26.000 palavras. O esforço gerou sete forças-tarefa do IMAG em vários momentos, e até quatro trabalharam simultaneamente em um determinado momento. Os plantões foram convocados de seis equipes, não incluindo aqueles da chamada “toda a ajuda possível ”. O postmortem continha 28 itens de ação.

Revisão

A interrupção do GKE CreateCluster foi um grande incidente para os padrões de qualquer pessoa. Vamos explorar o que correu bem e o que poderia ter sido melhor tratado.

O que ocorreu bem? A equipe tinha vários caminhos de escalação documentados e estava familiarizada com as táticas de resposta a incidentes. A Zara, a GKE de plantão, verificou rapidamente que o impacto estava afetando os clientes reais. Ela então usou um sistema de gerenciamento de incidentes preparado com antecedência para trazer Rohit, que comunicou a interrupção aos clientes.

O que poderia ter sido melhor tratado? O serviço em si tinha algumas áreas de preocupação. A complexidade e a dependência de especialistas eram problemáticas. O log foi insuficiente para o diagnóstico, e a equipe se distraiu com a corrupção no DockerHub, que não era o problema real.

No início do incidente, o Comandante do Incidente não estabeleceu uma estrutura formal de resposta a incidentes. Enquanto Zara assumiu este papel e transferiu a conversa para o IRC, ela poderia ter sido muito mais proativa na coordenação de informações e na tomada de decisões. Como resultado, um punhado de primeiros respondentes prosseguiu com suas próprias investigações sem coordenação. Il-Seong colocou uma estrutura formal de resposta a incidentes duas horas após a primeira página.

Por fim, o incidente revelou uma lacuna na prontidão para desastres do GKE: o serviço não tinha nenhuma mitigação genérica inicial que reduzisse a dor do usuário. Mitigações genéricas são ações que os primeiros respondentes realizam para aliviar a dor, mesmo antes que a causa raiz seja totalmente compreendida. Por exemplo, os respondentes poderiam reverter um lançamento recente quando uma interrupção está correlacionada com o ciclo de lançamento ou reconfigurar os balanceadores de carga para evitar uma região quando os erros são localizados. É importante observar que as mitigações genéricas são instrumentos contundentes e podem causar outras interrupções no serviço. No entanto, embora possam ter um impacto mais amplo do que uma solução precisa, eles podem ser implementados rapidamente para interromper a sangria enquanto a equipe descobre e aborda a causa raiz.

Vejamos novamente a cronologia deste incidente para ver onde uma mitigação genérica pode ter sido eficaz:

7 da manhã (Impacto avaliado). A Zara confirmou que os usuários foram afetados pela interrupção.
9:56 da manhã (encontrada possível causa). Puanani e Victoria identificaram uma imagem desonesta.
10:59 da manhã (mitigação sob medida). Vários membros da equipe trabalharam na reconstrução de binários para enviar uma nova configuração que buscaria imagens de um local diferente.
11:59 da manhã (foi encontrado a causa raiz e resolvido a questão). O Tugay e GCR de plantão desabilitaram o cache do GCR e removeram uma imagem corrompida de sua camada de armazenamento europeia.

Uma mitigação genérica após a etapa 2 (encontrada possível causa) teria sido muito útil aqui. Se os respondentes tivessem revertido todas as imagens para um estado bom conhecido assim que descobrissem a localização geral do problema, o incidente teria sido mitigado às 10h. Para mitigar um incidente, você não precisa entender completamente os detalhes – você só precisa conhecer a localização da causa raiz. Ter a capacidade de mitigar uma interrupção antes que sua causa seja totalmente compreendida é crucial para executar serviços robustos com alta disponibilidade.

Nesse caso, os respondentes teriam se beneficiado de algum tipo de ferramenta que facilitasse os rollbacks. As ferramentas de mitigação levam tempo de engenharia para serem desenvolvidas. O momento certo para criar ferramentas de mitigação de uso geral é antes de ocorrer um incidente, não quando você está respondendo a uma emergência. Consultar post-mortems é uma ótima maneira de descobrir mitigações e/ou ferramentas que seriam úteis em retrospectiva e integrá-las em serviços para que você possa gerenciar melhor os incidentes no futuro.

É importante lembrar que os primeiros respondentes devem priorizar a mitigação acima de tudo, caso contrário o tempo para a resolução será prejudicado. Ter uma mitigação genérica em vigor, como o rollback e drenagem, acelera a recuperação e conduz a clientes mais felizes. Em última análise, os clientes não se importam se você entende completamente ou não o que causou uma interrupção. O que eles querem é deixar de receber erros.

Com a mitigação como prioridade máxima, um incidente ativo deve ser tratado da seguinte forma:

Avaliar o impacto do incidente.
Mitigar o impacto.
Efetuar uma análise da causa raiz do incidente.
Após o incidente ter terminado, corrigir o que causou o incidente e escrever um post-mortem.

Depois, você pode executar simulações de resposta a incidentes para exercitar as vulnerabilidades no sistema, e os engenheiros podem trabalhar em projetos para lidar com essas vulnerabilidades.

Estudo de Caso 3: Queda de energia — um raio nunca cai duas vezes… até que aconteça

Os exemplos anteriores mostraram o que pode dar errado quando você não tem boas estratégias de resposta a incidentes. O próximo exemplo ilustra um incidente que foi gerenciado com sucesso. Quando você segue um protocolo de resposta bem definido e claro, pode lidar com incidentes raros ou incomuns com facilidade.

Contexto

Eventos de rede elétrica, como relâmpagos, fazem com que a energia que entra em uma instalação de datacenter varie muito. Os relâmpagos que afetam a rede elétrica são raros, mas não inesperados. O Google protege contra quedas de energia repentinas e inesperadas com geradores e baterias de backup, que são bem testados e conhecidos por funcionarem nesses cenários.

Muitos dos servidores do Google têm um grande número de discos anexados a eles, com os discos localizados em uma bandeja separada acima ou abaixo do servidor. Essas bandejas têm sua própria bateria de fonte de alimentação ininterrupta (UPS). Quando ocorre uma queda de energia, os geradores de backup são ativados, mas levam alguns minutos para iniciar. Durante esse período, as baterias de backup conectadas aos servidores e bandejas de disco fornecem energia até que os geradores de backup estejam totalmente funcionando, evitando assim que eventos da rede elétrica afetem a operação do datacenter.

Incidente

Em meados de 2015, um raio atingiu a rede elétrica perto de um datacenter do Google na Bélgica quatro vezes em dois minutos. Os geradores de backup do datacenter foram ativados para fornecer energia a todas as máquinas. Enquanto os geradores de backup estavam iniciando, a maioria dos servidores funcionava com baterias de backup por alguns minutos.

As baterias UPS nas bandejas de disco não trocaram o uso de energia pelas baterias de backup no terceiro e quarto relâmpagos porque os raios estavam espaçados demais. Como resultado, as bandejas de disco perderam energia até que os geradores de backup entraram em ação. Os servidores não perderam energia, mas não conseguiram acessar os discos que foram desligados.

A perda de um grande número de bandejas de disco no armazenamento permanente de discos resultou em erros de leitura e escrita para muitas máquinas virtuais (VM) em funcionamento no Google Compute Engine (GCE). O SRE de disco permanente de plantão foi imediatamente notificado sobre esses erros. Depois que a equipe do SRE de disco permanente estabeleceu o impacto, um grande incidente foi declarado e anunciado a todas as partes afetadas. O SRE de disco permanente de plantão assumiu o papel de Comandante do Incidente.

Após uma investigação inicial e comunicação entre as partes interessadas, estabelecemos que:

Cada máquina que perdeu uma bandeja de disco devido à falta de energia temporária precisava ser reinicializada.
Enquanto aguardava a reinicialização, alguns VMs clientes tinham dificuldade em ler e escrever nos seus discos.
Qualquer host que tivesse uma bandeja de disco e VMs do cliente não poderia simplesmente ser “reinicializado” sem perder os VMs do cliente que não foram afetados. O SRE de disco permanente pediu ao GCE SRE para migrar VMs não afetados para outros hosts.

O plantão principal do SRE de disco permanente manteve a função de CI, pois essa equipe tinha a melhor visibilidade do impacto no cliente.

Os membros da equipe de operações foram encarregados dos seguintes objetivos:

Restabelecer com segurança a energia para utilizar a rede elétrica em vez de geradores de backup.
Reiniciar todas as máquinas que não estavam hospedando VMs.
Coordenar entre o SRE de disco permanente e o SRE do GCE para mover os VMs com segurança para longe das máquinas afetadas antes de reiniciá-las.

Os dois primeiros objetivos foram claramente definidos, bem compreendidos e documentados. As operações de plantão do datacenter imediatamente começaram a trabalhar para restaurar a energia com segurança, fornecendo relatórios regulares de status ao CI. O SRE de disco permanente definiu procedimentos para reiniciar todas as máquinas que não hospedam máquinas virtuais. Um membro da equipe começou a reiniciar essas máquinas.

O terceiro objetivo era mais vago e não estava coberto por nenhum procedimento existente. O Comandante do Incidente designou um membro da equipe de operações dedicado para coordenar com o GCE SRE e o SRE de disco permanente. Estas equipes colaboraram para afastar com segurança os VMs das máquinas afetadas para que as máquinas afetadas pudessem ser reiniciadas. O CI monitorou de perto seu progresso e percebeu que esse trabalho exigia que novas ferramentas fossem escritas rapidamente. O CI organizou mais engenheiros para se reportarem à equipe de operações para que pudessem criar as ferramentas necessárias.

O Líder de Comunicação observou e fez perguntas sobre todas as atividades relacionadas a incidentes e foi responsável por relatar informações precisas para vários públicos:

Os líderes da empresa precisavam de informações sobre a extensão do problema, e a garantia de que o problema estava sendo resolvido.
As equipes com problemas de armazenamento precisavam saber quando seu armazenamento estaria totalmente disponível novamente.
Os clientes externos precisavam ser informados proativamente sobre o problema com seus discos nessa região de nuvem.
Clientes específicos que enviaram tickets de suporte precisavam de mais informações sobre os problemas que estavam vendo e conselhos sobre soluções alternativas e prazos.

Depois de mitigarmos o impacto inicial no cliente, precisávamos fazer alguns acompanhamentos, como:

Diagnosticar por que o UPS usado pelas bandejas de disco falhou e garantir que isso não aconteça novamente.
Substituição das baterias no datacenter que falhou.
Limpar manualmente operações “paradas” causadas pela perda de tantos sistemas de armazenamento simultaneamente.

A análise pós-incidente revelou que apenas um pequeno número de gravações – as gravações pendentes nas máquinas que perderam energia durante o incidente – nunca foram gravadas em disco. Como os snapshots do disco permanente e todos os dados do Cloud Storage são armazenados em vários datacenters para redundância, apenas 0,000001% dos dados das máquinas GCE em execução foram perdidos e apenas os dados das instâncias em execução estavam em risco.

Revisão

Ao declarar o incidente com antecedência e organizar uma resposta com liderança clara, um grupo de pessoas cuidadosamente gerenciado lidou com esse incidente complexo de forma eficaz.

O Comandante do Incidente delegou os problemas normais de restabelecimento da energia e reinício dos servidores ao Líder de Operações apropriado. Os engenheiros trabalharam na resolução do problema e relataram seu progresso ao Líder de Operações.

O problema mais complexo de atender às necessidades do GCE e do Disco Permanente exigia a tomada de decisão coordenada e a interação entre várias equipes. O Comandante do Incidente certificou-se de designar membros apropriados da equipe de operações de ambas as equipes para o incidente e trabalhou diretamente com eles para buscar uma solução. O Comandante do Incidente concentrou-se sabiamente no aspecto mais importante do incidente: atender às necessidades dos clientes afetados o mais rápido possível.

Estudo de Caso 4: Resposta a Incidentes no PagerDuty

Escrito por Arup Chakrabarti do PagerDuty

O PagerDuty desenvolveu e refinou nossas práticas internas de resposta a incidentes ao longo de vários anos. Inicialmente, contamos com um Comandante de Incidentes permanente em toda a empresa e engenheiros específicos dedicados por serviço para participar da resposta a incidentes. À medida que o PagerDuty cresceu para mais de 400 funcionários e dezenas de equipes de engenharia, nossos processos de resposta a incidentes também mudaram. A cada poucos meses, analisamos cuidadosamente nossos processos e os atualizamos para refletir as necessidades de negócios. Quase tudo o que aprendemos está documentado em https://response.pagerduty.com. Os nossos processos de Resposta a Incidentes não são propositadamente estáticos; eles mudam e evoluem tal como o nosso negócio.

Resposta a incidentes graves na PagerDuty

Normalmente, pequenos incidentes requerem apenas um único engenheiro de plantão para responder. Quando se trata de incidentes maiores, damos muita ênfase ao trabalho em equipe. Um engenheiro não deve se sentir sozinho em cenários de alto estresse e alto impacto. Usamos as seguintes técnicas para ajudar a promover o trabalho em equipe:

Participação em exercícios de simulação

Uma maneira de ensinar o trabalho em equipe é participando da Failure Friday. O PagerDuty se inspirou no Simian Army da Netflix para criar este programa. Originalmente, o Failure Friday era um exercício manual de injeção de falhas com o objetivo de aprender mais sobre as maneiras pelas quais nossos sistemas poderiam quebrar. Hoje, também usamos este exercício semanal para recriar problemas comuns em cenários de produção e resposta a incidentes.

Antes do Failure Friday começar, nomeamos um Comandante do Incidente (normalmente, uma pessoa treinando para se tornar um CI). Espera-se que eles se comportem e ajam como um CI real durante a realização de exercícios de injeção de falhas. Ao longo do exercício, os especialistas no assunto usam os mesmos processos e vernáculo que usariam durante um incidente real. Essa prática familiariza os novos engenheiros de plantão com a linguagem e os processos de resposta a incidentes e fornece aos engenheiros de plantão mais experientes uma atualização.

Jogar jogos de simulação com limite de tempo

Embora os exercícios de Failure Friday ajudem bastante no treinamento de engenheiros em diferentes funções e processos, eles não podem replicar totalmente a urgência de grandes incidentes reais. Usamos jogos de simulação com urgência limitada no tempo para capturar esse aspecto da resposta a incidentes.

“Keep Talking and Nobody Explodes” é um jogo que temos aproveitado bastante. Requer que os jogadores trabalhem juntos para desarmar bombas dentro dos limites de tempo. A natureza estressante e intensiva em comunicação do jogo força os jogadores a cooperar e trabalhar juntos de forma eficaz.

Aprendendo com incidentes anteriores

Aprender com incidentes anteriores nos ajuda a responder melhor a incidentes importantes no futuro. Para este fim, realizamos e revisamos regularmente post-mortems.

O processo postmortem do PagerDuty envolve reuniões abertas e documentação completa. Ao tornar essas informações facilmente acessíveis e detectáveis, nosso objetivo é reduzir o tempo de resolução de incidentes futuros ou evitar que um incidente futuro aconteça.

Também gravamos todas as chamadas telefônicas envolvidas em um grande incidente para que possamos aprender com o feed de comunicação em tempo real.

Vejamos um incidente recente em que o PagerDuty teve que alavancar nosso processo de resposta a incidentes. O incidente ocorreu em 6 de outubro de 2017 e durou mais de 10 horas, mas teve um impacto mínimo no cliente.

19h53 Um membro da equipe do PagerDuty SRE foi alertado de que os servidores NTP internos do PagerDuty estavam apresentando desvio de relógio. O SRE de plantão validou que todas as ações de recuperação automatizadas foram executadas e concluiu as etapas de mitigação em runbooks relevantes. Esse trabalho foi documentado no canal Slack dedicado da equipe do SRE.
20h20 Um membro da equipe de software PagerDuty A recebeu um alerta automatizado sobre erros de desvio de relógio em seus serviços. A equipe de software A e a equipe de SRE trabalharam para resolver o problema.
21h17 Um membro da equipe de software PagerDuty B recebeu um alerta automatizado sobre erros de desvio de relógio em seus serviços. O engenheiro da Equipe B entrou no canal do Slack onde o problema já estava sendo triado e depurado.
21h49 O SRE de plantão declarou um incidente grave e alertou o Comandante de Incidente de plantão.
21h55 O CI montou a equipe de resposta, que incluiu todos os engenheiros de plantão que tinham um serviço dependente do NTP e o suporte ao cliente do PagerDuty de plantão. O CI fez com que a equipe de resposta participasse da teleconferência dedicada e do canal Slack.

Nas oito horas seguintes, a equipe de resposta trabalhou para resolver e mitigar o problema. Quando os procedimentos em nossos runbooks não resolveram o problema, a equipe de resposta começou a tentar novas opções de recuperação de maneira metódica.

Durante esse período, revezamos os engenheiros de plantão e o CI a cada quatro horas. Isso encorajou os engenheiros a descansar e trouxe novas ideias para a equipe de resposta.

5h33 O SRE de plantão fez uma alteração na configuração dos servidores NTP.
6h13 O CI validou que todos os serviços haviam se recuperado com seus respectivos engenheiros de plantão. Depois que a validação foi concluída, o CI desligou a teleconferência e o canal do Slack e declarou o incidente concluído. Dado o amplo impacto do serviço NTP, foi garantido um postmortem. Antes de encerrar o incidente, o CI atribuiu a análise post-mortem à equipe do SRE de plantão para o serviço.

Ferramentas utilizadas para resposta a incidentes

Nossos processos de resposta a incidentes utilizam três ferramentas principais:

PagerDuty

Armazenamos todas as nossas informações de plantão, propriedade do serviço, postmortems, metadados de incidentes e similares no PagerDuty. Isso nos permite montar rapidamente a equipe certa quando algo dá errado.

Slack

Mantemos um canal dedicado (#incident-war-room) como um local de encontro para todos os especialistas no assunto e Comandantes de Incidentes. O canal é usado principalmente como um registro de informações para o escriba, que captura ações, proprietários e registros de data e hora.

Chamadas de conferencia

Quando solicitados a participar de qualquer resposta a incidentes, os engenheiros de plantão são obrigados a discar um número de chamada de conferência estática. Preferimos que todas as decisões de coordenação sejam tomadas na chamada em conferência, e que os resultados das decisões sejam registrados no Slack. Descobrimos que essa era a maneira mais rápida de tomar decisões. Também gravamos todas as chamadas para garantir que possamos recriar qualquer linha do tempo caso o escriba perca detalhes importantes.

Embora o Slack e as chamadas em conferência sejam os nossos canais de comunicação preferidos, você deve usar o método de comunicação que funciona melhor para sua empresa e seus engenheiros.

No PagerDuty, a forma como lidamos com a resposta a incidentes está diretamente relacionada ao sucesso da empresa. Em vez de enfrentar esses eventos despreparados, nos preparamos propositalmente para incidentes realizando exercícios de simulação, revisando incidentes anteriores e escolhendo as ferramentas certas para nos ajudar a ser resilientes a qualquer incidente importante que possa surgir em nosso caminho.

Colocando em prática as Melhores Práticas

Vimos exemplos de incidentes que foram bem tratados e alguns que não foram. Quando um pager alerta você sobre um problema, é tarde demais para pensar em como gerenciar o incidente. A hora de começar a pensar em um processo de gerenciamento de incidentes é antes de ocorrer um incidente. Então, como você prepara e coloca a teoria em prática antes que ocorra um desastre? Esta seção fornece algumas recomendações.

Formação em Resposta a Incidentes

É altamente recomendável treinar os respondentes para organizar um incidente para que eles tenham um padrão a seguir em uma emergência real. Saber como organizar um incidente, ter uma linguagem comum para usar durante todo o incidente e compartilhar as mesmas expectativas reduz a chance de falhas de comunicação.

A abordagem completa do Sistema de Comando de Incidentes pode ser mais do que você precisa, mas você pode desenvolver uma estrutura para lidar com incidentes selecionando as partes do processo de gerenciamento de incidentes que são importantes para sua organização. Por exemplo:

Deixe os plantonistas saberem que podem delegar e escalar durante um incidente.
Incentive uma resposta de mitigação em primeiro lugar.
Defina as funções de Comandante do Incidente, Líder de Comunicações e Líder de Operações.

Você pode adaptar e resumir sua estrutura de resposta a incidentes e criar um conjunto de slides para apresentar aos novos membros da equipe. Aprendemos que as pessoas são mais receptivas ao treinamento de resposta a incidentes quando podem conectar a teoria da resposta a incidentes a cenários reais e ações concretas. Portanto, não deixe de incluir exercícios práticos e compartilhar o que aconteceu em incidentes anteriores, analisando o que deu certo e o que não deu tão certo. Você também pode considerar o uso de agências externas especializadas em aulas e treinamento de resposta a incidentes.

Preparar de antemão

Além do treinamento de resposta a incidentes, ele ajuda a se preparar para um incidente com antecedência. Use as seguintes dicas e estratégias para estar melhor preparado.

Decidir sobre um canal de comunicação

Decida e concorde com um canal de comunicação (Slack, uma ponte telefônica, IRC, HipChat, etc.) de antemão – nenhum Comandante de Incidente deseja tomar essa decisão durante um incidente. Pratique usá-lo para que não haja surpresas. Se possível, escolha um canal de comunicação com o qual a equipe já esteja familiarizada para que todos na equipe se sintam à vontade para usá-lo.

Mantenha o seu público informado

A menos que você reconheça que um incidente está acontecendo e sendo tratado ativamente, as pessoas automaticamente assumirão que nada está sendo feito para resolver o problema. Da mesma forma, se você esquecer de cancelar a resposta depois que o problema for mitigado ou resolvido, as pessoas presumirão que o incidente está em andamento. Você pode antecipar essa dinâmica mantendo seu público informado durante todo o incidente com atualizações regulares de status. Ter uma lista de contatos preparada (veja a próxima dica) economiza um tempo valioso e garante que você não perca ninguém.

Pense com antecedência sobre como você redigirá, revisará, aprovará e divulgará postagens de blogs públicos ou comunicados à imprensa. No Google, as equipes buscam orientação da equipe de relações públicas. Além disso, prepare dois ou três modelos prontos para o compartilhamento de informações, certificando-se de que o plantão saiba como enviá-los. Ninguém quer escrever estes anúncios sob extrema tensão, sem orientações. Os modelos tornam o compartilhamento de informações com o público fácil e minimamente estressante.

Prepare uma lista de contatos

Ter uma lista de pessoas para enviar por e-mail ou página preparada com antecedência economiza tempo e esforço críticos. No estudo de caso 2: falha de serviço — me armazene em cache se puder, o líder de comunicação fez uma chamada “toda a ajuda possível” enviando um e-mail para várias listas do GKE que foram preparadas com antecedência.

Estabeleça critérios para um incidente

Às vezes fica claro que um problema de paginação é realmente um incidente. Outras vezes, não é tão claro. É útil ter uma lista estabelecida de critérios para determinar se um problema é realmente um incidente. Uma equipe pode apresentar uma lista sólida de critérios analisando as interrupções anteriores, levando em consideração as áreas conhecidas de alto risco.

Em resumo, é importante estabelecer um terreno comum para coordenação e comunicação ao responder a incidentes. Decida as maneiras de comunicar o incidente, quem é seu público e quem é responsável pelo quê durante um incidente. Essas diretrizes são fáceis de configurar e têm alto impacto na redução do tempo de resolução de um incidente.

Treinos

A etapa final no processo de gerenciamento de incidentes é praticar suas habilidades de gerenciamento de incidentes. Ao praticar durante situações menos críticas, sua equipe desenvolve bons hábitos e padrões de comportamento para quando um raio cai – figurativa e literalmente. Depois de introduzir a teoria da resposta a incidentes por meio de treinamento, a prática garante que suas habilidades de resposta a incidentes permaneçam atualizadas.

Há várias formas de realizar exercícios de gestão de incidentes. O Google realiza testes de resiliência em toda a empresa (chamado Teste de Recuperação de Desastres, ou DiRT; veja o artigo de Kripa Krishnan “Weathing the Unexpected” “), nos quais criamos uma emergência controlada que não afeta os clientes. As equipes respondem à emergência controlada como se fosse uma emergência real. Depois, as equipes revisam os procedimentos de resposta a emergências e discutem o que aconteceu. Aceitar o fracasso como um meio de aprendizado, encontrar valor nas lacunas identificadas e obter nossa liderança a bordo foram fundamentais para estabelecer com sucesso o programa DiRT no Google. Em uma escala menor, praticamos a resposta a incidentes específicos usando exercícios como a Roda do Infortúnio (ver “Capítulo 28” no primeiro livro).

Também se pode praticar a resposta a incidentes tratando intencionalmente problemas menores como os maiores que exigem uma resposta em grande escala. Isso permite que sua equipe pratique com os procedimentos e ferramentas em uma situação do mundo real com riscos mais baixos.

Os exercícios são uma maneira amigável de experimentar novas habilidades de resposta a incidentes. Qualquer pessoa em sua equipe que possa ser arrastada para a resposta a incidentes – SREs, desenvolvedores e até mesmo suporte ao cliente e parceiros de marketing – deve se sentir confortável com essas táticas.

Para encenar um exercício, você pode inventar uma interrupção e permitir que a sua equipe responda ao incidente. Você também pode criar interrupções de postmortems, que contêm muitas ideias para exercícios de gerenciamento de incidentes. Use ferramentas reais o máximo possível para gerenciar o incidente. Considere quebrar seu ambiente de teste para que a equipe possa realizar uma solução de problemas real usando as ferramentas existentes.

Todos esses exercícios são muito mais úteis se forem executados periodicamente. Você pode tornar os exercícios impactantes acompanhando cada exercício com um relatório detalhando o que deu certo, o que não deu certo e como as coisas poderiam ter sido melhor tratadas. A parte mais valiosa da execução de um exercício é examinar seus resultados, o que pode revelar muito sobre quaisquer lacunas no gerenciamento de incidentes. Depois de saber quais são, você pode trabalhar para fechá-los.

Conclusão

Esteja preparado para quando ocorrer um desastre. Se sua equipe praticar e atualizar seus procedimentos de resposta a incidentes regularmente, você não entrará em pânico quando ocorrer a interrupção inevitável.

O círculo de pessoas com as quais você precisa colaborar durante um incidente se expande com o tamanho do incidente. Quando você está trabalhando com pessoas que não conhece, os procedimentos ajudam a criar a estrutura necessária para avançar rapidamente em direção a uma resolução. É altamente recomendável estabelecer esses procedimentos com antecedência quando o mundo não estiver em chamas. Reveja e itere regularmente os seus planos de gestão de incidentes e os seus playbooks.

O Sistema de Comando de Incidentes é um conceito simples e de fácil compreensão. Ele aumenta ou diminui de acordo com o tamanho da empresa e o incidente. Embora seja simples de entender, não é fácil de implementar, especialmente no meio de um incidente, quando o pânico toma conta de você de repente. Manter a calma e seguir a estrutura de resposta durante uma emergência requer prática, e a prática constrói “memória muscular”. Isso lhe dá a confiança necessária para uma emergência real.

É altamente recomendável reservar algum tempo na agenda lotada de sua equipe para praticar o gerenciamento de incidentes regularmente. Garanta o suporte da liderança para um tempo de prática dedicado e certifique-se de que eles entendam como funciona a resposta a incidentes caso você precise envolvê-los em um incidente real. A preparação para desastres pode reduzir minutos ou horas valiosos do tempo de resposta e oferece uma vantagem competitiva. Nenhuma empresa acerta o tempo todo – aprenda com seus erros, siga em frente e faça melhor da próxima vez.

Fonte: Google SRE Work Book