Thiago Nogueira 
Salesforce — a indisponibilidade que começou nas primeiras horas do dia e se arrastou por quase oito horas elevou o debate sobre como componentes legados e dependências internas podem transformar uma falha técnica em risco empresarial. O episódio ocorreu simultaneamente ao Dreamforce e deixou clientes sem acesso, com atrasos severos e processos automatizados comprometidos.
Como a paralisação aconteceu e como foi o restabelecimento
O problema começou às 3:50 a.m. EDT quando pedidos passaram a travar aguardando respostas de um serviço interno de login. A companhia identificou um “external dependency failure” que impactou um servidor de login legado, e relatou que componentes centrais sofreram aumento de carga, limitando a capacidade de processar requisições.
Houve bloqueio de endpoints de API, reinícios em sequência (rolling restarts) e correções aplicadas por região. Algumas instâncias apresentaram recuperação parcial já às 7:20 a.m., mas a restauração completa variou: sinais de recuperação ampla ocorreram por volta das 11 a.m., mitigação em todas as instâncias foi registrada às 11:39 a.m., e o incidente foi marcado como resolvido por volta das 2:59 p.m. EDT.
“Cloud does not eliminate architectural dependencies. It can sometimes make them less visible. And when the platform is your system of record, those hidden dependencies become an enterprise risk rather than simply a technology risk.”
A citação acima reflete a preocupação central levantada por especialistas sobre concentração de dependências e falta de isolamento adequado. Durante a recuperação, a empresa também informou que não identificou problemas com infraestrutura de terceiros.
Impactos práticos e recomendações para clientes
Além da indisponibilidade interativa, clientes relataram que jobs agendados não rodaram mesmo após o restabelecimento inicial, e que algumas instâncias precisaram de reinício manual. Para sistemas que usam a plataforma como sistema de registro, isso pode gerar um problema temporal de dados: eventos fora de ordem, duplicações ou execuções perdidas.
Uma revisão pós-incidente credível deve mapear a cadeia causal completa: gatilho inicial, propagação técnica, mitigação, recuperação e ações permanentes. Também é crucial checar integrações, filas, retries, autenticações e credenciais privilegiadas para garantir integridade e segurança após a restauração.
O que você acha? O que você acha dessa falha e do risco que dependências em nuvem representam para empresas? Para acompanhar mais, acesse nossa editoria.
Perguntas Frequentes
Como e por quanto tempo a Salesforce ficou fora do ar durante o incidente?
A Salesforce teve uma interrupção iniciada às 3:50 a.m. EDT que se estendeu por cerca de sete horas e meia, com o incidente sendo marcado como resolvido por volta das 2:59 p.m. EDT. A recuperação foi gradual: sinais amplos de retorno apareceram por volta das 11 a.m., e mitigação abrangente em todas as instâncias foi registrada às 11:39 a.m.
Qual foi a causa técnica da queda e qual componente foi afetado?
A Salesforce sofreu uma falha de dependência externa que impactou um servidor de login legado, provocando aumento de carga em componentes centrais e bloqueio de endpoints de API. A empresa também informou que não houve problemas detectados na infraestrutura de terceiros, e aplicou reinícios e correções de código por região para recuperar serviços.
O que clientes da Salesforce devem checar após a restauração do serviço?
A Salesforce anunciou investigação completa, e especialistas recomendam que clientes entrem imediatamente em fase de reconciliação e integridade. Deve-se verificar transações que falharam ou foram duplicadas, jobs agendados, filas e retries de APIs, consistência de registros e comportamentos de autenticação e credenciais usadas durante a recuperação.
