Crash do S3 - Entenda o que aconteceu.

Amazon explica grande falha do AWS, diz que erro de empregado levou servidores off-line, promete mudanças.

Segundo matéria publicado no site GeeKWire, a Amazon disse que um membro da equipe S3 autorizado usando um playbook estabelecido executou um comando que se destinava a remover um pequeno número de servidores para um dos subsistemas S3 que é Usado pelo processo de faturamento do S3.Infelizmente, uma das entradas para o comando foi inserida incorretamente e um conjunto maior de servidores foi removido do que o previsto. "

Esses servidores afetaram outros subsistemas do S3, um dos quais era responsável por todos os metadados e informações de localização nos centros de dados do Norte da Virgínia. A Amazon teve de reiniciar esses sistemas e concluir as verificações de segurança, um processo que levou várias horas. Entretanto, tornou-se impossível concluir solicitações de rede com esses servidores. Outros serviços da AWS que dependiam do S3 para armazenamento também foram afetados.

Cerca de três horas após o início dos problemas, partes do S3 começaram a funcionar novamente.Por cerca de 1:50 pm Pacífico, todos os sistemas S3 estavam de volta ao normal. A Amazon disse que não teve que reiniciar completamente esses sistemas S3 por vários anos, eo programa tem crescido muito desde então, fazendo com que o reinício demore mais do que o esperado.

A Amazon disse que está fazendo mudanças como resultado deste evento, prometendo acelerar o tempo de recuperação dos sistemas S3. A empresa também criou novas salvaguardas para garantir que as equipes não levem demasiada capacidade de servidor off-line quando trabalham em questões de manutenção, como a desaceleração do sistema de faturamento S3.

Amazon também está fazendo mudanças em seu painel de saúde serviço , que é projetado para acompanhar as questões da AWS. A interrupção nocauteou o painel serviço de saúde por várias horas, e AWS teve de distribuir atualizações através de sua conta no Twitter e por programação em texto no topo da página. Na mensagem, a Amazon disse que fez uma mudança para espalhar esse site em várias regiões da AWS.

A Amazon concluiu sua explicação com esta mensagem:

• Finalmente, queremos nos desculpar pelo impacto que esse evento causou para nossos clientes.Enquanto estamos orgulhosos de nosso longo histórico de disponibilidade com o Amazon S3, sabemos o quão crítico este serviço é para nossos clientes, seus aplicativos e usuários finais e seus negócios. Faremos tudo o que pudermos para aprender com este evento e usá-lo para melhorar nossa disponibilidade ainda mais.

Vários observadores consultados pela GeekWire apontou para a necessidade de redundância no armazenamento em nuvem como um takeaway chave da interrupção. Redundância neste caso pode significar espalhar dados em várias regiões, de modo que uma interrupção em uma área não prejudique um site inteiro ou usando vários provedores de nuvem.

Anand Hariharan, vice-presidente de produtos para Califórnia-baseado Mountainview, Webscale Networks observou que o site de varejo da Amazon não "caiu"  durante a interrupção de terça-feira porque não coloca todos os seus ovos em uma cesta nuvem.

• Como a interrupção incrivelmente perturbadora AWS esta semana mostrou, cada provedor de nuvem pública grande experimentou - ou vai experimentar - tempo de inatividade. De fato, cada vez mais nossos clientes - particularmente aqueles que executam negócios de e-commerce - reconhecem que não podem confiar apenas em um provedor de nuvem ou em uma região. Amazon se manteve vivo e rápido porque eles fazem exatamente isso - espalhar sua infra-estrutura em várias regiões. Horas - e realmente apenas minutos - de tempo de inatividade são uma vida para as empresas. Tempo de inatividade não só custos receitas, mas a reputação da marca e confiança do consumidor, para que as empresas precisam considerar suas estratégias multi-região / multi-nuvem hoje.

FONTE: http://www.geekwire.com/2017/amazon-explains-massive-aws-outage-says-employee-error-took-servers-offline-promises-changes/

Cloud pós crash do S3

Acredito que os especialista de Cloud e Recuperação de Desastre vão concordar comigo, mas uma falha com a repotada  do S3 AWS requer uma reflexão. 

Quando se fala em comunicação, que é minha praia, fala-se que não pode parar e redundância é a palavra de ordem que direciona as soluções nas empresas. 

Acreditamos que redundância não fica apenas nas contratações de dois Links e dois roteadores, vai muito mais alem, passa pela redundância do acesso, pelo meio de acesso dos links (aéreo, terrestre), operadora distintas, por onde passa os links, as fibras,  as rotas distintas entre operadoras, quais são as rotas físicas e lógicas internas do backbone da operadora, que ruas, pontes e postes e quais equipamentos por onde passam  fim-a-fim... 

Uma coisa é certa: Não pode existir ponto comum de falha!

Não podemos abrir mão da Disponibilidade, este é o principal objeto de contratação de serviço!

Disponibilidade tem seu preço, o grau de redundância deve ser medido pelo efeito que a indisponibilidade faz ao negócio!

Um ambiente de alta disponibilidade e tolerante a falhas custa caro, mas pode fazer a diferença para o resultado do negócio!

Assim, acredito que as regras devem ser semelhantes quando se fala numa solução Cloud o grau de redundância deve ser considerado para a definição da solução a ser usada, deve ir mais além da simples redundância de Data Center e dos acessos dos links comunicação. Deve ir desde a tecnologia usada, até mesmo quantas soluções Cloud devem ser usadas.

Acredito que a discursão pós falha do S3 vai ser em tornos de uma abordagem de multicloud com múltiplos fornecedores para prover a redundância necessária para garantir disponibilidade!

Multicloud com múltiplos fornecedores vai ser tema constante nas empresas.

Quem estiver bem posicionado para ser redundante e conviver com múltiplas soluções, sairá na frente!

Qual sua opinião?