Ruptura de serviço do Amazon S3

LEIA ISTO PRIMEIRO:

Precisamos divulgar que este EXAMPLE RCA é baseado em informações publicamente disponíveis publicadas em um único relatório pela Amazon e não em qualquer investigação independente conduzida pela Sologic. A Sologic não investigou este incidente em nenhuma função oficial, e não queremos sugerir que estivéssemos de alguma forma associados a este evento. O único objetivo deste relatório de análise de causa raiz é que ele seja usado como um exemplo para nossos alunos e outras partes interessadas.

Uma análise de causa raiz tem dois objetivos principais: 1) Organizar uma ampla variedade de informações de fontes diferentes de uma maneira que facilite a compreensão, e 2) Identificar um conjunto de soluções baseadas em evidências para apresentar aos tomadores de decisão. Os relatórios de interrupção de TI costumam ser vagos e cheios de termos técnicos. Esse estilo os torna um pouco opacos para aqueles que estão fora do setor. Mas não precisa ser assim - um gráfico de causa e efeito fornece uma referência visual agradável para acompanhar o relatório. O gráfico coloca as interações causais no contexto com relação ao tempo, permitindo que o leitor veja como o evento se desenrolou.

Algumas reflexões sobre TI e análise de causa raiz em geral, não necessariamente associadas a esse evento específico. Tem sido nossa experiência que os profissionais de TI são extremamente inteligentes. Mas no nível macro, a TI é relativamente nova no mundo da solução padronizada de problemas. Muitos esforços de ITSM concentram-se primeiro no Gerenciamento de Incidentes, com a intenção de manter o Gerenciamento de Problemas em algum momento posterior. Quando um grande problema como o detalhado neste exemplo ocorre, os profissionais de TI estão sob extrema pressão para concluir a investigação o mais rápido possível. Muitas vezes, surgem novos problemas que precisam de atenção. E seus clientes estão exigindo respostas. Junte esse ambiente ao fato de que esses sistemas são complexos e a equipe de investigação é muitas vezes inexperiente com a análise de causa raiz, e você obtém as condições corretas para uma investigação abaixo do ideal. Isso nem sempre é o caso - apenas uma observação baseada em nossa experiência.

O problema com isso é a exposição contínua ao risco, mesmo quando são tomadas medidas para resolver formalmente o problema. Um investimento em uma investigação formal de causa-raiz deve financiar uma redução no risco. O risco de recorrência do problema está diretamente relacionado à qualidade das soluções implementadas pela equipe, e a qualidade da solução depende de uma análise de causa raiz lógica, completa e baseada em evidências. Quando as conseqüências da falha são altas, um investimento em capacidade de RCA compensa em grande escala. Esse investimento inclui treinamento, software e consultoria (tudo o que a Sologic fornece). Mas igualmente importante é a liderança de investimento no gerenciamento de mudanças. Construir capacidade requer a estrutura de um programa de ACR, e isso requer o reconhecimento pela liderança de que seu sucesso se deve à capacidade coletiva de solução de problemas da organização. Isso é particularmente verdadeiro em TI.

Se possível, considere imprimir o relatório de resumo a seguir e acompanhe o gráfico de causa e efeito ao ler o relatório. Observe as soluções que a Amazon implementou, juntamente com as causas que elas controlam. O que você acha?
 

Link para: Orignal Amazon Report

Em 28 de fevereiro de 2017, a Amazon Web Services (AWS) sofreu uma interrupção do serviço que afetou a Região EAST-1 dos EUA. A interrupção começou às 9h37 e durou até o serviço ser restaurado às 13h54. O sistema primário impactado foi o Amazon Simple Storage Service (S3). Outros serviços, incluindo o Amazon Elastic Compute Cloud (EC2), o Amazon Elastic Block Store (EBS) e o AWS Lambda - todos dependentes do S3 - foram afetados por várias horas a mais.

Note que pode ter havido impactos adicionais, mas eles não foram relatados publicamente. Para os propósitos de um exemplo, tudo bem. Em uma ACR real, gostaríamos de documentar os impactos detalhadamente.

Serviço S3 indisponível:

O Serviço S3 caiu quando um técnico estava com problemas para solucionar o problema do sistema de faturamento S3. O técnico estava tentando remover um pequeno número de servidores, o que não afetaria a disponibilidade do serviço. Mas, em vez disso, ele removeu um conjunto muito maior de servidores. Isso desestabilizou o Serviço S3, derrubando o sistema. O técnico estava seguindo um conjunto aprovado de procedimentos (o que o relatório da Amazon chama de "playbook estabelecido"), mas o técnico digitou um comando incorretamente. Não está claro se isso foi simplesmente um erro da parte do técnico, ou se houve um problema com o próprio livro de exercícios. Aparentemente, o sistema não possui proteções secundárias para evitar que esse comando seja executado, no entanto, parâmetros específicos de design do sistema não foram relatados. Uma RCA real percorrerá esse caminho para identificar como os sistemas são projetados, os riscos identificados e as ações preventivas implementadas.

4:17 Obrigatório para o S3 Recuperar:

Uma reinicialização completa do Index Subsystem foi necessária para trazer o S3 novamente online (tempo requerido = 3:41). Posteriormente, o subsistema de colocação precisou de tempo para recuperar (tempo necessário = 0:36). O sistema S3 experimentou um crescimento maciço nos últimos anos, o que aumentou sua complexidade. Há um histórico de recuperação limitado para este sistema. Isso porque esse sistema é geralmente confiável e, portanto, não passou por um reinício total em muitos anos.

Saiba mais sobre a Sologic RCA