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.

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?

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.

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.

Translate

quarta-feira, 12 de setembro de 2012