Apêndice D — Exemplo de Postmortem | Livro SRE Google

Soneto Shakespeare ++ Postmortem (incidente #465)

Data: 2015-10-21

Autores: jennifer, martym, agoogler

Estado: Completo, itens de ação em andamento

Resumo: Pesquisa de Shakespeare por 66 minutos durante um período de muito grande interesse em Shakespeare devido à descoberta de um novo soneto.

Impacto: Estimativa de 1,21 bilhão de consultas perdidas, sem impacto na receita.

Causas raiz: Falha em cascata devido à combinação de carga excepcionalmente elevada e uma fuga de recursos quando as buscas falharam devido a termos que não estavam no Shakespeare corpus. O soneto recentemente descoberto utilizou uma palavra que nunca tinha aparecido antes numa das obras de Shakespeare, que por acaso era o termo procurado pelos usuários. Em circunstâncias normais, a taxa de falhas de tarefas devido a fugas de recursos é suficientemente baixa para passar despercebida.

Gatilho: Bug latente acionado por aumento repentino no tráfego.

Resolução: Tráfego direcionado para o cluster sacrificial e capacidade 10x adicionada para mitigar a falha em cascata. Índice atualizado implantado, resolvendo a interação com o bug latente. Manutenção de capacidade extra até ao aumento do interesse público em novas passagens de soneto. Vazamento de recursos identificado e correção implantada.

Detecção: Borgmon detectou um nível elevado de HTTP 500s e paginou de plantão.

Itens de Ação:

Item de Ação	Tipo	Dono	Bug
Atualizar playbook com instruções para responder a falhas em cascata	mitigar	jennifer	n/a CONCLUÍDO
Usar condensador de fluxo para equilibrar a carga entre os clusters	prevenir	martym	Bug 5554823 TODO
Programar teste de falha em cascata durante o próximo DiRT	processo	docbrown	n/a TODO
Investigar continuamente o índice de funcionamento MR/fusão	prevenir	jennifer	Bug 5554824 TODO
Fugas de descritor de arquivo no subsistema de classificação de busca	prevenir	agoogDONEler	Bug 5554825
Adicionar recursos de redução de carga à pesquisa de Shakespeare	prevenir	agoogler	Bug 5554826 TODO
Construir testes de regressão para assegurar que os servidores respondam de forma sensata aos queries of death	prevenir	clarac	Bug 5554827 TODO
Implementar subsistema de classificação de pesquisa atualizado para produzir	prevenir	jennifer	n/a CONCLUÍDO

Congelar a produção até 2015-11-20 devido ao esgotamento do orçamento por erro ou buscar exceção devido a circunstâncias grotescas, inacreditáveis, bizarras e sem precedentes

outros

docbrown

n/a TODO

Lições aprendidas

O que ocorreu bem

O monitoramento nos alertou rapidamente para a elevada taxa (atingindo ~100%) de HTTP 500s
Rápida distribuição de Shakespeare corpus atualizado para todos os clusters

O que ocorreu mal

Estamos sem prática na resposta a falhas em cascata
Excedemos o nosso orçamento de erros de disponibilidade (em várias ordens de grandeza) devido ao aumento excepcional de tráfego que, essencialmente, resultou em falhas

Onde tivemos sorte

A lista de e-mail dos aficionados de Shakespeare tinha uma cópia do novo soneto disponível
Os logs do servidor tinham rastreamentos de pilha apontando para a exaustão do descritor de arquivo como causa da falha
Query-of-death foi resolvido ao enviar um novo índice contendo um termo de pesquisa popular

Timeline

2015-10-21 (todos os horários UTC)

14:51 Notícias relatam que um novo soneto shakespeariano foi descoberto no porta-luvas de um Deloriano
14:53 O tráfego para a pesquisa de Shakespeare aumenta 88 vezes depois que a postagem em /r/shakespeare aponta para o mecanismo de pesquisa de Shakespeare como local para encontrar um novo soneto (exceto que ainda não temos o soneto)
14:54 INÍCIO DA INTERRUPÇÃO – Os backends de pesquisa começam a derreter sob carga
14:55 docbrown recebe pager storm, ManyHttp500s de todos os clusters
14:57 Todo o tráfego para a busca de Shakespeare está falhando: ver https://monitor
14:58 docbrown começa a investigar, encontra taxa de falhas backend muito elevada
15:01 COMEÇA O INCIDENTE docbrown declara incidente #465 devido a falha em cascata, coordenação em #shakespeare, nomeia jennifer comandante do incidente
15:02 alguém por coincidência envia um e-mail para shakespeare-discuss@ re descoberta de soneto, que por acaso está no topo da caixa de entrada do martym
15:03 jennifer notifica shakespeare-incidents@ a lista do incidente
15:04 martym rastreia o texto do novo soneto e procura documentação sobre a atualização do corpus
15:06 docbrown descobre que os sintomas de falha são idênticos em todas as tarefas em todos os clusters, investigando a causa com base nos logs de aplicação
15:07 martym encontra documentação, inicia trabalho de preparação para atualização do corpus
15:10 martym adiciona soneto às obras conhecidas de Shakespeare, começa o trabalho de indexação
15:12 docbrown contata clarac e agoogler (da equipe de desenvolvimento de Shakespeare) para ajudar a examinar a base de código em busca de possíveis causas
15:18 clarac encontra uma arma do crime nos logs apontando para a exaustão do descritor de arquivo, confirma contra o código que existe vazamento se o termo que não está no corpus for pesquisado
15:20 O trabalho MapReduce do índice de martym é concluído
15:21 jennifer e docbrown decidem aumentar a contagem de instâncias o suficiente para baixar a carga em instâncias que são capazes de fazer um trabalho apreciável antes de morrerem e serem reiniciadas
15:23 docbrown a carga equilibra todo o tráfego para o cluster USA-2, permitindo o aumento da contagem de instâncias em outros clusters sem falha imediata dos servidores
15:25 martym começa a replicar o novo índice a todos os clusters
15:28 docbrown começa 2x aumento da contagem de instâncias
15:32 jennifer muda o equilíbrio de carga para aumentar o tráfego para clusters não sacrificiais
15:33 as tarefas em clusters não sacrificiais começam a falhar, os mesmos sintomas que antes
15:34 encontrado erro de ordem de grandeza nos cálculos do quadro branco, por exemplo aumento da contagem
15:36 jennifer reverte o equilíbrio de carga para resacrificar o cluster USA-2 em preparação para um aumento adicional global de 5x na contagem de instâncias (para um total de 10x na capacidade inicial)
15:36 INTERRUPÇÃO MITIGADA, índice atualizado e replicado para todos os clusters
15:39 docbrown inicia a segunda onda de aumento da contagem de instâncias para 10x a capacidade inicial
15:41 jennifer restabelece o equilíbrio de carga em todos os clusters para 1% do tráfego
15:43 taxas HTTP 500 de clusters não sacrificiais a taxas nominais, falhas de tarefas intermitentes a níveis baixos
15:45 jennifer equilibra 10% do tráfego através de clusters não sacrificiais
15:47 as taxas dos clusters não superficiais HTTP 500 permanecem dentro do SLO, não se observam falhas nas tarefas
15:50 30% do tráfego equilibrado através de clusters não sacrificiais
15:55 50% do tráfego equilibrado através de clusters não sacrificiais
16:00 TERMINA A INTERRUPÇÃO, todo o tráfego balanceado em todos os clusters
16:30 TERMINA O INCIDENTE, atingiu o critério de saída de 30 minutos de desempenho nominal

Informação de apoio:

Painel de controle,

https://monitor/shakespeare?end_time=20151021T160000&duração=7200

Fonte: Google SRE Book

Apêndice D — Exemplo de Postmortem

Lições aprendidas

Timeline

Informação de apoio:

Coloque o SRE em prática com a Elven.