IaC e backups testados evitaram perda de dados quando data centers da Yandex caíram

O ataque que tirou um cliente do ar

Em outubro de 2026, uma série de ataques atingiu data centers da Yandex na Rússia. Segundo a empresa, a unidade de Sasovo foi seriamente danificada e parada por completo, parte da infraestrutura de Kaluga saiu do ar e, depois, o data center de Vladimir também parou de funcionar. O relato é da KTS, consultoria de DevOps↳DevOps29 conteúdosHabilite o Código de Segurança Azure DevOpsDevSecOps · jun 2025O que é DevOps – minha experiência como executivo nessa frenteDev (Back & Front) · abr 2026DevOps: a automação de processos de TI como estratégia de eficiência operacionalDev (Back & Front) · set 2024Ver tudo em DevSecOps → russa, publicado no Habr em 30 de outubro de 2026 pelo engenheiro Sergey Kussev (fonte).

Um cliente da KTS tinha praticamente toda a infraestrutura em um único domínio de falha do Yandex Cloud. Quando a região caiu, caíram juntas as VMs, a rede e as aplicações que dependiam delas. Não havia nada para consertar no local: era preciso reconstruir o ambiente crítico em outro lugar, sob pressão de tempo e com outras empresas competindo pelos mesmos recursos na mesma hora.

Um risco que já era conhecido antes do incidente

A infraestrutura desse cliente existia e crescia havia anos junto com o negócio, concentrada majoritariamente em um único data center. Um ano antes do incidente, a KTS havia feito uma auditoria completa, mapeado esse risco e proposto um plano de um ano: distribuir serviços, evoluir a orquestração, migrar componentes, converter configurações em código e eliminar pontos únicos de falha aos poucos.

Parte desse plano já estava pronta quando o ataque aconteceu; outra parte, não. Essa é a parte honesta do relato: nenhuma arquitetura fica resiliente da noite para o dia, e o risco se materializou antes de o trabalho terminar. Mesmo assim, o que já tinha sido feito foi o que sustentou a recuperação.

Separar tempo de engenharia de tempo de calendário

O artigo propõe uma distinção útil para qualquer incidente de infraestrutura: tempo de engenharia (quanto leva para a equipe implantar, configurar e validar) e tempo de calendário (quanto passa, na prática, entre o início da falha e o serviço voltar, incluindo esperas externas).

Parte da recuperação dependia do suporte da Yandex: a equipe repassava snapshots e organizava a exportação de dados do armazenamento de objetos (S3) conforme ficavam prontos. Os dados em si não se perderam, então o SLA de dados foi cumprido, mas a velocidade de transferência virou o gargalo. Enquanto isso, a equipe da KTS preparava em paralelo configurações, dependências e checagens, adiantando tudo o que não dependia de terceiros.

O que realmente sustentou a recuperação

Quatro camadas de preparo, construídas ao longo do ano anterior, foram o que separou esse caso de uma reconstrução do zero:

• Mapa de dependências: a equipe já sabia quais serviços afetavam diretamente as operações do negócio, quais bancos e armazenamentos eles exigiam, e em que ordem checar tudo.
• IaC com Terraform, Ansible e GitOps: permitia reproduzir componentes de infraestrutura a partir dos repositórios, em vez de recriar configurações de memória ou de prints da interface do provedor. Vários engenheiros conseguiam trabalhar em paralelo sem conflitos, e cada correção feita durante a recuperação ficava salva no código.
• Eliminação de bus factor: mais de um engenheiro conhecia a fundo o ambiente e tinha acesso à documentação e ao código, então a recuperação não dependeu de uma única pessoa disponível.
• Documentação viva: descrições de serviços, dependências, configurações e instruções de operação, testadas com um critério simples: um engenheiro que não construiu aquele sistema consegue, lendo a documentação, entender onde ele se encaixa e dar o próximo passo?

Nem todo o deploy estava descrito em IaC, porque o plano de um ano ainda não tinha terminado. Mas a equipe sabia da existência de cada componente manual, sua função e sua ordem de restauração.

O IaC não reconstruiu o sistema com um clique, mas transformou a recuperação de uma arqueologia em uma sequência de passos claros.

Sergey Kussev, engenheiro DevOps na KTSОдной кнопкой IaC систему не восстановил, зато превратил восстановление из археологии в последовательность понятных шагов.

Os backups também já haviam sido testados antes do incidente: a equipe sabia se a cópia sobreviveria ao mesmo tipo de falha da origem, quanto tempo levava para recuperá-la, qual era o RPO real, quanto tempo demorava o deploy a partir dela e quem validava o resultado. Isso tirou da mesa a pergunta mais perigosa de um desastre: será que o backup vai funcionar mesmo?

Os oito passos da recuperação

O trabalho de restauração seguiu uma sequência:

1. Definir o alvo mínimo: só o contorno sem o qual o negócio não operava, nada além disso por enquanto.
2. Cruzar conhecimento, código e dados para enxergar a cadeia de recuperação inteira antes de começar.
3. Escolher a plataforma disponível, não necessariamente a ideal, priorizando onde os recursos sairiam mais rápido.
4. Preparar a infraestrutura básica (rede, acessos, computação, componentes de plataforma) reaproveitando o que já existia em Terraform, Ansible e GitOps.
5. Restaurar os dados na velocidade permitida pelos sistemas externos, sem subir serviços dependentes antes da checagem de integridade.
6. Subir as aplicações respeitando a ordem de dependências: primeiro o que é base, depois o crítico, por último o secundário.
7. Validar cenários de usuário de ponta a ponta, não só healthcheck verde.
8. Devolver os serviços críticos à operação e só então seguir restaurando o resto.

Menos de 24 horas, mas não por mágica

Os serviços sem os quais o cliente não conseguia operar voltaram ao ar em menos de 24 horas na nova plataforma. Esse tempo incluiu a decisão do cliente sobre migrar ou esperar o data center original voltar, o trabalho técnico em si, e a espera por recursos e transferência de dados. O que não houve foi perda de dias tentando descobrir do que o sistema era composto ou recriando configurações manualmente.

No pós-mortem, a equipe separou três questões: a causa raiz (os ataques aos data centers), a extensão do impacto (concentração do contorno crítico em um único domínio de falha) e a qualidade da recuperação (ações, dados e ferramentas que trouxeram os serviços de volta). Como as limitações da arquitetura já tinham sido discutidas antes do incidente, não houve disputa sobre de quem era a culpa, e o passo seguinte de melhoria começou direto.

O que muda para quem roda serviços críticos em nuvem no Brasil

AWS tem a região sa-east-1 em São Paulo, Google Cloud tem a southamerica-east1, Azure tem a Brazil South. É comum times brasileiros concentrarem toda a carga crítica em uma única região, às vezes numa única zona de disponibilidade, pelo mesmo motivo do cliente da KTS: funcionou bem por anos e o custo de redundância parecia difícil de justificar.

O caso russo não é exótico para quem desenvolve aqui. Vale usá-lo como checklist prático antes que um incidente force a resposta sob pressão:

• A infraestrutura crítica está descrita em Terraform, Pulumi ou equivalente, ou parte dela só existe como cliques salvos na cabeça de alguém?
• Um terraform apply recriaria o ambiente numa conta vazia, ou existem dependências manuais não documentadas?
• Alguém já testou restaurar um backup de produção de verdade, cronometrando RPO e tempo de restore, ou o backup só é verificado por existir?
• Mais de uma pessoa do time sabe operar o ambiente de ponta a ponta, ou há um bus factor de um?
• RTO e RPO foram decididos junto com quem paga a conta, ou ficaram só na cabeça da equipe de infraestrutura?

O que ainda está em aberto

O cliente da KTS mudou de postura depois do incidente: o Yandex Cloud continua sendo a plataforma principal, mas os serviços críticos agora têm uma reserva para o caso de nova falha. O próximo passo, segundo Kussev, é montar um ambiente de reserva em outro provedor, decidindo entre reserva quente, morna ou fria, forma de sincronização de dados e testes regulares de failover. Esse processo tem custo e complexidade reais, e a KTS promete detalhar essa escolha em um próximo artigo.

Fonte: Habr (Rússia)