 |
| Bellacosa Mainframe e a normalizacao do desvio |
☕ Um Café no Bellacosa Mainframe
A Normalização do Desvio: Doctor Who, COBOL e o Dia em que o Errado Virou Procedimento
Uma viagem pela TARDIS dos incidentes para descobrir por que “sempre fizemos assim” talvez seja uma das frases mais perigosas da informática
08:07.
Sala de operação.
Café razoavelmente quente.
Mainframe perfeitamente indiferente aos dramas humanos.
Um job termina:
JOB04217 ENDED - RC=0004
O programador COBOL recém-chegado olha para a tela.
Ele chama o analista veterano.
— Deu RC=04.
O veterano nem levanta os olhos.
— Normal.
O jovem observa novamente.
RC=0004
Ele hesita.
— Mas quatro não significa que aconteceu alguma coisa diferente?
O veterano bebe o café.
— Faz três anos que termina assim.
— E está correto?
— Nunca deu problema.
Nesse exato momento, em algum ponto aparentemente impossível entre Londres, Gallifrey e uma sala de máquinas IBM, começa aquele som.
VWORP.
VWORP.
VWORP.
Uma velha cabine policial azul materializa-se entre dois racks.
A porta abre.
O Doctor sai.
Olha para o monitor.
Olha para o veterano.
Olha novamente para:
RC=0004
E pergunta:
— Por que isso é normal?
O veterano responde:
— Porque acontece todos os dias.
O Doctor faz uma expressão preocupada.
— Ah.
Pausa.
— Isso não significa que seja normal.
Outra pausa.
— Significa apenas que vocês se acostumaram.
E assim começa nosso segundo passeio pela TARDIS dos incidentes.
Hoje conheceremos um dos fenômenos mais fascinantes — e perigosos — da engenharia de sistemas:
Normalization of Deviance
ou:
Normalização do Desvio.
🌀 Primeiro precisamos voltar no tempo
Nossa viagem anterior terminou no Swiss Cheese Model, de James Reason.
Aprendemos que sistemas complexos possuem várias camadas de defesa.
Cada camada possui fragilidades.
Os famosos buracos do queijo.
Um erro pode atravessar uma barreira e ser interrompido pela seguinte.
O desastre aparece quando vários buracos acabam alinhados.
Mas existe uma pergunta que ficou esperando dentro da TARDIS:
Como alguns desses buracos ficam tão grandes?
Ou ainda:
Como uma organização consegue conviver durante anos com uma situação claramente anormal sem perceber que existe perigo?
É aqui que encontramos a socióloga Diane Vaughan.
Vaughan estudou profundamente o processo decisório relacionado ao desastre do ônibus espacial Challenger e popularizou o conceito de normalization of deviance para explicar como desvios em relação aos padrões esperados podem, ao longo do tempo, tornar-se aceitos como normais dentro de uma organização. Materiais posteriores da própria NASA continuam usando explicitamente o conceito ao discutir Challenger, Columbia e outros eventos de segurança. (NTRS)
A ideia pode ser resumida assim:
Algo começa fora do padrão.
Nada ruim acontece.
Repetimos.
Nada ruim acontece novamente.
Repetimos outra vez.
Lentamente deixamos de enxergar aquilo como exceção.
Até que o desvio se transforma em normalidade.
E talvez a frase mais importante deste artigo seja:
Ausência de desastre não é evidência de segurança.
🧀 O queijo suíço começa a mudar de sabor
Voltemos ao nosso exemplo.
O padrão oficial diz:
RC=0000
Mas determinada rotina começou a terminar ocasionalmente com:
RC=0004
Na primeira vez alguém investigou.
Descobriu que existia um warning.
O processamento pareceu correto.
Nada foi perdido.
Então alguém decidiu:
— Podemos seguir.
Na semana seguinte:
RC=04 novamente.
A equipe verifica.
Tudo aparentemente correto.
Depois de um mês, ninguém verifica.
Depois de seis meses, o operador escreve no procedimento:
RC=04 pode ser ignorado.
Depois de dois anos, um programador pergunta:
— Por quê?
E ninguém mais sabe.
Essa é a parte fascinante.
A exceção adquiriu tradição.
👻 O fantasma do “nunca deu problema”
Existe uma expressão que aparece frequentemente em incidentes:
“Sempre fizemos assim.”
Sua prima:
“Nunca deu problema.”
E uma terceira:
“Isso acontece direto.”
As três deveriam causar aproximadamente a mesma reação que ouvir alguém dizer em Doctor Who:
“Não se preocupe. Essas estátuas nunca se mexem.”
Talvez seja uma boa hora para não piscar.
🚀 Challenger: quando resultados anteriores começam a ensinar a lição errada
O conceito de Diane Vaughan ficou fortemente associado à análise organizacional do desastre do Space Shuttle Challenger.
O Challenger foi destruído 73 segundos após o lançamento de 28 de janeiro de 1986, e os sete tripulantes morreram. A investigação e os estudos posteriores concentraram-se, entre outras questões, no comportamento dos O-rings dos Solid Rocket Boosters e no processo decisório que antecedeu o lançamento. (NTRS)
Mas o aspecto organizacional é particularmente interessante para nossa TARDIS.
Problemas e evidências envolvendo comportamento inadequado dos O-rings haviam aparecido anteriormente.
Os lançamentos anteriores, entretanto, não haviam terminado em catástrofe.
E aí ocorre algo profundamente humano.
Cada sucesso anterior começa a funcionar como argumento de segurança.
Observe a perversidade lógica:
Houve anomalia.
↓
Não ocorreu acidente.
↓
Logo, a anomalia aparentemente é tolerável.
↓
Repetimos.
↓
Outra anomalia.
↓
Novamente não ocorreu acidente.
↓
A confiança aumenta.
Parece lógico.
Mas existe um problema monumental.
Talvez você não esteja demonstrando que o sistema é seguro.
Talvez esteja apenas tendo sorte.
A própria NASA posteriormente passou a discutir explicitamente a normalização do desvio como uma lição de segurança associada a Challenger e Columbia. (NTRS)
🎲 Sorte não é controle operacional
Imagine um programa COBOL.
Existe um array:
01 WS-TABELA.
05 WS-ITEM OCCURS 100 TIMES.
Alguém encontra um cenário onde um índice eventualmente chega a 101.
Por alguma razão, nada visível acontece.
Talvez aquela posição de memória não produza imediatamente um efeito perceptível.
Executa novamente.
Nada.
Mais uma vez.
Nada.
Alguém conclui:
“Pode deixar.”
Não.
O que aconteceu foi apenas:
“Ainda não observamos a consequência.”
Essas duas frases parecem semelhantes.
Não são.
🧠 O cérebro humano aprende com resultados
Nós somos excelentes máquinas de reconhecimento de padrões.
Isso nos salvou muitas vezes durante a evolução.
Se fazemos algo repetidamente e recebemos um resultado positivo, nosso cérebro aprende:
isso funciona.
No trabalho ocorre o mesmo.
Imagine:
procedimento oficial: 12 passos.
Operador percebe que pode pular os passos 4 e 7.
Executa.
Tudo funciona.
No dia seguinte repete.
Funciona.
Depois ensina para o colega:
— Esses dois você não precisa fazer.
Meses depois chega um novo funcionário.
Pergunta por que o procedimento possui doze passos se todo mundo realiza dez.
Resposta:
— O documento está velho.
Talvez esteja.
Ou talvez os passos quatro e sete existam porque alguém aprendeu uma lição extremamente cara em 1998.
Mas ninguém mais se lembra.
🏛️ A arqueologia dos procedimentos
Essa é uma dica valiosíssima para quem entra em ambientes legados.
Nunca presuma imediatamente que um procedimento estranho é inútil.
Pergunte:
por que isso existe?
Mainframes possuem décadas de história operacional.
Algumas rotinas aparentemente absurdas surgiram porque algum incidente igualmente absurdo aconteceu muito tempo atrás.
Talvez exista uma checagem aparentemente redundante porque um arquivo chegou vazio em 1994.
Talvez exista uma reconciliação porque um lote foi processado duas vezes em 2001.
Talvez alguém exija:
COUNT INPUT = COUNT OUTPUT + COUNT REJECT
porque certa madrugada milhões desapareceram em alguma etapa intermediária.
Procedimentos carregam fósseis de incidentes.
O problema aparece quando esquecemos a história.
Então começamos a retirar as proteções.
🦖 Easter Egg nº 1 — O procedimento jurássico
Todo ambiente mainframe possui pelo menos um procedimento cujo autor:
aposentou-se;
mudou de empresa;
ninguém conhece;
talvez seja hoje uma lenda;
ou possivelmente todos os anteriores.
O documento chama-se algo como:
PROCEDIMENTO_BATCH_FINAL_REV17_2007.doc
Ninguém sabe por que o passo 13 existe.
Portanto alguém decide removê-lo.
Três semanas depois descobrimos.
🚨 Como nasce a Normalização do Desvio?
Ela raramente aparece em uma reunião onde alguém anuncia:
“A partir de hoje vamos trabalhar perigosamente.”
Seria conveniente.
Normalmente acontece gradualmente.
Primeiro surge uma pequena exceção.
Depois uma justificativa.
Depois repetição.
Depois tolerância.
Depois hábito.
Depois cultura.
Podemos representar assim:
PADRÃO
↓
PEQUENO DESVIO
↓
NADA ACONTECE
↓
REPETIÇÃO
↓
ACEITAÇÃO
↓
NOVO NORMAL
↓
DESVIO MAIOR
↓
NADA ACONTECE
↓
NOVA ACEITAÇÃO
↓
...
↓
INCIDENTE
Perceba um detalhe terrível.
A fronteira do aceitável se move.
Pouco a pouco.
🐸 A metáfora do sapo — com cuidado
Existe aquela famosa história do sapo colocado em água que esquenta lentamente e não percebe até ser tarde demais.
Como descrição literal do comportamento real de sapos, essa história é problemática.
Mas como metáfora organizacional é extraordinariamente útil.
As pessoas percebem facilmente uma mudança enorme.
Percebem muito menos uma mudança de 1% por semana.
Essa erosão progressiva da segurança também aparece em discussões de engenharia de segurança sob ideias relacionadas, como condições latentes e drift toward failure; um material da NASA sobre segurança organizacional coloca explicitamente esses conceitos próximos à normalização do desvio. (NTRS)
🖥️ Normalização do Desvio no Bellacosa Mainframe
Agora vamos aterrissar definitivamente no z/OS.
Imagine algumas frases.
“Esse dataset chega a 95%, mas nunca estourou.”
Desvio.
“Esse job demora três horas, mas sempre terminou antes da abertura.”
Desvio potencial.
“Temos que reiniciar a CICS toda quarta-feira.”
Hmm.
“Essa transação às vezes dá timeout; manda tentar de novo.”
Muito interessante.
“Quando ocorre esse ABEND, basta restartar.”
Doctor?
“Esse usuário tem SPECIAL porque facilita o suporte.”
DOCTOR?
“Essa senha é compartilhada pela equipe porque é operacional.”
DOCTOR!
O problema não é simplesmente cada situação isolada.
O problema é quando o excepcional ganha aparência de normalidade.
💾 Exemplo: o dataset de 95%
Segunda-feira:
82%.
Terça:
84%.
Semana seguinte:
87%.
Mês seguinte:
91%.
Alerta dispara.
Equipe limpa espaço.
Volta para 75%.
Meses depois:
93%.
Nada acontece.
Depois:
94%.
Nada.
95%.
Ainda funciona.
Então aparece uma nova crença:
“Até 95 está tranquilo.”
Observe.
O limite técnico pode não ter mudado.
Mas o limite psicológico mudou.
Depois chega 96%.
Funcionou.
Novo normal:
Depois 97.
Você percebe o padrão?
Estamos transformando sobrevivência passada em autorização futura.
⏱️ Exemplo: batch cada vez mais lento
Seu batch deveria terminar às 03:00.
Durante anos termina 02:15.
Um dia:
02:24.
Depois:
02:31.
02:38.
02:42.
02:50.
Ainda antes das 03:00.
Então ninguém se preocupa.
02:56.
02:58.
Continua “dentro da janela”.
Até que numa sexta-feira:
03:17.
E alguém pergunta:
— Como esse problema apareceu de repente?
Resposta:
não apareceu de repente.
Nós apenas demoramos para reconhecê-lo.
🔍 Aqui entram os Weak Signals
No episódio anterior falamos sobre sinais fracos.
Agora fica claro por que eles são tão importantes.
Normalização do desvio é frequentemente a arte organizacional de transformar sinais fracos em paisagem.
Um alerta aparece todo dia.
Inicialmente incomoda.
Depois você aprende a fechá-lo.
Depois configura filtro.
Depois ninguém vê.
Isso possui até um conceito associado:
alarm fatigue.
Quando tudo alerta, nada alerta.
Se um sistema produz 10.000 mensagens irrelevantes, a mensagem realmente importante precisa competir com 9.999 ruídos.
🚨 O pior alerta é aquele que todos conhecem
Imagine:
WARNING XYZ123
Operador novo:
— O que significa?
Veterano:
— Ignora.
— Por quê?
— Sempre aparece.
Essa conversa deveria imediatamente gerar uma pergunta:
Se é realmente irrelevante, por que ainda é um warning?
Existem duas possibilidades:
o alerta deveria ser eliminado ou corrigido;
o comportamento deveria ser investigado.
Deixar um warning permanente ensina pessoas a ignorarem warnings.
É treinamento comportamental involuntário.
🧀 Swiss Cheese + Normalization of Deviance
Agora podemos conectar nossos dois episódios.
No Swiss Cheese Model aprendemos que as barreiras possuem buracos.
A Normalização do Desvio mostra algo ainda mais assustador:
podemos aprender a conviver com os buracos.
Pior:
podemos ampliá-los.
Imagine:
FATIA 1 — PROCEDIMENTO
Desvio conhecido:
passo de validação ignorado.
Nada acontece.
Depois:
FATIA 2 — TESTE
Desvio conhecido:
cenário raro não testado.
Nada acontece.
Depois:
FATIA 3 — MONITORAMENTO
Desvio conhecido:
alerta ignorado.
Nada acontece.
Temos agora três buracos maiores.
O queijo suíço está ficando perigosamente transparente.
🛸 A TARDIS precisa viajar para antes do desastre
Em um post-mortem tradicional, talvez alguém pergunte:
“O que aconteceu às 14:32?”
Mas na normalização do desvio talvez precisemos perguntar:
“Quando esse comportamento começou?”
Pode ter sido:
três dias antes;
seis meses;
cinco anos.
Essa é outra razão pela qual incidentes são problemas temporais.
Precisamos estudar sua genealogia.
📝 Passo a passo — Como detectar Normalization of Deviance
Pegue papel, quadro, planilha, Confluence, SharePoint ou aquele bloco de notas que todo analista mainframe inexplicavelmente mantém ao lado do teclado.
Faça algumas perguntas.
Passo 1 — Liste os “sempre fazemos assim”
Converse com operadores e desenvolvedores.
Procure frases:
sempre fazemos;
pode ignorar;
nunca deu problema;
funciona desse jeito;
esse erro é normal;
precisa executar duas vezes;
de vez em quando trava;
é só reiniciar;
todo mundo usa esse usuário;
produção é diferente.
Cada uma merece investigação.
Não significa necessariamente que existe perigo.
Significa:
há algo interessante aqui.
🔍 Passo 2 — Compare prática e procedimento
Existe uma diferença entre:
work as imagined
e
work as done.
O primeiro é como imaginamos que o trabalho acontece.
O segundo é como ele realmente acontece.
Manual:
1. Gerar relatório.
2. Validar relatório.
3. Solicitar aprovação.
4. Executar processamento.
Realidade:
1. Gerar relatório.
2. Ninguém olha.
3. João manda OK no Teams.
4. Executar.
Temos um gap.
Investigue.
📈 Passo 3 — Procure tendências, não apenas limites
Não pergunte apenas:
“Passou do SLA?”
Pergunte:
“Está se aproximando progressivamente dele?”
Não pergunte apenas:
“Dataset encheu?”
Pergunte:
“Qual é a tendência de crescimento?”
Não pergunte:
“Houve ABEND?”
Pergunte:
“Warnings estão aumentando?”
Sistemas frequentemente contam sua doença antes de entrar em coma.
Precisamos escutar.
🧯 Passo 4 — Catalogue near misses
Lembra dos quase acidentes?
Eles são especialmente importantes aqui.
Imagine:
produção errada preparada.
Alguém percebe antes da execução.
Todo mundo comemora:
— Ainda bem.
Fecha chamado.
Fim.
Não.
Pergunte:
Por que quase executamos?
A NASA também usa casos de close call para discutir normalização do desvio. Em uma retrospectiva sobre a caminhada espacial EVA 23, a agência descreveu como uma falha de sensor passou a ser aceita como normal com base na experiência anterior, sem que sua causa fosse adequadamente questionada. (NASA)
Esse é um exemplo fantástico.
O sistema estava literalmente ensinando a equipe a aceitar um comportamento anormal.
🧠 Passo 5 — Pergunte o que mudou no significado de “normal”
Isso é poderoso.
Não pergunte apenas:
O sistema mudou?
Pergunte:
Nossa tolerância mudou?
Talvez um job sempre tivesse de terminar em 30 minutos.
Agora consideramos 50 aceitável.
Quando isso aconteceu?
Quem decidiu?
Foi formal?
Houve análise?
Ou aconteceu organicamente?
📏 Passo 6 — Defina guardrails
Um guardrail é uma proteção clara.
Por exemplo:
CPU > X → investigar
Elapsed > Y → investigar
Dataset > 85% → agir
RC != 0 → justificar
Rejeição > Z% → interromper
O importante é evitar limites negociáveis diariamente.
Caso contrário:
80 parece seguro.
82 também.
85 também.
90 também.
Até 99.
🛑 Passo 7 — Crie stop conditions
Profissionais precisam saber quando parar.
Em algumas culturas operacionais existe enorme pressão para:
continuar funcionando.
Mas maturidade também significa saber dizer:
“Não temos evidência suficiente para continuar com segurança.”
Isso vale para:
deploy;
migração;
batch;
IPL;
alteração de banco;
processamento financeiro;
mudança de infraestrutura.
🧹 Passo 8 — Mate warnings permanentes
Se existe alerta que pode ser ignorado diariamente, faça alguma coisa.
Corrija a causa.
Ajuste o alerta.
Mude severidade.
Documente formalmente.
Mas evite criar uma floresta de warnings inúteis.
Porque um dia, entre eles, chegará o warning importante.
🧪 Passo 9 — Revalide exceções
Toda exceção operacional deveria ter prazo.
Exemplo:
“Durante três semanas aceitaremos processamento de até 70 minutos.”
Excelente.
Depois de três semanas:
reavaliar.
Sem isso a exceção temporária possui uma habilidade corporativa impressionante:
tornar-se permanente.
📚 Passo 10 — Preserve memória organizacional
Documente:
por que o controle existe;
qual incidente o originou;
que risco ele reduz;
quem pode alterá-lo.
Imagine um comentário:
* NÃO REMOVER ESTA VALIDAÇÃO.
* INTRODUZIDA APÓS INCIDENTE INC-2008-1742.
* SEM ELA REGISTROS DUPLICADOS PODEM SER
* PROCESSADOS EM RESTART.
Isso vale ouro.
Muito melhor que:
* NAO MEXER.
Embora, admitamos, o segundo tenha certa elegância ameaçadora.
👾 Easter Egg nº 2 — “Não pisque”
No universo de Doctor Who, os Weeping Angels possuem uma regra extremamente simples:
Don't blink.
Na operação talvez devêssemos criar outra:
Don't normalize.
Encontrou algo estranho?
Observe.
Entenda.
Explique.
Corrija ou aceite conscientemente.
Mas nunca permita que se torne normal apenas porque você o viu muitas vezes.
⚠️ Normalização não significa incompetência
Essa é uma parte importantíssima.
Pessoas envolvidas nesse processo não precisam ser irresponsáveis.
Normalização do desvio pode acontecer justamente com profissionais experientes.
Eles conhecem o sistema.
Já viram aquilo várias vezes.
Criaram adaptações.
Obtiveram sucesso.
Então seu próprio conhecimento produz confiança.
Esse é o paradoxo.
Experiência pode aumentar segurança.
Mas experiência com desvios sobrevividos também pode produzir excesso de confiança.
🧭 “Funcionou ontem” não é prova matemática
Existe uma lógica silenciosa:
Funcionou 100 vezes.
Logo funcionará na 101ª.
Não necessariamente.
Talvez exista uma probabilidade pequena de falha.
Imagine 1%.
Você pode executar dezenas de vezes sem observar nada.
Isso não torna o risco zero.
Significa apenas que a amostra ainda não encontrou o problema.
Em sistemas críticos, precisamos evitar confundir:
histórico de sucesso
com
demonstração de segurança.
💥 Quando a sorte cobra juros
Pense numa equipe que realiza deploy manualmente.
Existe um passo perigoso.
Durante cinco anos ninguém erra.
A organização conclui:
O processo é seguro.
Talvez não seja.
Talvez você tenha uma equipe extraordinariamente cuidadosa compensando um processo ruim.
Então chega:
turnover;
pressão;
madrugada;
incidente paralelo;
pessoa nova;
cansaço.
Os buracos alinham.
A organização pergunta:
— Por que fulano errou?
Resposta mais interessante:
Por que nossa segurança dependia de ninguém jamais errar?
⚖️ Just Culture entra novamente na TARDIS
Precisamos criar ambiente onde alguém consiga dizer:
“Isso aqui está errado.”
Sem ouvir:
“Sempre funcionou.”
Profissionais novos possuem uma vantagem curiosa.
Eles ainda enxergam estranheza.
Depois de anos, nossos olhos se acostumam.
Por isso uma pergunta aparentemente ingênua pode ser extremamente valiosa:
“Por que fazemos isso?”
Nunca ridicularize essa pergunta.
Talvez o iniciante esteja vendo um buraco que todos os veteranos aprenderam a ignorar.
☕ Conselho Bellacosa para quem começa em COBOL
Se entrar num ambiente e alguém disser:
“Esse erro é normal.”
Não responda imediatamente:
“Está errado!”
Você ainda não possui contexto.
Pergunte humildemente:
“Você pode me explicar por que ele ocorre e por que sabemos que é seguro?”
Essa pergunta é extraordinária.
Pode haver uma explicação perfeitamente legítima.
Ótimo.
Você aprendeu.
Mas talvez a resposta seja:
“Não sei. Sempre foi assim.”
Nesse momento:
anote.
Talvez você tenha encontrado nossa próxima investigação.
🔬 Métricas que ajudam
Algumas tendências merecem acompanhamento:
tempo médio de batch;
CPU;
I/O;
paging;
volume processado;
crescimento de datasets;
frequência de restart;
ABENDs;
warnings;
timeouts;
filas;
reprocessamentos;
erros funcionais;
chamados repetidos;
intervenções manuais.
E existe uma métrica especialmente interessante:
quantas vezes alguém precisa “dar um jeitinho” para o sistema continuar funcionando?
Não costuma existir no dashboard.
Talvez devesse.
👨🚒 Heroísmo operacional pode esconder fragilidade
Existe aquele profissional lendário.
Quando tudo quebra:
liga para Carlos.
Carlos executa três comandos misteriosos.
Sistema volta.
Todos aplaudem.
Excelente Carlos.
Mas temos um problema.
Se isso acontece constantemente, Carlos pode estar funcionando como mecanismo compensatório de uma arquitetura frágil.
Organizações frequentemente confundem heroísmo com resiliência.
Resiliência é:
o sistema consegue lidar com problemas.
Heroísmo é:
precisamos encontrar Carlos às 03:17.
São coisas diferentes.
🌀 Doctor Who e o perigo da rotina
Talvez essa seja nossa melhor conexão com Doctor Who.
O Doctor chega em um lugar onde moradores dizem:
— Sempre fazemos esse ritual.
— Por quê?
— Porque sempre fizemos.
— E aquela porta?
— Nunca abrimos.
— Por quê?
— Porque disseram que não devemos.
Naturalmente atrás da porta existe algum alienígena ancestral capaz de destruir metade da galáxia.
Em organizações, nossos monstros são menos cinematográficos.
São:
scripts antigos;
autorizações excessivas;
warnings ignorados;
planilhas manuais;
restarts rotineiros;
acessos compartilhados;
validações puladas;
backups nunca restaurados;
procedimentos desatualizados.
Mas o mecanismo psicológico é surpreendentemente parecido.
🔄 A Regeneração
Nossa série não existe para admirar acidentes.
Existe para aprender.
Então qual seria a regeneração depois de detectar normalização do desvio?
Primeiro:
tornar o desvio novamente visível.
Depois:
entender sua origem.
Medir o risco.
Decidir conscientemente:
corrigir;
mitigar;
monitorar;
ou formalmente aceitar.
O fundamental é substituir:
“sempre fizemos assim”
por:
“sabemos por que fazemos assim.”
Essa diferença representa maturidade operacional.
📓 Diário do Doctor
Guarde estas ideias.
Normalização do desvio ocorre quando uma prática fora do padrão passa gradualmente a ser aceita porque consequências negativas não apareceram imediatamente.
Sucesso passado não comprova segurança futura.
Near misses são dados, não apenas golpes de sorte.
Warnings repetidos precisam ser entendidos, não domesticados.
A tolerância organizacional pode mudar lentamente sem decisão formal.
Procedimentos podem carregar memória de acidentes antigos.
Iniciantes enxergam coisas que veteranos deixaram de notar.
“Nunca deu problema” descreve o passado. Não garante absolutamente nada sobre amanhã.
E sobretudo:
O desvio mais perigoso pode ser justamente aquele que deixou de parecer desvio.
🕰️ 17:43 — sexta-feira
Voltamos à nossa sala de operação.
O programador iniciante continua olhando para:
JOB04217 ENDED - RC=0004
O veterano termina o café.
O Doctor aproxima-se.
— Há quanto tempo isso acontece?
— Uns três anos.
— Alguém investigou?
— No começo.
— E descobriram a causa?
Silêncio.
— Não lembro.
O Doctor sorri.
Não é um sorriso tranquilizador.
— Excelente.
— Excelente?
— Sim.
Ele abre a porta da TARDIS.
— Encontramos nosso monstro.
O programador aponta para a tela.
— O RC=04?
— Não.
O Doctor entra.
— O fato de vocês terem parado de perguntar por quê.
A porta fecha.
VWORP.
VWORP.
VWORP.
A cabine desaparece.
O jovem olha novamente para o console.
Pensa durante alguns segundos.
Abre o histórico.
Pesquisa:
JOB04217
Três anos.
Centenas de RC=04.
Mas encontra algo interessante.
No começo acontecia uma vez por mês.
Depois semanalmente.
Depois diariamente.
Mais interessante ainda:
o elapsed time também estava aumentando.
Pouco.
Lentamente.
Quase imperceptivelmente.
Ele pega o telefone.
— Temos uma coisa estranha aqui.
Do outro lado alguém pergunta:
— Está dando erro?
Ele olha para:
RC=0004
Sorri.
— Ainda não.
E talvez essa seja justamente a melhor hora para investigar.
Porque incidentes possuem uma propriedade desagradável:
antes de acontecerem, parecem apenas possibilidades.
Depois que acontecem, todos dizem que eram óbvios.
Nossa missão nessa série será encontrá-los enquanto ainda estão no primeiro grupo.
☕🌀
🥚 Easter Egg final
Em algum lugar do código do JOB04217 existe um comentário que ninguém havia notado:
* BAD WOLF
Ninguém sabe quem escreveu.
O ChangeMan indica que a linha existe desde 2005.
Melhor deixarmos para outra viagem.
Next stop: Hindsight Bias — o estranho fenômeno pelo qual todo incidente se torna absolutamente óbvio cinco minutos depois de acontecer.
