Dev DELETOU banco de dados de empresa bilionária

Hoje a gente vai contar uma história sobre como Gitlab acidentalmente deletou o banco de dados em produção. Isso é um estudo de caso perfeito pra gente aprender o que que a gente nunca vai fazer, né? Vamos aprender umas lições disso daqui.

A gente vai analisar esse caso. Assim como lito, aviões e música analisa o caso de um desastre de uma aeronave, a gente vai analisar o caso de um desastre no banco de dados em pro. Esse tipo de coisa, né, nunca acontece por causa de um único fator.

Essas empresas não são totalmente incompetentes, embora tenha uma incompetência aqui e ali acontece por uma série de fatores sempre. Antes da gente começar a nossa história, antes disso daqui, eu preciso fazer uma pausa rápida para falar da patrocinadora do canal, sem a qual esse vídeo não seria possível. Se você trabalha paraa gringa do Brasil e recebe seu dinheiro via PJ, eu tenho certeza absoluta que você vai querer usar a High Globe, porque a High Globe é a melhor maneira de receber seus dólares de fora do país, segundo eu, em todas as métricas, em todos os critérios que realmente importam.

Lógico, quando a gente tá querendo receber o nosso salário, né, o nosso salário, a primeira coisa que a gente vai querer analisar é o custo disso, certo? Então, a gente quer uma opção que seja barata. A High Globe acontece que ela tem a taxa que é a menor do mercado.

Eu nunca vi nenhuma outra taxa abaixo desse valor aqui de 0. 5%, uma taxa muito baixa. Pode analisar a concorrência, eu literalmente nunca vi nenhuma menor do que essa daqui, tá?

OK, mas a gente não se importa só com a taxa. A gente tem que saber que é uma alternativa segura, né? Bom, posso te falar aqui que eu uso a R Glob há se meses, eu nunca tive nenhum problema e mesmo que eu tivesse algum problema, a RGLUB tem um seguro ante perdas de até $.

000 000 transações por mês. Ou seja, né, seu salário mensal aí é até $20. 000.

Isso aqui é totalmente coberto pelo segurante perdas deles, que eu sou quase um ano, nunca tive nenhum problema, tá? Mas vem cá, High Globe é rápida, é o meu salário, né? Eu quero receber o meu salário o mais rápido possível.

Bom, que que eu vou te falar aqui? Esse saque é via Pix, então é óbvio, ele cai muito rápido e ele funciona todos os dias, né? Não, não tem essa de feriado bancário, né?

Pix não é TED, pode cair sábado, pode cair domingo, não tem problema. Então, pô, tem essas três aqui, é claramente a solução perfeita, mas tem mais coisa, né? Não é só isso.

Se você ativar o high Globe earn e eu deixo o meu ativado, tá? Esse mês eu ganhei quase $ no High Globe Earn, você vai ter uma rentabilidade na sua conta High Globe de até 3% ao ano, tá? Você vai receber no seu e-mail, por exemplo, e-mail assim toda semana dizendo que o seu saldo aumentou.

Claro, se você tiver saldo na High Glober, ele estiver com High Glob ativado, ele vai rendendo. Se você nem quiser converter e quiser gastar esse dinheiro em dólares, você vai ter acesso a cartões pré-pagos também, que você vai est podendo gastar em dólar e até em outras moedas, mas né, em dólar dos Estados Unidos não vai te cobrar taxa, em outras moedas vai te cobrar uma taxa de 2% por transação. Eu pessoalmente sou cliente da R Glob há vários meses, como eu falei, não tenho nenhuma obrigação de ser cliente deles.

Eu uso porque eu realmente acho a melhor e a única forma de trazer meus dólares pro Brasil que eu uso. Sinceramente, eu não sei o que você tá esperando. Clica no link na descrição.

Muito importante, usa o cupom Augusto 20 na hora de criar sua conta na High Glober para você ganhar 20% de desconto nos três primeiros meses e para eles saberem que você veio daqui. Vamos pro incidente. Esse é um vídeo um pouquinho baseado nesse vídeo muito famoso aqui.

Dev deleta, a database de produção inteira. Além disso, a gente vai ter também as fontes primárias aqui que eu vou estar acompanhando, que é o postm do próprio Gitlab do incidente de 31 de janeiro de 2017 e o database response. Aqui é a resposta que eles deram no dia seguinte ao incidente, explicando porque tudo caiu.

Os links para esses artigos vão estar na descrição também. E era um belo dia, 6 pm, 6 da tarde, 6 da noite, no horário UTC, você sabe, né? aquele horário que tá todo mundo cansado, aquele horário que tá propenso a erros, um horário perfeito para começar a dar problema, uma hora excelente para tomar várias decisões que afetam produção, né?

Melhor hora para fazer deploy é aqui, que se quebrar ninguém dorme. A gente vai inventar uns nomes fictícios aqui. Então a gente vai ter um dev chamado Gustavo Moreno, não é o nome de verdade desse dev, que vai ser o protagonista da nossa história, né?

E lembrando, isso aqui é uma história real, não tô inventando isso realmente aconteceu no Gitlab. Tem os documentos ali para provar. Esse carinha aqui, o Gustavo Moreno, ele recebe nesse belíssimo horário de 6 da tarde um ping no dashboard dele, né?

E o GitLab tava h um tempo lidando com spammers, pessoas que estão spamando o servidor, né, criando vários artigos ali. E ele percebeu que um único usuário, né, um único spammer, tava usando o GitLab como alguma forma de CDN ou coisa do tipo, o que resultou em 47. 000 IPs diferentes acessando a mesma conta no GitLab.

CDN, se você não sabe, significa content delivery network. A Netflix, por exemplo, vai ter uma CDN, que é uma network, é uma rede, cujo objetivo principal é entregar assets, entregar recursos estáticos para usuário. A CDN vai tentar estar o mais próximo possível do usuário para economizar, né, não ter que mandar os recursos lá de longe através da internet e tentar manter isso aí o mais perto do usuário possível.

Então, muito comum para vídeo, de repente para sites estáticos, para fotos, esse tipo de coisa que a galera acessa com muita frequência, em muita quantidade e que você quer salvar na numa localidade próxima do usuário. Gustavo então toma inteligente decisão aqui, né, de começar a bloquear alguns IPs, remover alguns usuários, né, e essa remoção dos spammers, dos usuários e de vários snipets que esses spammers criaram é um tanto quanto custosa, né? Imagina que alguém tá criando muitas entidades no seu banco de dados e você vai querer deletar tudo.

Demora um certo tempo para isso acontecer. Essa situação foi desenvolvendo, né, foi se desenvolvendo ao ponto de que às 9 pm do horário TC, nota o nosso Gustavinho aqui já devia estar querendo dormir, esse conjunto de spammers aqui, certo? De pessoas spamando seu banco de dados, tentando criar tabelas, perdão, tentando criar recursos, alocar ali coisas no banco de dados, aliado a essa deleção, né, vai causar aqui que o nosso banco de dados vai ter alguns locks.

Então, eles estavam usando aqui posters na versão 9. 6 e você vai ter que um lock no banco de dados acontece da seguinte forma, tá? Quando eu vou escrever algo no meu posteress, ele vai pegar isso daqui, ele vai primeiro escrever em algo que a gente vai ver depois que ele vai aparecer mais aqui, que é o tal do w A w right ahead logs.

Primeiro ele escreve aqui para depois persistir no banco de dados perc. Por que que ele escreve esses logs antes de persistir no banco de dados? Por quê?

Caso cair a internet, a máquina falha. Caso dê algum problema aqui no nas nossas tabelas no banco, a gente escreveu esses logs, a gente consegue recuperar essa informação de alguma forma. Então primeiro escrito no right logs, depois isso que vai ser persistido no banco de dados.

acontece que como tava muita coisa sendo escrita e deletada no banco de dados, algumas dessas rows aqui, né, estavam lidando com um certo problema de locks no banco de dados. O que que é um lock no banco de dados, né? Vamos supor que você tem o seu saldo bancário lá, saldo, e não vai ter uma tabela saldo no banco de dados, tá?

Um banco de dados vai usar um Ledger, mas só para esse propósito, imagina que você tem um saldo de R$ 10, alguém te fez um depósito de R$ 5, você vai ter que adicionar então mais C ao seu saldo. Só que simultaneamente, vamos supor que outra pessoa vai também te depositar mais 12. Bom, se o seu saldo pegar o 10 e somar cinco, vai dar 15.

Só que se ao mesmo tempo alguém depositar 12 e o seu saldo simplesmente pegar o 10 e somar 12, pode ser que a gente tenha esse 15 sobrescrito e você termine com 22 ao invés de 27, que deveria ser o valor, entendeu? Enquanto transações estão ocorrendo e eu fiz um lock, né, enquanto eu travei o meu saldo, eu falei: "Ó, eu só vou poder mexer nesse saldo de novo depois que eu persisti esse meu mais 5 aqui, né? Porque claro, muitas coisas podem estar acontecendo simultaneamente.

Quando o 15 aqui for persistido, então eu vou liberar pro 12 e conseguir puxar ali o saldo de 15, fazer o mais 12 e armazenar então o 27. E assim a gente evita alguns tipos de erros, né? Acontece que numa situação em que você tá sendo, tá sendo atacado por spamers, deletando um monte de coisa no banco de dados, esses locks vão começar a causar uma certa latência no seu serviço.

Então isso daqui às 9 pm, certo? 21 horas da noite, o banco de dados começa a ter bastante latência e tem algo que contribui com isso ainda. Eu catei o próprio issuo lá no GitLab.

Gitab é open source, inclusive você consegue ver alguns eixos de quando isso aconteceu. Post gres 9. 2 tem uma técnica chamada vacuum.

O vacuum ele é efetivamente um processo de garbage collection que quando a tabela vai crescendo demais, você tem um certo que aumento desenfreado no índex e o tal do vacuum vai coletando o lixo, né, fazendo ali as operações necessárias para otimizar provavelmente a B3 do index, certo? Os índices do banco de dados em postma em B3. Acredito que o processo de vacuum vai ser um processo de limpeza de lixo aqui e otimização dessa bite.

Então a situação continua, né? Nosso Gustavo Moreno aqui já tá morrendo de sono. Como toda hora que algo dá errado, tudo dá errado, é óbvio que mais coisas vão dar errado aqui.

Outro problema que surgiu, né? Bom, sabendo que GitLab é uma instituição gigantesca que armazen milhares de repositórios, você deve estar pensando que não é apenas um único banco de dados. Não faz sentido.

A gente vai ter um cluster de banco de dados que é o database 1, mas a gente também vai ter um segundo cluster de banco de dados, né? A gente não é tanto nem nada, certo? E os dados que são inscritos nesse banco de dados um, eles são replicados para o banco de dados dois.

Esse processo aqui não vai acontecer de maneira direta, assim como eu tô desenhando. Na verdade, o que vai ser replicado vão ser os WR aheads, certo? Lembra do log que eu falei que que acontece antes das coisas acontecerem de fato no banco de dados?

A escrita desses WR headlogs é o que é utilizado pelo banco de dados dois para a sua replicação. Então a gente tem esse processo aqui e, né, ao longo desse ataque aqui de spammer, nosso Gustavinho percebeu que havia um delay de mais ou menos 4 GB. O banco de dados 2 estava 4 GB atrás do banco de dados um.

Agora, né, tudo isso foi iniciado pela deleção aqui do spammer e existia um processo mal documentado no GitLab e que a remoção dos usuários não devia ser um hard delete, você não deve dar só um delete no usuário, você devia dar um soft delete, ou seja, a gente vai marcar aquele usuário como deletado para que um processo de background delete-o depois pra gente tentar evitar esse problema aqui. Não foi isso que o Gustavo fez, ele simplesmente deu um hard delete ali nos spammers, o que começou essa tragédia toda aqui. Isso não foi culpa dele, esse processo estava mal documentado.

E aqui a gente tem o setup perfeito pro caos acontecer. A gente tem o palco onde o nosso problema vai ocorrer. Esse processo aqui de replicação de um banco de dados pro outro, ele estava dentro do Gitlab extremamente mal documentado.

Era um processo que dava muito erro muito frequentemente. Eles estavam reiniciando isso aqui manualmente volta e meia. Processo de replicação extremamente frágil do banco de dados um pro banco de dados dois.

Nesse momento, nosso Gustavinho aqui menciona que ele vai sair, que ele quer sair e resolver esse problema amanhã, certo? Então a gente nota que ele tá mesmo muito cansado, mas antes disso ele decide tentar pelo menos reduzir esse delay aqui do banco de dados dois pro banco de dados um, fazendo com que a replicação funcione mais redondinha aqui. Como a replicação não estava funcionando de maneira adequada, o Gustavo conversou com um segundo dev aqui, cujo nome real a gente não sabe também, mas podemos chamar ele de Jason.

Gustavo e Jason conversaram, bolaram um excelente plano para resolver esse problema. Qual que é o plano? Cara, desliga e liga de novo, né?

Provavelmente se tá dando plau, se essa replicação tá ficando cada vez mais atrasada, que que a gente faz? A gente vai fazer um comandinho muito simples aqui. RMF post/D.

Se você não conhece o comando RMRF, é para deletar algo, deletar um diretório e recursivamente todos os diretórios dentro desse diretório, certo? Então se a gente deletar tudo que tá dentro da pasta data, nossa pasta data vai ficar vazio. Inclusive, vai deletar o diretório data também.

Após rodar isso daqui, deletar tudo que tá no banco de dados no DB2, a gente vai simplesmente puxar tudo do DB1 de novo. A gente vai aqui PG base backup e puxar tudo de volta. Não tem problema nenhum, certo?

É a grande estratégia de Vamos desligar e ligar de novo e vai funcionar. E bom, aqui começa o plano. Jason vai então abrir um terminalzinho, dar um SSH para DB2, certo?

SSH, ele vai entrar na máquina at remotamente, né, através do computador dele, criar uma conexão ali com a máquina do DB2 para poder executar comandos dentro do da máquina do DB2. Na verdade, um cluster de máquinas, ele taca o RMF, certo? Ele vai dar aqui RMF na pasta de dados e vai tentar executar esse comando aqui.

Acontece que o database 2 tá se recusando a se conectar com o database cluster 1 e tá reportando um problema. O problema é que Max W senders está muito baixo. Ele tá reclamando da ausência de max while senders.

WR aheads, aqueles logs, né, que vão ser utilizados para essa replicação aqui. Então, se esse é o problema, beleza, sem erro nenhum, a gente entra aqui, a gente dá um SSH pro database 1 e vamos aumentar esse valor aqui. Aumenta aqui o valor de Maxwell Senders para 32.

Reinicia o Postgess no database 1 para que isso aqui seja aplicado, né, esse valor seja aplicado. E depois o Postgam que existem muitas conexões abertas. reclama aqui que o número de Max Connections tá muito alto.

Número de Max Connections tava em 8. 000 e já tava nesse valor há mais de um ano. Mas então, Gustavinho Moreno aqui decidiu baixar esse número para 2000 para ver se funciona, né?

E beleza, tudo bem no DB1, DB2, é, perdão, DB1, Postg reiniciou, o reload que funciona. Temos então o nosso PHG do banco de dados um, tudo funcionando com novo número de Mac senders, tudo OK, pronto para fazer a replicação do DB2. Vamos tentar de novo.

Volta pro DB2, roda de novo o comando de PG base backup e nada acontece. Não tá fazendo nada aqui no PG2, né? Ele vai de um terminal para outro, checa, ver se tá tudo certo.

Máquina do DB1, parece que tá tudo certo. Máquina do DB2, parece que tá tudo certo. O Postgers backup não tá funcionando, não tá respondendo nada.

E aqui vai existir uma segunda falha na documentação, né, que depois eu vou explicar. Me lembra de eu voltar aqui depois. Como é que você vai me lembrar?

O vídeo já tá gravado. O que que ele concluiu aqui logicamente? Bom, quando a gente tentou rodar esse backup antes e deu problema, de repente foi criada uma pasta data e essa pasta deve est meio corrompida, né?

Eu tentei dar um backup antes, esse backup falhou. Eu posso ter criado uma pasta com, sei lá, vários arquivos corrompidos aqui. Ou de repente é melhor eu deletar essa pasta de novo e fazer o backup de novo, né?

A gente já fez isso antes, só fazer de novo. Ele vem aqui no terminal, né? Ele tem aqui as abas abertas do terminal DB1, DB2, ele vai na do DB2 e dentro do DB2 ele dá um RMF na pasta de dados.

E esse aqui provavelmente foi o pior segundo da vida desse cara. Se você conhece aqui um pouco do RMRF, né, você sabe que, bom, provavelmente se a pasta de data do postagress, né, se aqui o barrapostress/ data tivesse vazio ou com um pouco de arquivo lixo assim, ia ser instantâneo. Seria muito estranho se demorasse 1 2 3 segundos, né?

Nesse um segundo, depois de rodar RMRF, ele se tocou que ele não tava no terminal do database 2, que ele tava no terminal conectado ao database 1 e ele efetivamente deleitou os dados de produção. Ele tinha rodado RMRF Data no cluster 2, no cluster réplica e ele acabou de rodar RMRF data no cluster 1. Não tinha mais nenhum dado em produção, literalmente deletou tudo.

Cara, esse foi um dos piores segundos da vida desse cara. Eu posso afirmar isso categoricamente, né? Porque se você não percebeu aqui, Gustavo Moreno, na verdade é umas para Augusto Galego.

Fui eu que fiz isso, cara. Você nem faz ideia do que que passou na minha cabeça durante esse momento. Não, não, gente, é brincadeira, tá?

Era só para quebrar um pouco o gelo aqui. É óbvio que não fui eu. Eu nunca trabalhei no Git Lab.

É, a gente não sabe o nome desse dev aqui de verdade. Enfim, nessa situação aqui, o nosso dev Gustavo Moreno não tinha nada em produção. Ele tinha deletado tudo.

Mas bom, é, sem pânico, né? É importante que você espectador entenda que uma réplica de banco de dados não é um backup. RC e backup são coisas diferentes.

E existia um processo, eu vou copiar e colar isso aqui, ó. Existia um processo que regularmente pegava tudo que tava aqui no database 1, dava um PG dump para um S3. PG dump, Post GR dump, Post GR dump vai dampar aqui os dados num S3 da Amazon.

E isso daqui tava sendo utilizado como backup. É só restaurar esse backup, né? O Gustavinho entrou aqui no S3 e percebeu que não tinha nada no S3.

O S3 estava vazio também. Aqui novamente mais uma falha, né? Falha atrás de falha atrás de falha.

O problema foi que a Chrome Job que rodava esse PG dump aqui tava utilizando Pushgares 9. 2. Eles em produção tavam rodando Pushgares 9.

6 e por causa de algum problema de incompatibilidade isso aqui tava causando um erro que não seria um problema, porque teoricamente existiria um sistema de notificações, certo? Esse processo aqui que roda no Chrome job, que vai rodar dentro ali da Amazon, era para notificar por e-mail quando acontecesse um erro. Se o backup por qualquer motivo não funcionasse, os devs receberam um e-mail e ninguém nunca estava recebendo e-mail nenhum, portanto funcionou.

Certo? errado, porque aqui existe um negocinho chamado Demark, Domain based authentication reporting Conformance, que não estava corretamente configurado e não conseguia mandar e-mails. Ninguém nunca abriu os logs desse processo aqui para ver o que que de fato tava acontecendo.

Ninguém percebeu que os e-mails que deveriam ser mandados não estavam sendo mandados e ninguém testou isso daqui. Ah, total, o que que a gente tem? Como é que a gente pode resolver isso?

Bom, esse banco de dados aqui, né, ele com certeza roda em alguma máquina, certo? Essa máquina que vai ter um disco. A gente tem o disque aqui da máquina, né?

Os dados cru aqui é muito comum, é procedimento quase padrão, eu diria que vão existir snapshots sendo tirados aqui do banco de dados. Tem configurações disso na Amazon, tem configurações disso na Azure, que é o que tava usando sendo usado aqui no Gitlab. Então é só pegar desses snapshots aqui e jogar o snapshot de volta no banco de dados zoom, certo?

Sim, correto. Se os snapshots tivessem de fato sendo tirados, o que não aconteceu, porque como já tinha backups o suficiente, eles acharam que não seriam necessário esses snapshots aqui. É, não tinha snapshots, então.

E aqui, né, é quase quase que foi perdido tudo de todos os tempos. Existia uma única salvação, que é esse aqui o ambiente de proia e o gitab de tempos em tempos. Pegaria tudo do ambiente de proia, certo?

uma vez por dia aqui e replicaria isso em ambiente de staging pr, né, você tem um ambiente de staging para fazer testes em coisas que mais se assemelham produção por algo próximo de um milagre. Alguém tinha feito recentemente um backup aqui de pro de PlayStation, certo? Esse backup ele rodava uma vez a cada 24 horas, mas alguém tinha feito isso é 6 horas antes de tudo isso acontecer.

Então, muito bem. É, como a gente tinha um backup de 6 horas atrás, certo? Só o que você precisa fazer é pegar esses dados aqui e enviar de volta para a produção.

Você vai pegar do staging, vai duplicar pra produção e acontece, né, que a empresa tava querendo economizar um dinheirozinho aqui e tal. O banco de dados deles de staging não tinha as maiores velocidades. Esse processo aqui de replicar os dados de staging pra produção levou 18 horas.

O gitlab ficou 18 horas fora do ar enquanto os dados estavam sendo replicados da stag para a produção. E aqui, né, se a gente tem uma timeline do incidente aqui, né, foi feita essa réplica. Então aqui a gente tem a réplica.

6 horas se passaram até o incidente aqui, né, que a gente tem o incidente e mais 18 horas se passaram em que ficou tudo offline. Tudo que foi produzido nessas 6 horas aqui foi integralmente perdido, né? O Gitlab, se você não conhece, é algo parecido com GitHub e tal.

É, tudo que foi comitado, todos os repositórios que foram subidos, tudo que foi trabalhado nesse período de 6 horas foi perdido e deletado de todas as instâncias e todos os lugares, certo? Não existia mais. E aqui a gente teve uma massa de processos mal documentados, eh, pessoas fazendo SSH para as instâncias do banco de dados e executando comandos sem testar, sem ter outra pessoa ali com você para validar de repente.

Ã, nunca faça isso. Eu até no momento twitei, né, pô, em algum momento eu fiz esse tweet que se você vai executar comandos do banco de dados, é bom você ter um p request em cima disso para, tipo, todo mundo garantir que o que tá sendo feito tá correto, né? É, e é justamente nas nos momentos de pânico, assim, momentos de pressão e dificuldade que você vai acabar fazendo algo de errado.

Boa parte do que iniciou esse problema aqui foi primeiro esses right ahead logs, existe um limite físico máximo que você vai alocar pros right logs, certo? Se o seu posts aqui ele cabe, sei lá, 48 GB, os seus RCH logs não faz sentido eles terem 48 GB. Você vai, tipo assim, conforme os antigos vão sendo persistidos, você vai deletando eles.

E eles tinham um tamanho máximo aqui de, sei lá, 200 MB proser head logs. E acontece que todo esse processo aqui de spammers e deleção de coisas causou que alguns logs fossem deletados antes deles serem persistidos no banco de dados dois. Como alguns logs foram deletados, isso causou um atraso permanente no banco de dados dois, certo?

Se você perdeu algumas transições que foram feitas no banco de dados, essa informação fica dessincronizada e você meio que não consegue sincronizá-la de novo, né? É, porque o log não existe mais. Você tem que usar outra maneira para sincronizar de novo.

E eu falei que eu ia voltar lá nesse PG Base backup, certo? Que o nosso colega deu um PG base backup e ele viu que nada tinha acontecido. Ele presumiu que um erro estava acontecendo.

Na verdade é comportamento padrão do PG Base Backup. pelo menos na época, não sei que o PG Base Backup vai esperar o database primário começar a mandar dados de replicação. Enquanto ele tá esperando, ele vai esperar silenciosamente.

E isso eh tava mal documentado. A pessoa que executou o PGBAS Backup não sabia direito como funcionava. Ele viu que não teve nenhuma resposta, né?

Não teve nada ali que foi printado no terminal, não teve nenhum log, nada. Aí achou que simplesmente não tinha funcionado. E na verdade o PGBAS Backup tava apenas esperando que o banco de dados Zoom começasse a mandar os dados.

Se a pessoa tivesse, possivelmente, nesse segundo sabido o que que o PGBC fazia, né? Eh, se tivesse uma boa documentação, tivesse checado e só esperado, teria dado tudo certo se ele só tivesse esperado, se ele só tivesse sido um pouquinho mais, não sei, calmo. Mas nessas horas dá para entender, né?

Eh, o que que fica de lição pra gente, né? Pra gente sempre tá testando nossas presunções, certo? Pô, esse caso aqui do backup não funcionar e ah, a gente vai ser alertado por e-mail quando um backup não funcionar.

A gente precisa testar que esse meio funcionou, né? Precisa testar que isso daí de fato tá acontecendo. A gente precisa olhar no S3 e ver se backups estão sendo feito.

Tem que ter algum tipo de monitoramento, porque se o S3 tá vazio como tava, é muito óbvio que não foi feito nada. Temos que estar constantemente prestando nossas testando nossas presunções, né? Os RCH logs aqui, esse todo esse caso aqui tava provavelmente subdimensionado pra carga em horários de pico, né?

Eles não fizeram um stress testing tão compreensivo para ver que isso poderia dar problema. os processos de replicar, de reiniciar uma replicação aqui, não estavam bem documentados, não estavam bem compreendidos. O processo, né, de um engenheiro sozinho conseguir dar SSH para dois clusters de banco de dados e executar os comandos que ele bem entender também é um processo meio tenuo.

É algo que deveria ser fortemente desencorajado pela cultura da empresa ou talvez até proibido, né? Você pelo menos você deveria que ter duas pessoas olhando pra mesma tela e garantindo que cada comando tá funcionando, né? Se possível até fazer p requests para olhar que os comandos que vão ser executados são aqueles mesmos.

E tem várias coisas que a gente pode aprender disso daqui, tá? Eu espero ter explicado algumas delas.