 |
| Bellacosa Mainframe e o incidente do queijo suico |
☕ Um Café no Bellacosa Mainframe
O Incidente do Queijo Suíço: Doctor Who, COBOL e o Dia em que Todos os Buracos se Alinharam
Uma viagem pela TARDIS dos incidentes para entender por que sistemas seguros também falham
Imagine a seguinte manhã.
08:02.
Você chega ao trabalho.
Café na mesa.
TSO aberto.
ISPF funcionando.
Nenhum chamado desesperado.
Nenhum gerente perguntando por que a produção está parada.
Nenhum telefone tocando com aquela frase que todo analista veterano aprendeu a temer:
— Você mexeu em alguma coisa ontem?
Uma manhã perfeita.
Naturalmente, isso significa que alguma coisa terrível está prestes a acontecer.
Às 08:17, um pequeno alerta aparece no monitoramento.
Nada grave.
Às 08:22, outro.
Também aparentemente irrelevante.
Às 08:41, um job termina com RC=04.
Alguém olha.
— RC=04 não é erro.
Tecnicamente, a pessoa está correta.
O que, em informática, às vezes é uma maneira particularmente eficiente de estar completamente errada.
Às 09:06, uma fila começa a crescer.
Às 09:35, um batch demora sete minutos a mais que o normal.
Às 10:12, um operador executa um procedimento alternativo que já havia sido usado outras vezes.
Às 10:46, uma aplicação recebe dados incompletos.
Às 11:03, a primeira reclamação chega.
Às 11:11, cinquenta reclamações.
Às 11:27, alguém pronuncia a palavra que transforma adultos perfeitamente civilizados em personagens de filme-catástrofe:
produção.
E então, em algum lugar do universo, ouvimos o som característico da TARDIS.
VWORP.
VWORP.
VWORP.
Aquela velha cabine policial azul pousa discretamente ao lado de um IBM Z.
A porta se abre.
O Doctor olha para os consoles.
Olha para os operadores.
Olha novamente para os consoles.
E provavelmente diz:
— Fascinante.
Pausa.
— Vocês têm café?
Porque hoje não estamos procurando simplesmente quem errou.
Estamos procurando algo muito mais interessante:
como diversas pequenas falhas conseguiram se alinhar e atravessar todas as defesas do sistema.
Bem-vindo ao Swiss Cheese Model.
🧀 Afinal, o que queijo suíço tem a ver com incidentes?
O chamado Swiss Cheese Model, ou Modelo do Queijo Suíço, foi desenvolvido e popularizado pelo psicólogo britânico James Reason no estudo de erros humanos, acidentes e segurança de sistemas complexos.
A ideia central é brilhantemente simples.
Imagine que uma organização possua várias barreiras destinadas a impedir que alguma coisa ruim aconteça.
Por exemplo:
procedimentos;
treinamento;
validações;
testes;
segregação de funções;
revisão de código;
monitoramento;
autorização;
redundância;
backups;
controles automáticos.
Cada uma dessas barreiras seria uma fatia de queijo suíço.
O problema?
Nenhuma fatia é perfeita.
Cada uma possui buracos.
Esses buracos representam fragilidades.
Uma pessoa pode estar cansada.
Um procedimento pode estar desatualizado.
Um teste pode não cobrir determinado cenário.
Um alerta pode ter sido configurado incorretamente.
Uma documentação pode ser ambígua.
Um sistema pode permitir determinada operação sem confirmação.
Uma decisão gerencial tomada seis meses atrás pode ter reduzido redundâncias.
Normalmente isso não produz um desastre.
Por quê?
Porque existe outra fatia depois.
E outra.
E outra.
Um operador erra, mas o sistema detecta.
O sistema não detecta, mas a revisão humana percebe.
A revisão não percebe, mas uma validação posterior bloqueia.
A validação falha, mas o monitoramento dispara.
E assim por diante.
O acidente aparece quando, temporariamente, os buracos das diferentes fatias ficam alinhados.
A ameaça atravessa todas as barreiras.
É como se alguém pudesse olhar através de cinco pedaços de queijo e enxergar perfeitamente o outro lado.
Nesse momento:
Houston, nós temos um problema.
Ou, para manter nossa viagem britânica:
Doctor, I think we have a problem.
🌀 A TARDIS pousa antes do incidente
Existe algo especialmente interessante no Swiss Cheese Model.
Ele nos obriga a viajar no tempo.
Quando investigamos um incidente da maneira tradicional, existe uma tendência natural de começar pelo último acontecimento.
O programa apagou o arquivo.
Quem executou?
João.
Caso encerrado.
João apagou o arquivo.
Treinamos João.
Mandamos um memorando dizendo:
“Tenham mais atenção ao apagar arquivos.”
Pronto.
Problema resolvido.
Até o próximo João.
O Swiss Cheese Model pergunta:
Por que João tinha capacidade de apagar aquele arquivo?
Outra pergunta:
Por que não havia confirmação?
Outra:
Por que não havia backup imediatamente recuperável?
Outra:
Por que o procedimento permitia aquela operação?
Outra:
Por que ninguém percebeu durante os testes que esse cenário era possível?
Outra:
Por que João estava realizando aquela atividade sob pressão às duas horas da manhã?
Outra:
Por que aquele trabalho precisava acontecer às duas horas da manhã?
Outra:
Quem decidiu isso?
Outra:
Quando essa decisão foi tomada?
Agora entramos na TARDIS.
Porque descobrimos que o incidente das 02:17 começou talvez seis meses antes.
🧀 Fatia número 1 — O programador COBOL
Vamos construir um exemplo.
Você é um programador COBOL iniciante.
Recebe uma alteração:
“Excluir registros temporários com mais de 90 dias.”
Programa simples.
Algo conceitualmente parecido com:
IF WS-DIAS > 90
DELETE ARQUIVO
END-IF.
Você desenvolve.
Compila.
Testa.
Funciona.
Primeira fatia de queijo.
Mas existe um buraco.
A variável que calcula os dias eventualmente recebe uma data inválida.
Seu teste não cobre essa situação.
Ainda não aconteceu nada.
🧀 Fatia número 2 — Code Review
Outro desenvolvedor revisa seu código.
Ele verifica:
sintaxe;
nomes;
padrões;
fluxo;
chamadas;
tratamento de erros.
Tudo parece razoável.
A alteração é aprovada.
Segunda fatia.
Mas existe outro buraco.
O revisor também não percebe a condição envolvendo datas inválidas.
Dois buracos.
Ainda não estão alinhados necessariamente.
🧀 Fatia número 3 — Homologação
O programa vai para homologação.
Testam:
registro com 30 dias;
registro com 89;
registro com 90;
registro com 91;
registro com 180.
Perfeito.
Só que ninguém testa uma data zerada.
Ninguém testa 31 de fevereiro.
Ninguém testa um registro antigo migrado de outro sistema cujo campo possui um formato historicamente diferente.
Terceira fatia.
Terceiro buraco.
A ameaça continua avançando.
🧀 Fatia número 4 — Controle operacional
O programa entra em produção.
Existe uma previsão:
antes da exclusão definitiva, deveria ser produzido um relatório para conferência.
Excelente defesa.
Só existe um pequeno detalhe.
O volume cresceu muito nos últimos anos.
O relatório agora possui centenas de milhares de linhas.
Ninguém realmente o lê.
Ele existe.
É produzido.
É arquivado.
A auditoria pode verificar que o controle existe.
Todo mundo fica feliz.
Exceto o queijo.
Porque temos outro buraco.
Essa situação possui inclusive um nome extremamente importante no estudo de incidentes:
controle ritualístico.
Um mecanismo continua existindo formalmente, mas perdeu sua função prática.
O relatório nasceu para ser conferido.
Com o tempo virou:
“o relatório que precisamos gerar porque o procedimento manda.”
Isso acontece assustadoramente em ambientes corporativos.
🧀 Fatia número 5 — Backup
Mas tudo bem.
Temos backup.
A palavra mais reconfortante da informática.
Até alguém perguntar:
— Já testamos o restore?
Silêncio.
Um silêncio tão profundo que quase podemos ouvir a TARDIS estacionando.
Ter backup não significa necessariamente possuir capacidade de recuperação.
Existe uma diferença gigantesca entre:
backup realizado
e
restauração comprovadamente funcional dentro do tempo necessário.
Mais um buraco.
💥 Agora os buracos se alinham
Chega o dia.
Um conjunto de registros antigos possui datas inconsistentes.
O programa interpreta incorretamente.
A homologação nunca testou.
O code review não percebeu.
O relatório operacional é grande demais e ninguém verifica.
O job executa.
Os registros são apagados.
O backup existe.
Mas a restauração é lenta e nunca havia sido ensaiada adequadamente.
Pronto.
Incidente.
E agora surge a pergunta tradicional:
Quem escreveu o programa?
Nosso Doctor provavelmente levantaria uma sobrancelha.
Porque essa é uma pergunta extremamente conveniente.
Mas muito pobre.
O programador participou do incidente?
Sim.
Foi a causa?
Não exatamente.
Ele foi uma das fatias.
👨⚕️ James Reason e os dois tipos de falha
Aqui aparece uma das partes mais importantes dessa teoria.
Reason diferencia especialmente dois grupos de condições:
Falhas ativas
São erros próximos do evento.
Exemplos:
operador pressionou botão errado;
desenvolvedor criou condição incorreta;
administrador executou comando errado;
piloto selecionou opção equivocada;
enfermeiro administrou medicamento incorreto.
São extremamente visíveis.
Por isso recebem atenção.
🕰️ Condições latentes
Agora começam as coisas interessantes.
Condições latentes são fraquezas que podem permanecer escondidas durante semanas, meses ou anos.
Por exemplo:
Essas condições ficam esperando.
Como Cybermen adormecidos em uma instalação esquecida.
Até surgir a combinação adequada.
🧠 O erro humano frequentemente é consequência, não origem
Essa ideia merece ser colocada em letras garrafais.
“Erro humano” não deveria encerrar uma investigação.
Deveria iniciá-la.
Quando alguém diz:
“O incidente aconteceu por erro humano.”
Nossa próxima pergunta deveria ser:
“Excelente. Agora podemos começar a investigação?”
Porque dizer que um humano errou explica aproximadamente tanto quanto dizer que um avião caiu porque deixou de voar.
Precisamos descobrir por quê.
A pessoa estava cansada?
A interface induzia ao erro?
Havia duas opções visualmente idênticas?
O procedimento estava errado?
Existia pressão para terminar rapidamente?
Era normal ignorar aquele alarme?
A pessoa havia sido treinada?
O sistema permitia desfazer?
A ação exigia dupla autorização?
Quanto mais investigamos, mais descobrimos que aquilo que chamamos de “erro humano” frequentemente é a manifestação visível de problemas sistêmicos.
🚨 Os pequenos sinais antes da invasão
Uma das missões de nossa série será procurar weak signals, os sinais fracos.
Antes do grande incidente, normalmente existem pequenas pistas.
Imagine:
segunda-feira:
RC=04.
terça:
job demorou dez minutos a mais.
quarta:
um operador precisou reiniciar manualmente.
quinta:
duas reclamações.
sexta:
um arquivo ficou próximo de 90% de utilização.
Individualmente, parecem pequenas coisas.
Em conjunto podem formar uma narrativa.
É aqui que observabilidade e cultura operacional tornam-se fundamentais.
Não basta perguntar:
“O sistema está funcionando?”
Precisamos perguntar:
“O sistema está se comportando como normalmente se comporta?”
São perguntas muito diferentes.
📊 Baseline: conheça o normal antes de procurar o anormal
Imagine um batch que normalmente processa dez milhões de registros em 45 minutos.
Hoje levou 47.
Normal.
Amanhã 48.
Normal.
Depois 51.
Hmm.
Depois 56.
Ainda funciona.
Depois 63.
Continua RC=00.
Depois 81.
RC=00 novamente.
Tudo verde.
Mas existe uma tendência.
Um iniciante frequentemente procura ABEND.
Um profissional experiente procura mudança de comportamento.
Esse é um conhecimento importantíssimo para quem entra no mainframe.
RC=00 significa apenas que determinado programa terminou segundo critérios que foram definidos como sucesso.
Não significa:
“Todo o universo está em perfeita harmonia.”
🧀 Não existe queijo perfeito
Talvez você pense:
“Então precisamos eliminar todos os buracos.”
Seria ótimo.
Também seria ótimo possuir uma TARDIS.
Na engenharia real, sistemas possuem limitações.
Pessoas possuem limitações.
Processos possuem limitações.
Recursos são finitos.
Não existe segurança absoluta.
A estratégia é criar defesa em profundidade.
Se uma barreira falhar, outra deverá impedir a propagação.
Essa filosofia aparece em:
segurança cibernética;
aviação;
medicina;
energia nuclear;
sistemas financeiros;
engenharia industrial;
mainframes.
Nunca confie exclusivamente em uma única proteção.
🏦 Exemplo Bellacosa Mainframe: transferência bancária
Imagine uma transferência de R$ 10 milhões.
Seria pouco prudente possuir apenas:
EXEC CICS
TRANSFER MONEY
END-EXEC
e torcer pelo melhor.
Em um sistema sério existirão diversas barreiras:
autenticação;
autorização;
limite transacional;
validação da conta;
saldo;
controle antifraude;
segregação de funções;
confirmação;
log;
monitoramento;
reconciliação;
auditoria.
Cada uma é uma fatia do queijo.
Uma pode falhar.
Talvez duas.
O objetivo é impedir que todas falhem simultaneamente.
🛠️ Como aplicar o Swiss Cheese Model em um incidente
Agora vamos transformar teoria em método.
Imagine que ocorreu um incidente ontem.
Não comece procurando culpados.
Pegue café.
Abra um quadro.
E faça o seguinte.
Passo 1 — Defina o evento
Escreva claramente o que aconteceu.
Evite:
“O sistema deu problema.”
Prefira:
“Entre 14:03 e 14:47, transações do canal X foram processadas duas vezes.”
Precisão importa.
Passo 2 — Construa uma timeline
14:00 — deploy.
14:03 — primeiro erro.
14:04 — alerta.
14:09 — operador reconhece alerta.
14:16 — chamados aparecem.
14:22 — equipe de aplicação acionada.
14:31 — processamento interrompido.
14:47 — serviço estabilizado.
Timeline frequentemente revela coisas que narrativas escondem.
Passo 3 — Identifique as defesas esperadas
Pergunte:
O que deveria impedir isso?
Talvez:
teste automatizado;
revisão;
autorização;
monitoramento;
reconciliação;
rollback.
Cada mecanismo vira uma fatia.
Passo 4 — Descubra o buraco de cada fatia
Por que o teste não detectou?
Por que a revisão não detectou?
Por que o alerta não funcionou?
Por que o operador não percebeu?
Por que não houve rollback?
Não aceite:
“porque fulano esqueceu.”
Pergunte por que era possível esquecer.
🔍 Passo 5 — Procure condições latentes
Agora viaje meses para trás.
Houve corte de equipe?
Mudança organizacional?
Migração?
Novo fornecedor?
Pressão por entrega?
Acúmulo de dívida técnica?
Procedimento antigo?
Alertas demais?
Sistema sem manutenção?
Você ficará surpreso com quantos acidentes possuem raízes muito anteriores ao evento.
🧹 Passo 6 — Não corrija apenas o último buraco
Depois de um incidente causado por um comando incorreto, uma organização pode decidir:
“Treinaremos novamente os operadores.”
Ótimo.
Mas talvez também fosse necessário:
alterar a interface;
exigir confirmação;
restringir permissão;
registrar comando;
automatizar operação;
criar rollback;
melhorar documentação.
Treinamento sozinho frequentemente é a correção favorita porque é barata e transfere responsabilidade para pessoas.
Mas pessoas continuam sendo pessoas.
E continuarão errando.
Projetar sistemas seguros significa considerar essa realidade.
🔁 Passo 7 — Feche o loop
Aqui entramos no verdadeiro objetivo da nossa série:
melhoria contínua.
Incidente sem aprendizado é apenas sofrimento administrativo.
Depois do post-mortem, crie ações.
Cada ação precisa de:
responsável;
prazo;
prioridade;
evidência de conclusão;
validação posterior.
Caso contrário teremos um documento lindíssimo armazenado em algum SharePoint que ninguém jamais abrirá novamente.
Possivelmente ao lado de outros 847 post-mortems.
Todos chamados:
INCIDENT_FINAL_V2_FINAL_AGORA_VAI.docx
🪤 A grande armadilha: hindsight bias
Depois que sabemos o resultado, tudo parece óbvio.
“Como ninguém percebeu?”
Essa frase aparece depois de praticamente todos os grandes acidentes.
Mas existe um fenômeno chamado hindsight bias, o viés retrospectivo.
Nós conhecemos o final.
As pessoas naquele momento não conheciam.
Elas estavam tomando decisões com informações incompletas.
Por isso uma investigação justa pergunta:
“Com as informações disponíveis naquele instante, essa decisão parecia razoável?”
Essa pergunta muda tudo.
⚖️ Blameless não significa ausência de responsabilidade
Outra confusão comum.
Um post-mortem sem caça às bruxas não significa:
“ninguém é responsável por nada.”
Existem negligência, violações deliberadas e comportamentos imprudentes.
Eles precisam ser tratados.
Mas um ambiente que pune automaticamente qualquer erro cria outro problema:
as pessoas começam a esconder erros.
E sistemas complexos onde ninguém relata pequenos problemas são maravilhosos.
Até explodirem.
🛸 Doctor Who e o paradoxo da prevenção
Existe uma injustiça curiosa na segurança.
Quando você evita um incidente, aparentemente nada aconteceu.
Você detectou um problema.
Corrigiu.
Produção continuou.
No relatório executivo:
0 incidentes.
Alguém então pergunta:
— Por que gastamos tanto com essa equipe se nunca acontece nada?
Essa talvez seja uma das grandes ironias corporativas.
O sucesso da prevenção frequentemente parece evidência de que prevenção não era necessária.
O Doctor conhece bem esse problema.
Salva o universo.
Volta para a TARDIS.
E provavelmente ninguém aprovou sequer uma hora extra.
🧀 O queijo suíço aplicado à sua primeira semana como COBOL
Se você está começando agora, crie este hábito.
Ao escrever um programa, pergunte:
Se meu código estiver errado, o que impedirá o desastre?
Depois:
E se essa proteção também falhar?
Depois:
Existe outra?
Exemplo:
Programa gera arquivo.
Fatia 1: validação no programa.
Fatia 2: contagem de registros.
Fatia 3: totalizadores financeiros.
Fatia 4: comparação com histórico.
Fatia 5: validação antes da aplicação.
Fatia 6: possibilidade de rollback.
Agora você não está apenas programando.
Está pensando como engenheiro de confiabilidade.
🧪 Teste também o impossível
Uma das melhores lições para iniciantes:
testar apenas o caminho feliz é fácil.
Teste:
arquivo vazio;
arquivo duplicado;
número negativo;
campo inválido;
data impossível;
registro maior;
registro menor;
sequência incorreta;
arquivo inexistente;
disco cheio;
timeout;
retorno inesperado.
Pergunte constantemente:
“O que aconteceria se...?”
Essa pergunta talvez seja uma das ferramentas mais poderosas da engenharia.
👻 Easter Egg nº 1
Em Doctor Who existe uma regra quase universal:
se existe um corredor escuro onde claramente ninguém deveria entrar, alguém inevitavelmente entra.
Em TI existe uma versão semelhante:
se existe um parâmetro chamado:
BYPASS-VALIDATION=YES
alguém eventualmente usará.
Provavelmente numa sexta-feira.
Às 17:43.
🧯 Near Miss: quando o Dalek erra o tiro
Nem todo alinhamento de buracos termina em desastre.
Às vezes alguma defesa final salva o sistema.
Isso é um near miss.
Quase acidente.
E near misses são ouro.
Uma organização madura não comemora simplesmente:
“Ufa, não aconteceu nada.”
Ela pergunta:
“Por que quase aconteceu?”
Porque o universo acabou de oferecer uma investigação gratuita.
Sem clientes prejudicados.
Sem manchetes.
Sem diretor telefonando.
Estude seus near misses.
Eles são trailers dos incidentes futuros.
📚 Curiosidade: acidentes são bibliotecas
Existe um hábito poderoso para profissionais de tecnologia:
estudar acidentes de outras áreas.
Leia sobre:
aviação;
energia nuclear;
medicina;
ferrovias;
exploração espacial;
indústria química.
Por quê?
Porque tecnologias mudam.
Comportamentos sistêmicos, nem tanto.
Você começa a reconhecer padrões.
Pressão por prazo.
Alertas ignorados.
Redundância removida.
Normalização de desvios.
Comunicação falha.
Treinamento insuficiente.
Confiança excessiva na automação.
É quase assustador.
Troque cockpit por data center e certos relatórios parecem familiares.
🔄 Regeneração
E chegamos à palavra perfeita para nossa série.
No universo de Doctor Who, o Doctor não simplesmente morre.
Ele regenera.
Muda.
Aprende.
Continua.
Uma organização madura deveria fazer algo parecido depois de cada incidente.
Não restaurar simplesmente o estado anterior.
Mas perguntar:
como voltaremos melhores?
Esse é o objetivo da melhoria contínua.
Incidente.
Análise.
Aprendizado.
Mudança.
Validação.
Monitoramento.
Novo aprendizado.
Um loop.
🌀 A verdadeira mensagem do Swiss Cheese Model
Talvez o maior ensinamento seja abandonar a fantasia confortável de que acidentes possuem uma causa única.
Encontramos frequentemente diagramas assim:
João executou comando errado
↓
Sistema caiu
Simples.
Elegante.
Provavelmente incompleto.
A realidade costuma parecer mais assim:
pressão por prazo
↓
procedimento abreviado
↓
treinamento incompleto
↓
interface ambígua
↓
permissão excessiva
↓
comando incorreto
↓
alerta ignorado
↓
rollback indisponível
↓
INCIDENTE
Agora temos algo que pode realmente ser melhorado.
☕ Diário do Doctor
Se você guardar apenas algumas ideias desta nossa primeira viagem pela TARDIS dos incidentes, guarde estas:
Um acidente raramente nasce de uma única falha.
Existem diversas camadas de proteção.
Todas possuem fragilidades.
Incidentes surgem quando essas fragilidades se alinham.
O erro visível geralmente está próximo do fim da cadeia.
Condições latentes podem existir durante meses ou anos.
Erro humano deve iniciar perguntas, não encerrá-las.
Near misses precisam ser investigados.
Monitorar comportamento é tão importante quanto monitorar falhas.
Defesa em profundidade é melhor que confiar numa única proteção.
Post-mortems precisam produzir mudança verificável.
E talvez a mais importante:
não procure apenas quem estava segurando a chave de fenda quando a máquina explodiu. Descubra por que havia uma máquina capaz de explodir quando alguém segurasse aquela chave de fenda daquele jeito.
🧀 O último pedaço de queijo
Nosso programador COBOL iniciante fecha o notebook.
Olha para o velho mainframe.
Agora entende algo que talvez nenhum manual de sintaxe tenha explicado.
Programar não é apenas escrever instruções corretas.
É imaginar o que acontece quando alguma coisa estiver errada.
Porque estará.
Algum dia.
Em algum lugar.
Um campo virá inválido.
Um arquivo ficará cheio.
Uma rede cairá.
Uma pessoa ficará cansada.
Um procedimento estará desatualizado.
Um teste esquecerá um cenário.
Uma mensagem será interpretada incorretamente.
Não podemos eliminar completamente esses buracos.
Mas podemos evitar que se alinhem.
Lá fora ouvimos novamente:
VWORP.
VWORP.
VWORP.
A TARDIS começa a desaparecer.
O Doctor coloca a cabeça para fora da porta.
— Ah, mais uma coisa.
Olha para nosso jovem programador COBOL.
— RC=00?
O programador sorri.
— Sucesso.
O Doctor faz aquela expressão de quem acabou de encontrar algo terrivelmente interessante.
— Não. Apenas significa que o programa acredita que terminou bem.
Fecha a porta.
A TARDIS desaparece.
Na console chega uma mensagem:
JOB12345 ENDED - RC=0000
Tudo parece perfeito.
E é justamente por isso que resolvemos dar uma olhada nos logs.
Porque esta série está apenas começando.
Next stop: Normalization of Deviance.
Ou, como provavelmente diria algum operador veterano:
“Sempre fizemos desse jeito e nunca deu problema.”
Até o dia em que deu.
☕🌀
