 |
| Bellacosa Mainframe e o status quo bias |
☕ Um Café no Bellacosa Mainframe
Status Quo Bias: Doctor Who, COBOL e o Dia em que Ninguém Queria Mexer no Sistema que “Ainda Funcionava”
Uma viagem pela TARDIS dos incidentes para entender por que processos ruins, tecnologias antigas e riscos conhecidos podem sobreviver por anos simplesmente porque mudar parece mais assustador do que continuar
08:14.
Segunda-feira.
Café quente.
Reunião de arquitetura.
Na tela:
SISTEMA DE COBRANÇA
IDADE: 23 ANOS
INCIDENTES CRÍTICOS: 7
INTERVENÇÕES MANUAIS/MÊS: 143
JANELA BATCH: 92% UTILIZADA
DOCUMENTAÇÃO: PARCIAL
ESPECIALISTAS DISPONÍVEIS: 2
Nosso jovem programador COBOL olha.
— Não deveríamos modernizar isso?
Silêncio.
O gerente responde:
— Está funcionando.
O programador olha novamente.
INTERVENÇÕES MANUAIS/MÊS: 143
— Mais ou menos.
O especialista sorri.
— Você é novo. Esse sistema sempre foi assim.
Outro gerente:
— Migrar seria arriscado.
O DBA:
— Mexer nisso agora pode criar problema.
Operação:
— Melhor deixar quieto.
Então aparece a frase lendária:
“Em time que está ganhando não se mexe.”
Nosso jovem olha para os números.
Não tem certeza se aquilo realmente é “ganhar”.
Mas ninguém parece interessado em descobrir.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do projetor.
A porta abre.
O Doctor sai.
Olha para os indicadores.
Depois para a equipe.
— Por que vocês mantêm esse sistema exatamente assim?
O gerente responde:
— Porque ele funciona.
O Doctor aponta para:
143 INTERVENÇÕES MANUAIS
— Essa é uma definição bastante criativa de “funciona”.
O especialista cruza os braços.
— Mudar pode ser pior.
O Doctor sorri.
— Certamente.
Pausa.
— Mas vocês calcularam o risco da mudança...
Aponta para o sistema.
— ...e esqueceram de calcular o risco de não mudar.
Bem-vindo ao:
Status Quo Bias
Ou:
Viés do Status Quo
A tendência de preferir manter a situação atual simplesmente porque ela já existe, tratando mudança como algo que precisa ser justificado enquanto a permanência é aceita como se fosse neutra.
E aí mora o perigo:
não decidir mudar também é uma decisão.
🌀 Onde estamos na nossa TARDIS dos incidentes?
Nossa jornada já encontrou uma coleção respeitável de monstros.
Swiss Cheese Model mostrou que várias barreiras podem falhar juntas.
Normalization of Deviance mostrou como práticas ruins viram rotina.
Hindsight Bias mostrou como o passado parece óbvio depois.
Confirmation Bias explicou como procuramos provas para aquilo que acreditamos.
Anchoring Bias mostrou o peso excessivo da primeira informação.
Groupthink revelou como grupos podem concordar e continuar errados.
Authority Gradient mostrou como hierarquia pode silenciar dúvidas.
Plan Continuation Bias mostrou como continuamos planos que já perderam sentido.
Alarm Fatigue explicou por que alertas demais deixam de ser ouvidos.
Automation Bias mostrou como podemos confiar demais nas máquinas.
Drift Into Failure mostrou como sistemas derivam lentamente em direção à falha.
Diffusion of Responsibility mostrou como todos podem saber e ninguém assumir.
Normalcy Bias mostrou nossa tendência de acreditar que tudo voltará ao normal.
Survivorship Bias ensinou a procurar quem desapareceu da amostra.
Base Rate Neglect mostrou como esquecemos frequências reais.
Availability Heuristic mostrou que aquilo que lembramos facilmente parece mais provável.
Outcome Bias explicou por que resultado bom pode legitimar decisão ruim.
Overconfidence Bias mostrou como experiência e sucesso podem gerar certeza excessiva.
Planning Fallacy mostrou como subestimamos tempo e complexidade.
Sunk Cost Fallacy mostrou como investimentos passados podem nos prender ao futuro.
Agora o próximo passo é quase inevitável.
Às vezes continuamos não porque o sistema seja ótimo.
Mas porque:
ele já está ali.
🧠 O que exatamente é Status Quo Bias?
Imagine duas opções.
Opção A
Continuar exatamente como estamos.
Opção B
Mudar alguma coisa.
Mesmo que B tenha vantagens claras, nossa mente frequentemente exige muito mais evidência para mudar do que para ficar.
O estado atual recebe um privilégio psicológico.
Podemos representar:
STATUS QUO
↓
“JÁ CONHECEMOS”
↓
PARECE SEGURO
MUDANÇA
↓
“PODE DAR ERRADO”
↓
PARECE ARRISCADA
Mas repare:
o status quo também pode dar errado.
Só que seus riscos ficaram familiares.
☕ Bellacosa Mainframe: “Não mexe, está funcionando”
Todo mainframeiro já ouviu essa frase.
Talvez com variantes:
“Não toca nisso.”
“Esse programa é antigo, mas funciona.”
“Ninguém sabe exatamente como funciona.”
“Se mexer, quebra.”
“Foi escrito pelo pessoal antigo.”
“Deixa para depois.”
Essas frases podem conter prudência legítima.
Mas também podem esconder:
medo;
falta de conhecimento;
dívida técnica;
sunk cost;
dependência de especialista;
ausência de testes;
falta de documentação.
Não mexer pode ser a escolha correta.
Mas precisa ser uma decisão consciente.
Não reflexo.
🧠 Status Quo não é sinônimo de segurança
Esse é o primeiro ponto fundamental.
Um sistema existente possui uma vantagem:
é conhecido.
Mas “conhecido” não significa “seguro”.
Você pode conhecer perfeitamente um processo ruim.
Exemplo:
TODO DIA:
03:10 job atrasa
03:20 operador ajusta
03:30 restart
03:50 encerra
A organização diz:
— Sempre foi assim.
Então virou normal.
Esse é o encontro entre:
Status Quo Bias + Normalization of Deviance
🌀 O velho desvio vira patrimônio histórico
Primeira vez:
workaround temporário.
Depois:
workaround conhecido.
Depois:
procedimento informal.
Depois:
documentado.
Depois:
ninguém lembra por que existe.
Finalmente:
“Não mexe nisso.”
Parabéns.
Um desvio acabou de se transformar em patrimônio cultural.
👻 Easter Egg nº 1 — “Sempre esteve ali”
Imagine a TARDIS chegando a uma nave.
No meio da ponte existe um botão vermelho gigantesco.
Doctor pergunta:
— Para que serve?
Tripulação:
— Não sabemos.
— Há quanto tempo está aí?
— Quatrocentos anos.
— E ninguém investigou?
— Não. Sempre esteve aí.
O Doctor suspira.
— Essa frase explica metade dos problemas do universo.
💻 COBOL e o parágrafo misterioso
Você encontra:
IF WS-FLAG = 'Y'
PERFORM 9000-ROTINA-ESPECIAL
END-IF.
Pergunta:
— O que faz 9000-ROTINA-ESPECIAL?
Veterano:
— Não mexe.
— Por quê?
— Não sei.
— É usado?
— Acho que sim.
— Quando?
— Desde 1998.
Esse é o momento em que Status Quo Bias pode transformar desconhecimento em controle operacional.
A regra deveria ser:
Se não entendemos, precisamos reduzir a incerteza. Não santificar o código.
🧠 Legacy não significa errado
Importante.
Não confundamos Status Quo Bias com:
“Tudo velho precisa ser substituído.”
Isso seria outro viés.
Um sistema antigo pode ser:
robusto;
estável;
eficiente;
barato;
bem conhecido;
extremamente confiável.
COBOL e mainframe são exemplos perfeitos de tecnologias antigas que continuam valiosas em muitos contextos.
A questão não é idade.
A questão é:
o sistema ainda entrega valor dentro de risco aceitável?
🧮 Idade não é métrica de obsolescência
Pergunte:
performance?
manutenção?
segurança?
custo?
skill availability?
resiliência?
capacidade?
dependências?
Se respostas forem boas:
ótimo.
Não migre só porque PowerPoint diz “modernização”.
Status Quo Bias é ruim.
Mas:
Change Bias também seria ruim.
Mudar por moda é tão irracional quanto não mudar por medo.
☕ A pergunta correta
Não:
“É velho?”
Nem:
“É novo?”
Mas:
“Ainda é a melhor opção disponível para este contexto?”
Essa é engenharia.
💰 Sunk Cost Fallacy retorna imediatamente
No capítulo anterior vimos:
“Já gastamos demais para parar.”
Agora:
“Já investimos demais nesse sistema para trocar.”
Pode ser sunk cost.
Exemplo:
licenças;
treinamento;
integrações;
infraestrutura.
Tudo isso é relevante para custos futuros de transição.
Mas dinheiro passado, irrecuperável, não deveria ser usado sozinho para justificar permanência.
🧠 Status Quo + Sunk Cost
A combinação:
“JÁ ESTÁ AQUI”
+
“JÁ GASTAMOS MUITO”
=
“ENTÃO PRECISA CONTINUAR”
Não necessariamente.
A pergunta ainda é:
qual opção oferece melhor valor daqui para frente?
🌀 Drift Into Failure entra silenciosamente
Esse talvez seja o casamento mais importante.
Sistema funciona.
Não mudamos.
Volume cresce.
Equipe diminui.
Margem cai.
Workarounds aumentam.
Ainda funciona.
Então continuamos.
Pouco a pouco:
o status quo muda.
Ironia.
Você acredita estar preservando “o mesmo sistema”.
Mas ele está derivando.
🧠 Status Quo é dinâmico
Essa ideia é fascinante:
manter a arquitetura igual não significa manter o risco igual.
Porque o ambiente muda.
Volume.
Regulação.
Ameaças.
Pessoas.
Dependências.
Hardware.
Software.
Negócio.
Logo:
não mudar tecnicamente também pode produzir mudança de risco.
🔐 Segurança é um exemplo brutal
Sistema criado em 2010.
Autenticação adequada para 2010.
Em 2026:
ameaças diferentes.
Ataques diferentes.
Integrações diferentes.
Manter exatamente o mesmo controle não significa manter a mesma segurança.
O mundo se moveu.
Você não.
👥 “Mas nunca fomos atacados”
Aparecem:
Survivorship Bias.
Outcome Bias.
Normalcy Bias.
Talvez não houve incidente.
Isso não prova que controle atual seja suficiente.
🚨 CVE e Status Quo
Patch disponível.
Equipe evita:
“Pode quebrar.”
Risco real.
Mas manter vulnerabilidade também possui risco.
Uma decisão madura precisa comparar:
risk of change
versus:
risk of no change
Não apenas o primeiro.
⚖️ Change Risk versus Stay Risk
Essa deveria ser uma tela padrão:
MUDAR
Riscos:
- indisponibilidade
- regressão
- migração
- treinamento
NÃO MUDAR
Riscos:
- obsolescência
- falha
- segurança
- skill shortage
- custo crescente
Agora temos comparação simétrica.
🧠 Default Effect
Status Quo Bias possui relação com o chamado Default Effect.
Se uma opção já vem selecionada como padrão, pessoas tendem a mantê-la.
No mundo corporativo:
arquitetura existente é o default.
Processo atual é default.
Fornecedor atual é default.
Continuar exige zero movimento.
Mudar exige projeto.
Isso dá vantagem estrutural ao status quo.
☕ O fornecedor eterno
Contrato existe há 15 anos.
Pergunta:
— Ainda é competitivo?
Resposta:
— Nunca tivemos problema.
Talvez.
Mas revisamos alternativas?
— Não.
Então não sabemos.
Você não escolheu novamente.
Apenas não mudou.
🧠 Inação parece menos responsável
Existe outro fator psicológico.
Se mantemos situação atual e algo dá errado:
“Foi o sistema.”
Se mudamos e algo dá errado:
“Quem decidiu mudar?”
Percebe?
Mudança tem autor visível.
Inação, muitas vezes, não.
Isso favorece status quo.
🪡 A agulha volta ao Bellacosa
Em decisões corporativas:
quem aprova mudança pode sentir:
“Se der errado, a agulha aponta para mim.”
Manter tudo como está parece mais seguro politicamente.
Mesmo que tecnicamente não seja.
A gestão de risco pode virar gestão de responsabilidade pessoal.
🪜 Authority Gradient
Júnior:
— Talvez devêssemos substituir este processo.
Sênior:
— Está assim há vinte anos.
Fim.
Autoridade + história cria barreira.
A idade do sistema vira argumento.
👥 Groupthink
Todos repetem:
“Não mexe.”
Pessoa nova começa a achar que existe algum motivo profundo.
Talvez não exista.
Talvez todos apenas estejam repetindo a mesma frase desde 2007.
Isso é tradição sem documentação.
🧠 Institutional Memory versus Institutional Myth
Memória institucional:
“Não altere porque há dependência X documentada.”
Excelente.
Mito institucional:
“Não altere porque todo mundo sabe que quebra.”
Por quê?
— Não sabemos.
Maturidade exige distinguir.
🧪 Teste o mito
Crie ambiente controlado.
Clone.
Experimente.
Observe.
Talvez descubra:
era perigoso.
Ótimo.
Ou:
o medo era legado histórico.
Também ótimo.
Conhecimento substitui superstição.
🔬 Spike / POC contra Status Quo Bias
Se mudar parece assustador:
não precisa fazer Big Bang.
Faça:
POC;
piloto;
shadow mode;
canary;
módulo pequeno.
Isso reduz custo psicológico da mudança.
🧠 Reversibilidade é chave
Mudança irreversível assusta.
Então torne-a reversível.
Feature flag.
Rollback.
Blue/green.
Backup.
Versionamento.
Teste.
Quanto mais reversível:
menor barreira para experimentar.
🚦 Incremental Change
Status Quo Bias frequentemente nasce da falsa dicotomia:
manter tudo
versus
substituir tudo.
Não precisa.
Pode ser:
estrangular sistema aos poucos;
modernizar interfaces;
automatizar testes;
documentar;
separar componentes.
Pequenas mudanças reduzem risco.
🧱 Strangler Pattern
Um conceito arquitetural famoso:
em vez de substituir sistema inteiro de uma vez, novos componentes vão gradualmente assumindo funções.
Isso pode ser útil quando Big Bang é arriscado.
Não é solução universal.
Mas ilustra:
mudança pode ser desenhada para reduzir medo.
☕ Bellacosa Mainframe: modernizar sem destruir
Mainframe pode ganhar:
APIs;
Git;
CI/CD;
testes;
Zowe;
z/OSMF;
automação;
observabilidade;
sem necessariamente jogar COBOL fora.
Esse é um excelente exemplo de combater Status Quo Bias sem cair em:
“reescreve tudo.”
Modernização não precisa significar substituição.
🧠 Technology Replacement Bias
Às vezes consultoria diz:
“Sistema é antigo, substitua.”
Cuidado.
Isso pode ser viés oposto.
Se novo sistema adiciona:
mais custo;
mais latência;
menos estabilidade;
não melhorou.
A pergunta não é:
legacy versus moderno.
É:
qual arquitetura produz melhor resultado agora e no futuro previsível?
📊 Total Cost of Inaction
Já falamos de TCO.
Agora outra métrica útil:
Cost of Inaction
Quanto custa não fazer nada?
Exemplo:
MANUAL FIXES/MÊS: 143
15 min cada
=
35h45/mês
Mais:
incidentes;
erros;
treinamento;
turnover.
De repente “não mudar” também possui business case.
💰 Manutenção invisível
Status quo parece barato porque muita manutenção fica escondida.
Planilhas.
Scripts.
Telefonemas.
Heroísmo.
No Drift Into Failure vimos isso.
Conte.
🦸 “Carlos resolve”
Sistema parece barato porque Carlos corrige diariamente.
Carlos não é gratuito.
Nem eterno.
Se ele sair:
qual custo?
Bus Factor entra.
🧠 Skill Risk
Aplicação depende de três especialistas.
Dois perto da aposentadoria.
Status quo hoje funciona.
Mas horizonte de cinco anos?
A análise precisa incluir disponibilidade futura de skills.
Não como argumento sensacionalista.
Como risco real.
📅 Time Horizon
Uma escolha pode ser boa:
hoje.
Ruim:
em três anos.
Status Quo Bias olha muito para o conforto imediato.
Planejamento estratégico precisa olhar horizonte.
🧠 Present Bias aparece no horizonte
Preferimos benefício imediato e subestimamos consequências futuras.
Isso é outro viés relacionado:
Present Bias.
Talvez um ótimo episódio futuro.
Porque manter status quo gera conforto agora.
Dívida depois.
🔥 Technical Debt
Status Quo Bias protege dívida técnica.
“Funciona.”
Sim.
Mas mudança pequena custa:
2 dias?
2 semanas?
2 meses?
A velocidade de manutenção é um indicador.
📈 Change Failure Rate não é tudo
Sistema com zero mudanças também terá:
zero change failures.
Parabéns?
Talvez não.
Talvez ninguém consiga mudar nada.
Uma métrica isolada pode premiar imobilidade.
🧠 Stability versus Stagnation
Excelente distinção:
Estabilidade:
podemos mudar com segurança, mas não precisamos constantemente.
Estagnação:
não mudamos porque temos medo ou incapacidade.
De fora:
ambas parecem tranquilas.
Por dentro:
completamente diferentes.
🧪 Teste de saúde
Pergunte:
“Se precisássemos mudar amanhã, conseguiríamos?”
Se resposta:
“Deus nos livre.”
Talvez não tenhamos estabilidade.
Temos fragilidade.
🏛️ Lindy Effect retorna
Sistemas antigos que sobreviveram muito possuem evidência de robustez.
Isso merece respeito.
Mas não prova que:
todas as condições futuras serão iguais.
Use longevidade como evidência positiva.
Não como veto à revisão.
📚 COBOL antigo pode ser excelente
Um programa de 1987:
estável;
testado;
simples;
bem documentado;
baixo custo.
Por que substituir?
Talvez não deva.
Status Quo Bias só existe quando a preferência pelo atual decorre principalmente do fato de ser atual, não de análise.
Essa nuance é fundamental.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Não mexe porque funciona.”
Pergunte:
“O que significa ‘funciona’ em números?”
SLA?
Erro?
Custo?
Intervenção?
Margem?
🎯 Pergunta Bellacosa nº 2
Outra:
“Qual é o risco de continuar exatamente assim por três anos?”
🎯 Pergunta Bellacosa nº 3
Outra:
“Se esse sistema não existisse hoje, escolheríamos construí-lo dessa forma?”
Excelente contra Status Quo + Sunk Cost.
🎯 Pergunta Bellacosa nº 4
E:
“O que precisaríamos provar para considerar uma mudança segura?”
Agora o medo vira critério.
🧪 Como combater Status Quo Bias — passo a passo
Passo 1 — Torne explícita a opção “não mudar”
Não trate como default invisível.
Passo 2 — Calcule risk of change
Claro.
Passo 3 — Calcule risk of no change
Igualmente.
Passo 4 — Meça custo do status quo
Inclua trabalho oculto.
Passo 5 — Defina horizonte
1 ano?
5?
10?
Passo 6 — Faça pequenos experimentos
POCs.
Canary.
Pilotos.
Passo 7 — Aumente reversibilidade
Rollback.
Feature flags.
Backups.
Passo 8 — Preserve conhecimento
Documente antes de mudar.
Passo 9 — Reavalie periodicamente
Decisão antiga não é eterna.
Passo 10 — Compare com alternativas reais
Não imaginárias.
📋 Checklist anti-Status Quo Bias
[ ] Por que mantemos o estado atual?
[ ] Temos dados ou apenas tradição?
[ ] Qual o risco de mudar?
[ ] Qual o risco de não mudar?
[ ] Qual o custo oculto atual?
[ ] A margem de segurança está caindo?
[ ] Dependemos de heroísmo?
[ ] Conhecimento está concentrado?
[ ] O ambiente mudou?
[ ] Existem requisitos novos?
[ ] O sistema ainda atende bem?
[ ] Conseguimos mudar com segurança?
[ ] Estamos presos por sunk cost?
[ ] Existe uma alternativa incremental?
[ ] Se começássemos hoje, escolheríamos igual?
🧠 Decision symmetry
Uma defesa muito poderosa:
avalie mudança e permanência com o mesmo rigor.
Não:
MUDAR
→ precisa de business case
NÃO MUDAR
→ automático
Mas:
MUDAR
→ custos + benefícios + riscos
NÃO MUDAR
→ custos + benefícios + riscos
Simetria.
📊 Status Quo Review
A cada ano:
serviços críticos.
Pergunte:
ainda faz sentido?
Não significa lançar projeto.
Apenas revisar.
Talvez conclusão seja:
continue.
Excelente.
Agora você escolheu continuar.
Não apenas esqueceu de reconsiderar.
🧠 “Keep” também precisa ser decisão
Imagine arquitetura review:
SYSTEM A
DECISION:
KEEP
RATIONALE:
- cost competitive
- stable
- skills available
- headroom 40%
- security supported
- modernization via API underway
REVIEW:
12 months
Isso é status quo consciente.
Completamente diferente de:
“Sempre esteve aí.”
🤖 IA e Status Quo Bias
Empresas podem fazer duas coisas opostas.
Primeira:
“Nunca usaremos IA porque processo atual funciona.”
Status Quo Bias.
Segunda:
“Precisamos colocar IA em tudo.”
Shiny Object Bias.
Ambos ruins.
Pergunte:
qual problema?
qual valor?
qual risco?
☁️ Cloud versus Mainframe
Mesma coisa.
“Tudo precisa ir para cloud.”
Possível erro.
“Nada sai do mainframe.”
Também.
Arquitetura não deveria ser religião.
Cada workload possui características.
🧠 Status Quo tecnológico pode ser confortável
Porque mudar exige aprender.
E aprender significa admitir:
não sabemos.
Isso pode ser desconfortável para especialistas.
Logo, Status Quo Bias pode ser reforçado por identidade profissional.
👨💻 O programador COBOL iniciante
Aqui existe uma oportunidade.
O iniciante pergunta:
“Por que fazemos assim?”
Veterano pode ouvir como crítica.
Mas essa pergunta é valiosíssima.
Talvez exista ótimo motivo.
Explique.
Talvez ninguém saiba.
Então documente e investigue.
Fresh eyes quebram status quo.
🧠 O valor da pergunta ingênua
— Por que rodamos esse job duas vezes?
— Sempre rodamos.
— Mas por quê?
Silêncio.
Às vezes o newbie encontra fantasma de 1999.
Não porque sabe mais.
Porque ainda não aprendeu a parar de estranhar.
👻 Easter Egg nº 2 — o job do Y2K
Imagine um step criado para contornar problema de ano 2000.
Ano:
Ainda roda.
Ninguém sabe por quê.
Nosso jovem pergunta.
Descobre:
não faz nada útil há 24 anos.
CPU pequena.
Mas ritual perfeito.
Status Quo Bias fossilizado em JCL.
💾 Código morto também custa
Mesmo sem consumir muita CPU:
confunde;
aumenta análise;
gera dependência;
risco de alteração.
Excluir também pode reduzir complexidade.
🗑️ Delete é feature
Às vezes a melhor modernização:
remover.
Programa.
Job.
Interface.
Relatório que ninguém usa.
Menos sistema.
Menos superfície de falha.
🧠 Decommissioning precisa de coragem
Criar projeto dá visibilidade.
Desligar coisa velha também deveria.
Porque sistemas zumbis consomem:
licença;
staff;
segurança;
atenção.
📊 Usage Analytics
Antes de manter relatório “porque sempre existiu”:
quem usa?
Último acesso?
Valor?
Talvez ninguém.
Status quo alimenta sistemas órfãos.
🌀 Diffusion of Responsibility
Quem decide descontinuar?
Aplicação?
Negócio?
Infra?
Ninguém.
Então continua.
Diffusion + Status Quo.
Sistema fica vivo porque ninguém é owner de sua morte.
🎯 Pergunta Bellacosa nº 5
“Quem possui responsabilidade por decidir que este sistema ainda merece existir?”
Essa é uma pergunta poderosa.
🔥 Change Advisory Boards
Governança pode involuntariamente aumentar Status Quo Bias.
Se mudar exige:
20 aprovações;
10 formulários;
3 reuniões;
mas não fazer nada exige zero...
adivinhe qual comportamento será favorecido.
Processo precisa proteger mudança sem tornar imobilidade mais fácil que evolução.
🧠 Safety bureaucracy paradox
Controle criado para reduzir risco de mudança.
Mas se burocracia impede patches e melhorias:
pode aumentar risco de permanência.
Outro exemplo de sistema produzindo efeito oposto.
🧬 Resilience Engineering novamente
Sistemas resilientes não são sistemas que nunca mudam.
São capazes de:
adaptar;
absorver;
recuperar;
aprender.
Logo, capacidade segura de mudança é parte da resiliência.
🛠️ Changeability is a safety feature
Frase importante:
A capacidade de mudar com segurança também é um controle de risco.
Testes.
Automação.
Observabilidade.
Rollback.
Versionamento.
Tudo isso reduz custo de mudança.
E, portanto, Status Quo Bias.
🧠 Fear of Change diminui com engineering quality
Se cada deploy parece cirurgia cardíaca:
óbvio que ninguém quer mexer.
Melhore:
testes;
pipelines;
sandbox;
monitoramento;
rollback.
A cultura muda porque risco real cai.
Não apenas porque fizemos palestra sobre inovação.
🧪 Game Days
Simule mudança.
Rollback.
Failover.
Quanto mais prática:
menos status quo depende do medo.
Conhecimento gera opção.
📈 Option Value
Ter capacidade de mudar cria valor mesmo se você não mudar hoje.
É uma opção.
Arquitetura flexível preserva escolhas futuras.
🧠 Status Quo Bias e planejamento estratégico
Uma empresa pode passar anos otimizando:
“como manter?”
sem perguntar:
“ainda deveríamos?”
Eficiência operacional sem revisão estratégica pode manter perfeitamente uma coisa errada.
☕ Fazer perfeitamente aquilo que não precisava existir
Isso é uma tragédia técnica elegante.
Job otimizado.
CPU reduzida.
Automação perfeita.
Mas relatório não é usado há cinco anos.
Parabéns.
Otimizamos o irrelevante.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Status Quo Bias é a tendência de preferir o estado atual simplesmente porque ele já existe.
Não mudar também é uma decisão.
O risco da mudança precisa ser comparado ao risco da permanência.
Familiar não significa seguro.
Legacy não significa obsoleto.
Novo não significa melhor.
Sunk Cost pode proteger sistemas que perderam valor.
Normalization of Deviance pode transformar workarounds em tradição.
Drift Into Failure faz o risco crescer mesmo quando arquitetura não muda.
Reversibilidade e mudanças incrementais reduzem medo.
Fresh eyes ajudam a questionar rituais sem explicação.
Capacidade de mudar com segurança é uma propriedade de resiliência.
E principalmente:
A pergunta madura não é “por que mudar?”. É “comparando mudança e permanência, qual escolha ainda faz mais sentido?”
🕰️ De volta à reunião das 08:14
Sistema:
IDADE: 23 ANOS
INTERVENÇÕES: 143/MÊS
BATCH WINDOW: 92%
SPECIALISTS: 2
O gerente repete:
— Migrar é arriscado.
Nosso programador responde:
— Concordo.
Todos parecem surpresos.
— Então deixamos?
— Não foi isso que eu disse.
Ele abre outro slide.
RISCO DE MUDAR
--------------
regressão
migração
custo
treinamento
indisponibilidade
Depois:
RISCO DE NÃO MUDAR
------------------
janela quase cheia
2 especialistas
143 intervenções/mês
documentação parcial
crescimento de volume
Silêncio.
— Não precisamos substituir tudo.
O arquiteto pergunta:
— Então?
— Primeiro documentar.
Depois automatizar as intervenções.
Criar testes.
Expor APIs.
Reduzir dependências.
Separar componentes.
Medir.
Então decidir.
O Doctor sorri.
— Ah.
— O quê?
— Finalmente alguém percebeu que a alternativa a “não fazer nada” não precisa ser “destruir tudo”.
🧪 Dois anos depois
O sistema ainda roda COBOL.
Mas agora:
INTERVENÇÕES: 11/MÊS
BATCH WINDOW: 58%
SPECIALISTS: 7
TEST AUTOMATION: 84%
APIs: IMPLEMENTED
DOCUMENTATION: CURRENT
Alguns módulos foram substituídos.
Outros permaneceram.
A equipe não “migrou o mainframe”.
Também não ficou parada.
Modernizou onde havia valor.
Preservou onde fazia sentido.
Nosso programador olha para o Doctor.
— Então o status quo não era o problema?
— Não.
— O que era?
— Não saber por que vocês o mantinham.
Boa resposta.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(STATUSQUO)
Dentro:
IF CURRENT-STATE = 'WORKING'
PERFORM MEASURE-WHAT-WORKING-MEANS
END-IF.
IF CHANGE-RISK > ZERO
PERFORM CALCULATE-STAY-RISK
END-IF.
IF ONLY-REASON-TO-KEEP =
'WE-ALWAYS-DID-IT'
PERFORM ASK-WHY
END-IF.
Comentário:
* FAMILIAR IS NOT A REQUIREMENT.
Outro:
* OLD CAN BE EXCELLENT.
* NEW CAN BE TERRIBLE.
* MEASURE BOTH.
Mais um:
* DO NOTHING
* IS STILL A CHANGE DECISION.
E naturalmente:
* BAD WOLF WAS LEGACY.
* STILL SUPPORTED.
Nosso jovem fecha o membro.
Horas depois alguém pergunta:
— Podemos remover esse step?
Ele responde:
— Por quê?
— Parece velho.
Ele sorri.
— Essa é uma razão tão ruim quanto mantê-lo só porque é velho.
— Então?
— Vamos descobrir o que ele faz.
Executam análise.
O step ainda previne uma condição rara de restart.
Mantêm.
Documentam.
Outro step não fazia nada útil desde 2003.
Removem.
Nenhuma guerra entre:
legacy;
modernização;
velho;
novo.
Apenas engenharia.
VWORP.
VWORP.
VWORP.
A TARDIS começa a desaparecer.
No quadro da War Room fica uma última frase:
O sistema atual não merece permanecer porque já existe. A mudança não merece acontecer porque é nova. Ambos precisam passar pelo mesmo tribunal: evidência, risco, custo e valor.
☕🌀
Next stop: Present Bias — quando sabemos que o risco chegará no futuro, mas preferimos o conforto, a economia e a facilidade de hoje… deixando o problema como presente para a equipe de amanhã.
