 |
| Bellacosa Mainframe e o rollback e backup |
☕ Um Café no Bellacosa Mainframe — Especial Red Team
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
🚗 O glorioso momento em que alguém descobre que desfazer uma ação não significa desfazer suas consequências
Existe uma cena em Curtindo a Vida Adoidado que deveria ser exibida em todo curso de operações, recuperação, banco de dados, continuidade e resposta a incidentes.
A Ferrari foi usada.
A quilometragem aumentou.
O problema precisa desaparecer.
Surge então uma ideia absolutamente maravilhosa em sua simplicidade:
vamos colocar o carro em marcha a ré.
Se andar para frente aumentou a quilometragem...
andar para trás deveria diminuir.
Lógica cristalina.
Elegante.
Quase matemática.
E completamente incapaz de apagar tudo o que já aconteceu.
É neste momento que Ferris Bueller encontra uma das verdades mais dolorosas de produção:
desfazer estado não significa desfazer história.
Você pode voltar um valor.
Pode restaurar um arquivo.
Pode carregar um backup.
Pode executar ROLLBACK.
Pode recuperar uma tabela.
Pode restaurar um dataset.
Pode voltar configuração.
Mas talvez não consiga desfazer:
a mensagem enviada;
o pagamento processado;
o cliente que recebeu informação errada;
o arquivo copiado;
a fraude executada;
o log gerado;
o segredo exposto;
o processo disparado;
a decisão humana tomada.
Em outras palavras:
Produção não possui Ctrl+Z emocional.
Bem-vindo ao oitavo episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje vamos falar da Ferrari.
Mas, na verdade, vamos falar de backup, restore, rollback, journaling, Db2, VSAM, recuperação de transações e daquela reunião pós-incidente em que alguém pergunta:
— Dá para voltar?
E toda a sala fica em silêncio.
🔴 Primeiro erro: acreditar que “voltar” é uma coisa só
Em tecnologia usamos várias palavras como se significassem a mesma coisa.
Backup.
Restore.
Rollback.
Recovery.
Undo.
Rebuild.
Reprocess.
Failback.
Mas não são a mesma coisa.
Cada uma atua em uma camada diferente.
Ferris descobriria isso rapidamente.
💾 Backup não é rollback
Backup é uma cópia de estado em algum momento.
Ele responde:
“Temos uma versão anterior?”
Isso é importante.
Mas não significa que você consegue voltar instantaneamente.
Exemplo:
00:00 BACKUP
02:00 INCIDENT
05:00 DETECTION
Se você restaurar o backup da meia-noite...
o que acontece com tudo que ocorreu entre 00:00 e 05:00?
Pedidos?
Pagamentos?
Cadastros?
Transações?
Logs?
Talvez você recupere consistência técnica destruindo realidade de negócio.
Ferrari voltou para garagem.
Mas a cidade inteira já viu o carro.
🔁 Rollback é outra coisa
Rollback normalmente significa desfazer uma transação ou conjunto de mudanças antes da confirmação definitiva.
Em banco de dados, isso é natural.
Você inicia uma unidade de trabalho.
Faz alterações.
Algo dá errado.
Executa rollback.
O banco volta ao estado anterior daquela transação.
Perfeito.
Mas perceba:
isso funciona porque o sistema ainda possui contexto suficiente para desfazer.
Depois que uma mudança é confirmada, propagada e consumida por outros sistemas, a história complica.
☕ COMMIT é quase um rito religioso
Quem trabalha com transação entende.
Antes do COMMIT, o universo ainda pode ser negociado.
Depois do COMMIT...
a conversa muda.
UPDATE...
UPDATE...
UPDATE...
COMMIT
Pronto.
A transação foi assumida como válida.
Agora talvez existam:
logs;
replicações;
mensagens;
processos downstream;
auditoria;
integrações.
A quilometragem já saiu da Ferrari e entrou no ecossistema.
🧠 O sistema pode voltar, o mundo não
Essa é a essência.
Imagine:
um operador envia uma transferência errada.
Depois percebe.
Você pode corrigir o registro.
Mas o dinheiro talvez já tenha saído.
Pode restaurar a tabela.
Mas outro sistema já consumiu o evento.
Pode reverter status.
Mas cliente já recebeu e-mail.
Pode apagar arquivo.
Mas alguém já copiou.
Recuperação técnica não garante recuperação operacional.
🚗 A Ferrari em marcha a ré é rollback sem modelo de consequência
Eles olharam apenas para o indicador:
quilometragem.
Queriam mudar um número.
Mas o evento foi maior.
O carro saiu.
Rodou.
Foi visto.
Foi usado.
Voltou.
A história existiu.
Esse é o erro clássico de sistemas:
confundir estado observável com totalidade do evento.
📜 Logs existem porque história importa
Um bom sistema não registra apenas o estado atual.
Registra também eventos.
Quem alterou.
Quando.
O que era antes.
O que ficou depois.
Isso é fundamental para auditoria e recuperação.
Se você só sabe o estado final, perde contexto.
🧾 Journaling: o diário do sistema
Journaling existe exatamente porque operações importam.
Em vez de guardar apenas:
BALANCE = 1500
você também consegue reconstruir:
10:01 CREDIT +500
10:02 DEBIT -100
10:05 CREDIT +200
Isso muda tudo.
Você não tem apenas fotografia.
Tem filme.
🦖 Db2 entende que o passado importa
No Db2, log é central para recuperação.
As alterações são registradas para permitir:
rollback;
rollforward;
recovery;
consistência.
A lógica é maravilhosa.
Banco de dados crítico não pode depender de memória humana.
Precisa saber o que aconteceu.
🔐 Write-Ahead Logging
O princípio é simples:
registre intenção antes de assumir mudança.
Assim, em caso de falha, o sistema consegue entender o que estava acontecendo.
Isso é profundamente diferente de:
“Espero que dê tudo certo.”
Ferris aprovaria.
💥 Crash no meio da transação
Imagine:
UPDATE A
UPDATE B
SYSTEM CRASH
Sem mecanismo transacional, talvez A mude e B não.
Estado inconsistente.
Com log e controle transacional, o banco pode decidir:
completar;
ou desfazer.
Atomicidade.
É o sistema dizendo:
ou tudo ou nada.
🧠 ACID encontra Ferris Bueller
ACID é aquele conjunto de propriedades que muita gente aprende e depois esquece.
Atomicity.
Consistency.
Isolation.
Durability.
Mas na cena da Ferrari, ele ganha vida.
Ferris quer que o sistema pareça como antes.
Só que realidade já sofreu efeitos fora da transação.
ACID protege o banco.
Não protege o universo.
🔁 Rollforward também existe
Nem sempre queremos voltar.
Às vezes queremos restaurar base antiga e reaplicar logs até um ponto específico.
Isso é rollforward.
Exemplo:
BACKUP 00:00
+
LOGS
+
RECOVERY UNTIL 02:14
Agora chegamos perto de um ponto anterior ao incidente.
Muito melhor que simplesmente restaurar tudo.
Mas ainda exige planejamento.
⏱️ Point-in-Time Recovery
Essa é uma das ferramentas mais poderosas.
Voltar ao estado exato ou aproximado antes da corrupção.
Mas perguntas continuam:
qual momento?
Como sabemos?
Outros sistemas estavam sincronizados?
As mensagens externas foram revertidas?
A aplicação tem cache?
Existe replicação?
Recovery é ecossistema.
🧱 Sistema distribuído: agora a Ferrari tem microserviços
Imagine:
APP
↓
API
↓
DB
↓
MQ
↓
SERVICE A
↓
SERVICE B
Você restaura o banco.
Excelente.
Mas o MQ já entregou mensagens.
Service A já executou ação.
Service B já notificou outro sistema.
Agora seu estado interno voltou no tempo.
O resto do mundo não.
Parabéns.
Você acabou de inventar inconsistência distribuída.
📬 Mensagem enviada não possui Ctrl+Z
Essa é uma bela metáfora.
Em mensageria, depois que algo é consumido, talvez você precise de evento compensatório.
Não apagar história.
Compensar.
Exemplo:
PAYMENT_SENT
Depois:
PAYMENT_REVERSAL
A primeira ação continua existindo.
A segunda corrige consequência.
Isso é muito diferente de fingir que a primeira nunca aconteceu.
🔄 Compensating Transaction
Esse conceito é lindíssimo para Ferrari.
Você não consegue apagar o passeio.
Mas pode fazer uma operação posterior para reduzir impacto.
Em sistemas distribuídos, isso aparece muito.
Em vez de rollback perfeito:
compensação.
Porque o mundo real raramente é transacional ponta a ponta.
🧠 Saga Pattern tem espírito de Ferris
Em arquiteturas distribuídas, uma transação pode envolver várias etapas.
Se uma falha no meio, você executa ações compensatórias.
Reserve
↓
Charge
↓
Ship
↓
Notify
Se Ship falhar:
talvez precise estornar Charge.
Não “desfazer magicamente” o tempo.
Compensar.
A Ferrari volta para garagem.
Mas o pai ainda pode descobrir.
☕ Backup bom é backup restaurável
Outra verdade dolorosa.
Toda empresa diz:
“Temos backup.”
Pergunta:
quando foi o último restore testado?
Silêncio.
Backup não testado é hipótese.
Restore testado é capacidade.
💣 O backup estava lá. Só não funcionava.
Clássico.
Arquivo corrompido.
Permissão errada.
Retenção insuficiente.
Chave de criptografia perdida.
Dependência esquecida.
Versão incompatível.
Backup sem catálogo.
Você descobre no pior momento.
Ferris diria:
“Talvez devêssemos ter testado isso antes de sair com o carro.”
🧪 Recovery Drill
Organizações maduras testam recuperação.
Simulam perda.
Restauram.
Medem.
Validam.
Porque desastre real não é momento de aprender documentação.
Recovery precisa virar músculo.
⏱️ RPO: quanto passado você aceita perder?
Recovery Point Objective.
Pergunta:
até quanto tempo de dados podemos perder?
5 minutos?
1 hora?
24 horas?
Isso define estratégia.
Ferrari:
quanto de quilometragem o pai perceberia?
Talvez RPO emocional de Cameron seja zero.
🕐 RTO: quanto tempo pode ficar parado?
Recovery Time Objective.
Quanto tempo para voltar ao serviço?
Minutos?
Horas?
Dias?
Backup existe.
Mas restaurar demora 12 horas.
Talvez negócio não aceite.
🧠 RPO e RTO são decisões de negócio
Não de infraestrutura apenas.
TI implementa.
Negócio decide impacto aceitável.
Não adianta prometer:
RPO zero.
RTO zero.
Sem orçamento, arquitetura e testes.
Ferrari-level availability custa Ferrari-level money.
🗂️ VSAM entra na garagem
No mainframe, VSAM continua sendo parte crítica de muitos ambientes.
KSDS.
ESDS.
RRDS.
Arquivos usados em sistemas centrais.
Recuperação precisa considerar:
backup;
repro;
journaling;
CICS recovery;
logs.
Se um arquivo crítico sofre alteração indevida, simplesmente copiar backup anterior pode não ser suficiente.
🔁 CICS e integridade transacional
CICS existe justamente para lidar com processamento transacional robusto.
Unidades de trabalho.
Syncpoint.
Recovery.
Rollback.
Quando algo falha antes da confirmação, CICS pode ajudar a manter consistência.
Isso é controle real.
Não esperança.
🧠 Syncpoint é o momento “agora vale”
Até ali, ainda dá para desfazer.
Depois, a unidade de trabalho se torna permanente.
É o equivalente ao carro atravessar a porta da garagem.
Depois disso, consequências aparecem.
🚨 Resposta a incidente não é apenas restaurar
Outro erro clássico.
Durante incidente, alguém pensa:
“Vamos restaurar backup.”
Talvez.
Mas antes:
o atacante ainda está dentro?
a credencial ainda está válida?
o vetor foi fechado?
a persistência foi removida?
Se você restaura sem eliminar causa...
o atacante volta.
🔁 Restaurar ambiente comprometido sem corrigir causa
É como:
Ferrari volta para garagem.
Chave continua disponível.
Ferris continua na casa.
Excelente plano.
🕵️ Incident Response precisa entender linha do tempo
Quem entrou?
Quando?
O que fez?
Até onde chegou?
Quais sistemas tocou?
Quais credenciais usou?
Quais dados alterou?
Logs e journaling tornam isso possível.
Sem timeline, recovery vira chute.
🧾 Logs são mais que auditoria
Eles ajudam a reconstruir.
Mas também podem informar escopo.
Se você não sabe o que foi alterado, talvez restaure demais.
Ou de menos.
Ambos são perigosos.
🔐 Log também precisa sobreviver ao atacante
Se invasor pode apagar logs, investigação fica difícil.
Por isso:
centralização;
imutabilidade;
retenção;
segregação.
A Ferrari precisava de câmera na garagem.
📹 Observabilidade teria acabado com a brincadeira
Imagine:
GARAGE DOOR OPEN
CAR STARTED
ODOMETER CHANGED
UNAUTHORIZED DRIVER
Alerta.
Cameron desmaia.
Filme acaba em 20 minutos.
Observabilidade reduz espaço para surpresa.
🔴 Restore não apaga evidência externa
Mesmo que você restaure tudo:
SIEM guardou evento.
Sistema externo recebeu mensagem.
Banco parceiro registrou transação.
Cliente viu ação.
História distribuída permanece.
Isso é bom para investigação.
Ruim para quem queria “voltar no tempo”.
☕ Produção não possui Ctrl+Z emocional
Vamos aprofundar essa frase.
Você pode desfazer tabela.
Não desfaz medo.
Pode restaurar sistema.
Não restaura confiança automaticamente.
Pode reverter acesso.
Não desaprende dado vazado.
Pode corrigir transação.
Não elimina impacto reputacional.
Essa é a diferença entre recovery técnico e recovery de negócio.
🧠 Segurança também precisa pensar em irreversibilidade
Algumas ações têm custo permanente.
Exfiltração.
Publicação.
Vazamento de chave.
Segredo exposto.
Depois que dado sai, não existe rollback real.
Você pode revogar.
Mitigar.
Trocar credencial.
Mas informação já foi vista.
🔑 Chave vazada é Ferrari sem garagem
Se certificado privado vaza:
rotacionar.
Revogar.
Reemitir.
Mas você precisa assumir que foi comprometido.
Não adianta apagar arquivo local e dizer:
“Pronto.”
O passado aconteceu.
🧨 Ransomware ensina isso cruelmente
Organizações restauram sistemas.
Mas também precisam lidar com:
exfiltração;
credenciais;
persistência;
pressão;
comunicação;
compliance.
Backup ajuda.
Mas não resolve tudo.
Backup combate indisponibilidade.
Não necessariamente confidencialidade ou integridade.
🔵 Backup é uma fatia do queijo
Muito importante.
Mas apenas uma fatia.
Você precisa também:
detecção;
segmentação;
MFA;
PAM;
logs;
resposta;
recovery.
Ferrari segurada apenas por marcha a ré é um plano fraco.
🧠 Imutabilidade
Backups críticos deveriam ser protegidos contra alteração e exclusão indevida.
Porque atacante moderno sabe que backup atrapalha.
Então tenta destruir.
Imutabilidade reduz isso.
🧱 Air Gap e Isolation
Alguns ambientes mantêm cópias isoladas.
Físicas ou lógicas.
Objetivo:
se produção for comprometida, backup não cai junto.
É colocar uma Ferrari reserva em outro prédio.
🔐 Credentials do backup também são privilegiadas
Isso é frequentemente esquecido.
Quem controla backup controla recovery.
Se a mesma conta administrativa domina:
produção;
logs;
backup;
então comprometimento único pode destruir tudo.
Segregação novamente.
🦖 Mainframe vive de recovery disciplinado
Mainframe ganhou reputação de confiabilidade não por magia.
Mas por décadas de disciplina operacional.
Journaling.
Logs.
Checkpoint.
Restart.
Backup.
Recovery.
Transação.
Tudo isso nasceu porque processamento crítico não tolera improviso.
🔁 Batch também precisa voltar
Nem tudo é online.
Imagine batch longo.
Falha no passo 47.
Você vai reprocessar desde o início?
Talvez não.
Checkpoint/restart existe para reduzir isso.
Mas depende de desenho.
🧠 Restartability
Aplicação batch deveria saber recomeçar de ponto consistente.
Caso contrário, reexecutar pode duplicar:
pagamentos;
registros;
mensagens.
Ferris daria marcha a ré e depois descobriria que rodou a quilometragem duas vezes.
💸 Idempotência
Uma operação idempotente pode ser repetida sem mudar resultado além da primeira execução.
Isso é ouro em recovery.
Porque retries acontecem.
Se repetir pagamento gera outro pagamento, temos problema.
🔁 Retry não é rollback
Outra confusão.
Retry tenta de novo.
Rollback desfaz.
Restore recupera estado.
Cada um tem papel.
Misturar esses conceitos cria incidentes novos durante recuperação.
🚨 O pior momento para improvisar é durante incidente
Todo mundo sob pressão.
Diretor ligando.
Clientes afetados.
Equipe cansada.
Aí alguém sugere:
“Vamos executar esse script que achei.”
Ferris sorri.
Recovery precisa de runbook.
📚 Runbooks
Passos definidos.
Critérios.
Dependências.
Quem aprova.
Como validar.
Como voltar.
Isso reduz improvisação.
🧪 Mas runbook também precisa ser testado
Documentação pode estar errada.
Sistema mudou.
Pessoa saiu.
Senha expirou.
Ferramenta foi atualizada.
Drill encontra isso antes do desastre.
☕ A pergunta Bellacosa número 1
Numa War Room:
“Se precisarmos restaurar agora, alguém já fez isso de verdade?”
Não:
“tem procedimento.”
Pergunta:
“já funcionou?”
🔴 Pergunta número 2
“Qual foi a última transação confiável antes do incidente?”
Sem isso, point-in-time recovery vira adivinhação.
🧠 Pergunta número 3
“O que já saiu do nosso sistema e não pode ser desfeito?”
Essa pergunta muda resposta.
🔐 Pergunta número 4
“Depois do restore, o atacante ainda consegue entrar?”
Se sim, você só resetou o tabuleiro.
🧀 Recovery também é Swiss Cheese
Camadas:
Backup
↓
Logs
↓
Recovery Procedure
↓
Validation
↓
Security Fix
↓
Monitoring
Uma falha não deve destruir tudo.
🚗 E então a Ferrari cai
A beleza da cena é que o plano de marcha a ré não apenas falha conceitualmente.
A situação piora dramaticamente.
É quase uma alegoria perfeita de recovery improvisado.
Você tenta corrigir incidente.
Cria outro.
Quem nunca?
💥 “A correção causou indisponibilidade”
Clássico.
Script emergencial.
Configuração errada.
Restore incompleto.
Rollback impossível.
O remédio cria novo problema.
Isso é por que mudança durante incidente precisa de controle.
🧠 Change Management continua existindo em crise
Urgência não elimina risco.
Pode simplificar processo.
Mas não significa:
faça qualquer coisa.
Mudanças emergenciais também precisam de:
registro;
aprovação;
plano de retorno;
validação.
🔁 O plano de rollback precisa existir antes da mudança
Essa frase é fundamental.
Não depois.
Antes.
Toda mudança deveria perguntar:
se falhar, como voltamos?
Se resposta for:
“depois vemos”,
você acabou de criar dívida operacional.
🔵 Blue Team e Operations precisam conversar
Segurança detecta.
Operações recupera.
DBA restaura.
Aplicação valida.
Negócio confirma.
Incidente atravessa times.
Recovery é colaborativo.
🧠 Técnica e negócio precisam concordar sobre “recuperado”
Infra diz:
servidor está online.
DBA:
banco está consistente.
Aplicação:
serviço responde.
Negócio:
clientes ainda estão vendo saldo errado.
Então não recuperou.
📊 Recovery precisa de critérios
Não basta “verde no dashboard”.
Precisamos validar:
integridade;
completude;
reconciliação;
transações;
acessos;
segurança.
Ferrari dentro da garagem não basta.
Precisamos saber se o pai percebeu.
🧾 Reconciliação
Especialmente em sistemas financeiros.
Comparar:
origem;
destino;
totais;
contagens;
valores.
Isso encontra discrepâncias depois de recuperação.
🦖 Db2 + CICS + MQ: recovery coordenado
Em sistemas empresariais, vários componentes interagem.
Db2 atualiza.
CICS coordena.
MQ envia.
Recuperação precisa respeitar consistência entre componentes.
Não adianta um voltar para 10h e outro ficar em 10h30.
🕰️ Time consistency
Esse é um problema real.
Quando múltiplos sistemas têm backups em horários diferentes, restore pode criar mundos paralelos.
Sistema A pensa que evento aconteceu.
Sistema B não.
Agora nasce reconciliação dolorosa.
🔐 Cyber Recovery
Hoje fala-se muito em cyber recovery.
Não apenas recuperar hardware.
Recuperar de ataque.
Isso exige:
ambiente limpo;
cópias confiáveis;
validação;
isolamento;
credenciais novas;
forense.
É muito mais amplo.
🧪 Clean Room
Em certos cenários, você recupera num ambiente isolado.
Valida antes de reconectar.
Porque não quer restaurar malware junto.
Ferrari passa por inspeção antes de voltar para garagem.
🧠 Backup infectado também existe
Se comprometimento aconteceu semanas antes e você não percebeu, backup pode conter persistência.
Então:
qual ponto é realmente limpo?
Logs ajudam.
Forense ajuda.
Não é trivial.
🕵️ Detection latency afeta recovery
Quanto mais tempo atacante fica sem ser detectado, mais difícil saber onde voltar.
Incidente identificado em 5 minutos?
Ótimo.
Depois de 60 dias?
Boa sorte.
📉 MTTD encontra RPO
Mean Time To Detect interfere em recuperação.
Se você demora para detectar corrupção, pode ter backups já contaminados.
Detecção não é só segurança.
É recovery.
🚗 A Ferrari ensina observabilidade
Se Cameron tivesse registro claro de:
quem tirou;
quando;
quanto rodou;
onde;
talvez não tentasse resolver com marcha a ré.
Informação reduz pânico.
🧠 Pânico produz rollback ruim
Em incidente, a primeira vontade é voltar.
Mas recovery precipitado pode destruir evidência.
Antes de apagar:
preserve.
Colete.
Registre.
Depois recupere.
Forense e operação precisam equilibrar.
🔬 Preserve Evidence
Imagem de disco.
Logs.
Memória quando necessário.
Eventos.
Artefatos.
Porque depois do restore talvez você perca pistas.
Ferrari lavada demais perde impressão digital.
🧾 Cadeia de custódia
Em incidentes graves, evidência pode ter valor jurídico.
Quem coletou?
Quando?
Como preservou?
Integridade.
Mais uma vez: história importa.
☕ Produção não possui memória emocional, mas nós possuímos
Sistemas podem voltar.
Pessoas lembram.
Clientes lembram.
Auditores lembram.
Reguladores lembram.
Diretores lembram.
É por isso que incidentes têm efeitos duradouros.
🎬 Ferris tentou resolver um problema técnico que já era humano
A quilometragem era um indicador.
O verdadeiro problema era:
Cameron havia quebrado confiança com o pai.
Não existe rollback técnico para isso.
A cena é genial justamente porque mostra limite da reversibilidade.
🧠 Segurança também lida com confiança
Depois de vazamento:
usuários mudam comportamento.
Clientes questionam.
Parceiros exigem garantias.
Você pode restaurar sistema em duas horas.
Reputação pode levar anos.
Esse é o Ctrl+Z emocional que não existe.
🔴 O objetivo não é voltar no tempo
Essa é talvez a conclusão mais madura.
Recovery não é viagem temporal.
É construir um estado novo e confiável depois de algo ruim.
Você não apaga incidente.
Você aprende.
Corrige.
Recupera.
Monitora.
Segue.
🔁 Recovery como transição, não reversão
Pense:
NORMAL
↓
INCIDENT
↓
CONTAINMENT
↓
RECOVERY
↓
NEW TRUSTED STATE
Não voltamos exatamente ao começo.
Voltamos melhores.
Ou deveríamos.
☕ A pergunta final Bellacosa
Quando alguém disser:
— Dá para dar rollback?
Pergunte:
“Rollback de quê?”
Do banco?
Do arquivo?
Da aplicação?
Do pagamento?
Da mensagem?
Da confiança?
Do vazamento?
Essa pergunta salva reuniões.
🎬 Epílogo: marcha a ré não apaga estrada
A Ferrari anda para frente.
Depois anda para trás.
Mas a estrada continua existindo.
Esse é o ponto.
Sistemas guardam estado.
Negócios acumulam consequências.
Pessoas acumulam memória.
Red Team precisa pensar nisso porque ataque não termina no acesso inicial.
Importa também:
o que pode ser revertido;
o que pode ser restaurado;
o que pode ser compensado;
o que é irreversível.
Backup é essencial.
Restore é capacidade.
Rollback é mecanismo.
Journaling é memória.
Logs são história.
Recovery é processo.
E resposta a incidente é o momento em que tudo isso precisa funcionar junto.
Então, da próxima vez que alguém sugerir:
“É só voltar.”
Coloque a xícara na mesa.
Olhe para a equipe.
E responda:
“Produção não possui Ctrl+Z emocional.”
Porque às vezes você consegue colocar a Ferrari em marcha a ré.
Mas não consegue fazer o mundo esquecer que ela saiu da garagem.
☕ SAVE FERRIS.
No próximo artigo:
Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente
Porque depois de errar o rollback...
nada melhor do que deixar o defensor destruir o ambiente tentando provar que estava certo.
Sem comentários:
Enviar um comentário