Yandex bloqueia parte das funções do 360 e do Disk após ataque de drone ao terceiro data center

O Yandex restringiu parte das funções principais da plataforma Yandex 360 e do armazenamento em nuvem Disk. O motivo foi o ataque de um drone ao terceiro data center da companhia. Segundo a RBC, a direção tomou a decisão em caráter de emergência para proteger a infraestrutura de TI de uma sobrecarga crítica. Os materiais disponíveis não trazem a lista de recursos desativados nem dados sobre danos físicos, de modo que parte das conclusões abaixo continua sendo hipótese de trabalho.

O que se sabe até agora

Há poucos fatos, e eles cabem em uma lista curta:

• Produtos afetados: Yandex 360 (plataforma de trabalho da companhia) e o armazenamento em nuvem Disk.
• Natureza das medidas: bloqueio de parte das funções principais, e não o desligamento completo dos serviços.
• Motivação: evitar uma sobrecarga crítica da infraestrutura.
• Fonte: RBC, com repercussão no Hi-Tech em 12 de outubro de 2026.
• Número do incidente: o título fala do terceiro data center, o que indica que não se trata de um episódio isolado.

Não foi divulgado quanta capacidade saiu do ar, se a replicação de dados foi comprometida nem quando as restrições serão retiradas.

Por que a sobrecarga é tão perigosa quanto o ataque

Quando parte da capacidade cai, a carga é redistribuída para os sites que continuam de pé. Os clientes, nesse momento, não ficam parados. Aplicativos repetem requisições que falharam, os clientes desktop do Disk tentam sincronizar arquivos, e os serviços de e-mail e de escritório batem nos mesmos back-ends. Forma-se uma avalanche, e até nós intactos podem cair sob ela.

Por isso os engenheiros recorrem ao load shedding: desativam de propósito as funções menos críticas e mais caras para preservar o funcionamento básico. Em geral, as primeiras a serem cortadas são operações pesadas em segundo plano, como sincronização em massa, geração de miniaturas, indexação ou upload de grandes volumes. É uma prática comum no setor. Nos materiais citados, a companhia não especifica quais opções o Yandex desativou.

Para o armazenamento, a situação é mais delicada. Se parte das réplicas foi afetada, o sistema gasta recursos para restaurar a redundância dos dados, e cada requisição extra de usuário tira recursos da tarefa mais crítica, a integridade dos arquivos. Nesse modo, a limitação de funções parece mais uma medida de precaução para proteger os dados do que um incômodo imposto aos usuários.

O que ainda falta para ter o quadro completo

As principais perguntas continuam sem resposta. Quantos sites foram afetados e que fatia da capacidade total foi atingida? Os serviços de nuvem para clientes corporativos foram afetados, ou apenas os produtos de consumo? A companhia tem regiões de reserva com capacidade suficiente para uma substituição completa? Um terceiro incidente seguido, se o título estiver correto, transforma a questão: deixa de ser uma falha pontual e passa a ser um problema de projeto. A proteção física e a distribuição geográfica dos data centers se tornam parte da arquitetura tanto quanto a redundância de energia.

Outro ponto a acompanhar é como a redução de capacidade vai afetar as demais cargas da companhia, incluindo a nuvem e os serviços de ML em sites compartilhados. Não há confirmação direta disso, mas, quando falta poder de computação, as prioridades inevitavelmente mudam.

O que fazer: usuários e empresas

Enquanto o Yandex não publica os detalhes, o razoável é seguir o básico de higiene digital:

• Faça uma cópia local ou externa dos arquivos críticos do Disk, se a sincronização ainda estiver funcionando. Não inicie um download em massa de tudo: isso aumentaria a carga sobre o sistema.
• Verifique quais processos de negócio dependem do Yandex 360: calendário, e-mail, documentos compartilhados. Prepare canais alternativos de comunicação para a equipe.
• Consulte os termos do SLA e as regras de compensação, caso os serviços façam parte de um contrato corporativo.
• Acompanhe os comunicados oficiais da companhia: são eles que vão definir quando e em que ordem as funções voltarão.

Para gestores de TI, a lição é prática: uma dependência única de nuvem, sem plano de degradação controlada, vira um ponto único de falha, mesmo que o provedor tenha vários data centers.