 |
| Bellacosa Mainframe e a illusion of control |
☕ Um Café no Bellacosa Mainframe
Illusion of Control: Doctor Who, COBOL e o Dia em que Achávamos que Controlávamos Tudo Porque Tínhamos um Console
Uma viagem pela TARDIS dos incidentes para entender por que comandos, dashboards, automações, procedimentos e experiência podem nos fazer acreditar que temos muito mais controle sobre sistemas complexos do que realmente possuímos
02:47.
Madrugada.
Produção.
Café número quatro.
A War Room estava cheia.
Na tela:
TRANSACTION FAILURE RATE: 7.8%
QUEUE DEPTH: 41.000
DB2 RESPONSE TIME: NORMAL
CPU: 71%
EXTERNAL API:
INTERMITTENT
O gerente pergunta:
— Estamos controlando?
O operador responde:
— Sim.
— Como sabe?
— Reduzimos as threads.
O DBA acrescenta:
— Ajustei o pool.
O pessoal de middleware:
— Reiniciamos o consumer.
O desenvolvedor:
— Também aumentamos o timeout.
O gerente respira aliviado.
— Ótimo. Então está sob controle.
Nosso jovem programador COBOL olha para os números.
FAILURE RATE:
7.8%
8.1%
8.6%
9.4%
Ele levanta a mão.
— Desculpe...
— Sim?
— Se está sob controle, por que continua piorando?
Silêncio.
O gerente responde:
— Estamos atuando.
— Eu sei.
— Então estamos controlando.
Nosso jovem olha novamente para o dashboard.
— Ou estamos apenas mexendo?
Silêncio ainda maior.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se entre os consoles.
A porta abre.
O Doctor sai.
Olha para:
threads;
timeouts;
queue;
API;
pessoas.
Depois pergunta:
— Quem controla a API externa?
Ninguém.
— Quem controla o volume dos clientes?
Ninguém.
— Quem controla a rede do parceiro?
Ninguém.
— Quem controla quando uma determinada combinação rara de transações aparece?
Silêncio.
— Então o que vocês controlam?
O operador responde:
— Nossos parâmetros.
O Doctor sorri.
— Excelente.
Pausa.
— Controlar algumas alavancas não significa controlar o universo.
Bem-vindo ao:
Illusion of Control
Ou:
Ilusão de Controle
A tendência de acreditar que temos mais influência sobre resultados do que realmente temos, especialmente quando podemos realizar ações, escolher opções, manipular parâmetros ou participar ativamente do processo.
Em linguagem Bellacosa:
“Se eu tenho botão, comando e dashboard, meu cérebro começa a achar que também tenho o resultado.”
🌀 A TARDIS dos incidentes está cada vez mais cheia
Nossa viagem já passou por:
Swiss Cheese Model — várias barreiras podem falhar juntas.
Normalization of Deviance — desvios repetidos viram rotina.
Hindsight Bias — o passado parece óbvio depois.
Confirmation Bias — buscamos provas para nossas hipóteses.
Anchoring Bias — a primeira informação pesa demais.
Groupthink — consenso não garante acerto.
Authority Gradient — hierarquia pode silenciar sinais.
Plan Continuation Bias — continuamos planos que perderam sentido.
Alarm Fatigue — alertas demais viram ruído.
Automation Bias — confiamos demais em automações.
Drift Into Failure — pequenas adaptações empurram sistemas para a borda.
Diffusion of Responsibility — todos veem e ninguém assume.
Normalcy Bias — esperamos que tudo volte ao normal.
Survivorship Bias — olhamos apenas para quem sobreviveu.
Base Rate Neglect — esquecemos frequências reais.
Availability Heuristic — o memorável parece mais provável.
Outcome Bias — resultado bom parece validar decisão.
Overconfidence Bias — acreditamos mais no nosso julgamento do que deveríamos.
Planning Fallacy — subestimamos esforço e complexidade.
Sunk Cost Fallacy — investimentos passados prendem decisões futuras.
Status Quo Bias — o estado atual recebe privilégio psicológico.
Present Bias — o conforto imediato vence o custo futuro.
Optimism Bias — acreditamos que provavelmente dará certo conosco.
Action Bias — fazer algo parece melhor do que observar.
Omission Bias — não agir pode parecer menos culpável.
Loss Aversion — perder dói mais do que ganhar alegra.
Framing Effect — a forma de apresentar muda decisões.
Recency Bias — o último evento pesa demais.
Representativeness Heuristic — “tem cara de X” vira “é X”.
Narrative Bias — histórias coerentes parecem causalidade.
Fundamental Attribution Error — culpamos pessoas e esquecemos contexto.
Self-Serving Bias — vitória é nossa; derrota é externa.
Actor-Observer Bias — nosso erro tem contexto; o do outro tem personalidade.
Dunning-Kruger Effect — saber pouco pode dificultar perceber o quanto ainda não sabemos.
Agora acrescentamos:
Illusion of Control
O momento em que confundimos:
ação;
interface;
participação;
influência
com:
controle real.
🧠 O que exatamente é a Ilusão de Controle?
Imagine um dado.
Você lança.
Número:
Agora imagine que você pode escolher:
qual dado usar;
a força;
a maneira de jogar.
De repente existe sensação maior de controle.
Mas se o dado for justo:
o resultado continua fortemente aleatório.
Nós gostamos de:
participar.
Escolher.
Apertar.
Configurar.
Isso gera sensação de agência.
E agência é boa.
O problema é inferir:
“Eu participei do processo, portanto controlo o resultado.”
Não necessariamente.
☕ Bellacosa Mainframe: o console é uma droga poderosa
Você senta em frente ao sistema.
Digita:
F CICS,SET...
Enter.
Mudança aparece imediatamente.
Sensação:
PODER.
Você alterou comportamento de um sistema gigantesco.
Isso é real.
Mas existe um salto psicológico perigoso:
“Eu controlo CICS.”
Não.
Você controla:
alguns comandos.
CICS interage com:
aplicações;
Db2;
MQ;
rede;
storage;
usuários;
workload;
schedulers;
outros sistemas.
O sistema inteiro possui autonomia emergente suficiente para destruir sua autoestima em poucos segundos.
👻 Easter Egg nº 1 — O Doctor e a TARDIS
Companion:
— Você controla a TARDIS?
Doctor:
— Claro.
A TARDIS faz:
VWORP.
Eles pousam no lugar errado.
Companion:
— Tinha certeza?
Doctor:
— Eu disse que controlo.
Pausa.
— Não disse que ela obedece.
Se até o Doctor precisa negociar com a própria máquina do tempo...
talvez devêssemos ser humildes com produção.
🧠 Controle versus influência
Essa distinção é central.
Você pode:
controlar
um parâmetro.
Pode:
influenciar
um comportamento.
Mas pode não controlar:
o resultado final.
Exemplo:
aumentar timeout.
Você controla:
TIMEOUT = 30s
Mas o resultado depende de:
API externa;
conexões;
thread pool;
volume;
retry.
Então:
PARÂMETRO CONTROLADO
≠
RESULTADO CONTROLADO
🧠 Sistemas complexos possuem muitas variáveis fora da nossa visão
Mainframe não opera isolado.
Mesmo um batch aparentemente simples pode depender de:
arquivo recebido;
catalog;
SMS;
Db2;
horário;
locks;
downstream;
reconciliação.
A ilusão aparece quando nossa tela mostra apenas:
algumas variáveis.
E passamos a sentir que:
o que não está no dashboard não existe.
📊 Dashboard como janela — não universo
Dashboard mostra:
CPU
MEMORY
QUEUE
DB2
Tudo verde.
Equipe:
“Sistema saudável.”
Cliente:
“Pagamento não processa.”
Como?
Porque dashboard não media:
regra de negócio.
Integridade.
Dependência específica.
Automação Bias + Illusion of Control.
🧠 Métricas dão sensação de domínio
Quanto mais gráficos:
mais profissional parece a War Room.
Mas quantidade de telemetria não significa:
entendimento causal.
Você pode ter 300 métricas...
e ainda não saber o que controla o fenômeno.
☕ A NASA do dashboard
Cinco monitores.
Vinte gráficos.
Quatro pessoas olhando.
Alguém diz:
“Temos total visibilidade.”
Excelente.
Pergunta:
“Então qual é a causa?”
— Ainda não sabemos.
Visibilidade não é controle.
E nem sempre é compreensão.
🧠 Illusion of Control + Action Bias
Essa combinação é explosiva.
Incidente.
Ansiedade.
Temos comandos disponíveis.
Action Bias:
faça alguma coisa.
Illusion of Control:
nossas ações devem alterar o resultado.
Então:
restart;
parameter tuning;
flush;
retry.
Cada intervenção aumenta sensação de participação.
Talvez sem melhorar nada.
🧠 O problema do “tuning emocional”
CPU alta.
Alguém muda parâmetro.
CPU cai.
Conclusão:
“Resolvi.”
Mas talvez:
volume tenha caído.
Job acabou.
Cliente reduziu tráfego.
Ou outra dependência voltou.
Outcome Bias entra.
Agora ação vira ritual.
☕ O sacerdote do parâmetro
— Sempre aumento XYZ quando isso acontece.
— Por quê?
— Funciona.
— Como sabe?
— Porque depois melhora.
Talvez seja verdade.
Talvez o sistema sempre melhorasse sozinho.
Correlação novamente.
🧠 Regression to the Mean
Aqui aparece um conceito interessantíssimo:
Regressão à média.
Muitos eventos extremos naturalmente tendem a ser seguidos por valores menos extremos.
Exemplo:
latência normalmente 200ms.
Pico:
2s.
Você executa ação.
Depois volta:
300ms.
Talvez ação ajudou.
Mas talvez o pico fosse naturalmente transitório.
Se repetimos esse padrão:
passamos a acreditar:
“meu comando sempre resolve.”
Ilusão de controle alimentada por estatística.
👻 Easter Egg nº 2 — Sonic screwdriver terapêutico
Doctor vê máquina piscando.
Usa sonic screwdriver.
Luz volta ao normal.
Companion:
— Você consertou?
Doctor:
— Talvez.
— Talvez?
— Às vezes ela ia parar de piscar de qualquer maneira.
— Então por que usou?
— Ficou visualmente excelente.
War Room adora ações visualmente excelentes.
🧠 Outcome Bias reforça a ilusão
Ação.
Resultado bom.
Outcome Bias:
decisão boa.
Illusion of Control:
eu causei o resultado.
Self-Serving Bias:
competência minha.
Overconfidence:
posso repetir.
Quatro vieses.
Um botão.
🧠 Normalization of Deviance
Toda vez que queue cresce:
restartamos.
Funciona.
Agora restart vira procedimento.
Talvez nunca tenhamos demonstrado causalidade.
O ritual vira norma.
Normalization of Deviance transforma superstição operacional em runbook.
☕ O runbook mágico
IF SYSTEM SLOW
RESTART CONSUMER
Pergunta:
qual evidência?
— Sempre fizemos assim.
Frase perigosa da série inteira.
🧠 Controle probabilístico versus determinístico
Alguns sistemas são bastante determinísticos.
COBOL:
COMPUTE A = B + C
Se entradas e condições forem conhecidas:
resultado previsível.
Mas sistemas distribuídos possuem:
concorrência;
rede;
timeouts;
fila;
falhas externas.
Você pode aumentar probabilidade de bom resultado.
Não garantir.
Engenharia moderna trabalha muito com:
controle estatístico e resiliência
não:
certeza total.
🧠 Reliability Engineering não promete universo obediente
Ela pergunta:
qual probabilidade de falha?
quanto impacto?
como detectamos?
como recuperamos?
qual margem?
Isso é mais humilde.
E mais poderoso.
☕ “Five nines”
99,999%.
Parece controle absoluto.
Ainda existe:
0,001%.
Em escala enorme:
coisas acontecem.
Alta confiabilidade é redução de risco.
Não eliminação metafísica da possibilidade.
🧠 Illusion of Control + Optimism Bias
Temos automação.
Monitoring.
Rollback.
Equipe pensa:
“Se der problema, controlamos.”
Optimism Bias:
provavelmente dará certo.
Illusion of Control:
e se não der, conseguimos resolver.
Essa dupla pode reduzir respeito pelo risco.
🧠 Plan Continuation Bias
Mudança piora.
Equipe pensa:
“Só precisamos ajustar mais um parâmetro.”
Porque acredita que ainda controla trajetória.
Plan Continuation mantém movimento.
Illusion of Control sustenta esperança operacional.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Está sob controle.”
Pergunte:
“O que exatamente está sob nosso controle?”
Parâmetro?
Volume?
Fornecedor?
Tempo?
Usuários?
🎯 Pergunta Bellacosa nº 2
“Quais variáveis importantes não controlamos?”
Essa é ainda melhor.
🧠 Control Surface
Podemos pensar numa:
superfície de controle.
O que podemos manipular diretamente?
THREADS
TIMEOUT
ROUTING
WORKLOAD
ROLLBACK
E o que não?
CUSTOMER DEMAND
PARTNER HEALTH
NETWORK INTERNET
HUMAN BEHAVIOR
RANDOM FAILURE
Ter isso explícito melhora decisões.
☕ Matrix Bellacosa do Controle
CONTROLAMOS
-----------
configuração
deploy
rollback
monitoramento interno
INFLUENCIAMOS
-------------
performance
tráfego
comportamento downstream
NÃO CONTROLAMOS
---------------
cliente
partner
internet
acaso
Agora temos um mapa mais realista.
🧠 Illusion of Control + Dunning-Kruger
Pouco conhecimento:
não vemos variáveis ocultas.
Então:
“Eu controlo.”
Mais conhecimento:
vemos dependências.
Então:
“Controlamos algumas partes.”
Essa é uma conexão maravilhosa com o capítulo anterior.
🧠 Expertise real reduz linguagem absoluta
Iniciante:
“Se aumentar threads resolve.”
Especialista:
“Pode melhorar throughput se gargalo estiver no worker pool e o downstream suportar carga.”
Parece menos poderoso.
Mas é mais correto.
🧠 Dunning-Kruger encontra o botão
Quanto menos sabemos sobre efeitos colaterais:
mais simples parece mexer.
Você vê:
MAXTHREADS=100
Pensa:
200 é duas vezes melhor.
Talvez não.
Db2 pode sofrer.
Downstream.
Memory.
Contention.
Queue.
Controle local pode degradar sistema global.
🌀 Local Optimization
Você melhora:
seu componente.
Piora:
sistema.
Isso aparece muito em sistemas complexos.
CICS aumenta throughput.
Db2 satura.
Aplicação ficou “mais rápida” em empurrar problema adiante.
Parabéns.
☕ Otimização Whac-A-Mole
Gargalo aqui.
Aperta.
Aparece ali.
É quase jogo de parque.
Sistemas complexos redistribuem pressão.
🧠 Illusion of Control + Framing Effect
Dashboard diz:
97% CONTROLLED
O que isso significa?
Nada sem definição.
Palavras como:
“controlado”;
“estável”;
“sob gestão”
criam frame psicológico.
Precisamos métricas concretas.
🧠 “Incident contained”
Contido significa:
sem crescimento?
sem cliente novo afetado?
causa removida?
Às vezes War Room declara “contained” porque:
paramos processo.
Isso é controle de impacto.
Não controle da causa.
Boa distinção.
🧠 Containment versus Resolution
Containment
Limitamos dano.
Mitigation
Reduzimos impacto.
Resolution
Removemos causa imediata.
Prevention
Reduzimos recorrência.
Quatro coisas.
Misturar gera ilusão.
☕ “Voltou” não significa “resolvemos”
Produção voltou.
Excelente.
Mas se não sabemos por quê:
controle ainda é limitado.
🧠 Automation Bias + Illusion of Control
Automação dá enorme sensação de poder.
Auto-scaling.
Auto-healing.
Auto-remediation.
Agora:
“Sistema se corrige sozinho.”
Até encontrar failure mode fora da automação.
Automação amplia capacidade.
Mas também pode ampliar:
a confiança de que já cobrimos tudo.
🤖 Agentes e Illusion of Control
Com agentes de IA isso fica ainda mais interessante.
Você dá:
tools;
autonomia;
workflow.
Dashboard mostra:
“Agent completed task.”
Agora gestor sente:
“Processo está automatizado e sob controle.”
Mas agente pode depender de:
modelo;
prompt;
tool permissions;
dados;
APIs;
contexto.
Cada camada pode falhar.
🧠 Human-on-the-loop
Humano supervisiona.
Mas consegue realmente compreender velocidade e volume das ações?
Se não:
supervisão pode ser controle nominal.
Uma luz verde dizendo:
“human oversight enabled”
não garante oversight efetivo.
☕ O botão de STOP que ninguém consegue apertar a tempo
Tecnicamente existe controle humano.
Praticamente:
agente executa 500 ações antes de alguém perceber.
Controle de papel.
🧠 Manual override
Manual override parece ótimo.
Mas precisa ser:
rápido;
testado;
compreendido.
Se nunca foi usado:
talvez seja só conforto psicológico.
🎯 Pergunta Bellacosa nº 3
“Nosso mecanismo de controle já foi realmente testado?”
Rollback?
DR?
Kill switch?
Failover?
🧠 Backups
Tem backup.
Sensação:
dados seguros.
Mas restore foi testado?
Se não:
Illusion of Control.
Você controla processo de backup.
Talvez não controle recuperação.
☕ Backup não testado é fé com compressão
Já falamos.
Continua perfeito.
🧠 Disaster Recovery
Documento diz:
RTO 2 horas.
Último teste?
Nunca.
Isso não é controle.
É desejo formatado em PDF.
🧠 Planning Fallacy
Planejamos:
“Se falhar, rollback em 15 minutos.”
Baseado em quê?
Não testado.
Illusion of Control dá falsa segurança.
Planning Fallacy transforma em cronograma.
🧠 O rollback imaginário
Runbook:
ROLLBACK: AVAILABLE
Ótimo.
Mas:
credencial funciona?
versão antiga está disponível?
dados continuam compatíveis?
Já fez?
Controle não testado é hipótese.
🧠 Sunk Cost + Illusion of Control
Projeto ruim.
Equipe pensa:
“Ainda conseguimos virar.”
Porque acredita que ações futuras restaurarão trajetória.
Sunk Cost diz:
continue.
Illusion of Control diz:
podemos corrigir.
Às vezes isso prolonga projeto muito além do racional.
☕ “Só precisamos executar melhor”
Talvez.
Ou talvez premissa esteja errada.
A crença em execução como solução universal pode ser ilusão de controle.
🧠 Markets e projetos
Pessoas frequentemente acreditam que:
mais esforço
controlará resultado.
Mas mercado possui:
clientes;
competidores;
timing.
Você controla produto.
Não controla adoção.
Em TI interno:
controla projeto.
Não controla todas as dependências.
🧠 Illusion of Control em segurança
Security instala:
firewall;
EDR;
MFA.
Agora:
“Estamos seguros.”
Não.
Estamos:
mais protegidos.
Diferença enorme.
Segurança absoluta não existe.
Controles reduzem probabilidade e impacto.
🔐 Compliance ≠ Security
Checklist 100%.
Auditoria OK.
Isso pode gerar:
ilusão de segurança.
Compliance mostra aderência a controles definidos.
Não garante ausência de ataque.
☕ RACF perfeitamente configurado
Excelente.
Mas:
usuário autorizado pode abusar.
Aplicação pode ter falha.
Credencial pode vazar.
Controle tem limites.
🧠 Least Privilege
Não elimina risco.
Reduz blast radius.
Essa é a linguagem correta.
🧠 Control Effectiveness
Pergunte:
não apenas:
controle existe?
Mas:
funciona?
E:
contra qual failure mode?
📊 Control Coverage
Exemplo:
MFA
COVERS:
stolen password
DOES NOT COVER:
session hijack
authorized insider
application flaw
Isso destrói ilusão de cobertura total.
🧠 Swiss Cheese novamente
Cada controle é uma fatia.
Nenhuma é perfeita.
Illusion of Control aparece quando:
vemos cinco fatias
e imaginamos:
parede sólida.
Swiss Cheese lembra:
buracos continuam.
🧠 Diffusion of Responsibility
Curiosamente:
quando temos sistemas automáticos de controle, pessoas podem pensar:
“monitoramento cuidará.”
Agora responsabilidade difunde.
Illusion of Control institucional:
“Temos sistema para isso.”
Mas quem acompanha?
🔔 Alarm Fatigue
Temos alertas.
Logo:
“Vamos saber quando der problema.”
Mas milhares de alertas podem tornar esse controle inútil.
Controle nominal.
Efetividade real baixa.
🧠 Control Theater
Uma expressão útil:
teatro de controle.
Processos que parecem aumentar controle, mas pouco reduzem risco.
Exemplo:
15 aprovações de mudança
sem ninguém realmente revisar conteúdo.
Parece governança.
Pode ser ritual.
☕ CAB com quinze pessoas e zero leitores
Ticket circula.
Todos aprovam.
Depois incidente.
Pergunta:
— Quem revisou rollback?
Silêncio.
Control theater.
🧠 Authority Gradient
Mais aprovações também podem gerar:
“Se todos aprovaram, deve estar seguro.”
Groupthink + Illusion of Control.
Cada pessoa assume que outra verificou.
Diffusion.
Queijo suíço corporativo.
🎯 Pergunta Bellacosa nº 4
“Esse controle reduz risco ou apenas produz sensação de governança?”
Dolorosa.
Excelente.
🧠 Procedures
Procedimento é útil.
Mas procedimento não controla realidade.
Ele orienta comportamento.
Se condição não prevista aparece:
pessoa precisa adaptar.
Work-as-Done retorna.
🧠 Checklist não substitui julgamento
Checklist ajuda.
Mas:
checklist incompleto
não torna incidente impossível.
Controlos precisam coexistir com:
capacidade adaptativa.
☕ Runbook não é grimório mágico
Não basta recitar comandos.
O contexto importa.
🧠 Status Quo Bias
Processo existe há 15 anos.
Então sentimos:
“está controlado.”
Talvez apenas nunca tenha encontrado condição adversa suficiente.
Survivorship Bias reforça.
🧠 Survivorship Bias + Illusion of Control
Executamos 200 mudanças.
Nenhuma catástrofe.
Conclusão:
nosso processo controla risco.
Talvez.
Ou tivemos sorte em algumas.
Precisamos analisar:
near misses;
margem;
falhas pequenas.
🧠 Normalization of Deviance
Pulamos etapa.
Nada acontece.
Agora:
“sabemos controlar.”
Na verdade:
risco foi tolerado e não materializou.
Repetição cria falsa confiança.
☕ Sorte repetida parece competência
Até a distribuição cobrar.
🧠 Randomness
É difícil aceitar quanto acaso participa de resultados.
Especialmente para engenheiros.
Gostamos de:
causalidade;
controle.
Mas sistemas possuem:
timing;
race conditions;
load variations.
Nem tudo é totalmente previsível.
🧠 Probabilidade não é derrota intelectual
Dizer:
“Existe 2% de chance.”
não significa:
“não entendemos nada.”
Significa:
entendemos variabilidade.
☕ O mainframe é determinístico até encontrar o resto do mundo
Bonita frase.
🧠 Illusion of Control em estimativas
Projeto:
“Terminamos dia 30.”
O gestor sente:
cronograma = controle.
Mas datas dependem de:
bugs;
aprovações;
fornecedor.
Planejamento é ferramenta.
Não profecia.
🧠 Gantt Chart não controla o futuro
Ele representa plano.
Talvez essa frase devesse vir impressa na licença de todo software de project management.
😄 O cronograma como amuleto
Quanto mais barras coloridas:
mais controle parece existir.
Planning Fallacy manda lembranças.
🧠 Risk Register
Registrar risco também pode dar sensação:
“tratado.”
Mas:
“risco registrado”
≠
“risco mitigado.”
Excelente distinção.
☕ Ticket aberto não conserta produção
Nem risk register.
Nem PowerPoint.
Ação concreta importa.
🧠 Control Loops
Na teoria de controle, um sistema precisa de:
sensor;
feedback;
ação;
nova medição.
Isso é excelente metáfora.
Você não controla apenas porque age.
Precisa observar resposta.
📈 Closed-loop control
OBSERVE
↓
DECIDE
↓
ACT
↓
MEASURE
↓
ADJUST
Sem feedback:
é open-loop.
Ou seja:
chute sofisticado.
🧠 War Room open-loop
Muda threads.
Muda timeout.
Reinicia serviço.
Tudo em dois minutos.
Sem medir efeito individual.
Isso não é controle.
É confete operacional.
☕ One Change at a Time
Quando possível:
ação.
medição.
próxima ação.
Isso cria causalidade observável.
🧠 Feedback delay
Outro problema:
ação agora.
efeito só aparece em 5 minutos.
Se mudar tudo antes:
não sabe o que causou quê.
Controle exige entender atraso.
🧠 Queueing Systems
Aumentou worker.
Backlog demora a cair.
Pessoa pensa:
“Não funcionou.”
Muda de novo.
Talvez apenas não esperou dinâmica do sistema.
Conhecer lag importa.
🎯 Pergunta Bellacosa nº 5
“Quanto tempo devemos esperar para observar o efeito dessa ação?”
Ótima.
🧠 Action Bias + Control Loop
Sem essa pergunta:
Action Bias dispara próxima intervenção cedo demais.
🧠 Control vs Resilience
Talvez essa seja uma das maiores lições.
Em sistemas complexos, o objetivo não é:
controlar tudo.
É:
ser resiliente ao que não controlamos.
Não controlo parceiro cair.
Mas posso:
timeout;
circuit breaker;
fallback.
Não controlo usuário errar.
Mas posso:
validar.
Não controlo hardware nunca falhar.
Mas posso:
redundância.
☕ Resiliência é humildade arquitetural
Você diz:
“Isso pode falhar.”
E projeta:
“Então continuaremos.”
Muito mais maduro que:
“Não vai falhar porque controlamos.”
🧠 Control What You Can, Bound What You Can't
Uma regra maravilhosa:
controle o que puder e limite o dano do que não puder controlar.
Essa é arquitetura.
💥 Blast Radius
Quanto menos controlável o evento:
mais importante limitar blast radius.
Canary.
Partitions.
Isolation.
🧠 Feature Flags
Não controlam bug.
Mas permitem:
desligar funcionalidade.
Controle parcial útil.
🧠 Circuit Breaker
Não controla parceiro.
Mas impede cascata.
Excelente exemplo de engenharia contra ilusão de controle.
🧠 Retry
Retry parece controle.
Mas retry excessivo pode piorar falha.
Retry storm.
Outro exemplo:
uma ferramenta criada para aumentar controle pode gerar perda de controle.
☕ O botão “Retry” é esperança com loop
Use backoff.
🧠 Idempotency
Não controla falha de rede.
Mas garante que repetição não duplique efeito.
Resiliência contra incerteza.
Especialmente relevante em processamento financeiro.
🏦 COBOL e restartability
Um bom batch não presume:
“Não vai cair.”
Ele pergunta:
“Se cair, onde recomeço?”
Checkpoint.
Control totals.
Reconciliation.
Isso é engenharia sem ilusão.
💻 Exemplo COBOL
Programa ingênuo:
READ INPUT
PROCESS
WRITE OUTPUT
Programa mais resiliente:
READ INPUT
VALIDATE
PROCESS
WRITE OUTPUT
UPDATE CHECKPOINT
CHECK RETURN-CODE
Mais complexo.
Porque aceita:
falha existe.
🧠 Restart não controla falha
Mas controla:
recuperabilidade.
Essa é a diferença.
☕ Mainframe foi construído em grande parte em cima dessa humildade
Return codes.
Checkpoints.
Journaling.
Logging.
Recovery.
Tudo diz:
“coisas podem dar errado.”
Isso é maturidade operacional incorporada.
🧠 Illusion of Control + Loss Aversion
Quando acreditamos controlar sistema atual:
temos medo de trocar.
“Aqui sabemos tudo.”
Talvez.
Status Quo + Loss Aversion.
Mas talvez controle seja familiaridade.
🧠 Familiarity ≠ Control
Conheço sistema há 20 anos.
Isso aumenta capacidade.
Mas não elimina:
falhas raras;
dependências.
“Conhecido” parece “controlado.”
Nem sempre.
☕ O legado confortável
Você sabe onde bater.
Isso não significa que o motor esteja saudável.
🧠 Actor-Observer Bias
Nossa equipe:
“Temos controle.”
Outra:
“Eles improvisam.”
Talvez ambas operem com incerteza.
Mesma régua.
🧠 Self-Serving Bias
Quando intervenção funciona:
“controlamos.”
Quando falha:
“evento externo.”
Isso perpetua ilusão.
Decision log ajuda.
📝 Action Attribution Log
Registre:
ACTION:
Restart consumer
EXPECTED:
queue drain within 5 min
ACTUAL:
queue unchanged
CONCLUSION:
Action ineffective
Agora não podemos dizer depois:
“Restart ajudou um pouco.”
Dados.
🧠 A/B operational thinking
Se possível:
mude subset.
Compare.
Canary.
Isso ajuda distinguir:
controle real
de:
coincidência.
🧪 Experiments
Em ambientes controlados:
teste.
Produção nem sempre permite.
Mas chaos engineering, game days e load tests ajudam.
Você descobre:
quanto controle realmente possui.
☕ Game Day é exame de realidade
“Failover automático.”
Desliga.
Veja.
Se não acontece:
melhor terça-feira à tarde que domingo às 03h.
🧠 Manual dependencies
Muita automação esconde:
pessoa específica.
Game Day revela:
“Precisamos ligar para João.”
Controle menor que imaginado.
🧠 Bus Factor
Sistema parece controlado porque:
João sempre está.
Não é controle.
É dependência humana.
🎯 Pergunta Bellacosa nº 6
“O sistema continua controlável quando a pessoa mais experiente não está disponível?”
Boa.
🧠 Illusion of Control em RCA
Depois:
queremos identificar:
“a causa.”
Ter uma causa dá sensação de domínio.
Mas sistemas complexos podem ter múltiplos fatores.
Narrative Bias + Illusion of Control:
“Agora sabemos exatamente.”
Talvez não.
Aceitar:
“causa mais provável”
às vezes é honestidade.
🧠 Unknown remains valid
Como vimos:
ROOT CAUSE:
NOT FULLY CONFIRMED
Pode ser melhor que falsa precisão.
☕ Não saber tudo não significa não aprender nada
Podemos reduzir risco mesmo com incerteza.
🧠 Bayesian humility
Comece com hipótese.
Atualize.
Não precisa certeza absoluta.
Engenharia é muitas vezes decidir com:
probabilidade.
🧠 Control Confidence
Podemos registrar:
CONTROL:
Rollback
CONFIDENCE:
High
WHY:
tested monthly
LIMIT:
cannot reverse data format migration
Agora controle tem escopo.
🧠 Boundary Conditions
Todo controle deveria possuir:
onde funciona;
onde não.
Exemplo:
rollback do código funciona.
Rollback de dados?
Talvez não.
Importante.
☕ “Rollback disponível” é frase incompleta
Rollback de:
quê?
Código?
Config?
Dados?
Schema?
🧠 Irreversibility
Quanto mais irreversível:
menos devemos confiar na ilusão de controle.
Delete.
Financial posting.
Schema migration.
Precisa:
mais gates;
mais testes.
🧠 Reversibility como antidoto
Pequenas apostas.
Canary.
Feature flag.
Rollback.
Tudo reduz necessidade de acreditar em controle perfeito.
📋 Checklist anti-Illusion of Control
[ ] O que realmente controlamos?
[ ] O que apenas influenciamos?
[ ] O que está totalmente fora do nosso controle?
[ ] Nosso controle já foi testado?
[ ] O resultado melhorou por nossa ação ou poderia melhorar sozinho?
[ ] Existe regressão à média?
[ ] Estamos confundindo dashboard com realidade?
[ ] Estamos executando várias ações sem medir?
[ ] Qual é o feedback esperado?
[ ] Quanto tempo até o efeito aparecer?
[ ] Existe dependência externa?
[ ] Temos fallback para aquilo que não controlamos?
[ ] O controle reduz risco ou só gera sensação de governança?
[ ] Estamos confundindo familiaridade com domínio?
[ ] Se o controle falhar, qual é o blast radius?
🧪 Como combater Illusion of Control — passo a passo
Passo 1 — Faça um mapa de controle
Controlamos.
Influenciamos.
Não controlamos.
Passo 2 — Defina resultado esperado antes da ação
Não depois.
Passo 3 — Meça resposta
Feedback.
Passo 4 — Evite múltiplas ações simultâneas
Quando possível.
Passo 5 — Teste controles
Rollback.
DR.
Kill switch.
Passo 6 — Documente limites
Quando controle não funciona?
Passo 7 — Use redundância e fallback
Para fatores externos.
Passo 8 — Limite blast radius
Não controle o universo.
Controle o dano.
Passo 9 — Faça Game Days
Descubra realidade.
Passo 10 — Reavalie sua confiança
O que achávamos que controlávamos mas não controlávamos?
🧠 Controle percebido versus controle observado
Uma boa organização compara:
CONTROLE DECLARADO:
Failover automático em 2 min
TESTE REAL:
Failover em 18 min e precisou intervenção
Agora temos aprendizado.
☕ Documento diz 2.
Produção diz 18.
Produção ganha.
🧠 Metrics for controls
Meça:
frequency of successful rollback;
DR execution time;
false positive rate;
mean time to detect;
manual interventions.
Controle precisa de KPI próprio.
🧠 “Temos monitoramento”
Pergunta:
detecta quanto?
Tempo?
Cobertura?
Não basta existir.
🧠 Control Health
Controles também degradam.
Certificado do monitor vence.
Runbook envelhece.
Script quebra.
Controle precisa manutenção.
🌀 Drift Into Failure dos próprios controles
Esse é um ponto lindo.
Não apenas produção deriva.
As defesas também derivam.
Backup deixa de incluir dataset novo.
Alertas ficam obsoletos.
Documentação envelhece.
Ainda dizemos:
“Temos controle.”
Mas o controle já não corresponde ao sistema.
🎯 Pergunta Bellacosa nº 7
“Quando foi a última vez que provamos que esse controle ainda funciona?”
Excelente pergunta para auditoria, DR e War Room.
🧠 Control Debt
Talvez exista:
dívida de controle.
Controle criado.
Sistema muda.
Controle não acompanha.
Exemplo:
script de rollback antigo.
Ao longo do tempo:
confiança permanece;
efetividade cai.
Isso é perigoso.
☕ O extintor vencido
Está na parede.
Dá sensação de segurança.
Na hora do incêndio...
melhor descobrir antes.
🔐 Security control decay
Firewall rule.
IAM role.
MFA.
Tudo precisa revisão.
Controle antigo pode virar:
falsa segurança.
🧠 Psychological Safety e Illusion of Control
Equipe precisa poder dizer:
“Não temos controle suficiente aqui.”
Se cultura exige:
certeza,
pessoas fingem.
Isso esconde fragilidade.
☕ “Não controlamos essa dependência” não é fracasso
É informação arquitetural.
Agora podemos decidir:
redundância?
SLA?
fallback?
🧠 Leadership
Líder pergunta:
“Está sob controle?”
Talvez uma pergunta melhor seja:
“Qual parte está controlada e qual risco continua aberto?”
Muito melhor.
🧠 War Room language
Em vez de:
“Está controlado.”
Use:
“Impacto está contido, causa ainda não confirmada.”
Excelente.
Precisão epistemológica.
🧠 Status Reporting
Exemplo:
IMPACT:
Contained
CAUSE:
Unknown
RECOVERY:
Stable
RISK:
Recurrence possible
Muito melhor que:
“Tudo sob controle.”
☕ “Tudo sob controle” talvez seja a frase corporativa menos verificável do mundo
E das mais populares.
🧠 Illusion of Control + Narrative Bias
Depois do incidente, construímos história:
“Fizemos X, então sistema recuperou.”
Isso restaura sensação de domínio.
Mesmo quando:
não temos prova.
Cuidado com post-hoc causality.
🧠 Counterfactual thinking
Pergunte:
“Se não tivéssemos feito X, o que provavelmente teria acontecido?”
Difícil.
Mas útil.
Se sistema já estava recuperando:
talvez ação fosse irrelevante.
🧠 Observational uncertainty
Nem sempre conseguiremos saber.
Então:
registre incerteza.
Não transforme em vitória operacional.
🧠 Self-Serving Bias novamente
Equipe quer crédito.
Natural.
Mas:
controle exagerado sobre sucesso
é autoengano.
Success Review ajuda.
☕ Onde tivemos sorte?
Essa pergunta volta.
Porque sorte é exatamente aquilo que nossa ilusão de controle tenta apagar.
🧠 Resilience over control
Uma organização resiliente diz:
“Não sabemos quando parceiro falhará.”
Mas:
timeout;
circuit breaker;
retry limitado;
fallback.
Isso é maturidade.
Ela não controla o parceiro.
Controla:
a própria resposta.
🧠 Stoicism engineering edition
Não precisamos virar filósofos gregos.
Mas a ideia é ótima:
distinga:
o que depende de você;
o que não depende.
Em sistemas:
controle interno;
dependência externa.
Concentre arquitetura no primeiro.
Proteja-se do segundo.
☕ Epicteto encontraria emprego como SRE
Provavelmente escreveria excelentes runbooks.
🧠 COBOL e a humilde FILE STATUS
Por que verificar:
FILE STATUS
Porque programa não presume:
“WRITE vai funcionar.”
Ele pergunta ao sistema:
“Funcionou?”
Isso é feedback.
Uma pequena vacina contra ilusão de controle.
💻 Exemplo
WRITE REG-OUT
IF WS-FILE-STATUS NOT = '00'
PERFORM TRATAR-ERRO
END-IF
Você emitiu comando.
Não presume resultado.
Verifica.
Isso é filosofia de controle em COBOL.
🧠 Db2 SQLCODE
Mesma coisa.
Executou:
UPDATE
Mas verifica:
SQLCODE
Porque intenção não garante resultado.
☕ EXEC SQL não é feitiço
É pedido.
O banco responde.
Excelente metáfora.
🧠 MQ Reason Code
MQ também.
Você pede.
Recebe completion code.
Sistemas robustos reconhecem:
ação e resultado são coisas diferentes.
🧠 Return Codes como humildade computacional
Talvez isso seja uma das coisas mais bonitas do mainframe.
RC existe porque:
o sistema não presume sucesso só porque você mandou fazer.
Humanos deveriam copiar.
🎯 Regra Bellacosa
Comando emitido não é resultado confirmado.
Vale para:
JCL;
DB2;
MQ;
CICS;
cloud;
IA;
vida.
🧬 Regeneração organizacional
Uma organização madura contra Illusion of Control:
mapeia o que controla;
testa rollback;
executa Game Days;
mede controles;
documenta limites;
monitora dependências;
usa feedback loops;
reduz blast radius;
evita várias mudanças simultâneas;
e valoriza linguagem de incerteza.
Principalmente:
ela troca:
“Temos controle.”
por:
“Temos controles para estes riscos, dentro destes limites, e um plano para o restante.”
Isso é menos cinematográfico.
Muito mais poderoso.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Illusion of Control é a tendência de acreditar que influenciamos mais os resultados do que realmente influenciamos.
Poder executar uma ação não significa controlar o resultado.
Dashboards aumentam visibilidade, não garantem compreensão.
Ações seguidas por melhora podem criar falsa causalidade por regressão à média.
Outcome Bias e Self-Serving Bias podem transformar coincidência em sensação de competência.
Automation Bias pode fazer ferramentas automáticas parecerem controles mais completos do que são.
Controles precisam ser testados, medidos e mantidos.
Rollback documentado não é rollback validado.
Fatores externos não precisam ser controlados se o sistema for resiliente a eles.
Mainframe já ensina humildade através de return codes, file status, SQLCODE e mecanismos de recovery.
O objetivo de sistemas complexos não é controlar tudo, mas detectar, limitar, adaptar e recuperar.
E principalmente:
Você não precisa controlar o universo. Precisa saber quais alavancas realmente funcionam, quais coisas não obedecem a você e como impedir que o inesperado leve tudo junto.
🕰️ De volta às 02:47
O gerente pergunta:
— Está sob controle?
Nosso jovem responde:
— O impacto está parcialmente contido.
— E a causa?
— Ainda não confirmamos.
— O que controlamos?
— Reduzimos tráfego e isolamos o fluxo problemático.
— E o que não controlamos?
— A API externa continua instável.
— Então qual é o plano?
— Circuit breaker temporário, fallback para transações elegíveis e monitoramento.
O Doctor sorri.
— Agora sim.
O gerente pergunta:
— Então está sob controle?
Nosso jovem pensa.
— Está sob limites conhecidos.
Pausa.
— Prefiro essa frase.
Boa.
🔧 Trinta minutos depois
Partner volta.
API normaliza.
Equipe observa:
failure rate cai.
Mas desta vez registram:
EXTERNAL API RECOVERED:
03:17
OUR MITIGATION:
Reduced impact from 9.4% to 3.1%
FULL RECOVERY:
03:23
Importante.
Eles não dizem:
“Nós resolvemos tudo.”
Dizem:
“Nossa mitigação reduziu impacto; recuperação total dependeu também da volta do parceiro.”
Self-Serving Bias perde força.
Illusion of Control também.
E aprendizagem melhora.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(CONTROL)
Dentro:
IF ACTION-PERFORMED
PERFORM VERIFY-RESULT
END-IF.
IF CONTROL = 'EXISTS'
PERFORM TEST-CONTROL
END-IF.
IF DEPENDENCY = 'EXTERNAL'
PERFORM LIMIT-BLAST-RADIUS
END-IF.
IF SOMEONE-SAYS
'EVERYTHING-IS-UNDER-CONTROL'
PERFORM ASK-WHAT-EXACTLY
END-IF.
Comentário:
* A BUTTON IS NOT THE UNIVERSE.
Outro:
* COMMAND ISSUED
* DOES NOT MEAN
* RESULT CONFIRMED.
Outro:
* CONTROL WHAT YOU CAN.
* CONTAIN WHAT YOU CANNOT.
Mais um:
* RETURN CODES EXIST
* BECAUSE INTENT IS NOT OUTCOME.
E naturalmente:
* THE DOCTOR CONTROLS THE TARDIS.
* MOST OF THE TIME.
Nosso jovem fecha o membro.
Pouco depois alguém diz:
— Nosso failover está garantido.
Ele pergunta:
— Quando testamos?
— Há dois anos.
— Então temos um desenho de failover.
— E não um failover?
— Até provar novamente...
Pausa.
— temos confiança histórica.
Game Day agendado.
Failover executado.
Uma rota antiga falha.
Corrigem.
Agora sim.
Menos ilusão.
Mais controle real.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma última frase:
Controle não é a quantidade de botões que podemos apertar. É conhecer os limites das nossas ações, medir suas consequências e continuar funcionando quando o mundo decide não obedecer.
☕🌀
Next stop: Control Bias / Need for Control — quando a necessidade psicológica de reduzir incerteza começa a produzir processos, aprovações, dashboards e regras em excesso, até que controlar o sistema passa a atrapalhar o próprio sistema.
