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
