Há mais de uma dez, o noção de post-mortem “simples” mudou a forma uma vez que as empresas de tecnologia reconhecem falhas em grande graduação.
John Allspaw, que cunhou o termo durante seu procuração na Etsy, argumentou que as autópsias tinham tudo a ver com controlar nossa reação originário a um incidente, que é indicar o dedo: “Uma opção é assumir que a única razão é a incompetência e gritar com os engenheiros para fazê-los 'prestar atenção!' ou 'tenha mais desvelo!' Outra opção é indagar com atenção uma vez que o acidente realmente aconteceu, tratar os engenheiros envolvidos com reverência e aprender com o evento.”
O que podemos, por sua vez, aprender com algumas das autópsias mais honestas e inocentes – e públicas – dos últimos anos?
GitLab: 300 GB de dados do usuário perdidos em segundos
O que aconteceu: Em 2017, o GitLab passou por uma dolorosa interrupção de 18 horas. Essa história, e a subsequente honestidade e transparência do GitLab, impactaram significativamente a forma uma vez que as organizações lidam com a segurança de dados hoje.
O incidente começou quando o banco de dados secundário do GitLab, que replicava o primordial e agia uma vez que failover, não conseguia mais sincronizar as alterações com rapidez suficiente devido ao aumento da fardo. Supondo que um ataque de spam temporário criou essa fardo, os engenheiros do GitLab decidiram ressincronizar manualmente o banco de dados secundário, excluindo seu teor e executando o script associado.
Quando o processo de ressincronização falhou, outro engenheiro tentou o processo novamente, somente para perceber que o havia executado no primordial.
O que foi perdido: Embora o engenheiro tenha interrompido o comando em dois segundos, ele já havia excluído 300 GB de dados recentes de usuários, afetando as estimativas do GitLab, 5.000 projetos, 5.000 comentários e 700 novas contas de usuários.
Uma vez que eles se recuperaram: uma vez que os engenheiros tinham concluído de excluir o teor do banco de dados secundário, eles não puderam usá-lo para a finalidade pretendida uma vez que failover. Pior ainda, os backups diários do banco de dados, que deveriam ser carregados no S3 a cada 24 horas, falharam. Devido a uma feição incorreta do e-mail, ninguém recebeu os e-mails de notificação informando isso.
Em qualquer outra situação, a única opção seria restaurar o momentâneo anterior, que tinha quase 24 horas. Aconteceu um evento muito feliz: somente 6 horas antes da perda de dados, um engenheiro tirou um momentâneo do banco de dados primordial para teste, salvando inadvertidamente a empresa de 18 horas adicionais de perda de dados.
Depois de 18 horas terrivelmente lentas de transcrição de dados em discos de rede lentos, os engenheiros do GitLab restauraram totalmente o serviço.
O que aprendemos
- Analise suas causas raízes com o “Cinco porquês.” Os engenheiros do GitLab fizeram um trabalho assombroso em sua necropsia explicando a razão raiz do incidente. Não foi que um engenheiro tenha excluído acidentalmente os dados de produção, mas sim que um sistema automatizado denunciou erroneamente um funcionário do GitLab por spam – a remoção subsequente causou o aumento da fardo e dessincronização primária<->secundária.
Quanto mais profundamente você diagnosticar o que deu incorrecto, melhor será provável erigir sistemas de segurança de dados e perpetuidade de negócios que abordem a longa masmorra de eventos infelizes que podem ocasionar falhas novamente.
- Compartilhe seu roteiro de melhorias. O GitLab tem operado continuamente com extrema transparência, o que se aplica a esta interrupção e perda de dados. Na sequência, os engenheiros criaram dezenas de questões públicas discutindo seus planos, uma vez que testar cenários de recuperação de desastres para todos os dados que não estavam em seu banco de dados. Tornar públicas essas correções deu aos seus clientes garantias precisas e compartilhou aprendizados com outras empresas de tecnologia e startups de código simples.
- Os backups precisam de propriedade. Antes deste incidente, nenhum engenheiro do GitLab era responsável por validar o sistema de backup ou testar o processo de restauração, o que significava que ninguém o fazia. Os engenheiros do GitLab rapidamente atribuíram a um membro de sua equipe o recta de “parar a traço” se os dados estivessem em risco.
Leia o resto: Postmortem da interrupção do banco de dados em 31 de janeiro.
Tarsnap: Decidindo entre dados seguros versus disponibilidade
O que aconteceu: Certa manhã, no verão de 2023, esse serviço de backup individual ficou completamente offline.
Tarsnap é dirigido por Colin Percival, que trabalha no FreeBSD há mais de 20 anos e é o grande responsável por trazer esse sistema operacional para o serviço de computação em nuvem EC2 da Amazon. Em outras palavras, poucas pessoas entenderam melhor uma vez que o FreeBSD, o EC2 e o Amazon S3, que armazenavam os dados dos clientes da Tarsnap, poderiam trabalhar juntos… ou falhar.
O serviço de monitoramento de Colin notificou-o de que o servidor médio Tarsnap EC2 estava offline. Ao verificar a integridade da instância, ele imediatamente encontrou danos catastróficos no sistema de arquivos – ele soube imediatamente que teria que reconstruir o serviço do zero.
O que foi perdido: Sem backups de usuários, graças a duas decisões inteligentes da secção de Colin.
Primeiro, Colin construiu o Tarsnap em um sistema de arquivos estruturado em log. Enquanto armazenava logs em cache na instância EC2, ele armazenou todos os dados no armazenamento de objetos S3, que tem suas próprias estratégias de resiliência e recuperação de dados. Ele sabia que os backups dos usuários do Tarsnap eram seguros – o repto era torná-los facilmente acessíveis novamente.
Segundo, quando Colin construiu o sistema, ele escreveu scripts de automação, mas não os configurou para serem executados de forma autônoma. Em vez de permitir que a infraestrutura fosse reconstruída e reiniciasse os serviços maquinalmente, ele queria verificar ele mesmo o estado antes de permitir que os scripts assumissem o controle. Ele escreveu: “'Prevenir a perda de dados se um tanto quebrar' é muito mais importante do que 'maximizar a disponibilidade do serviço'”.
Uma vez que eles se recuperaram: Colin iniciou uma novidade instância do EC2 para ler os logs armazenados no S3, o que levou muro de 12 horas. Depois de emendar alguns bugs em seu script de restauração de dados, ele conseguiu “reproduzir” cada ingresso de log na ordem correta, o que levou mais 12 horas. Com os logs e os dados do conjunto S3 mais uma vez devidamente associados, o Tarsnap estava instalado e funcionando novamente.
O que aprendemos
- Teste regularmente seu manual de recuperação de desastres. No oração público sobre a interrupção e a postmortem, os usuários do Tarsnap expressaram sua surpresa pelo vestimenta de Colin nunca ter tentado seus scripts de recuperação, o que teria revelado vários bugs que atrasaram significativamente sua capacidade de resposta.
- Atualize seus processos e configurações para corresponder às mudanças tecnológicas. Colin admitiu nunca atualizar seus scripts de recuperação com base nos novos recursos dos serviços nos quais Tarsnap confiava, uma vez que S3 e EBS. Ele poderia ter lido os dados de log do S3 usando mais de 250 conexões simultâneas ou provisionado um volume EBS com maior rendimento para reduzir o tempo de recuperação totalidade.
- Faça verificações humanas para coletar detalhes sobre seu estado antes de deixar a automação fazer o trabalho pesado. Não há uma vez que expressar exatamente o que teria realizado se Colin não tivesse incluído alguns “cintos de segurança” em seu processo de recuperação, mas isso ajudou a evitar um erro uma vez que o do pessoal do GitLab.
Leia o resto: 02/07/2023 — 03/07/2023 interrupção do Tarsnap post-mortem
Roblox: 73 horas de ‘contenção’
O que aconteceu: Por volta do Halloween de 2021, um jogo jogado por milhões de pessoas todos os dias em uma infraestrutura de 18.000 servidores e 170.000 contêineres sofreu uma interrupção totalidade.
O serviço não caiu de uma só vez – algumas horas depois que os engenheiros da Roblox detectaram um único cluster com subida fardo de CPU, o número de jogadores online caiu para 50% inferior do normal. Nascente cluster hospedava o Consul, que funcionava uma vez que um middleware entre muitos serviços Roblox distribuídos, e quando o Consul não conseguia mais mourejar nem mesmo com a subtracção do número de jogadores, tornou-se um ponto único de omissão para toda a experiência online.
O que foi perdido: Somente dados de feição do sistema. A maioria dos serviços Roblox usava outros sistemas de armazenamento em seus data centers locais. Para aqueles que usaram o armazenamento de valores-chave da Consul, os dados foram armazenados depois que os engenheiros resolveram os problemas de fardo e contenção ou armazenados em cache com segurança em outro lugar.
Uma vez que eles se recuperaram: Os engenheiros da Roblox primeiro tentaram reimplantar o cluster Consul em um hardware muito mais rápido e, em seguida, permitiram que novas solicitações entrassem no sistema muito lentamente, mas nenhuma delas funcionou.
Com a ajuda dos engenheiros da HashiCorp e muitas horas de trabalho, as equipes finalmente identificaram duas causas principais:
- Contenção: Depois de desenredar por quanto tempo as gravações do Consul KV ficaram bloqueadas, as equipes perceberam que a novidade arquitetura de streaming do Consul estava sob fardo pesada. Os dados recebidos disputavam canais Go projetados para simultaneidade, criando um ciclo vicioso que somente aumentou o gargalo.
- Um bug muito inferior: Consul usa um banco de dados de código simples, BoltDB, para armazenar logs. Ele deveria limpar entradas de log antigas regularmente, mas nunca liberou verdadeiramente o espaço em disco, criando uma fardo de trabalho de computação pesada para o Consul.
Depois de emendar esses dois bugs, a equipe Roblox restaurou o serviço – estressantes 73 horas posteriormente o primeiro alerta de CPU subida.
O que aprendemos
- Evite sistemas de telemetria rodear. Os sistemas de telemetria da Roblox, que monitoravam o cluster Consul, também dependiam dele. Na estudo post-mortem, eles admitiram que poderiam ter agido mais rapidamente com dados mais precisos.
- Olhe dois, três ou quatro passos além do que você construiu para as causas raízes. A infraestrutura moderna baseia-se numa enorme masmorra de fornecimento de serviços de terceiros e software de código simples. Sua próxima interrupção pode não ser causada por um erro honesto de um engenheiro, mas sim pela exposição de um bug idoso em uma subordinação, três etapas removidas do seu código, que ninguém mais tinha somente o envolvente claro para acionar.
Leia o resto: Roblox Retorno ao serviço 28/10 a 31/10, 2021
Cloudflare: um longo término de semana (pronto pelo estado)
O que aconteceu: Poucos dias antes do Dia de Ação de Graças de 2023, um invasor usou credenciais roubadas para acessar o servidor Atlassian lugar da Cloudflare, que executava Confluence e Jira. Pouco tempo depois, eles usaram essas credenciais para fabricar uma conexão persistente com essa secção da infraestrutura global da Cloudflare.
O invasor tentou se movimentar lateralmente pela rede, mas teve chegada recusado a cada passo. No dia seguinte ao Dia de Ação de Graças, os engenheiros da Atlassian removeram permanentemente o invasor e derrubaram o servidor Atlassian afetado.
Em seu post-mortem, a Cloudflare afirma confiar que o invasor foi bravo por um estado-nação ansioso por chegada generalizado à rede da Cloudflare. O invasor abriu centenas de documentos internos no Confluence relacionados à arquitetura de sua rede e às práticas de gerenciamento de segurança.
O que foi perdido: Sem dados do usuário. A arquitetura Zero Trust da Cloudflare evitou que o invasor saltasse do servidor Atlassian para outros serviços ou acessasse dados do cliente.
A Atlassian tem sido notícia por outro motivo ultimamente: sua oferta de servidores atingiu o término de sua vida útil, forçando as organizações a transmigrar para alternativas de nuvem ou data center. Durante ou posteriormente esse longo processo, os engenheiros percebem que sua novidade plataforma não vem com os mesmos recursos de segurança e backup de dados com os quais estavam acostumados, forçando-os a repensar suas práticas de segurança de dados.
Uma vez que eles se recuperaram: depois de inicializar o invasor, os engenheiros da Cloudflare alternaram mais de 5.000 credenciais de produção, fizeram a triagem de 4.893 sistemas e recriaram a imagem e reinicializaram todas as máquinas. Uma vez que o invasor tentou acessar um novo data center no Brasil, a Cloudflare substituiu todo o hardware por extrema prevenção.
O que aprendemos
- Arquiteturas Zero Trust funcionam. Ao fabricar um recta de autorização/autenticação, você evita que um sistema comprometido exclua dados ou opere uma vez que um trampolim para movimentos laterais na rede.
- Apesar da exposição, a documentação ainda é sua amiga. Seus engenheiros sempre precisarão saber uma vez que reinicializar, restaurar ou reconstruir seus serviços. Seu objetivo é que mesmo que um invasor aprenda tudo sobre sua infraestrutura por meio de sua documentação interna, eles ainda não deverão ser capazes de fabricar ou roubar as credenciais necessárias para invadir ainda mais profundamente.
- A segurança SaaS é mais fácil de ignorar. Essa intrusão só foi provável porque os engenheiros da Cloudflare não conseguiram intercalar credenciais para aplicativos SaaS com chegada administrativo aos seus produtos Atlassian. A razão raiz? Eles acreditavam que ninguém ainda usava essas credenciais, portanto não fazia sentido alterná-las.
Leia o resto: Incidente de segurança do Dia de Ação de Graças de 2023
O que vem a seguir para sua segurança de dados e planejamento de perpetuidade?
Essas análises retrospectivas, que detalham exatamente o que deu incorrecto e explicam uma vez que os engenheiros estão evitando outra ocorrência, são mais do que somente bons modelos de uma vez que uma organização pode agir com honestidade, transparência e empatia pelos clientes durante uma crise.
Se você puder tirar uma única prelecção de todas essas situações, alguém na sua organização, seja um engenheiro cobiçoso ou uma equipe inteira, deve ser responsável pelo ciclo de vida da segurança dos dados. Teste e documente tudo porque só a prática leva à sublimidade.
Mas também reconheça que todos esses incidentes ocorreram na nuvem própria ou na infraestrutura lugar. Os engenheiros tiveram chegada totalidade aos sistemas e dados para diagnosticá-los, protegê-los e restaurá-los. Você não pode expressar o mesmo sobre as muitas plataformas SaaS baseadas em nuvem que seus colegas usam diariamente, uma vez que controle de versão de código e gerenciamento de projetos no GitHub ou implantação de campanhas lucrativas de e-mail via Mailchimp. Se um tanto suceder com esses serviços, você não poderá simplesmente usar o SSH para verificar os logs ou sincronizar novamente seus dados.
À medida que a shadow IT cresce exponencialmente (um aumento de 1.525% em somente sete anos), as melhores estratégias de perpetuidade não cobrirão a infraestrutura que você possui, mas os dados SaaS dos quais seus pares dependem. Você pode esperar por uma novidade estudo retrospectiva para fornecer recomendações sólidas sobre a fronteira de dados SaaS… ou tomar as medidas necessárias para prometer você é não aquele que está escrevendo.
