Capítulo 10 – Cultura postmortem: aprendendo com o fracasso

Por /

Por Daniel Rogers, Murali Suriar, Sue Lueder,
Pranjal Deo e Divya Sudhakar
com Gary O’Connor e Dave Rensin

Nossa experiência mostra que uma cultura de postmortem verdadeiramente sem culpa resulta em sistemas mais confiáveis — por isso, acreditamos que essa prática é importante para criar e manter uma organização de SRE bem-sucedida.

Introduzir postmortems em uma organização é tanto uma mudança cultural quanto técnica. Fazer essa mudança pode parecer intimidante. A principal lição deste capítulo é que fazer essa mudança é possível e não precisa parecer um desafio insuperável. Não saia de um incidente esperando que seus sistemas se corrijam sozinhos eventualmente. Você pode começar pequeno introduzindo um procedimento de post-mortem muito básico e, em seguida, refletir e ajustar seu processo para se adequar melhor à sua organização — como em muitas coisas, não existe uma solução única que sirva para todos.

Quando bem escritos, implementados e amplamente compartilhados, os postmortems podem ser uma ferramenta muito eficaz para impulsionar mudanças organizacionais positivas e prevenir interrupções recorrentes. Para ilustrar os princípios de uma boa redação de postmortem, este capítulo apresenta um estudo de caso de uma interrupção real que ocorreu no Google. Um exemplo de um postmortem mal escrito destaca as razões pelas quais práticas de postmortem “ruins” são prejudiciais para uma organização que está tentando criar uma cultura de postmortem saudável. Em seguida, comparamos o post-mortem ruim com o postmortem real que foi escrito após o incidente, destacando os princípios e melhores práticas de um postmortem de alta qualidade.

A segunda parte deste capítulo compartilha o que aprendemos sobre a criação de incentivos para o cultivo de uma cultura robusta de postmortem e como reconhecer (e remediar) os primeiros sinais de que a cultura está se deteriorando.

Por fim, fornecemos ferramentas e modelos que você pode usar para iniciar uma cultura de postmortem. 

Para uma discussão abrangente sobre a filosofia de postmortem sem culpa, consulte o Capítulo 15 em nosso primeiro livro, Livro SRE.

Estudo de Caso

Este estudo de caso apresenta uma decomissão rotineira de racks que resultou em um aumento na latência do serviço para nossos usuários. Um bug em nossa automação de manutenção, combinado com limites de taxa insuficientes, fez com que milhares de servidores que transportavam tráfego de produção fossem offline simultaneamente.

Embora a maioria dos servidores do Google esteja localizada em nossos data centers proprietários, também temos racks de máquinas de proxy/cache em instalações de colocação (ou “colos”). Os racks nos colos que contêm nossas máquinas de proxy são chamados de satélites. Como os satélites passam por manutenção e atualizações regulares, um número de racks de satélite está sendo instalado ou descomissionado a qualquer momento. No Google, esses processos de manutenção são em grande parte automatizados.

O processo de descomissionamento sobrescreve todo o conteúdo de todos os discos no rack usando um processo que chamamos de diskerase. Uma vez que uma máquina é enviada para o diskerase, os dados que ela armazenava anteriormente não são mais recuperáveis. Os passos para um descomissionamento de rack típico são os seguintes:

# Get all active machines in "satellite" 
machines = GetMachines(satellite) 

# Send all candidate machines matching "filter" to decom 
SendToDecom(candidates=GetAllSatelliteMachines(), 
             filter=machines)

Nosso estudo de caso começa com um rack de satélite que foi marcado para descomissionamento. A etapa de diskerase do processo de descomissionamento foi concluída com sucesso, mas a automação responsável pelo restante da descomissão da máquina falhou. Para depurar a falha, tentamos novamente o processo de descomissionamento. O segundo descomissionamento ocorreu da seguinte forma:

# Get all active machines in "satellite" 
machines = GetMachines(satellite) 

# "machines" is an empty list, because the decom flow has already run. 
# API bug: an empty list is treated as "no filter", rather than "act on no 
# machines" 

# Send all candidate machines matching "filter" to decom 
SendToDecom(candidates=GetAllSatelliteMachines(),
             filter=machines) 

# Send all machines in "candidates" to diskerase.

Dentro de minutos, os discos de todas as máquinas de satélite, globalmente, foram apagados. As máquinas foram tornadas inativas e não puderam mais aceitar conexões de usuários, então as conexões de usuários subsequentes foram roteadas diretamente para nossos data centers. Como resultado, os usuários experimentaram um leve aumento na latência. Graças ao bom planejamento de capacidade, muito poucos de nossos usuários perceberam o problema durante os dois dias que nos levou para reinstalar as máquinas nos racks de colo afetados. Após o incidente, passamos várias semanas auditando e adicionando mais verificações de sanidade à nossa automação para tornar nosso fluxo de trabalho de descomissionamento idempotente.

Três anos após essa interrupção, nós vivenciamos um incidente similar: um número de satélites foi drenado, resultando em aumento na latência do usuário. As medidas implementadas a partir do postmortem original reduziram drasticamente o raio de impacto e a taxa do segundo incidente.

Suponha que você fosse a pessoa responsável por escrever o relatório postmortem para este estudo de caso. O que você gostaria de saber e quais ações você proporia para evitar que essa interrupção acontecesse novamente?

Vamos começar com um postmortem não tão bom para este incidente.

Postmortem ruim

Postmortem: todos os equipamentos satélites enviados para o diskerase

11 de agosto de 2014

Responsáveis: maxone@, logantwo@, sydneythree@, dylanfour@

Compartilhado com: satellite-infra-team@

Status: finalizado

Data do incidente: 11 de agosto de 2014

Publicado: 30 de dezembro de 2014

Resumo executivo

Impacto: todos os equipamentos satélites foram enviados para o diskerase, o que praticamente eliminou o Google Edge.

Causa Raiz: dylanfour@ ignorou a configuração de automação e executou manualmente a lógica de inicialização do cluster, o que acionou um bug existente.

Resumo do problema

Duração do problema: 40 minutos

Produto(s) afetado(s): equipe de infraestrutura de satélites

% do produto afetado: todos os clusters de satélites.

Impacto no usuário: todas as consultas que normalmente são direcionadas para os satélites foram atendidas a partir do núcleo, causando aumento na latência.

Impacto na receita: alguns anúncios não foram exibidos devido às consultas perdidas. O impacto exato na receita é desconhecido neste momento.

Detecção: alerta de monitoramento.

Resolução: desvio de tráfego para o núcleo seguido de reparo manual dos clusters de borda.

Antecedentes (opcional)

Impacto

Impacto no usuário

Todas as consultas que normalmente são direcionadas para os satélites foram, em vez disso, atendidas a partir do núcleo, causando aumento na latência do tráfego do usuário.

Impacto na receita

Alguns anúncios não foram exibidos devido às consultas perdidas.

Causas raízes e gatilho

A automação de inicialização/desligamento do cluster não é destinada a ser idempotente. A ferramenta possui salvaguardas para garantir que determinadas etapas não possam ser executadas mais de uma vez. Infelizmente, não há nada que impeça alguém de executar o código manualmente quantas vezes quiser. Nenhuma documentação mencionou essa armadilha. Como resultado, a maioria dos membros da equipe acredita que é aceitável executar o processo várias vezes se não funcionar.

Isso é exatamente o que aconteceu durante a decomissão de rotina de um rack. O rack estava sendo substituído por um novo satélite baseado em Iota. dylanfour@ ignorou completamente o fato de que a inicialização já havia sido executada uma vez e estava travada na primeira tentativa. Devido à ignorância descuidada, eles acionaram uma interação ruim que atribuiu todas as máquinas satélites à equipe de diskerase.

Esforços de Recuperação

Lições Aprendidas

Aspectos positivos:

  • O sistema de alerta identificou imediatamente o problema.
  • A gestão do incidente foi bem executada.

Aspectos negativos:

  • A equipe (especialmente maxone@, logantwo@) nunca escreveu documentação para instruir os Engenheiros de Confiabilidade de Sites (SREs) a não executar a automação várias vezes, o que é ridículo.
  • O plantão não agiu com rapidez suficiente para evitar que a maioria das máquinas satélites fosse apagada. Esta não é a primeira vez que o plantão falha em reagir a tempo.

Sorte que tivemos:

  • O núcleo foi capaz de atender todo o tráfego que normalmente teria sido direcionado para a Edge. Eu não consigo acreditar que sobrevivemos a essa!

Item de ação

Melhorar a automação.

  • Tipo: Mitigar
  • Prioridade: P2
  • Responsável: logantwo@

Melhorar o acionamento e alerta.

  • Tipo: Detectar
  • Prioridade: P2

Item de Ação: Sydneythree@ precisa aprender o protocolo adequado de transferência de responsabilidade entre locais para que ninguém precise trabalhar em problemas duplicados.

  • Tipo: Mitigar
  • Prioridade: P2

Item de Ação: Treinar os humanos para não executar comandos inseguros.

  • Tipo: Prevenir
  • Prioridade: P2

Por que este postmortem é ruim?

O exemplo de postmortem “ruim” contém vários modos de falha comuns que tentamos evitar. As seções a seguir explicam como melhorar este postmortem.

Contexto Ausente

Desde o início, nosso exemplo de postmortem introduz terminologia específica para o servimento de tráfego (por exemplo, “satélites”) e camadas inferiores de automação de gerenciamento de máquinas no Google (por exemplo, “diskerase”). Se for necessário fornecer contexto adicional como parte do postmortem, use as seções Antecedentes e/ou Glossário (que podem ser vinculadas a documentos mais extensos). Neste caso, ambas as seções estavam em branco.

Se você não contextualizar adequadamente o conteúdo ao escrever um postmortem, o documento pode ser mal compreendido ou até mesmo ignorado. É importante lembrar que sua audiência se estende além da equipe imediata.

Detalhes-chave omitidos

Várias seções contêm resumos de alto nível, mas faltam detalhes importantes. Por exemplo:

Resumo do problema

Para interrupções que afetam vários serviços, você deve apresentar números para fornecer uma representação consistente do impacto. Os únicos dados numéricos que nosso exemplo fornece são a duração do problema. Não temos detalhes suficientes para estimar o tamanho ou o impacto da interrupção. Mesmo que não haja dados concretos, uma estimativa bem fundamentada é melhor do que nenhuma informação. Afinal, se você não sabe como medir, então você não pode saber se está resolvido!

Causas raízes e gatilho

Identificar as causas raízes e o gatilho é uma das razões mais importantes para escrever um postmortem. Nosso exemplo contém um pequeno parágrafo que descreve as causas raízes e o gatilho, mas não explora os detalhes em nível mais baixo do problema.

Esforços de recuperação

Um postmortem atua como o registro de um incidente para seus leitores. Um bom postmortem informará aos leitores o que aconteceu, como o problema foi mitigado e como os usuários foram impactados. As respostas para muitas dessas perguntas geralmente são encontradas na seção de Esforços de Recuperação, que foi deixada vazia em nosso exemplo.

Se uma interrupção justifica um postmortem, você também deve dedicar tempo para capturar e documentar com precisão os detalhes necessários. O leitor deve obter uma visão completa da interrupção e, o mais importante, aprender algo novo.

Características-chave de itens de ação ausentes

A seção de Itens de Ação (AIs) do nosso exemplo está sem os aspectos essenciais de um plano acionável para evitar a recorrência. Por exemplo:

  • Os itens de ação são principalmente mitigativos. Para minimizar a probabilidade de a interrupção ocorrer novamente, você deve incluir alguns itens de ação preventivos e correções. O único item de ação “preventivo” sugere que devemos “tornar os humanos menos propensos a erros”. Em geral, tentar mudar o comportamento humano é menos confiável do que mudar sistemas e processos automatizados. (Ou como Dan Milstein disse uma vez: “Vamos planejar um futuro onde sejamos tão estúpidos quanto somos hoje.”)
  • Todos os itens de ação foram marcados com igual prioridade. Não há como determinar qual ação abordar primeiro.
  • Os dois primeiros itens de ação na lista usam frases ambíguas como “Melhorar” e “Tornar melhor”. Esses termos são vagos e abertos à interpretação. Usar linguagem pouco clara dificulta a medição e compreensão dos critérios de sucesso.
  • Apenas um item de ação foi atribuído a um bug de rastreamento. Sem um processo de rastreamento formal, os itens de ação dos postmortems geralmente são esquecidos, resultando em interrupções.

Nas palavras de Ben Treynor Sloss, VP de Operações 24/7 do Google: “Para nossos usuários, um postmortem sem ação subsequente é indistinguível de nenhum postmortem. Portanto, todos os postmortems que seguem uma interrupção afetando os usuários devem ter pelo menos um bug P[01] associado a eles. Eu pessoalmente reviso exceções. Há muito poucas exceções.”

Apontar o dedo de maneira contraprodutiva

Todo postmortem tem o potencial de se transformar em uma narrativa culpabilizadora. Vamos dar uma olhada em alguns exemplos:

Coisas que correram mal

Toda a equipe é culpada pela interrupção, enquanto dois membros (maxone@ e logantwo@) são especificamente mencionados.

Itens de ação

O último item da lista visa sydneythree@ por ceder à pressão e gerenciar mal a transferência de responsabilidade entre locais.

Causas raízes e gatilho

dylanfour@ é responsabilizado exclusivamente pela interrupção.

Pode parecer uma boa ideia destacar indivíduos em um postmortem. No entanto, essa prática leva os membros da equipe a se tornarem avessos ao risco porque têm medo de serem envergonhados publicamente. Eles podem ser motivados a encobrir fatos críticos para entender e prevenir a recorrência.

Linguagem animada

Um postmortem é um artefato factual que deve estar livre de julgamentos pessoais e linguagem subjetiva. Ele deve considerar múltiplas perspectivas e ser respeitoso com os outros. Nosso exemplo de postmortem contém vários exemplos de linguagem indesejável:

Causas raízes e gatilho

Linguagem supérflua (por exemplo, “ignorância descuidada”)

Coisas que correram mal

Texto animado (por exemplo, “o que é ridículo”)

Onde tivemos sorte

Um exclamação de incredulidade (por exemplo, “Eu não consigo acreditar que sobrevivemos a essa!!!”)

A linguagem animada e descrições dramáticas dos eventos distraem da mensagem principal e minam a segurança psicológica. Em vez disso, forneça dados verificáveis para justificar a gravidade de uma afirmação.

Propriedade ausente 

Declarar oficialmente a propriedade resulta em responsabilidade, o que leva à ação. Nosso exemplo de postmortem contém vários exemplos de propriedade ausente:

  • O postmortem lista quatro responsáveis. Idealmente, um responsável é um único ponto de contato que é responsável pelo postmortem, acompanhamento e conclusão.
  • A seção de Itens de Ação tem pouco ou nenhum responsável para suas entradas. Itens de ação sem responsáveis claros são menos propensos a serem resolvidos.

É melhor ter um único responsável e vários colaboradores.

Público limitado

Nosso exemplo de postmortem foi compartilhado apenas entre os membros da equipe. Por padrão, o documento deveria ser acessível a todos na empresa. Recomendamos compartilhar proativamente seu postmortem o mais amplamente possível – talvez até com seus clientes. O valor de um postmortem é proporcional ao aprendizado que ele cria. Quanto mais pessoas puderem aprender com incidentes passados, menos provável será que se repitam. Um postmortem ponderado e honesto também é uma ferramenta chave para restaurar a confiança abalada.

À medida que sua experiência e conforto aumentam, você provavelmente também expandirá seu “público-alvo” para não humanos. Culturas de postmortem maduras frequentemente adicionam tags legíveis por máquina (e outros metadados) para permitir análises subsequentes.

Publicação atrasada

Nosso exemplo de postmortem foi publicado quatro meses após o incidente. No intervalo, se o incidente tivesse recorrido (o que na realidade aconteceu), os membros da equipe provavelmente teriam esquecido detalhes importantes que um postmortem oportuno teria capturado.

Bom postmortem

Este é um postmortem real. Em alguns casos, ficcionalizamos nomes de indivíduos e equipes. Também substituímos valores reais por espaços reservados para proteger informações sensíveis de capacidade. Nos postmortems que você criar para consumo interno, você deve absolutamente incluir números específicos!

Postmortem: Todas as máquinas satélite enviadas para diskerase

11 de agosto de 2014

Proprietário: 

  • Postmortem: maxone@, logantwo@
  • Automação de datacenter: sydneythree@
  • Rede: dylanfour@
  • Gerenciamento de servidores: finfive@

Compartilhado com: todos_os_funcionários_de_engenharia@google.com

Status: Final

Data do incidente: Seg, 11 de agosto de 2014, 17:10 às 17:50 PST8PDT

Publicado: Sex, 15 de agosto de 2014

Resumo executivo

Impacto: consultas de frontend interrompidas

Alguns anúncios não foram servidos

Houve um aumento de latência para todos os serviços normalmente servidos a partir de satélites por quase dois dias.

Causa raiz: Um bug na automação de desligamento fez com que todas as máquinas satélite, em vez de apenas um rack de máquinas satélite, fossem enviadas para o DisKerase. Isso resultou em todas as máquinas satélite entrando no fluxo de trabalho de decomposição, o que apagou seus discos. O resultado foi uma interrupção global do frontend de satélite.

Resumo do problema

Duração do problema:

Principais interrupções: Seg, 11 de agosto, 17:10 às 17:50 PST8PDT

Trabalho de reconstrução e dores residuais até Qua, 13 de agosto, 07:46 PST8PDT, momento em que o incidente foi encerrado.

Produto(s) afetado(s): Infraestrutura de Frontend, especificamente todas as localizações de satélite.

% do produto afetado: Global – todo o tráfego normalmente servido a partir de satélites (tipicamente 60% das consultas globais).

Impacto para o usuário: [Valor omitido] consultas de frontend foram interrompidas ao longo de um período de 40 minutos ([valor omitido] QPS em média durante o período, [valor omitido] % do tráfego global). Aumento de latência para todos os serviços normalmente servidos a partir de satélite por quase dois dias.

Impacto na receita: O impacto exato na receita é desconhecido neste momento.

Detecção: Alerta de caixa preta: a equipe de tráfego foi alertada com “satellite a12bcd34 falhando em muitas solicitações HTTP” para ~todo satélite no mundo.

Resolução: A própria interrupção foi rapidamente mitigada movendo todo o tráfego de frontend do Google para clusters principais, ao custo de latência adicional para o tráfego do usuário.

Contexto (opcional)

Se você não está familiarizado com o tráfego de frontend e as camadas inferiores da automação de serviço no Google, leia o glossário antes de continuar.

Impacto

Impacto para o usuário

  • [Valor omitido] consultas de frontend foram interrompidas ao longo de um período de [valor omitido] minutos. [Valor omitido] QPS em média durante o período, [valor omitido] % do tráfego global. Nossa monitoração sugere uma cratera muito maior; no entanto, os dados eram pouco confiáveis, pois cessaram a monitoração de satélites que ainda estavam em operação, pensando que estavam desligados. O apêndice descreve como os números acima foram estimados.
  • Houve um aumento de latência para todos os serviços normalmente servidos a partir de satélite por quase dois dias:
    • Picos de RTT de [valor omitido] ms para países próximos a clusters principais
    • Até [valor omitido] ms para localizações que dependem mais fortemente de satélites (por exemplo, Austrália, Nova Zelândia, Índia)

Impacto na receita

Alguns anúncios não foram servidos devido às consultas perdidas. O impacto exato na receita é desconhecido neste momento:

  • Display e vídeo: Os dados têm barras de erro muito amplas devido a flutuações de dia para dia, mas estimamos entre [valor omitido] % e [valor omitido] % de perda de receita no dia da interrupção.
  • Busca: Perda de [valor omitido] % a [valor omitido] % entre 17:00 e 18:00, novamente com barras de erro amplas.

Impacto na equipe

  • A equipe de Tráfego passou aproximadamente 48 horas com todos os membros disponíveis reconstruindo satélites.
  • NST (Network Systems Team) teve uma carga de interrupção/alerta maior do que o normal porque precisavam engenheirar o tráfego em links de interconexão sobrecarregados.
  • Alguns serviços podem ter observado um aumento nas respostas servidas em seus frontends devido à redução da taxa de acerto no cache nos GFEs.
    • Por exemplo, veja este tópico [link] sobre [serviço dependente de cache].
    • [Serviço dependente de cache] viu sua taxa de acerto no cache nos GFEs cair de [valor omitido] % para [valor omitido] % antes de se recuperar lentamente.

Documento do incidente

[O link para nosso documento de rastreamento de incidentes foi omitido.]

Causas raízes e desencadeante

Um antigo bug de validação de entrada no servidor de Administração de Tráfego foi acionado pela reexecução manual de um fluxo de trabalho para descomissionar o satélite a12bcd34. O bug removeu a restrição da máquina na ação de descomissionamento, enviando todas as máquinas satélite para descomissionamento.

A partir daí, a automação do datacenter executou o fluxo de trabalho de descomissionamento, apagando os discos rígidos da maioria das máquinas satélite antes que essa ação pudesse ser interrompida.

O servidor de Administração de Tráfego fornece um RPC (Procedimento de Chamada Remota) ReleaseSatelliteMachines. Este manipulador inicia o descomissionamento do satélite usando três chamadas de API MDB:

  • Procure o nome do rack associado ao nó de borda (por exemplo, a12bcd34 -> <nome do rack>).
  • Procure os nomes das máquinas associadas ao rack (<rack> -> <máquina 1>, <máquina 2>, etc.).
  • Reatribua essas máquinas para diskerase, o que indiretamente desencadeia o fluxo de trabalho de descomissionamento.

Este procedimento não é idempotente, devido a um comportamento conhecido da API MDB combinado com uma verificação de segurança ausente. Se um nó de satélite foi anteriormente enviado com sucesso para decom, o passo 2 acima retorna uma lista vazia, que é interpretada no passo 3 como a ausência de uma restrição em um nome de máquina.

Esse comportamento perigoso existe há algum tempo, mas foi ocultado pelo fluxo de trabalho que invoca a operação insegura: a etapa do fluxo de trabalho que invoca o RPC é marcada como “executar uma vez”, o que significa que o mecanismo de fluxo de trabalho não reexecutará o RPC uma vez que tenha sido bem-sucedido.

No entanto, a semântica de “execução única” não se aplica a várias instâncias de um fluxo de trabalho. Quando a equipe de Ativação de Cluster iniciou manualmente outra execução do fluxo de trabalho para a12bcd34, essa ação desencadeou o bug do servidor de administração.

Cronograma/Esforços de Recuperação

[O link para nosso registro de Cronograma foi omitido para publicação em livro. Em um postmortem real, essa informação sempre seria incluída.]

Lições aprendidas

Coisas que correram bem:

  • Evacuação da borda. Os GFEs no núcleo são explicitamente planejados em termos de capacidade para permitir que isso aconteça, assim como a espinha dorsal de produção (exceto pelos links de interconexão; veja a lista de interrupções na próxima seção). Essa evacuação da borda permitiu que a equipe de Tráfego mitigasse prontamente sem medo.
  • Mitigação automática de falhas catastróficas de satélite. Rotas de cobertura automaticamente retiram o tráfego de satélites com falha de volta para clusters principais, e os satélites se esvaziam quando é detectada uma churn anormal.
  • O descomissionamento/diskerase do satélite funcionou de forma muito eficaz e rápida, apesar de ser um vice-confuso.
  • A interrupção acionou uma rápida resposta da IMAG via OMG e a ferramenta se mostrou útil para o acompanhamento contínuo do incidente. A resposta entre as equipes foi excelente, e o OMG ajudou ainda mais a manter todos se comunicando entre si.

Coisas que correram mal

Interrupção

  • O servidor de Administração de Tráfego não possuía verificações de sanidade apropriadas nos comandos que enviava para o MDB. Todos os comandos deveriam ser idempotentes, ou pelo menos à prova de falhas em invocações repetidas.
  • O MDB não objetou à ausência de restrição de nome de host na solicitação de alteração de propriedade.
  • O fluxo de trabalho de descomissionamento não verifica solicitações de descomissionamento com outras fontes de dados (por exemplo, descomissionamentos de rack planejados). Como resultado, não houve objeções à solicitação de descarte (de muitas) máquinas geograficamente diversas.
  • O fluxo de trabalho de descomissionamento não possui limitação de taxa. Uma vez que as máquinas entraram em descomissionamento, a limpeza de disco e outras etapas de descomissionamento ocorreram na velocidade máxima.
  • Alguns links de interconexão entre o Google e o mundo estavam sobrecarregados como resultado do tráfego de saída se deslocar para locais diferentes quando os satélites pararam de servir, e suas consultas foram servidas a partir do núcleo. Isso resultou em curtos períodos de congestão para pares selecionados até que os satélites fossem restaurados, e trabalho de mitigação pela NST para se ajustar.

Recuperação

  • As reinstalações das máquinas satélite foram lentas e pouco confiáveis. As reinstalações utilizam TFTP para transmitir dados, o que funciona mal ao transmitir para satélites no final de links de alta latência.
  • A infraestrutura do Autoreplacer não foi capaz de lidar com a configuração simultânea de [valor omitido] dos GFEs no momento da interrupção. Igualar a velocidade das configurações automatizadas exigiu o trabalho de muitos SREs trabalhando em paralelo realizando configurações manuais. Os seguintes fatores contribuíram para a lentidão inicial da automação:
    • Timeouts de SSH excessivamente rigorosos impediram a operação confiável do Autoreplacer em satélites muito remotos.
    • Um processo de atualização de kernel lento foi executado independentemente se a máquina já possuía a versão correta.
    • Uma regressão de concorrência no Autoreplacer impediu a execução de mais de duas tarefas de configuração de máquina por máquina de trabalho.
    • Confusão sobre o comportamento do Autoreplacer desperdiçou tempo e esforço.
  • As verificações de segurança do delta de configuração de monitoramento (alteração de 25%) não foram acionadas quando 23% dos alvos foram removidos, mas foram acionadas quando os mesmos conteúdos (29% do que restou) foram re-adicionados. Isso causou um atraso de 30 minutos na reativação do monitoramento dos satélites.
  • “O instalador” tem uma equipe limitada. Como resultado, fazer alterações é difícil e lento.
  • O uso de superpoderes para recuperar máquinas do diskerase deixou muitos estados zumbis, causando dores contínuas na limpeza.

Onde tivemos sorte

  • Os GFEs nos clusters principais são gerenciados de forma muito diferente dos GFEs de satélite. Como resultado, eles não foram afetados pelo descomissionamento descontrolado.
  • Da mesma forma, a CDN do YouTube é executada como uma peça distinta de infraestrutura, então o serviço de vídeo do YouTube não foi afetado. Se isso tivesse falhado, a interrupção teria sido muito mais grave e prolongada.

Itens de ação

Devido à natureza abrangente deste incidente, dividimos os itens de ação em cinco temas:

  1. Prevenção/educação de riscos
  2. Resposta a emergências
  3. Monitoramento/alerta
  4. Provisionamento de satélites/borda
  5. Limpeza/diversos

Prevenção/educação de riscos

Ações: 

Auditar todos os sistemas capazes de transformar servidores ativos em pesos de papel (ou seja, não apenas reparos e fluxo de diskerase).

  • Tipo: investigar 
  • Prioridade: P1 
  • Responsável: sydneythree@ 
  • Rastreamento de bug: BUG1234

Registrar problemas para rastrear a implementação de rejeição de entradas ruins em todos os sistemas identificados em BUG1234.

  • Tipo: prevenir 
  • Prioridade: P1 
  • Responsável: sydneythree@ 
  • Rastreamento de bug: BUG1235

Não permitir que qualquer operação única afete servidores que abranjam limites de namespace/classe.

  • Tipo: mitigar 
  • Prioridade: P1 
  • Responsável: maxone@ 
  • Rastreamento de bug: BUG1236

O servidor de administração de tráfego precisa de uma verificação de segurança para não operar em mais do que [valor omitido] número de nós.

  • Tipo: mitigar
  • Prioridade: P1 
  • Responsável: dylanfour@ 
  • Rastreamento de bug: BUG1237

O servidor de administração de tráfego deve solicitar à <serviço de verificação de segurança> a aprovação do trabalho destrutivo.

  • Tipo: prevenir 
  • Prioridade: P0 
  • Responsável: logantwo@ 
  • Rastreamento de bug: BUG1238

MDB deve rejeitar operações que não fornecem valores para uma restrição esperada-presente.

  • Tipo: prevenir 
  • Prioridade: P0 
  • Responsável: louseven@ 
  • Rastreamento de bug: BUG1239

Resposta a emergências

Ações:

Garantir que o fornecimento a partir do núcleo não sobrecarregue os links de rede de saída.

  • Tipo: reparar 
  • Prioridade: P2 
  • Responsável: rileysix@ 
  • Rastreamento de bug: BUG1240

Garantir que os problemas de fluxo de decomposição sejam observados sob [o link para nosso documento de parada de emergência foi omitido] e [o link para nossa página de contato de escalonamento foi omitido].

  • Tipo: mitigar 
  • Prioridade: P2 
  • Responsável: logantwo@ 
  • Rastreamento de bug: BUG1241

Adicionar uma abordagem de desativação do grande botão vermelho* para os fluxos de decomposição.

  • Tipo: mitigar 
  • Prioridade: P0 
  • Responsável: maxone@ 
  • Rastreamento de bug: BUG1242

*Um termo geral para um interruptor de desligamento (por exemplo, um botão de desligamento de emergência) usado em circunstâncias catastróficas para evitar danos adicionais.

Monitoramento/alerta

Ações:

Os testes de segurança do alvo de monitoramento não devem permitir que você faça uma alteração que não possa ser revertida.

  • Tipo: mitigar 
  • Prioridade: P2 
  • Responsável: dylanfour@ 
  • Rastreamento de bug: BUG1243

Adicionar um alerta quando mais de [valor omitido] % de nossas máquinas foram retiradas de nós. As máquinas foram retiradas dos satélites às 16:38 enquanto o mundo começou a sinalizar apenas por volta das 17:10.

  • Tipo: detectar 
  • Prioridade: P1 
  • Responsável: rileysix@ 
  • Rastreamento de bug: BUG1244

Provisionamento de Satélite/Borda

Ações:

Utilizar o iPXE para usar HTTPS e tornar as reinstalações mais confiáveis/mais rápidas.

  • Tipo: mitigar 
  • Prioridade: P2 
  • Responsável: dylanfour@ 
  • Rastreamento de bug: BUG1245

Limpeza/diversos

Ações:

Revisar o código relacionado ao MDB em nossas ferramentas e trazer o servidor de administração de volta para desfazer ativações/desativações emperradas.

  • Tipo: reparar 
  • Prioridade: P2 
  • Responsável: rileysix@ 
  • Rastreamento de bug: BUG1246

Agendar testes DiRT:

  • Trazer de volta o satélite após diskerase.
  • Fazer o mesmo para o YouTube CDN.
    • Tipo: mitigar 
    • Prioridade: P2 
    • Responsável: louseven@ 
    • Rastreamento de bug: BUG1247

Glossário

Servidor de Administração

Um servidor RPC que permite a automação executar operações privilegiadas para a infraestrutura de atendimento ao cliente da frente. O servidor de automação está mais visivelmente envolvido na implementação de PCRs e ativações/desativações de clusters.

Autoreplace

Um sistema que move servidores não-Borgificados de uma máquina para outra. É usado para manter os serviços em execução diante de falhas de máquina e também para suportar remanejamentos e reconfigurações de colocações.

Borg

Um sistema de gerenciamento de cluster projetado para gerenciar tarefas e recursos de máquina em grande escala. Borg possui todas as máquinas em uma célula Borg e atribui tarefas às máquinas que têm recursos disponíveis.

Decom

Uma abreviação de descomissionamento. O decom de equipamentos é um processo relevante para muitas equipes operacionais.

Diskerase

Um processo (e sistemas de hardware/software associados) para limpar de forma segura os discos rígidos de produção antes de deixarem os data centers do Google. Diskerase é uma etapa no fluxo de decom.

GFE (Google Front End)

O servidor ao qual o mundo externo se conecta para (quase) todos os serviços do Google.

IMAG (Gerenciamento de Incidentes no Google)

Um programa que estabelece uma maneira padrão e consistente de lidar com todos os tipos de incidentes – desde interrupções do sistema até desastres naturais – e organizar uma resposta eficaz.

MDB (Banco de Dados de Máquinas)

Um sistema que armazena todos os tipos de informações sobre o estado do inventário de máquinas do Google.

OMG (Gerenciamento de Interrupções no Google)

Um painel/ferramenta de gerenciamento de incidentes que serve como um local central para rastrear e gerenciar todos os incidentes em andamento no Google.

Satélites

Pequenos racks de máquinas baratos que servem apenas tráfego de front-end não relacionado a vídeo, a partir da borda da rede do Google. Quase nenhuma da infraestrutura de cluster de produção tradicional está disponível para satélites. Os satélites são distintos da CDN que serve o conteúdo de vídeo do YouTube a partir da borda da rede do Google e de outros lugares na internet mais ampla. A CDN do YouTube não foi afetada por este incidente.

Apêndice

Por que o ReleaseSatelliteMachines não é idempotente?

[A resposta para esta pergunta foi omitida.]

O que aconteceu depois que o Servidor de Administração atribuiu todos os satélites à equipe de diskerase?

[A resposta para esta pergunta foi omitida.]

Qual foi a perda real de QPS durante a interrupção?

[A resposta para esta pergunta foi omitida.]

Logs do IRC

[Os registros do IRC foram omitidos.]

Gráficos

Estatísticas de latência mais rápidas – o que os satélites já fizeram por nós?

Empiricamente, a partir desta interrupção, os satélites reduziram [valor omitido] ms de latência em muitos locais próximos aos clusters principais e até [valor omitido] ms em locais mais distantes de nossa espinha dorsal:

[A explicação dos gráficos foi omitida.]

Carga de atendimento de núcleo versus borda

Uma bela ilustração do esforço de reconstrução. Conseguir atender novamente 50% do tráfego a partir da borda levou cerca de 36 horas, e retornar ao equilíbrio normal de tráfego levou mais 12 horas (consulte a Figura 10-1 e a Figura 10-2).

Esforço de peering devido a mudanças no tráfego

[Gráfico omitido.]

O gráfico mostra a perda de pacotes agregada por região de rede. Houve alguns picos curtos durante o próprio evento, mas a maioria das perdas ocorreu à medida que várias regiões entravam em pico com pouca/ou nenhuma cobertura de satélite.

Pessoa versus Máquina, edição GFE

[Explicação do gráfico sobre taxas de configuração humana versus automática omitida.]


Figura 10-1. Distribuição do QPS (Requisições por Segundo) entre Núcleo e Borda


Figura 10-2. Distribuição do QPS entre Núcleo e Borda (representação alternativa)

Por que este postmortem é melhor?

Este postmortem exemplifica várias boas práticas de escrita.

Clareza

O postmortem está bem organizado e explica os termos-chave com detalhes suficientes. Por exemplo:

Glossário

Um glossário bem escrito torna o postmortem acessível e compreensível para uma ampla audiência.

Ações

Este foi um incidente grande com muitas ações a serem tomadas. Agrupar as ações por tema facilita a atribuição de responsáveis e prioridades.

Métricas Quantificáveis

O postmortem apresenta dados úteis sobre o incidente, como taxas de acertos de cache, níveis de tráfego e duração do impacto. Seções relevantes dos dados são apresentadas com links de volta para as fontes originais. Essa transparência de dados remove ambiguidades e fornece contexto ao leitor.

Ações concretas

Um postmortem sem ações é ineficaz. Estas ações possuem algumas características notáveis:

Propriedade

Todas as ações têm tanto um responsável quanto um número de rastreamento.

Priorização

Todas as ações são atribuídas a um nível de prioridade.

Mensurabilidade

As ações possuem um estado final verificável (por exemplo, “Adicionar um alerta quando mais de X% de nossas máquinas forem retiradas de nós”).

Ação preventiva

Cada “tema” de ação possui ações de Prevenção/Mitigação que ajudam a evitar a recorrência de interrupções (por exemplo, “Não permitir que qualquer operação única afete servidores que abranjam limites de namespace/classe”).

Ausência de culpa

Os autores concentraram-se nas lacunas no design do sistema que permitiram modos de falha indesejáveis. Por exemplo:

Aspectos que ocorreram mal

Nenhum indivíduo ou equipe é culpado pelo incidente.

Causa raiz e gatilho

Foca no “que” deu errado, não em “quem” causou o incidente.

Ações

São direcionadas para a melhoria do sistema em vez de melhorar as pessoas.

Profundidade

Em vez de investigar apenas a área imediata da falha do sistema, o postmortem explora o impacto e as falhas do sistema em várias equipes. Especificamente:

Impacto

Esta seção contém muitos detalhes de diversas perspectivas, tornando-a equilibrada e objetiva.

Causa raiz e gatilho

Esta seção faz uma investigação profunda sobre o incidente e chega a uma causa raiz e gatilho.

Conclusões baseadas em dados

Todas as conclusões apresentadas são baseadas em fatos e dados. Qualquer dado utilizado para chegar a uma conclusão é vinculado a partir do documento.

Recursos adicionais

Estes apresentam informações úteis adicionais na forma de gráficos. Os gráficos são explicados para fornecer contexto aos leitores que não estão familiarizados com o sistema.

Prontidão

O postmortem foi escrito e circulado menos de uma semana após o encerramento do incidente. Um postmortem rápido tende a ser mais preciso porque as informações estão frescas na mente dos colaboradores. As pessoas afetadas pela interrupção estão esperando por uma explicação e alguma demonstração de que você tem as coisas sob controle. Quanto mais tempo você esperar, mais elas preencherão a lacuna com produtos de sua imaginação. Isso raramente funciona a seu favor!

Concisão

O incidente foi global, impactando múltiplos sistemas. Como resultado, o postmortem registrou e subsequentemente analisou muitos dados. Fontes extensas de dados, como transcrições de chat e logs do sistema, foram abstraídas, com as versões não editadas vinculadas ao documento principal. No geral, o postmortem alcança um equilíbrio entre a verbosidade e a legibilidade.

Incentivos Organizacionais 

Idealmente, a liderança sênior deve apoiar e incentivar postmortems eficazes. Esta seção descreve como uma organização pode incentivar uma cultura de postmortem saudável. Destacamos sinais de alerta de que a cultura está falhando e oferecemos algumas soluções. Também fornecemos ferramentas e modelos para simplificar e automatizar o processo de postmortem.

Modelar e reforçar o comportamento sem culpa

Para apoiar adequadamente a cultura de postmortem, líderes de engenharia devem consistentemente exemplificar comportamento sem culpa e incentivar a ausência de culpa em todos os aspectos das discussões de postmortem. Você pode usar algumas estratégias concretas para reforçar o comportamento sem culpa em uma organização.

Utilize uma linguagem sem culpa

Uma linguagem acusatória inibe a colaboração entre equipes. Considere o seguinte cenário:

Sandy perdeu um treinamento de serviço Foo e não estava certo de como executar um comando de atualização específico. O atraso acabou prolongando uma interrupção.

O SRE Jesse [para o gerente de Sandy]: “Você é o gerente; por que você não está garantindo que todos concluam o treinamento?”

A troca inclui uma pergunta tendenciosa que instantaneamente colocará o destinatário na defensiva. Uma resposta mais equilibrada seria:

SRE Jesse [para o gerente de Sandy]: “Lendo o postmortem, vejo que o responsável de plantão perdeu um treinamento importante que teria permitido resolver a interrupção mais rapidamente. Talvez os membros da equipe devam ser obrigados a concluir este treinamento antes de entrar na rotação de plantão? Ou poderíamos lembrá-los de que, se ficarem presos, devem escalar rapidamente. Afinal, a escalada não é um pecado – especialmente se ajudar a reduzir o sofrimento do cliente! A longo prazo, não devemos realmente depender tanto de treinamento, pois é fácil esquecer no calor do momento.”

Inclua todos os participantes do incidente na elaboração do postmortem

Pode ser fácil negligenciar fatores importantes que contribuíram para uma interrupção quando o postmortem é escrito isoladamente ou por uma única equipe.

Reúna feedback

Um processo de revisão claro e um plano de comunicação para postmortems podem ajudar a evitar que linguagem e perspectivas acusatórias se propaguem dentro de uma organização. Para um processo de revisão estruturado sugerido, consulte a seção “Lista de Verificação para Postmortem”

Recompense os resultados dos postmortems

Quando bem escritos, aplicados e amplamente compartilhados, os postmortems são um veículo eficaz para impulsionar mudanças organizacionais positivas e evitar interrupções repetidas. Considere as seguintes estratégias para incentivar a cultura de postmortem.

Recompense o encerramento de itens de ação

Se você recompensar os engenheiros por escrever postmortems, mas não pelo encerramento dos itens de ação associados, você corre o risco de um ciclo vicioso de postmortems não encerrados. Certifique-se de que os incentivos estejam equilibrados entre escrever o postmortem e implementar com sucesso seu plano de ação.

Recompense a mudança organizacional positiva

Você pode incentivar a implementação generalizada das lições aprendidas com os postmortems apresentando-os como uma oportunidade de expandir o impacto em toda a organização. Recompense esse nível de impacto com bônus de colegas, avaliações de desempenho positivas, promoção e similares.

Destaque a melhoria na confiabilidade

Com o tempo, uma cultura eficaz de postmortem leva a menos interrupções e sistemas mais confiáveis. Como resultado, as equipes podem se concentrar na velocidade de entrega de recursos em vez de corrigir problemas de infraestrutura. É intrinsecamente motivador destacar essas melhorias em relatórios, apresentações e avaliações de desempenho.

Destacar os proprietários de postmortem como líderes

Celebrar os postmortems por meio de e-mails ou reuniões, ou dando aos autores a oportunidade de apresentar lições aprendidas para um público, pode atrair indivíduos que apreciam reconhecimentos públicos. Estabelecer o proprietário como um “especialista” em um tipo de falha e sua prevenção pode ser gratificante para muitos engenheiros que buscam reconhecimento dos colegas. Por exemplo, você pode ouvir alguém dizer: “Converse com a Sara, ela é uma especialista agora. Ela acabou de coautoria um postmortem onde descobriu como corrigir essa lacuna!”

Gamificação

Algumas pessoas são incentivadas por um senso de realização e progresso em direção a um objetivo maior, como corrigir fraquezas do sistema e aumentar a confiabilidade. Para essas pessoas, um placar ou acompanhamento dos itens de ação do postmortem pode ser um incentivo. No Google, realizamos semanas de “FixIt” duas vezes por ano. Os SREs que fecham a maioria dos itens de ação do postmortem recebem pequenos tokens de apreciação e (é claro) o direito de se vangloriar. A Figura 10-3 mostra um exemplo de um quadro de líderes de postmortem.


Figura 10-3. Quadro de líderes de postmortem

Compartilhe postmortems abertamente

Para manter uma cultura de postmortem saudável dentro de uma organização, é importante compartilhar os postmortems o mais amplamente possível. Implementar mesmo uma das seguintes táticas pode ajudar:

Compartilhe anúncios em toda a organização

Anuncie a disponibilidade do rascunho do postmortem em seus canais de comunicação internos, por e-mail, Slack e similares. Se você tem reuniões gerais regulares da empresa, torne uma prática compartilhar um postmortem recente de interesse.

Realize revisões entre equipes

Realize revisões entre equipes de postmortems. Nessas revisões, uma equipe passa por seu incidente enquanto outras equipes fazem perguntas e aprendem vicariamente. No Google, vários escritórios têm Clubes de Leitura de Postmortem informais que são abertos a todos os funcionários. Além disso, um grupo multifuncional de desenvolvedores, SREs e líderes organizacionais revisa o processo geral de postmortem. Essas pessoas se reúnem mensalmente para revisar a eficácia do processo de postmortem e do modelo.

Realize exercícios de treinamento

Utilize a “Roda do Infortúnio” ao treinar novos engenheiros: um grupo de engenheiros reencena um postmortem anterior, assumindo os papéis descritos no postmortem. O Comandante do Incidente original comparece para ajudar a tornar a experiência o mais “real” possível.

Reporte incidentes e interrupções semanalmente

Crie um relatório semanal de interrupções contendo os incidentes e interrupções dos últimos sete dias. Compartilhe o relatório com o maior número possível de pessoas. A partir das interrupções semanais, compile e compartilhe um relatório periódico dos destaques.

Responder às falhas na cultura de postmortem

A quebra da cultura de postmortem nem sempre é óbvia. A seguir estão alguns padrões comuns de falha e soluções recomendadas.

Evitar associação

Desenvolver uma desvinculação do processo de postmortem é um sinal de que a cultura de postmortem em uma organização está falhando. Por exemplo, suponha que o Diretor de SRE, Parker, ouça a seguinte conversa:

Engenheiro de Software (SWE) Sam: Nossa, você ouviu sobre aquela grande explosão?

SWE Riley: Sim, foi terrível. Eles terão que escrever um postmortem agora.

SWE Sam: Ah não! Estou tão feliz por não estar envolvido nisso.

SWE Riley: Sim, eu realmente não gostaria de estar na reunião onde isso será discutido.

Garantir que postmortems de alta visibilidade sejam revisados em busca de linguagem acusatória pode ajudar a evitar esse tipo de evasão. Além disso, compartilhar exemplos de alta qualidade e discutir como aqueles envolvidos foram recompensados pode ajudar a reenvolver os indivíduos.

Falha em reforçar a cultura

Responder quando um executivo sênior utiliza linguagem acusatória pode ser desafiador. Considere a seguinte declaração feita pela liderança sênior em uma reunião sobre uma interrupção:

VP Ash: Eu sei que devemos ser sem culpa, mas este é um espaço seguro. Alguém deve ter sabido antecipadamente que isso era uma má ideia, então por que você não ouviu essa pessoa?

Atenue o dano movendo a narrativa em uma direção mais construtiva. Por exemplo:

SRE Dana: Hmmm, tenho certeza de que todos tinham a melhor intenção, então, para manter a abordagem sem culpa, talvez possamos perguntar genericamente se houve algum sinal de alerta que poderíamos ter seguido e por que os ignoramos.

As pessoas agem de boa fé e tomam decisões com base nas melhores informações disponíveis. Investigar a origem de informações enganosas é muito mais benéfico para a organização do que atribuir culpa.

Falta de tempo para escrever postmortems

Postmortems de qualidade levam tempo para serem escritos. Quando uma equipe está sobrecarregada com outras tarefas, a qualidade dos postmortems sofre. Postmortems de qualidade inferior, com itens de ação incompletos, tornam uma recorrência muito mais provável. Os postmortems são cartas que você escreve para futuros membros da equipe: é muito importante manter um padrão de qualidade consistente, para que você não ensine acidentalmente futuros colegas de equipe de forma inadequada. Priorize o trabalho de postmortem, rastreie a conclusão e revisão do postmortem e permita que as equipes tenham tempo adequado para implementar o plano de ação associado. As ferramentas discutidas na seção “Ferramentas e Modelos” na página 220 podem ajudar nessas atividades.

Incidentes repetidos

Se as equipes estão enfrentando falhas que refletem incidentes anteriores, é hora de investigar mais a fundo. Considere fazer perguntas como:

  • Os itens de ação estão demorando muito para serem concluídos?
  • A velocidade de implementação de recursos está prevalecendo sobre as correções de confiabilidade?
  • Os itens de ação corretos estão sendo capturados desde o início?
  • O serviço com defeito está atrasado para uma refatoração?
  • As pessoas estão apenas colocando curativos em um problema mais sério?

Se você descobriu um problema sistêmico de processo ou técnico, é hora de dar um passo para trás e considerar a saúde geral do serviço. Reúna os colaboradores do postmortem de cada incidente semelhante para discutir o melhor curso de ação para prevenir repetições.

Ferramentas e modelos 

Um conjunto de ferramentas e modelos pode iniciar uma cultura de postmortem facilitando a escrita de postmortems e o gerenciamento dos dados associados. Existem diversos recursos do Google e de outras empresas que você pode aproveitar nesse espaço.

Modelos de postmortem

Os modelos facilitam a escrita de postmortems completos e compartilhá-los em toda a organização. Usar um formato padrão torna os postmortems mais acessíveis para leitores fora do domínio específico. Você pode personalizar o modelo para atender às suas necessidades. Por exemplo, pode ser útil capturar metadados específicos da equipe, como marca/modelo de hardware para uma equipe de centro de dados, ou versões do Android afetadas para uma equipe móvel. Você pode então adicionar personalizações à medida que a equipe amadurece e realiza postmortems mais sofisticados.

Template do Google

O Google compartilhou uma versão de nosso modelo de postmortem em formato do Google Docs em http://g.co/SiteReliabilityWorkbookMaterials. Internamente, nós principalmente utilizamos o Docs para escrever postmortems porque facilita a colaboração através de direitos de edição compartilhados e comentários. Algumas de nossas ferramentas internas preenchem este modelo com metadados para facilitar a escrita do postmortem. Nós aproveitamos o Google Apps Script para automatizar partes da autoria e capturar muitos dos dados em seções e tabelas específicas para facilitar a análise de dados pelo nosso repositório de postmortem.

Ferramentas de postmortem

No momento desta escrita, as ferramentas de gerenciamento de postmortem do Google não estão disponíveis para uso externo. No entanto, podemos explicar como nossas ferramentas facilitam a cultura de postmortem.

Criação de postmortem

Nossas ferramentas de gerenciamento de incidentes coletam e armazenam muitos dados úteis sobre um incidente e os inserem automaticamente no postmortem. Exemplos de dados que inserimos incluem:

  • Comandante do incidente e outros papéis
  • Linha do tempo detalhada do incidente e logs do IRC
  • Serviços afetados e serviços de causa raiz
  • Severidade do incidente
  • Mecanismos de detecção do incidente

Lista de verificação de postmortem

Para ajudar os autores a garantir que um postmortem seja concluído corretamente, fornecemos uma lista de verificação de postmortem que guia o responsável por etapas-chave. Aqui estão apenas alguns exemplos de verificações na lista:

  • Realizar uma avaliação completa do impacto do incidente.
  • Realizar uma análise de causa raiz suficientemente detalhada para orientar o planejamento de itens de ação.
  • Garantir que os itens de ação sejam avaliados e aprovados pelos líderes técnicos do serviço.
  • Compartilhar o postmortem com toda a organização.

A lista de verificação completa está disponível em: http://g.co/SiteReliabilityWorkbookMaterials.

Armazenamento de postmortem

Armazenamos os postmortems em uma ferramenta chamada Requiem para que seja fácil para qualquer funcionário do Google encontrá-los. Nossa ferramenta de gerenciamento de incidentes envia automaticamente todos os postmortems para o Requiem, e qualquer pessoa na organização pode publicar seu postmortem para que todos vejam. Temos milhares de postmortems armazenados, datando de 2009. O Requiem analisa os metadados de cada postmortem e os disponibiliza para pesquisa, análise e relatórios.

Acompanhamento de postmortem

Nossos postmortems são armazenados no banco de dados do Requiem. Todos os itens de ação resultantes são registrados como bugs em nosso sistema centralizado de rastreamento de bugs. Consequentemente, podemos monitorar o fechamento dos itens de ação de cada postmortem. Com esse nível de rastreamento, podemos garantir que os itens de ação não sejam negligenciados, evitando serviços cada vez mais instáveis. A Figura 10-4 mostra um esboço de monitoramento de itens de ação postmortem habilitado por nossas ferramentas.


Figura 10-4. Monitoramento de itens de ação postmortem

Análise de postmortem

Nossa ferramenta de gerenciamento de postmortem armazena suas informações em um banco de dados para análise. As equipes podem usar os dados para escrever relatórios sobre as tendências de seus postmortems e identificar seus sistemas mais vulneráveis. Isso nos ajuda a descobrir fontes subjacentes de instabilidade ou disfunções de gerenciamento de incidentes que de outra forma poderiam passar despercebidas. Por exemplo, a Figura 10-5 mostra gráficos que foram construídos com nossas ferramentas de análise. Esses gráficos nos mostram tendências como quantos postmortems temos por mês por organização, duração média do incidente, tempo para detectar, tempo para resolver e raio de explosão.


Figura 10-5. Análise de postmortem

Conclusão

O investimento contínuo na promoção de uma cultura de postmortem gera dividendos na forma de menos interrupções, uma experiência geral melhor para os usuários e mais confiança das pessoas que dependem de você. A aplicação consistente dessas práticas resulta em um melhor design de sistema, menos tempo de inatividade e engenheiros mais eficazes e felizes. Se o pior acontecer e um incidente se repetir, você sofrerá menos danos, se recuperará mais rápido e terá ainda mais dados para continuar reforçando a produção.

Rolar para cima