 |
| Bellacosa Mainframe drift into failure |
☕ Um Café no Bellacosa Mainframe
Drift Into Failure: Doctor Who, COBOL e o Dia em que Ninguém Quebrou o Sistema — Mas Ele Quebrou Mesmo Assim
Uma viagem pela TARDIS dos incidentes para entender como sistemas complexos derivam lentamente para o desastre enquanto cada pequena decisão continua parecendo perfeitamente razoável
03:14.
Produção funcionando.
Nenhum ABEND importante.
Nenhum incêndio.
Nenhum gerente correndo pelo corredor.
Nenhum operador gritando:
— PAREM TUDO!
Na verdade, nada parece particularmente dramático.
Um job demora cinco minutos a mais.
Um alerta conhecido aparece.
Um procedimento recebe mais uma pequena exceção.
Um analista resolve uma inconsistência manualmente.
Um parâmetro é aumentado.
Uma janela operacional fica dez minutos menor.
Uma validação é adiada para a manhã.
Um funcionário experiente se aposenta e ninguém documenta completamente aquilo que ele sabia.
Um servidor recebe mais carga.
Um batch ganha mais arquivos.
Um relatório deixa de ser conferido porque ficou grande demais.
Nada quebra.
Dia seguinte.
Tudo funciona novamente.
Semana seguinte.
Mais uma pequena adaptação.
Mês seguinte.
Outra.
Ano seguinte.
A operação continua.
Até que, numa terça-feira perfeitamente comum:
03:17:42
SYSTEM STATUS: DEGRADED
03:18:01
QUEUE DEPTH: CRITICAL
03:18:14
TRANSACTION FAILURES
03:18:29
RECONCILIATION ERROR
03:19:03
INCIDENT DECLARED
A War Room abre.
E alguém faz a pergunta inevitável:
— Quem mudou alguma coisa?
Nesse momento...
VWORP.
VWORP.
VWORP.
A TARDIS aparece ao lado do console.
A porta abre.
O Doctor sai.
Olha para os logs.
Olha para o histórico.
Olha para a equipe.
— Quando vocês acham que esse incidente começou?
O gerente aponta:
— Às 03:17.
O Doctor balança a cabeça.
— Não.
— Às 03:14?
— Também não.
O programador COBOL iniciante pergunta:
— Então quando?
O Doctor abre uma timeline.
Ela começa três anos antes.
— Talvez aqui.
Silêncio.
— Ou aqui.
Volta mais seis meses.
— Ou talvez aqui.
O jovem arregala os olhos.
— Mas não aconteceu nada nesses dias.
O Doctor sorri.
— Exatamente.
Bem-vindo ao:
Drift Into Failure
Ou, numa tradução livre:
Deriva em Direção à Falha
O fenômeno pelo qual sistemas sociotécnicos complexos podem gradualmente aproximar-se de condições perigosas sem que exista necessariamente uma única decisão claramente irresponsável, um único culpado ou um instante mágico em que alguém “quebrou tudo”.
🌀 A TARDIS precisa viajar muito mais longe desta vez
Nos episódios anteriores nós investigávamos eventos relativamente identificáveis.
Uma decisão.
Um alerta.
Uma hipótese.
Uma autoridade.
Um plano.
Agora precisamos mudar a escala.
Drift Into Failure exige olhar não apenas para:
o que alguém fez ontem
mas para:
como o sistema evoluiu durante meses ou anos.
Essa perspectiva tem raízes importantes no trabalho do pesquisador dinamarquês Jens Rasmussen, especialmente em seu artigo de 1997, Risk Management in a Dynamic Society: A Modelling Problem. Rasmussen argumentava que segurança em sistemas complexos precisa ser estudada como um problema envolvendo múltiplos níveis da sociedade e da organização, porque decisões e pressões em diferentes níveis interagem para produzir o comportamento real do sistema. (ScienceDirect)
Décadas depois, ideias dessa tradição sistêmica seriam fortemente associadas à expressão Drift Into Failure, popularizada por Sidney Dekker ao discutir por que buscar apenas componentes “quebrados” ou indivíduos culpados é insuficiente para compreender falhas em sistemas complexos. Trabalhos posteriores descrevem essa deriva como uma erosão gradual de restrições e margens, à medida que adaptações locais vão sendo racionalizadas e aceitas. (ScienceDirect)
Em outras palavras:
O desastre pode ser uma trajetória.
Não apenas um evento.
🗺️ O mapa de Rasmussen
Imagine uma organização funcionando dentro de um espaço.
Existem diferentes forças empurrando suas decisões.
Uma delas:
Segurança
Não podemos ultrapassar determinada fronteira.
Outra:
Economia
Precisamos reduzir custos.
Outra:
Carga de trabalho
Precisamos realizar o trabalho sem exigir esforço impossível das pessoas.
Uma organização saudável tenta permanecer dentro desse espaço.
Mas existe pressão constante.
Custos.
Prazos.
Concorrência.
SLA.
Projetos.
Produtividade.
Clientes.
Metas.
Recursos limitados.
Rasmussen mostrou justamente a importância de observar essas pressões e restrições como parte de um sistema dinâmico de controle, em vez de estudar cada ator isoladamente. (ScienceDirect)
Podemos imaginar:
FRONTEIRA ECONÔMICA
“PRECISAMOS SER VIÁVEIS”
↓
ÁREA NORMAL DE OPERAÇÃO
PRESSÃO → ← PRESSÃO
↑
FRONTEIRA DE
SEGURANÇA
O problema?
A organização não fica parada.
Ela se move.
🧭 Drift significa deriva
A palavra inglesa drift é maravilhosa neste contexto.
Não significa necessariamente:
correr em direção ao precipício.
Significa algo mais sutil:
derivar.
Como um barco.
O vento sopra um pouco.
A corrente empurra outro pouco.
O navegador corrige.
Depois relaxa.
Outra corrente.
Mais alguns metros.
Horas depois, o barco está quilômetros longe da rota original.
Não houve:
“Agora navegaremos para o lugar errado.”
Houve pequenas adaptações.
Isso é Drift Into Failure.
☕ Bellacosa Mainframe: o batch das duas da manhã
Imagine um batch crítico.
Quando foi criado:
START: 00:00
END: 01:30
AVAILABLE WINDOW:
4 HOURS
Excelente.
Margem enorme.
Cinco anos depois:
mais clientes.
Mais arquivos.
Mais regras.
Mais SQL.
Agora:
START: 00:00
END: 02:05
Ainda funciona.
Ano seguinte:
END: 02:24
Outro:
END: 02:41
Outro:
END: 03:02
A abertura é às 04:00.
Alguém pergunta:
— Temos problema?
Resposta:
— Não. Ainda termina antes da abertura.
Tecnicamente correto.
Mas observe o que desapareceu:
margem.
🧯 Margem é invisível até precisarmos dela
Quando tudo funciona:
30 minutos de margem parecem desperdício.
Quando algo falha:
30 minutos podem ser a diferença entre:
restartar tranquilamente;
e declarar incidente.
Essa é uma característica central da deriva.
Organizações tendem a otimizar aquilo que enxergam.
Custo.
Tempo.
Capacidade.
Mas segurança frequentemente depende de:
folga;
redundância;
capacidade ociosa;
tempo disponível;
pessoas extras;
alternativas.
Tudo isso parece ineficiente enquanto nada acontece.
💰 Eficiência pode empurrar contra segurança
Imagine:
“Por que temos dois analistas nesse turno?”
Corta um.
Nada acontece.
Depois:
“Por que temos esse relatório manual?”
Remove.
Nada acontece.
“Por que mantemos 30% de capacidade livre?”
Reduz.
Nada acontece.
“Por que precisamos dessa validação extra?”
Simplifica.
Nada acontece.
Cada decisão isoladamente possui justificativa.
Talvez até excelente justificativa.
Mas juntas podem mover a organização.
Centímetro.
Por centímetro.
Em direção à fronteira.
🧀 Swiss Cheese encontra Drift Into Failure
Agora nossa primeira teoria retorna.
Swiss Cheese dizia:
cada barreira possui buracos.
Drift Into Failure acrescenta:
os buracos podem mudar ao longo do tempo.
Uma barreira começa forte.
Depois:
menos pessoas.
Menos testes.
Mais exceções.
Mais pressão.
Mais automação sem revisão.
Mais alerts ignorados.
A fatia vai ficando fina.
Então:
ANO 1
████████○██████
ANO 3
███○████○██○██
ANO 5
██○██○█○██○○█
Até um dia os caminhos se alinham.
🌀 Normalization of Deviance é praticamente vizinha
Esse é um casamento natural.
Pequeno desvio.
Nada acontece.
Logo, parece seguro.
Repete.
O limite aceitável se move.
Isso alimenta a deriva.
Exemplo:
dataset chega a 80%.
Depois 85%.
Depois 90%.
Nada acontece.
Agora 90 virou normal.
A organização não decidiu formalmente:
“Vamos operar perigosamente.”
Ela apenas atualizou informalmente aquilo que chama de normal.
Essa erosão gradual de restrições é uma das formas pelas quais abordagens sistêmicas descrevem a trajetória em direção à falha. (ScienceDirect)
🚨 Alarm Fatigue entra no barco
Começamos com:
10 alertas importantes.
Depois:
4.000.
Operadores começam a filtrar.
Primeiro mentalmente.
Depois ferramentas.
Depois silenciam alguns.
Essa adaptação é racional.
Ninguém consegue processar milhares de alarmes.
Mas talvez um importante controle de segurança tenha sido progressivamente degradado.
Novamente:
não houve uma reunião chamada:
“Projeto oficial para diminuir nossa capacidade de detectar incidentes.”
Aconteceu organicamente.
Drift.
🤖 Automation Bias também empurra
Automação funciona.
Primeira semana:
humano confere tudo.
Após seis meses:
confere algumas coisas.
Ano seguinte:
olha rapidamente.
Depois:
autoapprove.
Nenhum incidente.
Cada passo parece justificado pelos resultados anteriores.
Agora a organização depende da automação de forma muito maior que originalmente projetado.
Derivou.
⚓ Anchoring Bias conserva velhos mapas
Outro fenômeno.
Arquitetura mudou.
Volume mudou.
Usuários mudaram.
Mas continuamos ancorados em premissas antigas.
“Esse job aguenta.”
Baseado em testes de quando processava 5 milhões.
Agora:
80 milhões.
A âncora psicológica fica.
O sistema real deriva.
🔎 Confirmation Bias protege a trajetória
A equipe acredita:
nossa arquitetura é robusta.
Cada dia sem incidente confirma.
Warnings são reinterpretados:
pontuais.
Atrasos:
sazonais.
Falhas:
humanas.
Near misses:
azar.
Tudo que contradiz a narrativa recebe explicação.
A deriva continua.
👥 Groupthink transforma adaptação em cultura
Uma pessoa questiona:
— Não estamos trabalhando perto demais do limite?
Resposta coletiva:
— Sempre foi assim.
Agora temos consenso.
O desvio ganha proteção social.
Não é apenas operação.
É cultura.
🪜 Authority Gradient impede sinais de subir
Quem está perto do sistema normalmente percebe deriva cedo.
Operador.
Desenvolvedor.
Analista.
Eles veem:
mais retries;
mais ajustes;
mais trabalho manual;
menos margem.
Mas executivos enxergam:
SLA verde.
Availability 99,99%.
Custos menores.
Se existe Authority Gradient forte, a informação não sobe.
Rasmussen justamente destacou a importância de observar os diversos níveis de decisão de um sistema — do trabalho operacional às estruturas organizacionais e regulatórias — e as interações entre esses níveis. (ScienceDirect)
▶️ Plan Continuation Bias empurra depois da fronteira
Quando finalmente aparecem sinais claros:
já investimos muito.
Projeto quase terminou.
Migração está avançada.
Mudança está quase concluída.
Agora Plan Continuation Bias diz:
continuar.
A organização talvez já estivesse derivando durante anos.
A continuação do plano apenas fornece o último empurrão.
🕰️ Hindsight Bias chega depois com uma lupa
E então acontece o acidente.
Todo mundo olha para trás.
— Como ninguém percebeu?
Agora os sinais parecem óbvios:
batch crescendo;
alertas aumentando;
capacidade caindo;
procedimentos sendo abreviados;
turnover;
warnings.
Mas cuidado.
Eles não necessariamente formavam uma narrativa óbvia naquele momento.
Hindsight Bias transforma deriva lenta numa estrada vermelha perfeitamente desenhada.
Na vida real:
era neblina.
👻 Easter Egg nº 1 — A TARDIS pousa um centímetro de cada vez
Imagine a TARDIS tentando chegar ao precipício.
Não pousa diretamente na borda.
Primeiro:
100 km.
Depois:
100 metros.
10 metros.
1 metro.
Nenhum pouso isolado parece absurdo.
Até abrirmos a porta.
Isso é drift.
🔍 Work as Imagined versus Work as Done
No papel:
PROCEDIMENTO
1. Validar arquivo.
2. Reconciliar.
3. Solicitar aprovação.
4. Processar.
5. Validar resultado.
Na prática:
1. Script valida quase tudo.
2. Reconciliação só quando diferença é grande.
3. Aprovação pelo Teams.
4. Processar.
5. Olhar dashboard.
Por que mudou?
Talvez porque:
volume cresceu;
equipe diminuiu;
prazo apertou;
processo oficial ficou impraticável.
Não conclua imediatamente:
pessoas irresponsáveis.
Talvez estejam adaptando-se para conseguir realizar o trabalho.
🧠 Localmente racional
Essa expressão é central para compreender Drift Into Failure.
Muitas decisões que mais tarde contribuem para acidentes eram localmente racionais.
Ou seja:
faziam sentido para a pessoa naquele contexto.
Exemplo:
operador pula verificação.
Por quê?
Porque:
tem 200 jobs;
verificação leva dez minutos;
nunca encontrou problema;
precisa cumprir janela.
Dentro daquele ambiente:
faz sentido.
O problema está no sistema que tornou essa adaptação necessária.
🏗️ Não procure apenas comportamento; procure pressões
Pergunte:
Por que começaram a pular essa etapa?
Resposta pobre:
preguiça.
Talvez.
Mas investigue:
a etapa ficou lenta?
Volume cresceu?
Equipe caiu?
Ferramenta ficou inadequada?
Meta conflitante?
Trabalho virou impossível segundo procedimento oficial?
Essas perguntas encontram drift.
📏 A fronteira de segurança não possui placa
Essa é talvez a parte mais assustadora.
Não existe necessariamente:
ATENÇÃO
VOCÊ ESTÁ A 5 METROS
DA FALHA SISTÊMICA
A fronteira pode ser desconhecida.
Descobrimos sua localização...
quando a atravessamos.
Por isso Rasmussen discutia a necessidade de manter controle sobre sistemas dinâmicos diante de pressões e mudanças, em vez de presumir que limites podem ser totalmente conhecidos e gerenciados por regras estáticas. (ScienceDirect)
🧯 Por isso precisamos de margem
Se não sabemos exatamente onde está o precipício:
não caminhe na borda.
Mantenha buffer.
Em mainframe:
capacidade;
tempo;
storage;
staff;
rollback;
thresholds;
redundância.
Margin is safety.
📊 Leading Indicators versus Lagging Indicators
Outro conceito importante.
Lagging indicator
Mostra algo depois que aconteceu.
Exemplo:
número de incidentes.
Leading indicator
Pode indicar deterioração antes.
Exemplo:
aumento de:
restarts;
warnings;
tempo médio;
intervenção manual;
exceções;
near misses.
Se você monitora apenas:
INCIDENTES ESTE MÊS: 0
pode concluir:
excelente.
Enquanto:
RESTARTS +300%
WARNINGS +80%
MANUAL FIXES +200%
O sistema está gritando.
Ainda sem incidente.
🎯 Ausência de acidente pode esconder deriva
Isso conecta com tudo.
Uma organização pode ficar anos sem grande incidente.
Isso não necessariamente significa:
segurança aumentando.
Talvez risco esteja crescendo silenciosamente.
O sistema ainda não encontrou a combinação final.
🧯 Near Miss é boia na correnteza
Near miss mostra:
chegamos perto.
Em drift, near misses são especialmente preciosos.
Eles ajudam a estimar:
onde talvez esteja a fronteira.
Se quase processamos arquivo errado:
não comemore apenas.
Pergunte:
Por que chegamos tão perto?
🏛️ Acidentes pequenos são mensagens do futuro
Um pequeno incidente pode mostrar mecanismo maior.
Exemplo:
100 registros duplicados.
Corrigido manualmente.
Pergunta:
Isso poderia acontecer com 10 milhões?
Talvez.
Então pequeno incidente é laboratório.
🧠 Drift não significa inevitabilidade
Importante.
Não estamos dizendo:
Todo sistema complexo inevitavelmente falhará.
Estamos dizendo:
sistemas mudam.
Pressões mudam.
Comportamento adapta-se.
Segurança precisa acompanhar.
Uma abordagem sistêmica procura compreender e controlar essas interações e trajetórias, não apenas responsabilizar componentes após o evento. (ScienceDirect)
🧪 Como detectar Drift Into Failure
Agora nosso programador COBOL quer um método.
Excelente.
Passo 1 — Procure tendências de longo prazo
Não apenas hoje versus ontem.
Compare:
6 meses;
1 ano;
3 anos.
Exemplo:
BATCH ELAPSED
2023: 70 min
2024: 88 min
2025: 112 min
2026: 148 min
Isso é drift.
📈 Passo 2 — Monitore margem
Não apenas:
está dentro do limite?
Mas:
quanto sobra?
Exemplo:
SLA LIMIT: 180 min
2023 margin: 110
2024 margin: 92
2025 margin: 68
2026 margin: 32
Ainda dentro.
Mas direção é clara.
🔧 Passo 3 — Conte intervenções manuais
Quantas vezes alguém precisa:
restartar;
ajustar;
limpar;
reprocessar;
corrigir manualmente?
Se aumenta:
sistema pode estar sendo sustentado por esforço humano invisível.
🦸 Heroísmo é métrica de fragilidade
Esse ponto é maravilhoso.
Equipe diz:
— Nunca tivemos indisponibilidade porque Carlos sempre resolve.
Talvez isso signifique:
excelente resiliência humana.
Mas talvez também:
arquitetura depende de Carlos.
Conte heroísmo.
Ele pode ser leading indicator.
📝 Passo 4 — Conte exceções
Quantas exceções temporárias estão abertas?
EXCEPTION-001
EXCEPTION-002
...
EXCEPTION-143
Se sistema depende de 143 exceções:
qual é exatamente a regra?
A exceção pode ter virado arquitetura.
🚨 Passo 5 — Observe warnings normalizados
Faça inventário:
quais sinais são conhecidos e ignorados?
Cada um pode indicar área de drift.
👥 Passo 6 — Pergunte aos operadores
Talvez o dashboard esteja verde.
Pergunte:
“O que ficou mais difícil nos últimos dois anos?”
Essa pergunta pode revelar mais que cinquenta KPIs.
Operadores sentem deriva.
🧠 Passo 7 — Pergunte quais atalhos surgiram
Sem julgamento:
“Que passos vocês precisam adaptar para o trabalho caber na janela?”
Agora você encontra Work as Done.
🗺️ Passo 8 — Faça AcciMap ou mapa sistêmico
Uma extensão importante do trabalho de Rasmussen é o uso de representações como AcciMap, concebidas para mapear atores, decisões, condições e relações através de diferentes níveis do sistema, em vez de limitar a análise à linha de frente. Literatura posterior descreve AcciMap e mapas relacionados como formas de representar cenários de acidente, atores e fluxos de informação. (ResearchGate)
Para nosso exemplo:
REGULAÇÃO
↓
DIRETORIA
↓
GESTÃO
↓
ARQUITETURA
↓
OPERAÇÃO
↓
COBOL / CICS / DB2
Pergunte em cada nível:
que pressões existem?
que decisões foram tomadas?
que informação sobe?
que informação desce?
Agora vemos sistema.
🧩 Passo 9 — Procure decisões locais que criam risco global
Exemplo:
Infra reduz storage.
Boa decisão local.
Aplicação aumenta logging.
Boa decisão local.
Negócio aumenta retenção.
Boa decisão local.
Juntas:
dataset explode.
Nenhuma equipe estava “errada”.
O sistema emergente ficou frágil.
🕸️ Complexidade produz efeitos emergentes
Isso é central.
Sistemas complexos possuem comportamento que não pode ser compreendido olhando componente por componente isoladamente.
Equipe A otimiza A.
Equipe B otimiza B.
Equipe C otimiza C.
O conjunto produz D.
Ninguém planejou D.
Isso é comportamento emergente.
💻 Exemplo COBOL completo
Imagine um programa criado em 2005.
Inicialmente:
1 milhão de registros
1 arquivo
1 regra fiscal
30 minutos
Em 2026:
48 milhões de registros
17 arquivos
34 regras
6 integrações
2h48
Mas arquitetura central permaneceu.
Ao longo dos anos:
adicionaram copybooks;
IFs;
chamadas;
workarounds;
restarts;
parâmetros.
Nada individualmente absurdo.
Agora qualquer mudança é arriscada.
Isso é uma forma de deriva arquitetural.
🏚️ Technical Debt encontra Drift
Dívida técnica não é exatamente Drift Into Failure.
Mas pode contribuir.
Atalho hoje.
TODO.
Depois outro.
Depois outro.
Sistema continua.
Até mudanças simples exigirem enorme cuidado.
A margem de mudança desaparece.
🧱 Complexidade acidental
Muitas camadas podem acumular-se:
COBOL
→ DB2
→ MQ
→ API
→ gateway
→ cloud
→ parceiro
Cada integração resolve problema.
Também adiciona modos de falha.
O sistema de 2026 pode ser completamente diferente do modelo mental de quem o projetou.
📚 Documentação também deriva
Documento criado em 2018.
Sistema mudou em:
2019;
2020;
2021;
2022;
2024;
Manual:
Agora Work as Imagined e Work as Done vivem em universos paralelos.
Até uma crise.
🧠 Conhecimento tribal
Quando documentação falha, pessoas compensam.
Carlos sabe.
Maria sabe.
João sabe.
Então:
Carlos aposenta.
Maria muda de equipe.
João fica doente.
De repente a redundância humana desapareceu.
Ninguém percebeu porque ela nunca estava formalmente registrada.
Drift.
🪫 Redundância desaparece silenciosamente
Começamos:
3 pessoas sabem.
Depois:
Depois:
Nenhum incidente.
Até precisar.
Mais um exemplo de margem invisível.
🔐 Drift em segurança
Primeiro:
acesso emergencial temporário.
Depois:
não removido.
Segundo usuário recebe.
Depois grupo inteiro.
Motivo:
agilidade operacional.
Nada acontece.
Anos depois:
permissão excessiva virou normal.
Ataque ou fraude encontra porta aberta.
O incidente parece repentino.
A trajetória não era.
🤖 Drift em sistemas de IA
Agentes tornam isso ainda mais interessante.
Primeiro agente:
só recomenda.
Depois:
executa tarefas pequenas.
Depois:
executa mudanças.
Depois:
aprovação automática em certos casos.
Cada extensão parece pequena.
Talvez nenhum momento tenha existido em que a organização conscientemente disse:
“Vamos delegar grande autoridade.”
Autonomia cresceu incrementalmente.
Isso também precisa de controle de drift.
🔁 Capability Creep
Ferramenta começou fazendo A.
Depois B.
Depois C.
Agora toma decisão crítica.
Permissões cresceram junto.
Isso é capability creep.
Pergunte periodicamente:
“Este sistema hoje possui mais poder que quando fizemos sua avaliação de risco?”
Ótima pergunta.
🎯 Pergunta Bellacosa nº 1
Pergunte:
“O que hoje consideramos normal que seria considerado preocupante três anos atrás?”
Essa pergunta encontra deriva.
🎯 Pergunta Bellacosa nº 2
Outra:
“Que margem tínhamos antes e não temos mais?”
Tempo?
Capacidade?
Pessoas?
Rollback?
Dinheiro?
Conhecimento?
🎯 Pergunta Bellacosa nº 3
Outra:
“O que precisamos fazer manualmente hoje apenas para manter tudo funcionando?”
Isso revela adaptações invisíveis.
🎯 Pergunta Bellacosa nº 4
E talvez a mais poderosa:
“Se montássemos este sistema do zero hoje, aceitaríamos operá-lo desta maneira?”
Se resposta for não:
provavelmente aconteceu alguma deriva.
🧪 Passo 10 — Crie indicadores de drift
Exemplos:
batch margin
capacity margin
manual intervention count
alert volume
restart frequency
exception count
near miss rate
staff coverage
rollback time
test coverage trend
documentation age
Não espere incidente.
Observe trajetória.
📊 Não monitore apenas estado; monitore derivada
Uma pequena brincadeira matemática.
Não importa apenas:
X
Importa:
dX/dt
Ou seja:
a direção da mudança.
CPU 70% talvez seja normal.
CPU:
40 → 48 → 56 → 63 → 70
conta outra história.
O mainframeiro precisa aprender a enxergar movimento.
🧭 Trending is storytelling
Um único número é fotografia.
Uma tendência é filme.
Drift vive no filme.
Não na fotografia.
📅 Revisões temporais
Crie revisão semestral:
o que mudou?
Não apenas:
houve incidente?
Pergunte:
capacidade;
arquitetura;
pessoas;
volume;
processo;
risco.
A segurança de dois anos atrás pode não existir mais.
🧯 Safety Margin Review
Uma revisão específica:
MARGIN REVIEW
CPU headroom
Storage headroom
Batch window
Rollback margin
Staff redundancy
Provider capacity
Verde não significa:
“não atingimos limite.”
Verde significa:
“temos margem adequada.”
Muito mais inteligente.
🚦 Green não deveria significar “ainda não morreu”
Isso conecta com Automation Bias.
Dashboard verde porque:
uso < 100%.
Mas storage em 97%.
Tecnicamente:
ainda funciona.
Operacionalmente:
talvez estejamos na borda.
Dashboard precisa refletir margem.
👀 Weak Signals novamente
Sinais fracos são a linguagem do drift.
Exemplos:
mais chamadas;
mais reclamações pequenas;
mais exceções;
mais warnings;
mais tempo;
mais trabalho manual;
mais dependência de especialistas.
Individualmente:
nada.
Juntos:
trajetória.
🧠 Pattern Recognition organizacional
Precisamos ensinar equipes a perguntar:
“Esses eventos separados fazem parte do mesmo movimento?”
É aí que incident management vira systems thinking.
🧬 Resilience Engineering
A resposta ao drift não é construir regras infinitas.
Sistemas reais mudam.
Precisamos capacidade de:
detectar;
adaptar;
absorver;
recuperar;
aprender.
Essa perspectiva está alinhada à tradição de engenharia de resiliência e às abordagens sistêmicas que tratam segurança como uma propriedade dinâmica do sistema, e não apenas como ausência de componentes quebrados. (Lund University Publications)
🔄 Regeneração organizacional
Como regenerar um sistema que está derivando?
Não procure apenas:
“qual componente substituir?”
Pergunte:
quais pressões existem?
quais margens desapareceram?
quais adaptações surgiram?
quais barreiras enfraqueceram?
quais métricas estão piorando?
que conhecimento desapareceu?
quais exceções viraram regra?
Depois:
restaure margem;
simplifique;
automatize onde faz sentido;
melhore observabilidade;
documente;
reduza ruído;
treine;
reavalie capacidade;
fortaleça barreiras.
Isso é regeneração de verdade.
📋 Checklist anti-Drift
Periodicamente:
[ ] Nosso volume cresceu?
[ ] Nossa arquitetura mudou?
[ ] Nossa margem operacional caiu?
[ ] Existem mais intervenções manuais?
[ ] Existem mais warnings?
[ ] Existem mais exceções permanentes?
[ ] Rollback ficou mais difícil?
[ ] Equipe perdeu conhecimento?
[ ] Documentação representa a realidade?
[ ] Near misses estão aumentando?
[ ] Estamos operando mais perto de limites?
[ ] Alguma prática que antes era proibida virou normal?
[ ] Se começássemos hoje, aceitaríamos este estado?
Se muitas respostas incomodarem...
não espere ABEND.
👽 Easter Egg nº 2 — A fronteira invisível
O Doctor aponta para o chão.
— Aqui é seguro.
Dá um passo.
— Aqui também.
Outro.
— Também.
Outro.
— Ainda seguro.
Companion:
— Então podemos continuar.
O Doctor responde:
— Não necessariamente.
— Por quê?
— Porque acabamos de provar onde estivemos.
Pausa.
— Não onde está a borda.
Essa frase deveria morar em todo data center.
🧠 Safety não é extrapolação infinita do sucesso
100 execuções sem falha provam:
o sistema sobreviveu a 100 execuções dentro daquelas condições.
Não provam:
segurança eterna.
Condições mudam.
Volume muda.
Pessoas mudam.
Software muda.
Organização muda.
O sucesso passado é dado.
Não garantia.
🏦 Drift no banco
Vamos imaginar fechamento financeiro.
Ano 1:
10 milhões de movimentos.
Ano 5:
50 milhões.
Equipe continua igual.
Batch maior.
Margem menor.
Mais restarts.
Mais procedimentos manuais.
Mas SLA continua verde.
Diretoria:
operação excelente.
Talvez.
Ou talvez uma equipe heroica esteja segurando um sistema cada vez mais próximo da fronteira.
Precisamos saber qual.
🦸 Não use pessoas para esconder dívida sistêmica
Profissionais extraordinários conseguem compensar sistemas ruins por anos.
Depois alguém pergunta:
“Por que nunca tivemos problema?”
Resposta:
porque Ana, Carlos e João impediam diariamente.
Isso é sucesso humano.
E risco organizacional.
🔬 Investigue o trabalho que evita incidentes
Isso é fantástico.
Não estude apenas falhas.
Estude:
por que normalmente dá certo?
Que adaptações os operadores fazem?
Que verificações extras?
Que telefonemas?
Que planilhas?
Que memórias?
Talvez sua verdadeira arquitetura de segurança não esteja no Visio.
Está nas pessoas.
🧠 Safety-II
Essa ideia conversa com perspectivas modernas de segurança que não olham apenas para o que deu errado, mas também para como o trabalho cotidiano consegue ter sucesso apesar de variabilidade e pressão.
Pergunta:
“Como as pessoas normalmente evitam que isso quebre?”
Você descobrirá mecanismos de resiliência.
Depois poderá fortalecê-los.
🛑 Drift precisa de contraforças
Pressões empurram:
mais barato;
mais rápido;
mais produção.
Então precisamos de forças conscientes puxando de volta:
revisões;
buffers;
standards;
limites;
auditoria;
capacity planning;
resilience reviews;
stop authority.
Sem contraforça:
a eficiência naturalmente consome margem.
💸 Segurança parece cara antes do incidente
Redundância custa.
Pessoas extras custam.
Capacidade livre custa.
Testes custam.
Rollback custa.
Observabilidade custa.
Depois do acidente:
parecem baratos.
Nosso Hindsight Bias dá risada.
📓 Diário do Doctor
Se guardar apenas algumas ideias desta viagem, guarde estas:
Drift Into Failure descreve a trajetória gradual pela qual sistemas complexos podem aproximar-se da falha.
Nem sempre existe uma única decisão absurda ou um único culpado.
Decisões localmente racionais podem produzir risco global.
Pressões de custo, produtividade e carga de trabalho alteram o comportamento do sistema ao longo do tempo.
Margem de segurança pode desaparecer silenciosamente.
Normalization of Deviance ajuda a deslocar a fronteira do aceitável.
Alarm Fatigue degrada detecção.
Automation Bias pode reduzir independência humana.
Authority Gradient impede sinais de subir.
Plan Continuation Bias dificulta parar quando finalmente percebemos o risco.
Near misses e sinais fracos mostram a trajetória.
Monitore tendências e margens, não apenas falhas.
E principalmente:
Sistemas raramente acordam numa terça-feira e decidem tornar-se perigosos. Eles podem passar anos aprendendo, pouco a pouco, a operar cada vez mais perto do limite.
🕰️ A TARDIS volta três anos
Nosso programador COBOL entra com o Doctor.
VWORP.
Três anos antes.
O batch termina:
01:31
Doctor:
— Algum problema?
— Não.
Dois anos antes:
01:57
— Problema?
— Ainda não.
Um ano:
02:24
— Problema?
— Não.
Seis meses:
02:46
Agora:
03:02
O jovem observa.
— Então o incidente começou quando o job ficou mais lento?
— Talvez não.
O Doctor abre outra timeline.
Equipe:
8 pessoas
→ 7
→ 6
→ 5
Outra.
Warnings:
12/mês
→ 48
→ 110
→ 390
Outra.
Exceções:
2
→ 7
→ 19
→ 43
Outra.
Intervenções manuais:
1/semana
→ 2
→ 5
→ diária
O programador fica em silêncio.
— Então qual dessas coisas causou o incidente?
O Doctor sorri.
— Talvez essa seja a pergunta errada.
— Qual seria a certa?
Ele aponta para todas as telas.
“Que sistema produz todas essas coisas ao mesmo tempo?”
Agora nosso jovem entende.
Não existe apenas uma seta:
ERRO
↓
INCIDENTE
Existe uma paisagem.
Pressões.
Adaptações.
Compromissos.
Perda de margem.
Decisões.
Sinais.
Tempo.
O acidente foi apenas o instante em que a trajetória finalmente cruzou uma fronteira.
🥚 Easter Egg final
De volta a 2026, nosso programador encontra:
BELLACOSA.SYSTEMS(DRIFT)
Dentro:
IF SYSTEM-STATUS = 'OK'
PERFORM CHECK-TREND
END-IF.
IF MARGIN < LAST-YEAR
PERFORM INVESTIGATE
END-IF.
IF EVERYONE-SAYS
'IT STILL WORKS'
PERFORM ASK-HOW-CLOSE
END-IF.
Comentário:
* SUCCESS TODAY
* DOES NOT DEFINE
* THE LOCATION OF TOMORROW'S BOUNDARY.
Logo abaixo:
* WATCH THE TRAJECTORY.
* NOT ONLY THE CRASH.
E naturalmente:
* BAD WOLF WAS HERE.
Nosso programador fecha o membro.
O console mostra:
SYSTEM STATUS: GREEN
Ele quase sorri.
Depois lembra de Automation Bias.
Abre tendência.
BATCH MARGIN
12 MONTHS AGO: 91 MIN
TODAY: 34 MIN
Abre warnings.
Subiram.
Abre restarts.
Subiram.
Abre exceções.
Subiram.
Nenhum incidente.
Ainda.
Ele chama o operador.
— Temos um problema?
O operador olha.
— Nada caiu.
Nosso programador responde:
— Eu sei.
Pausa.
— É justamente por isso que talvez seja uma boa hora para conversar.
Em algum lugar do espaço-tempo ouvimos:
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
Nenhum incidente ocorreu.
Nenhum cliente reclamou.
Nenhuma War Room abriu.
E talvez esta seja a mais importante vitória de toda nossa série:
perceber a trajetória antes de precisar estudar os destroços.
☕🌀
Next stop: Diffusion of Responsibility — quando todo mundo recebeu o alerta, todo mundo viu o problema e todo mundo tinha certeza de que outra pessoa estava cuidando.
Sem comentários:
Enviar um comentário