blast-radius
4 conteúdos publicados sobre este assunto.
Architecture Studies· 4
Post-mortemAzure (2026): Sobrecarga de Workloads GenAI e o Blast Radius CompartilhadoEm 29 de maio de 2026, a Microsoft Azure sofreu um incidente de disponibilidade ligado à saturação de infraestrutura de roteamento compartilhada por workloads de IA generativa de primeira-parte. O evento expôs o risco clássico de noisy neighbor em escala de nuvem hiper-escalável e levou a Microsoft a migrar cargas GenAI próprias para planos de roteamento dedicados. Esta análise reconstrói o incidente, avalia as decisões de arquitetura envolvidas e extrai lições aplicáveis a qualquer plataforma que hospede inferência de LLM em infraestrutura multi-tenant.Abrir Post-mortemCrowdStrike (2024): o content update que derrubou 8,5 milhões de máquinas WindowsEm 19 de julho de 2024, uma atualização de conteúdo do sensor Falcon da CrowdStrike causou leitura fora dos limites em um driver de kernel Windows, provocando BSOD em escala global e paralisando infraestruturas críticas em aviação, saúde e finanças. A ausência de rollout progressivo para atualizações de conteúdo e uma falha no validador interno foram os vetores centrais do incidente. Este post-mortem examina a cadeia de falhas, o blast radius real e as lições arquiteturais que todo engenheiro que opera software em kernel-space deve internalizar.Abrir Post-mortemDatadog (2023): como um patch de segurança do systemd derrubou 5 regiões simultaneamenteEm março de 2023, uma atualização automática de segurança do systemd-networkd reiniciou o subsistema de rede em dezenas de milhares de nós Kubernetes do Datadog ao mesmo tempo, cortando a conectividade gerenciada pelo Cilium em múltiplas regiões. O incidente expôs os riscos de auto-updates de SO sem controle de blast radius, a dependência crítica de CNI plugins no plano de dados e a ausência de isolamento regional em pipelines de atualização.Abrir Post-mortemAWS S3 us-east-1 (2017): quando um typo derruba a internetEm 28 de fevereiro de 2017, um engenheiro da AWS executou um comando de debug com um parâmetro incorreto e removeu uma quantidade muito maior de servidores do subsistema de indexação do S3 do que o pretendido. O resultado foi quatro horas de degradação severa em us-east-1 que afetou centenas de serviços dependentes — de ferramentas de monitoramento a grandes plataformas SaaS. O incidente expôs fragilidades estruturais em torno de dependências implícitas, ausência de rate limiting em operações destrutivas e a falácia de assumir que uma única região AWS seria suficientemente resiliente.Abrir 