Falhas de memória derrubaram o switch central da Salesforce e seu failover - 900 mil assinantes ficaram sem acesso

Em 6 de janeiro de 2009, o salesforce.com ficou offline. A partir das 20h39 UTC (cerca de meio-dia no horário do Pacífico), os clientes não conseguiam fazer login nem acessar seus dados de CRM; o The Register noticiou que mais de 900 mil assinantes ficaram sem acesso aos aplicativos nos quais conduzem seus negócios. O Business Insider estimou a indisponibilidade total em 30 a 40 minutos. Para uma empresa cujo discurso era que as organizações podiam confiar seus dados mais importantes à sua nuvem, quase uma hora de falha total ocorreu em pleno dia útil.

A explicação da própria Salesforce, publicada depois: "um dispositivo central de rede falhou devido a erros de alocação de memória. A falha fez com que ele parasse de transmitir dados, mas não acionou adequadamente um failover transparente para o sistema redundante, pois os erros de alocação de memória também estavam presentes no sistema de failover." Em outras palavras, o dispositivo redundante falhou da mesma forma que o primário, e a plataforma teve de ser recuperada com etapas manuais.

O incidente também expôs uma falha de segunda ordem. O painel público de status de "confiança" da Salesforce - a página que divulgava sua confiabilidade - estava fora do ar junto com o produto, de modo que os clientes não conseguiam saber se eram os únicos afetados. Centenas recorreram ao Twitter para confirmar a indisponibilidade, uma demonstração precoce de que, quando uma plataforma SaaS falha, sua camada de comunicação falha junto, a menos que seja deliberadamente mantida fora do raio de impacto.

Cerca de 40 minutos de falha total do serviço para mais de 900 mil assinantes, em pleno dia útil, sem failover funcional.

O dispositivo de failover carregava o mesmo defeito de alocação de memória que o primário que falhou, então o caminho "redundante" nunca assumiu o tráfego.

O failover não foi acionado de forma transparente; a restauração do serviço completo exigiu etapas manuais de recuperação pela equipe de operações.

O painel público de confiança estava dentro do mesmo domínio de falha, deixando os clientes às cegas e levando-os a diagnosticar a indisponibilidade por conta própria no Twitter.

Redundância construída com peças idênticas herda bugs idênticos. Se a unidade de reserva carrega o mesmo defeito que a primária, ela é um espelho, não uma margem - diversifique o caminho de failover.

A Salesforce publicou sua explicação no site de confiança, afirmou que a causa raiz havia sido "contornada pela solução alternativa" e disse que sua equipe continuaria trabalhando com fornecedores de hardware para detalhar a causa raiz e identificar correções adicionais. O The Register e a imprensa de negócios enquadraram a indisponibilidade como o "lado sombrio" da computação em nuvem para uma empresa que vendia a disponibilidade como sua vantagem central sobre o software de CRM instalado. Observadores de confiabilidade extraíram uma lição diferente: tudo falha, e o que separa os operadores é se os clientes conseguem descobrir o que está acontecendo - a comunicação, não o tempo de atividade, foi a falha.