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