quinta-feira, 18 de dezembro de 2014

CONTO DE FALHA: Microsoft oferece tintim por tintim conta interrupção Azure


A Microsoft publicou um relato completo, franco e feio de apenas o que deu errado quando Azure Storage entrou total incapacidade para apoiar o desempenho Usual - TITSUP - Modo em novembro.


O cerne do problema era que os procedimentos de atualização da Azure e código tinha "... uma lacuna no conjunto de ferramentas de implantação que se baseou em decisões humanas e protocolo."







No momento do incidente, a Microsoft disse que ela foi causada por "... uma questão que resultou na frente blob armazenamento termina entrando em um loop infinito, que ainda não foram detectados durante a luta (teste)."


Microsoft diz que seu processo flighting funciona assim:


"Há dois tipos de implantações Azure armazenamento: implantações de software (ou seja, código de publicação) e implantações de configuração (ou seja, configurações de mudar). Ambas as implantações de software e de configuração exigem múltiplas fases de validação e estão gradativamente implantado para a infraestrutura Azure em pequenos lotes. Esta abordagem de implementação progressiva é chamado de 'flighting.' Quando os voos estão em andamento, nós monitoramos de perto exames de saúde. Como o uso e testes continuaram demonstra resultados bem sucedidos, vamos implantar a mudança a fatias adicionais em toda a infraestrutura Azure Storage ".

A nova análise dos dedos interrupção flighting defeituoso como a causa da confusão, dizendo que começou com "uma mudança de software para melhorar o desempenho Azure Storage, reduzindo a pegada de CPU dos Azure Storage Table front-ends".


Durante a atualização, "A política de implementação flighting padrão de forma incremental implantar as alterações em pequenas fatias não foi seguido." O engenheiro fazendo a atualização "acreditava que porque a mudança já havia sido veiculado em uma parte da infra-estrutura de produção por várias semanas, permitindo que este em toda a infra-estrutura foi de baixo risco. "


Mas não foi, porque "o interruptor de configuração foi incorretamente habilitado para armazenamento Azure Blob front-ends".


"Habilitando essa mudança no armazenamento Azure Blob front-ends exposto um erro que resultou em algumas Azure Blob Storage front-ends entrar em um loop infinito e incapaz de solicitações de serviço."


Microsoft tem mudado desde seus processos e "lançou uma atualização para o nosso sistema de ferramentas de implementação para assegurar o cumprimento dos testes acima e políticas flighting para atualizações padrão, se o código ou de configuração."


Essas atualizações significa "política é agora aplicada pela própria plataforma de implementação."


Microsoft de ser muito aberto sobre esta questão. Não só existe um detalhado artigo sobre a bagunça, há também uma entrevista em vídeo com mais detalhes.


Essa é uma quantidade incomum de material explicativo para qualquer incidente e um despejo muito mais detalhada do que os rivais nublados ofereceram segundo as suas próprias interrupções.


Com os serviços em nuvem agora difícil diferenciar no preço, e muitas vezes não altamente diferenciadas em termos de recursos, talvez este tipo de clientes a abertura de balanço? Ou é mais seguro assumir que se a Microsoft tem um grande SNAFU assim dentro dele, há outros à espera de acontecer e Azure é melhor evitar?


Você é o juiz. ®



Nenhum comentário:

Postar um comentário