Bellacosa Mainframe e o moral hazard

☕ Um Café no Bellacosa Mainframe

Moral Hazard: Doctor Who, COBOL e o Dia em que Alguém Assumiu o Risco — Porque Outro Time Pagaria a Conta

Uma viagem pela TARDIS dos incidentes para entender como seguros, contratos, SLAs, terceirização, automações e separação entre decisão e consequência podem incentivar comportamentos mais arriscados em sistemas críticos

08:37.

Segunda-feira.

War Room ainda vazia.

Café recém-passado.

Produção normal.

Na tela, uma proposta de mudança:

CHANGE:
BATCH PAYMENT ENGINE

SCOPE:
14 PROGRAMS
6 COPYBOOKS
3 DB2 TABLES
2 MQ FLOWS

WINDOW:
2 HOURS

Nosso jovem programador COBOL olha.

— Isso tudo em duas horas?

O gerente responde:

— Sim.

— Parece apertado.

— Se atrasar, operações segura.

— E se quebrar?

— Infra faz rollback.

— E se perdermos dados?

— O time de reconciliação corrige.

— E se o fornecedor não responder?

— Temos SLA.

Nosso jovem fica alguns segundos em silêncio.

Interessante.

Para cada risco:

alguém tinha uma resposta.

Mas quase sempre:

a resposta era outra pessoa.

O gerente continua:

— Vamos fazer Big Bang. É mais rápido.

O programador pergunta:

— Quem decidiu isso?

— Nós.

— E quem fica de plantão se der problema?

— Operações.

— Quem reconcilia?

— Financeiro.

— Quem responde ao cliente?

— Atendimento.

— Quem paga penalidade?

— A empresa.

Silêncio.

— Então...

Pausa.

— quem está assumindo o risco?

O gerente olha.

— Nós estamos decidindo.

— Eu sei.

— Então?

— Decidir e carregar a consequência são a mesma coisa?

Antes que alguém responda:

VWORP.

A TARDIS materializa-se ao lado do projetor.

A porta abre.

O Doctor sai.

Olha para o change.

Depois para a lista de times envolvidos.

— Quem escolheu o Big Bang?

— Gestão de projeto.

— Quem fará recuperação se falhar?

— Operações.

— Quem trabalhará madrugada adentro?

— Operações e desenvolvimento.

— Quem recebe bônus se entregar antes?

Silêncio.

— Gestão do projeto.

O Doctor sorri.

— Ah.

— O quê?

— Vocês criaram um sistema em que uma pessoa recebe parte do benefício da decisão...

Pausa.

— enquanto outras pessoas recebem parte maior do prejuízo se a decisão der errado.

Bem-vindo ao:

Moral Hazard

Ou:

Risco Moral

Um conceito econômico e comportamental que aparece quando alguém toma decisões de risco sabendo que não suportará integralmente as consequências negativas dessas decisões.

Em linguagem Bellacosa:

“Se eu ganho quando dá certo e outra pessoa paga boa parte da conta quando dá errado, meu incentivo para ser cauteloso diminui.”

🧠 Moral Hazard não significa “pessoa imoral”

Primeiro cuidado.

O nome pode confundir.

“Moral Hazard” não significa necessariamente:

fraude;

má-fé;

falta de caráter.

Pode existir mesmo quando ninguém está conscientemente tentando prejudicar alguém.

O problema é:

estrutura de incentivos.

Se benefício e consequência estão separados:

o comportamento pode mudar.

Isso é profundamente importante em:

seguros;

finanças;

outsourcing;

cloud;

DevOps;

projetos;

SRE;

segurança;

incidentes.

E naturalmente:

mainframe.

☕ O exemplo clássico do seguro

Imagine que você possui seguro completo para um carro.

Se qualquer dano for integralmente pago por outra entidade, talvez exista menos incentivo econômico para evitar alguns riscos.

Isso não significa que todo segurado vai dirigir perigosamente.

Significa que:

a proteção contra perdas pode alterar incentivos.

Por isso seguros possuem:

franquia;

limites;

condições.

Eles tentam manter:

skin in the game.

Ou seja:

alguma parte da consequência continua com quem toma a decisão.

🧠 Risk Compensation versus Moral Hazard

Eles se parecem.

Mas não são iguais.

Risk Compensation

“Estou mais protegido, então posso me sentir confortável assumindo mais risco.”

Pode acontecer mesmo quando eu continuo pagando as consequências.

Moral Hazard

“Parte importante das consequências cairá sobre outra pessoa, então meu incentivo para reduzir risco diminui.”

A diferença principal é:

quem paga a conta.

☕ Exemplo Bellacosa

Risk Compensation

Equipe recebe rollback automático.

Passa a deployar mais.

Ela ainda sofre os incidentes.

Moral Hazard

Projeto decide acelerar deploy.

Se der certo:

projeto bate prazo.

Se falhar:

operações passa a madrugada corrigindo.

Agora temos:

assimetria de recompensa e consequência.

👻 Easter Egg nº 1 — O botão do Companion

Companion:

— Doctor, posso apertar aquele botão?

Doctor:

— Não.

— Por quê?

— Pode destruir o sistema de contenção.

— E quem conserta?

— Eu.

— Ah.

Ela começa a estender o dedo.

Doctor:

— E é exatamente por isso que você não vai apertar.

Às vezes a melhor governança começa quando quem aperta o botão conhece o custo de apertá-lo.

🧠 Principal-Agent Problem

Moral Hazard aparece frequentemente dentro de um problema maior:

principal-agent problem.

Uma pessoa ou organização — o principal — delega alguma atividade para outra — o agente.

Mas:

os incentivos não são perfeitamente alinhados.

Exemplo:

empresa contrata fornecedor.

Fornecedor recebe por:

entregar mudança.

Empresa suporta:

risco operacional.

Se contrato recompensa:

velocidade,

mas não penaliza adequadamente:

incidentes,

o fornecedor pode racionalmente priorizar:

velocidade.

Não porque seja “malvado”.

Porque:

o sistema de incentivos está ensinando isso.

☕ Outsourcing mainframe

Fornecedor tem KPI:

DELIVERIES / MONTH

Equipe interna mede:

AVAILABILITY
INCIDENTS
DATA INTEGRITY

Fornecedor quer:

entregar.

Operação quer:

não quebrar.

Conflito estrutural.

Se change falha:

fornecedor talvez recebe ticket.

Operação recebe:

telefone às 03:00.

Quem sente mais risco?

Operação.

Quem decidiu escopo?

Talvez fornecedor/projeto.

Moral Hazard possível.

🧠 KPI cria comportamento

Se premiamos:

quantidade de releases,

podemos ter:

mais releases.

Se quem gera releases não sofre custo completo de incidentes:

atenção.

Goodhart entra discretamente.

🧠 Moral Hazard + Goodhart's Law

Métrica:

“entregar projeto no prazo.”

Equipe corta:

testes.

Documentação.

Rollback rehearsal.

Entrega no prazo.

KPI:

verde.

Três semanas depois:

produção quebra.

Quem absorve?

Operação.

Agora a métrica ficou verde...

e o sistema ficou vermelho.

☕ A entrega terminou no Go-Live?

Para projeto:

sim.

Para operações:

talvez tenha começado ali.

Essa diferença é enorme.

🧠 Definition of Done

Uma defesa simples contra Moral Hazard:

Definition of Done precisa incluir consequências operacionais.

Não apenas:

código entregue.

Mas:

testes completos;
observabilidade;
runbook;
rollback;
suporte;
documentação;
reconciliação.

Agora benefício e responsabilidade ficam mais próximos.

🧠 “Você constrói, você opera”

A filosofia:

You Build It, You Run It

pode reduzir Moral Hazard porque quem cria também participa da operação.

Não é solução universal.

Mas o princípio é poderoso:

aproxime decisão e consequência.

Quando desenvolvedor sente incidente:

passa a considerar:

logging;

recovery;

monitoring

durante o desenvolvimento.

☕ O código muda depois da primeira madrugada de plantão

Curiosamente.

Depois de um SEV-1 às 03:00:

aquele DISPLAY adicional começa a parecer muito barato.

🧠 Skin in the Game

Expressão útil.

Quem toma risco deveria ter:

alguma exposição ao resultado.

Não punição.

Exposição informacional e operacional.

Exemplo:

arquiteto aprova desenho.

Participa da revisão do incidente.

Projeto entrega.

Continua responsável pelo hypercare.

Fornecedor implanta.

SLA inclui qualidade pós-produção.

Isso reduz distância entre:

decisão

efeito.

🧠 Moral Hazard + Self-Serving Bias

Se dá certo:

“Projeto entregou.”

Se dá errado:

“Operações não estabilizou.”

Self-Serving Bias protege quem recebeu benefício.

Moral Hazard protege estruturalmente porque custo ficou em outro lugar.

Combinação ruim.

🧠 Fundamental Attribution Error

Projeto envia mudança arriscada.

Operação executa.

Falha.

Relatório:

“Operador executou procedimento incorretamente.”

Mas:

por que arquitetura exigia manobra manual sob pressão?

Moral Hazard pode terminar em:

culpa na ponta.

☕ Quem tem a agulha?

A velha regra operacional volta.

Decisão precisa ter:

owner.

Aprovação.

Registro.

Quando incidente ocorre:

não pode desaparecer a cadeia decisória.

🧠 Authority Gradient

Chefe:

— Faça hoje.

Operador:

— Risco está alto.

Chefe:

— Assumo.

Mas depois...

incidente.

Quem está na timeline?

Operador que apertou Enter.

Authority Gradient + Moral Hazard.

Quem dá ordem pode estar distante da consequência imediata.

🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Pode fazer.”

Pergunte:

“Quem é o risk owner dessa decisão?”

Não apenas:

quem executa.

🧠 Execution Owner ≠ Risk Owner

Muito importante.

EXECUTOR:
Operations

DECISION OWNER:
Project Manager

RISK OWNER:
Business Service Owner

Agora a organização sabe:

quem tomou decisão;

quem executou;

quem aceitou risco.

🧠 Omission Bias

Às vezes ninguém quer explicitamente assumir risco.

Então decisão fica difusa.

“Vamos seguir.”

Quem decidiu?

Todo mundo.

Logo:

ninguém.

Diffusion of Responsibility aparece.

Moral Hazard institucional.

🧠 Diffusion of Responsibility + Moral Hazard

Se custo será dividido entre:

cinco departamentos,

cada um sente apenas parte.

Então ninguém possui incentivo forte suficiente para prevenir.

Tragedy of the commons começa a aparecer.

☕ Shared platform

Time A consome CPU.

Custo geral pago por infraestrutura.

Então A não otimiza.

Time B faz igual.

Time C também.

Resultado:

capacity problem.

Quem paga?

Empresa inteira.

Isso é um terreno fértil para Moral Hazard.

🧠 FinOps e Moral Hazard

Cloud oferece exemplo perfeito.

Desenvolvedor cria:

máquina enorme.

Benefício:

performance.

Conta:

centro de custo central.

Se equipe não vê custo:

incentivo para otimização diminui.

Showback e chargeback tentam alinhar:

consumo

consequência econômica.

☕ CPU “grátis”

Nada é tão caro quanto recurso que alguém acredita ser grátis.

🧠 Mainframe MIPS/MSU

Mesmo lógica.

Se aplicação consome:

muito CPU

mas custo é abstrato e pago centralmente:

equipe pode não sentir incentivo econômico para otimizar.

Isso não significa:

culpar aplicação.

Significa:

dar visibilidade.

📊 Showback

TEAM A:
CPU CONSUMPTION: X
STORAGE: Y
BATCH WINDOW IMPACT: Z

Não precisa cobrar diretamente.

Só tornar custo visível já muda comportamento.

🧠 Moral Hazard em capacity

Equipe pede:

mais capacidade.

Se é grátis para ela:

por que otimizar primeiro?

Arquiteto:

— Precisamos de 4x mais CPU.

Sysprog:

— Vocês revisaram SQL?

— Não.

— Por quê?

— Upgrade é mais rápido.

Quem paga hardware?

Outro orçamento.

Incentivo desalinhado.

🧠 Moral Hazard + Risk Compensation

Agora combinamos.

Novo seguro:

rollback.

Risk Compensation:

mais risco.

Se incidente for suportado por outro time:

Moral Hazard:

mais incentivo ainda para aumentar risco.

☕ O deploy ousado

Dev:

“Se der problema, operações volta.”

Operations:

“E se o rollback falhar?”

Dev:

“Vocês têm DR.”

Maravilhoso.

Toda camada de proteção vira justificativa para alguém aumentar exposição.

🧠 Swiss Cheese e propriedade das fatias

Um detalhe interessante:

cada time controla uma fatia.

Dev:

teste.

Ops:

rollback.

Security:

controle.

DBA:

recovery.

Se cada um pensa:

“a próxima fatia segura”,

os buracos podem se alinhar.

Moral Hazard pode enfraquecer responsabilidade local.

🧠 Defense in Depth não significa:

“Posso relaxar porque existe outra defesa.”

Significa:

cada camada deve cumprir sua função independentemente.

☕ Cinto + airbag + freio

Não significa:

pode dirigir olhando o celular.

As camadas somam.

Não se substituem emocionalmente.

🧠 Moral Hazard em segurança

Usuário pensa:

“Security tem antivírus.”

Então:

menos cuidado.

Equipe pensa:

“Tem cyber insurance.”

Então:

menos investimento.

Gestor pensa:

“Fornecedor é responsável.”

Então:

menos verificação.

Todas podem ser formas de desalinhamento.

🔐 Cyber Insurance

Seguro pode reduzir impacto financeiro.

Mas talvez não cubra:

reputação;

dados;

operação.

Mesmo economicamente:

franquias;

exclusões.

Não é transferência total de risco.

🧠 Risk Transfer não é Risk Elimination

Você compra seguro.

Risco financeiro parcialmente transferido.

Mas:

incidente continua existindo.

Cliente continua impactado.

Dados continuam vazados.

Logo:

RISK TRANSFER
≠
RISK REMOVAL

☕ “Tem SLA”

Outra frase mágica.

Fornecedor falha.

Você recebe crédito.

Ótimo.

Cliente?

Ainda ficou sem serviço.

SLA transfere parte do custo.

Não restaura disponibilidade retroativamente.

🧠 SLA Credits

Se fornecedor cai 8 horas:

você ganha desconto.

Financeiro sorri.

Operação não.

O crédito pode ser:

insignificante diante do impacto.

Moral Hazard pode surgir se fornecedor sabe:

penalidade máxima

é pequena.

🧠 Contract Design

Contrato precisa alinhar:

incentivos.

Não apenas:

penalidade.

Pode incluir:

availability;

quality;

security;

recovery.

Mas cuidado com métricas demais.

Goodhart continua.

☕ Contrato perfeito também não existe

Se você tentar escrever toda possibilidade:

Need for Control reaparece com 700 páginas.

Balance.

🧠 Moral Hazard no modelo “fixed price”

Projeto fornecedor recebe valor fixo.

Quanto menos gastar:

maior margem.

Empresa quer:

qualidade.

Fornecedor pode ter incentivo para:

reduzir custo.

Isso é normal em contratos.

O design precisa:

aceitação;

quality gates;

SLA.

Não confiar em bondade.

Nem assumir maldade.

Desenhe incentivos.

🧠 Incentive-Compatible Systems

Economia gosta dessa ideia:

criar regras em que agir de forma desejável também seja racional para quem decide.

Em operação:

não dependa de:

heroísmo.

Crie incentivos em que:

qualidade;

segurança;

custo

façam parte da decisão.

☕ Não peça “ownership”

Enquanto recompensa apenas:

velocidade.

Pessoas aprendem pelo bônus.

Não pelo pôster.

🧠 Moral Hazard + Planning Fallacy

Projeto promete:

6 meses.

Se atrasar:

equipe de sustentação recebe pressão.

Quem fez estimativa já pode estar em outro projeto.

Agora custo do otimismo é transferido.

Isso incentiva estimativas agressivas.

📅 Bid otimista

Fornecedor promete:

4 meses.

Ganha contrato.

Depois:

change requests.

Extensões.

Quem paga?

Cliente.

Se penalidade inicial é pequena:

incentivo para bid agressivo.

Um problema clássico de contratos.

🧠 Winner's Curse pode aparecer

Outro conceito interessante:

em licitações, quem faz a estimativa mais otimista pode ganhar.

Depois descobre:

subestimou.

Não é exatamente Moral Hazard.

Mas contratos podem criar ambiente onde:

o vencedor é quem aceita mais risco.

Se parte desse risco será renegociada depois:

Moral Hazard aumenta.

☕ “Ganha primeiro, negocia depois”

Estratégia conhecida.

Nem sempre saudável.

🧠 Moral Hazard em projetos internos

Não precisa fornecedor.

Time de transformação:

recebe bônus por:

migração concluída.

Time legado:

absorve:

incidentes.

Agora incentivo:

migrar rápido.

Não necessariamente:

operar bem.

Inclua:

post-go-live KPIs.

🧠 Hypercare

Manter projeto responsável por algumas semanas após Go-Live:

excelente.

Agora quem tomou decisões sente:

efeitos operacionais.

Isso alinha.

☕ Projeto não termina no `HASP395`

Acabou o job.

Mas negócio continua.

Boa analogia.

🧠 Moral Hazard e turnover

Pessoa toma decisão de longo prazo.

Vai embora antes da consequência.

Não podemos impedir carreira.

Mas arquitetura precisa:

documentação;

decision records.

Senão:

benefício agora.

Dívida para quem fica.

🧠 Technical Debt como Moral Hazard

Equipe entrega feature rápido.

Recebe crédito.

Debt vai para:

futuro.

Talvez outra equipe.

Isso é um tipo de externalização de custo.

☕ “Depois a gente refatora”

“Depois” normalmente é um time sem nome.

🧠 Present Bias + Moral Hazard

Benefício:

agora.

Custo:

depois.

E talvez para:

outro.

Essa combinação é poderosíssima.

Present Bias já favorece curto prazo.

Moral Hazard reduz peso do custo futuro.

🧠 Sunk Cost

Depois dívida cresce.

Ninguém quer reescrever.

Agora Status Quo.

Os vieses começam a formar uma guilda.

🧠 Externalities

Moral Hazard conversa com:

externalidades.

Uma decisão produz custo para terceiros.

Exemplo:

aplicação dispara consultas pesadas.

Time ganha:

feature.

Db2 sofre:

CPU.

Outros sistemas recebem:

latência.

A aplicação não vê integralmente custo.

☕ “Na minha aplicação está rápido”

Parabéns.

Você terceirizou lentidão para o banco.

Local Optimization encontra Moral Hazard.

🧠 End-to-End Metrics

Antídoto:

medir:

impacto sistêmico.

Não apenas:

métrica local.

Se time é avaliado por:

latência ponta-a-ponta

custo,

incentivo melhora.

🧠 WLM e prioridades

Todo mundo quer:

service class alta.

Se custo de prioridade for coletivo:

cada time pede prioridade máxima.

Se todos são prioridade 1:

ninguém é.

Moral Hazard de recursos compartilhados.

☕ “Meu job é crítico”

Claro.

Todo job é crítico quando perguntamos ao owner.

Por isso precisamos:

governança.

🧠 Tragedy of the Commons

Recursos compartilhados:

CPU;

I/O;

storage;

rede.

Cada time maximiza seu uso.

Custo distribuído.

Resultado:

degradação coletiva.

Não é exatamente Moral Hazard em todos os casos, mas é parente próximo.

🧠 Moral Hazard em War Room

Incident Commander decide:

restart agressivo.

Se der certo:

MTTR cai.

Se der errado:

evidência desaparece;

RCA sofre.

Talvez commander seja medido apenas por:

restore time.

Agora incentivo favorece:

ação rápida.

Action Bias + Moral Hazard.

☕ Métrica de MTTR sozinha

Pode ensinar:

“recupere rápido.”

Mesmo que destrua evidência.

Talvez adicione:

quality of recovery;

recurrence.

🧠 Balanced Metrics

Use:

MTTR.

Repeat Incident Rate.

Data Integrity.

Customer Impact.

Agora incentivo menos unilateral.

🧠 Moral Hazard e bônus

Se bônus depende:

apenas de uptime,

equipe pode:

não registrar incidentes.

Goodhart.

Se depende:

zero security findings,

pode esconder.

Precisamos métricas que:

não tornem verdade inimiga da recompensa.

☕ Se reportar problema reduz bônus...

adivinhe o que acontece com observabilidade.

🧠 Psychological Safety

Se quem admite risco perde:

status,

risco será escondido.

Moral Hazard pode existir na direção oposta:

gestor recebe benefício por dashboard verde

e custo de esconder risco recai no futuro.

🧠 Narrative Bias

Depois do incidente:

“Ninguém poderia prever.”

Mas decision log mostra:

dois engenheiros alertaram.

Agora narrativa tenta externalizar custo.

Decision records combatem.

🎯 Pergunta Bellacosa nº 2

“Quem recebe o benefício se der certo e quem suporta o custo se der errado?”

Talvez a melhor pergunta do capítulo.

Desenhe.

📊 Incentive Map

DECISION:
Big Bang deployment

BENEFIT:
Project — deadline achieved

COST IF FAILURE:
Operations — overtime
Business — lost revenue
Customer — service outage
Support — complaints

Agora Moral Hazard fica visível.

🧠 Risk Ownership Matrix

Outra ferramenta:

RISK:
Data corruption

DECISION OWNER:
Project

RISK OWNER:
Business

EXECUTOR:
Operations

MITIGATION OWNER:
DBA

Muito melhor que:

“todos responsáveis.”

☕ Quando todos são responsáveis...

o alerta já sabe como termina.

Diffusion of Responsibility.

🧠 RACI

RACI pode ajudar:

Responsible.

Accountable.

Consulted.

Informed.

Mas só se realmente usado.

Uma planilha com 300 linhas pode virar Control Theater.

Use de forma pragmática.

🧠 Accountability

A palavra chave.

Moral Hazard diminui quando:

quem decide também responde:

por qualidade;

por custo;

por impacto.

Não no sentido punitivo.

No sentido:

decisão não termina quando benefício foi capturado.

🧠 Accountability ≠ Blame

Precisamos repetir.

Se toda accountability vira punição:

pessoas evitam decidir.

Authority e Omission Bias.

Queremos:

ownership do resultado.

Não caça às bruxas.

☕ Skin in the game sem pele arrancada

Talvez a formulação Bellacosa.

🧠 Moral Hazard em IA

Agora fica especialmente interessante.

Equipe usa agente.

Agente toma ação.

Algo quebra.

Humano diz:

“Foi a IA.”

Fornecedor:

“Usuário aprovou.”

Gestão:

“Ferramenta estava homologada.”

Responsabilidade pulveriza.

Perfeito terreno para Moral Hazard.

🤖 AI Vendor

Fornecedor vende:

automação de mudança.

Benefício:

mais volume.

Se incidente:

cliente suporta.

Contrato talvez limite responsabilidade.

Incentivo precisa ser avaliado.

🧠 AI Agent Permissions

Se agente possui:

DELETE;

DEPLOY;

PAYMENT,

quem assume risco?

Designer?

Owner?

Operator?

Business?

Defina antes.

Não depois do incidente.

🧠 Human-in-the-loop como liability theater

HITL pode virar:

“Humano aprovou, então culpa dele.”

Mas se humano recebeu:

200 approvals;

3 segundos cada;

sem contexto,

isso não é controle real.

É transferência de responsabilidade.

Moral Hazard institucional.

☕ A aprovação humana pode virar para-raios jurídico

Se design é ruim.

Precisamos evitar.

🧠 Meaningful Human Control

Humano precisa:

entender;

ter tempo;

poder rejeitar;

possuir informação.

Se não:

approval é decorativo.

🎯 Pergunta Bellacosa nº 3

“O humano realmente controla a decisão ou apenas assina a responsabilidade?”

Fortíssima.

🧠 Moral Hazard + Automation Bias

Ferramenta recomenda.

Humano confia.

Se errado:

“Modelo falhou.”

Mas a organização escolheu:

delegar.

Precisamos ownership sistêmico.

🧠 Insurers, vendors, cloud providers

Ter contrato não significa:

ter transferido todas as consequências.

Você pode terceirizar:

infraestrutura.

Não:

responsabilidade final perante o cliente.

Muito importante.

☕ “Está na cloud” não significa “é problema da cloud”

Shared Responsibility Model deveria estar tatuado em alguns projetos.

Metaforicamente.

🧠 Shared Responsibility

Cloud provider:

hardware.

Você:

configuração.

IAM.

Dados.

Aplicação.

Se breach:

“a AWS deveria impedir” não basta.

Moral Hazard pode aparecer quando empresa interpreta outsourcing como:

outsourcing de responsabilidade.

🧠 Outsourcing Risk

Você terceiriza:

execução.

Não necessariamente:

accountability.

Contrato ajuda.

Governança continua.

☕ Você pode terceirizar o datacenter

Não pode terceirizar a reputação perante seu cliente.

🧠 Moral Hazard em change windows

Projeto não precisa ficar de plantão.

Então agenda:

mudança sexta 23h.

Ops sofre.

Solução:

quem pede mudança participa do plantão.

Agora decisão sobre horário muda magicamente.

Skin in the game.

😄 Sexta-feira 23h

Antes:

“Melhor janela.”

Depois que project manager precisa ficar:

“Talvez terça 20h seja melhor.”

Incentivos são professores excelentes.

🧠 On-call rotation

Desenvolvedor entra no on-call.

Observabilidade melhora.

Código fica mais recuperável.

Por quê?

Porque consequência ficou próxima.

Não é punição.

É feedback.

🧠 Moral Hazard + Feedback Loops

Quando quem decide recebe feedback tarde ou nunca:

aprendizado fraco.

Aproxime:

feedback.

Isso reduz:

Moral Hazard

Outcome Bias.

🧠 Feedback delay

Feature lançada.

Erro operacional aparece meses depois.

Equipe original já esqueceu.

Decision logs ajudam.

Post-implementation review também.

☕ “Depois do Go-Live”

Deveria existir formalmente.

Não só bolo e foto.

🧠 Post-Implementation Review

30 dias depois:

incidentes?
performance?
cost?
manual work?
customer impact?

Agora projeto recebe:

consequência real.

🧠 Moral Hazard e budget silos

Time A economiza:

R$100k.

Decisão aumenta custo de infra:

R$500k.

A economiza.

Empresa perde.

Local incentives.

FinOps tenta combater.

☕ Economia local, prejuízo global

Clássico.

🧠 Total Cost of Ownership

Use TCO.

Não apenas:

project cost.

Inclua:

run;

support;

licenses;

capacity;

incidents.

Isso reduz externalização.

🧠 Build vs Run

Projeto barato.

Operação caríssima.

Se procurement olha apenas:

CAPEX,

Moral Hazard na seleção.

Inclua:

OPEX.

🧠 Vendor lock-in

Fornecedor oferece:

entrada barata.

Saída cara.

Benefício inicial.

Custo futuro:

cliente.

Contrato precisa enxergar ciclo.

☕ O almoço “grátis”

Normalmente chega com fatura em outra sprint.

🧠 Moral Hazard e Sunk Cost

Depois de entrar:

custo de sair alto.

Agora fornecedor pode ter poder.

Não é automaticamente Moral Hazard, mas incentivos mudam.

Governança precisa observar.

🧠 Procurement e SLA

Procurement negocia:

preço baixo.

Operação recebe:

serviço ruim.

Procurement KPI:

verde.

Operação:

vermelho.

Separação de benefício e consequência.

🎯 Pergunta Bellacosa nº 4

“A métrica de sucesso de quem decide inclui o custo operacional gerado depois?”

Excelente.

🧠 Moral Hazard na arquitetura

Arquiteto escolhe:

tecnologia complexa.

Projeto fica moderno.

Depois suporte:

escasso.

Arquiteto muda de iniciativa.

Ops fica.

Inclua:

operability review.

🧠 Operational Readiness Review

Antes de produção:

quem suporta?
skill existe?
tooling?
backup?
recovery?
monitoring?
cost?

Arquitetura não termina no diagrama.

☕ Caixa bonita com setas não atende pager

Muito menos às 03:00.

🧠 Runbook as Contract

Um bom runbook declara:

quem faz o quê.

Isso reduz:

“achei que o outro time faria.”

🧠 Moral Hazard + Diffusion

Quanto mais dependências:

mais fácil externalizar.

“DBA resolve.”

“Security verifica.”

“Ops monitora.”

No fim:

ninguém é dono do sistema inteiro.

Service ownership ajuda.

🧠 Product / Service Ownership

Uma pessoa ou equipe precisa olhar:

end-to-end.

Não executar tudo.

Mas possuir:

accountability do serviço.

Isso internaliza parte dos custos.

☕ Dono do serviço

Não significa:

faz tudo.

Significa:

não pode dizer “não é meu problema” para cada seta do diagrama.

🧠 Moral Hazard em bancos

Crédito é exemplo clássico.

Quem origina empréstimo pode receber benefício imediato.

Se risco for vendido ou transferido:

pode diminuir incentivo para avaliar cuidadosamente.

Esse tipo de desalinhamento ficou famoso em discussões sobre crises financeiras.

A estrutura importa:

origination versus retention of risk.

🧠 Analogia mainframe

Equipe cria transação.

Outro time processa.

Outro reconcilia.

Outro suporta.

Se criador não absorve custo:

pode gerar complexidade sem sentir.

Service costing ajuda.

☕ Cada interface “gratuita”

Custa:

monitoramento;

teste;

suporte;

incident response.

Torne visível.

🧠 Moral Hazard e observabilidade

Se incident cost é invisível para projeto:

ele não entra na decisão.

Então crie:

cost of incident.

Horas.

clientes.

receita.

Agora feedback econômico.

📊 Incident Cost Allocation

Não necessariamente cobrança financeira.

Mas:

INCIDENT:
4h outage

ENGINEERING HOURS:
96

CUSTOMER IMPACT:
X

REVENUE IMPACT:
Y

Mostre.

Incentivos ficam mais realistas.

🧠 Decision Journals

Antes:

“Big Bang é aceitável porque rollback é sólido.”

Depois:

falha.

Não deixe reescrever:

“Ninguém sabia.”

Registro ajuda accountability.

🧠 Hindsight Bias

Cuidado inverso.

Não julgue decisão apenas pelo resultado.

Se risco era conscientemente aceito e processo foi bom:

resultado ruim não prova irresponsabilidade.

Outcome Bias.

Moral Hazard exige analisar:

incentivo antes.

☕ Uma decisão pode ser arriscada sem ser irresponsável

Se:

risk owner sabe;

benefício justifica;

controles existem.

Muito importante.

🧠 Moral Hazard não é “qualquer risco tomado”

É:

risco incentivado pela separação entre decisão e consequência.

Essa definição evita banalização.

🧠 Risk Appetite

Se business aceita:

10% de risco

por benefício X,

e business também absorve consequência:

não é necessariamente Moral Hazard.

É decisão de risco.

🧠 Moral Hazard aparece quando:

benefício privado/local;

custo coletivo/externo.

Simplificando:

UPSIDE:
ME

DOWNSIDE:
US

☕ A versão corporativa

“Meu bônus, nosso incidente.”

Magnífico e terrível.

🧠 Moral Hazard em liderança

Líder promete prazo impossível.

Se sucesso:

reconhecimento.

Se falha:

equipe “não entregou”.

Incentivo claro.

Por isso metas precisam:

accountability bidirecional.

🧠 Psychological Contract

Se líderes sempre externalizam custo:

equipes deixam de confiar.

Então Moral Hazard também destrói:

cultura.

🧠 Burnout externality

Prazo agressivo.

Gestão recebe entrega.

Equipe paga:

horas;

burnout.

Se custo humano não entra:

decisão parece barata.

☕ Toda estimativa tem alguém dormindo atrás dela

Às vezes literalmente.

🧠 Sustainable Pace

Não é luxo.

É internalizar custo.

Se entrega depende:

sempre de horas extras,

TCO está sendo escondido.

🧠 Moral Hazard + Present Bias

Ganho trimestral.

Custo em seis meses.

Executivo talvez já seja medido por:

trimestre.

Incentivo estrutural para:

curto prazo.

Governança precisa:

métricas de longo prazo.

📈 Long-term KPIs

Reliability.

Debt.

Retention.

Customer trust.

Não apenas:

delivery.

🧠 Moral Hazard em segurança de acesso

Gestor pede:

acesso amplo.

Benefício:

velocidade.

Security assume:

risco.

Se gestor não sente consequência de breach:

pode pedir acesso excessivo.

Least privilege reduz isso por arquitetura.

🔐 Guardrails

Em vez de:

“por favor, peça só o necessário.”

Sistema limita.

Porque incentivo humano pode ser:

“me dê tudo para não depender de ninguém.”

☕ `SPECIAL` no RACF para resolver ticket pequeno

Talvez um pouco exagerado.

Só um pouco.

🧠 Strong Controls versus incentives

Quando Moral Hazard é forte:

não dependa só de:

boas intenções.

Use:

limits;
audit;
approvals;
segregation of duties.

Mas proporcionalmente.

Need for Control continua espreitando.

🧠 Moral Hazard + Need for Control

Descobrimos incentivos ruins.

Resposta:

40 approvals.

Cuidado.

A solução ideal é:

alinhar incentivos e usar guardrails fortes onde necessário.

Não burocracia infinita.

🧠 Incentive alignment > paperwork

Se fornecedor ganha mais quando:

qualidade melhora,

melhor.

Se só adicionarmos:

relatórios,

talvez não mude comportamento.

🎯 Pergunta Bellacosa nº 5

“O comportamento arriscado é racional dentro dos incentivos que nós mesmos criamos?”

Fantástica.

Se sim:

não adianta palestra.

Mude sistema.

🧠 “Treinamento” como solução preguiçosa

Equipe sempre pula etapa porque:

prazo impossível.

Empresa:

“Treinamento de compliance.”

Nada muda.

Porque incentivo continua.

Moral Hazard não é resolvido por PowerPoint.

☕ Incentivo vence cartaz motivacional por nocaute técnico

Quase sempre.

🧠 Mechanism Design

Termo econômico mais avançado:

projetar regras e incentivos para induzir resultados desejáveis.

Em TI:

se você quer:

qualidade,

inclua qualidade no sucesso.

Se quer:

operabilidade,

faça equipe participar do run.

Se quer:

custo eficiente,

mostre custo.

🧠 Error Budgets

SRE outra vez.

Equipe pode inovar.

Mas se reliability cai:

budget acaba.

Agora quem gera risco também encontra limite.

Excelente alinhamento.

☕ Você pode gastar risco

Mas a conta aparece.

Isso é bonito.

🧠 Chargeback / Showback

Uso de recurso fica visível.

Não necessariamente para punir.

Mas para internalizar:

consequência.

🧠 On-call ownership

Mesmo princípio.

Construiu?

Receba feedback.

Isso muda decisões de design.

🧠 Shared KPIs

Dev + Ops:

mesmo SLO.

Agora:

não existe benefício de entregar feature derrubando reliability.

Objetivo compartilhado reduz conflito.

☕ DevOps no sentido profundo

Não é só:

pipeline.

É:

reduzir fronteiras onde um time captura benefício e outro absorve consequência.

Isso encaixa perfeitamente com Moral Hazard.

🧠 Silo incentives

Dev:

delivery.

Ops:

stability.

Security:

zero findings.

Business:

revenue.

Cada silo pode otimizar localmente.

Service-level objectives ajudam criar:

visão comum.

🧠 Moral Hazard e Zero-Risk Bias

Curioso.

Security pode exigir:

zero risco

porque custo da fricção cai no Dev.

Dev pode exigir:

velocidade

porque custo do incidente cai no Ops.

Cada time otimiza:

o que recebe benefício.

Sistema inteiro sofre.

☕ Todo departamento consegue produzir uma solução perfeita

Para o próprio dashboard.

🧠 End-to-End Governance

Pergunte:

como decisão afeta:

cliente;

infra;

security;

support;

finance.

Multi-perspective review.

📋 Checklist anti-Moral Hazard

[ ] Quem toma a decisão?

[ ] Quem recebe o benefício se der certo?

[ ] Quem paga o custo se der errado?

[ ] Esses grupos são os mesmos?

[ ] O executor está assumindo risco decidido por outra pessoa?

[ ] O risk owner está explícito?

[ ] Existe incentivo para aumentar risco?

[ ] O contrato recompensa qualidade, não apenas volume?

[ ] O projeto continua responsável após Go-Live?

[ ] O custo operacional entra na decisão?

[ ] O serviço possui owner end-to-end?

[ ] Existe shared KPI entre Dev, Ops e negócio?

[ ] Estamos usando seguro, SLA ou rollback como licença para assumir risco?

[ ] O humano realmente decide ou só assina?

[ ] Há externalidades para outros times?

🧪 Como combater Moral Hazard — passo a passo

Passo 1 — Mapeie benefício e consequência

Quem ganha?

Quem perde?

Passo 2 — Identifique o risk owner

Nome explícito.

Passo 3 — Aproxime decisão e operação

Hypercare.

On-call.

Passo 4 — Ajuste métricas

Não recompense só velocidade.

Passo 5 — Mostre custos ocultos

Incident hours.

Capacity.

Support.

Passo 6 — Crie shared KPIs

Reliability + delivery.

Passo 7 — Use guardrails técnicos

Least privilege.

Canary.

Passo 8 — Melhore contratos

Alinhe qualidade e resultado.

Passo 9 — Faça post-implementation review

Não encerre projeto no deploy.

Passo 10 — Revise incentivos após incidentes

Pergunte:

o comportamento era previsível dadas as regras?

🧠 O teste do contador de consequências

Uma técnica Bellacosa.

Antes da decisão:

IF SUCCESS:
Who benefits?

IF FAILURE:
Who works overnight?

Who loses money?

Who gets blamed?

Who pays?

Se respostas forem completamente diferentes:

investigue Moral Hazard.

☕ O teste das 03:00

Pergunta simples:

“Quem estará acordado às três da manhã se isso der errado?”

Depois:

“Essa pessoa participou da decisão?”

Se não:

há algo para revisar.

🧠 Moral Hazard e incident ownership

Mudança pedida por:

Business.

Aprovada por:

Project.

Executada por:

Ops.

Falha.

Todos precisam:

participar do post-mortem.

Não apenas Ops.

🧠 Postmortem attendance as feedback

Quem toma risco deveria ver:

consequência.

Isso ajusta modelo mental.

☕ Uma hora de RCA pode economizar muita confiança gratuita

Especialmente depois de sucesso fácil.

🧠 Moral Hazard e Near Misses

Se consequências negativas não materializam:

incentivos ruins podem permanecer invisíveis.

Near miss é oportunidade.

Pergunte:

quem teria pago?

Antes que aconteça.

🧠 Pre-mortem

Imagine falha.

Quem sofre?

Agora externalidades aparecem.

Muito útil.

🎯 Pergunta Bellacosa nº 6

“Se essa decisão desse errado amanhã, alguém que está aprovando hoje mudaria de opinião se tivesse que suportar pessoalmente o custo operacional?”

Excelente teste.

🧠 Moral Hazard na IA generativa

Programador gera código.

Se quebrar:

reviewer pega.

Então pode revisar menos o próprio output.

Copilot aumenta produtividade.

Mas talvez também:

externalize validation.

Reviewer vira filtro.

Moral Hazard micro.

☕ “O code review pega”

Frase perigosa.

Reviewer é barreira.

Não substituto para responsabilidade autoral.

🧠 CI/CD

Testes automáticos pegam.

Então:

menos teste local.

Talvez racional.

Mas se pipeline fica caro e falha mais:

o custo foi transferido.

Observe.

🧠 Quality at Source

Lean gosta de ideia:

qualidade onde trabalho ocorre.

Não empurre defeito para:

QA.

QA não deveria ser:

departamento de encontrar aquilo que Dev decidiu não verificar.

☕ QA não é lavanderia de bug

A camiseta está quase pronta.

🧠 Moral Hazard e handoffs

Toda fronteira organizacional pode:

externalizar custo.

Dev → QA.

QA → Ops.

Ops → Support.

Support → Customer.

Quanto mais handoffs:

mais risco de:

“problema do próximo.”

🧠 Flow Ownership

Mapeie cadeia.

Defeito gerado aqui.

Descoberto ali.

Quanto custa?

Shift-left tenta aproximar detecção da origem.

Além de técnica:

é alinhamento de incentivo.

🧠 Cost of Late Defect

Bug encontrado:

na IDE:

barato.

em teste:

mais caro.

em produção:

caríssimo.

Se criador não vê custo tardio:

Moral Hazard.

Feedback rápido ajuda.

☕ Compilador é um ótimo cobrador instantâneo

Erro na linha.

Pagamento imediato.

Por isso aprendemos.

🧠 COBOL e return codes

Programa devolve:

RC.

Chamador precisa:

tratar.

Não empurre erro silenciosamente.

Um RC=00 falso é quase:

Moral Hazard codificado.

Você captura benefício:

“job verde.”

Próximo step recebe:

dados errados.

💻 Exemplo

Ruim:

IF FILE-STATUS NOT = '00'
   DISPLAY 'ERRO'
   MOVE 0 TO RETURN-CODE
END-IF

Operação vê:

sucesso.

Erro vai adiante.

Melhor:

IF FILE-STATUS NOT = '00'
   DISPLAY 'ERRO'
   MOVE 12 TO RETURN-CODE
END-IF

Agora consequência volta para:

quem precisa decidir.

🧠 Greenwashing operacional

Job verde.

Negócio vermelho.

Se time é medido por:

RC=00,

pode haver incentivo para:

suprimir falhas.

Não faça.

☕ `$HASP395 ... CC 0000`

Não é absolvição espiritual.

Dados precisam estar corretos.

🧠 Error Handling and accountability

Erro precisa chegar:

ao lugar correto.

Não ser:

absorvido silenciosamente

para manter dashboard bonito.

🧠 Moral Hazard + Normalization of Deviance

Equipe empurra problema downstream.

Funciona.

Repete.

Outro time corrige manualmente.

Agora workaround vira serviço invisível.

Origem não sente custo.

Perfeito Moral Hazard.

☕ Maria corrige toda manhã

Enquanto sistema oficial acredita:

“processamento automático.”

Maria é arquitetura.

Mas não aparece no diagrama.

🧠 Manual Reconciliation

Se downstream sempre conserta:

upstream pode relaxar.

Então contabilize:

rework.

Mostre para origem.

📊 Rework Metrics

SOURCE SYSTEM A:
Errors generated: 400/month
Manual correction: 70h

Agora custo deixa de ser invisível.

🧠 Moral Hazard e observabilidade organizacional

Não basta monitorar CPU.

Monitore:

externalized work.

Incidents created by change.

Support tickets.

Rework.

Isso revela incentivos ruins.

🧠 Blame is not incentive alignment

Você pode culpar time.

Nada muda.

Se métrica e orçamento continuam iguais:

comportamento racional persiste.

Mude estrutura.

☕ Se sistema recompensa errado

não espere comportamento certo por patriotismo corporativo.

🧠 Leadership lesson

Uma boa pergunta de liderança:

“Que comportamento nosso sistema de metas está incentivando?”

Não:

“Por que as pessoas fazem isso?”

Isso conecta:

Moral Hazard;

Fundamental Attribution Error;

Actor-Observer Bias.

🧠 People respond to systems

Não deterministicamente.

Mas incentivos importam.

A melhor cultura não depende de:

santos.

Depende de:

regras razoáveis.

🧠 Ethics matters too

Claro.

Moral Hazard não elimina ética individual.

Uma pessoa pode agir corretamente mesmo com incentivo ruim.

Mas engenharia organizacional não deve depender:

exclusivamente

de heroísmo moral.

☕ Sistemas críticos gostam de pessoas boas

Mas preferem pessoas boas com bons controles.

🧠 Moral Hazard e Resilience

Resiliência pode paradoxalmente criar Moral Hazard.

Se Ops sempre salva:

projetos começam a confiar:

“Ops dá jeito.”

O heroísmo operacional vira seguro gratuito.

Perigoso.

🧠 Hero Culture

Operações salva.

Recebe aplauso.

Mas sistema nunca melhora.

Por quê?

Porque capacidade heroica absorve custo.

Deixe custo ficar visível.

☕ O sysprog que salva tudo

Pode estar involuntariamente subsidiando processo ruim.

Essa dói.

🧠 Remove hidden subsidies

Não pare de ajudar.

Mas registre:

quantas intervenções.

Quanto esforço.

Mostre.

Agora investimento em prevenção ganha business case.

🧠 Moral Hazard e staffing

Equipe pequena absorve tudo.

Outros times assumem:

“eles resolvem.”

Até turnover.

Agora risco explode.

Bus Factor.

🧠 Skills as Shared Risk

Se só uma pessoa sabe:

custo da dependência deve aparecer.

Não deixe:

“tem fulano”

virar mitigação permanente.

☕ “Fala com João”

Não é arquitetura HA.

🧠 Moral Hazard e decision rights

Quem possui direito de decisão deve possuir:

accountability proporcional.

Se não:

risco desalinhado.

🧠 RAPID / DACI

Frameworks de decisão podem ajudar.

Não precisamos decorar siglas.

Princípio:

quem decide precisa estar claro.

quem aceita risco precisa estar claro.

🧠 Stop-the-Line Authority

Qualquer pessoa detecta risco crítico:

pode parar.

Isso reduz Moral Hazard hierárquico.

Porque executor não precisa aceitar risco imposto sem voz.

☕ Toyota encontra TARDIS

Puxou Andon.

Parou linha.

Doctor aprovaria.

🧠 Psychological Safety again

Se júnior diz:

“isso é arriscado”

e é ignorado,

risk owner precisa estar explícito.

Caso contrário:

decisão vira:

“todo mundo concordou.”

Groupthink.

📋 Bellacosa Moral Hazard Decision Card

DECISION:
________________________

UPSIDE:
________________________

WHO RECEIVES UPSIDE?
________________________

DOWNSIDE:
________________________

WHO BEARS DOWNSIDE?
________________________

RISK OWNER:
________________________

EXECUTOR:
________________________

ROLLBACK OWNER:
________________________

Simples.

Poderoso.

🧠 Accountability Triangle

Podemos imaginar:

DECISION
   /\
  /  \
BENEFIT — CONSEQUENCE

Quanto mais afastados:

mais Moral Hazard possível.

🧠 Alinhe o triângulo

Quem decide:

entende benefício.

Entende consequência.

Participa da revisão.

Isso melhora decisões.

☕ Decisão sem consequência é teoria

Consequência sem poder de decisão é ressentimento.

Excelente.

🧠 Governance madura

Boa governança tenta evitar:

dois extremos.

Extremo 1

Ninguém pode decidir.

Need for Control.

Extremo 2

Quem decide nunca paga consequência.

Moral Hazard.

O equilíbrio:

autonomia com accountability.

🧠 Guardrails + Ownership

Permita:

decidir dentro de limites.

Mas resultado:

continua pertencendo ao serviço.

Essa talvez seja uma das melhores formas.

🧠 Product Teams

Equipes end-to-end reduzem:

handoffs.

Externalidades.

Não eliminam.

Mas diminuem fronteira Dev/Ops.

☕ “Não é meu problema”

Quanto menos vezes essa frase cabe na arquitetura:

melhor.

🧠 Moral Hazard + Zero-Risk Bias + Risk Compensation

Nosso trio recente:

Zero-Risk Bias

“Quero eliminar risco.”

Risk Compensation

“Agora estou protegido, posso arriscar mais.”

Moral Hazard

“E parte do custo nem será meu.”

Agora imagine:

rollback;

seguro;

SLA;

Ops heroico.

Pode surgir:

overconfidence institucional.

🧠 Illusion of Control entra novamente

“Se falhar, temos mecanismos.”

Talvez.

Mas:

quem paga cada falha?

quantas falhas estamos dispostos a gerar?

🧠 Risk Budget com Owner

Erro budget é útil porque:

permite risco.

Mas deixa:

limite visível.

Se time consome:

para.

Isso internaliza.

☕ O risco finalmente recebeu extrato bancário

Bonito.

🧠 Moral Hazard e regulatory bailout

Em finanças, Moral Hazard é frequentemente discutido quando instituições acreditam que poderão ser resgatadas se decisões arriscadas produzirem perdas sistêmicas.

A lógica:

se upside fica com a instituição

e downside extremo pode ser socializado,

incentivo pode mudar.

No mainframe corporativo:

escala menor.

Mas estrutura parecida:

benefício local, custo coletivo.

🧠 “Too Important to Fail”

Sistema crítico.

Todos sabem:

se falhar, organização inteira mobiliza.

Então projeto pode inconscientemente pensar:

“Alguém resolverá.”

Quanto mais crítico:

mais recursos de salvamento.

Paradoxalmente:

pode aumentar tolerância a risco.

☕ O sistema VIP

Sempre tem vinte especialistas disponíveis.

Então ninguém investe em automatizar recuperação.

Até um dia:

não estão.

🧠 Heroic Backstop

Especialista veterano vira:

seguro informal.

Novatos arriscam mais porque:

“se der ruim, chama ele.”

Risk Compensation + Moral Hazard.

Treinamento precisa:

usar mentor,

não depender dele como airbag humano.

🧠 Controlled Escalation

Escalar é certo.

Mas preserve:

responsabilidade por aprender.

Depois:

review.

Não apenas:

“o sênior resolveu.”

🎯 Pergunta Bellacosa nº 7

“Estamos tratando a competência de alguém como uma proteção gratuita que nos permite manter um processo ruim?”

Excelente.

🧠 Moral Hazard e root cause

RCA deveria perguntar:

“Que incentivos tornaram esta decisão razoável?”

Não apenas:

“quem errou?”

Se time sempre faz change grande porque:

só mudanças grandes recebem atenção executiva,

incentivo estranho.

🧠 Organizational Economics

Todo processo tem:

economia.

Tempo.

Status.

Bônus.

Fricção.

Pessoas respondem.

Mainframe não existe fora da organização.

☕ O JCL roda em z/OS

Mas a decisão de rodá-lo roda em seres humanos.

🧠 Step-by-step anti-Moral Hazard em uma War Room

Antes da mudança

Defina:

owner.

Risco.

Conseqüência.

Durante

Executor pode parar.

Depois

Owner participa do resultado.

Após incidente

Revise incentivos.

Simples.

🧪 Exemplo completo

Mudança:

DB2 schema.

Benefício:

projeto entrega.

Risco:

rollback difícil.

Decisão anterior:

projeto decide.

Ops executa.

Melhoria:

DECISION OWNER:
Application Service Owner

RISK ACCEPTANCE:
Business

EXECUTION:
DBA

HYPERCARE:
Dev + DBA + Ops

SUCCESS KPI:
Business + Reliability

Agora:

benefício e consequence closer.

🧠 Moral Hazard não desaparece

Nenhum desenho alinha tudo perfeitamente.

Mas podemos:

reduzir.

Dar visibilidade.

Criar accountability.

☕ Zero Moral Hazard

Cuidado.

Zero-Risk Bias está ouvindo.

🧠 Curiosidade: o termo

A expressão “moral hazard” vem de longa tradição em seguros e economia.

Historicamente, havia preocupação de que proteção contra perdas pudesse alterar comportamento.

Com o tempo, o conceito se tornou central em:

economia da informação;

contratos;

finanças.

Hoje é útil para pensar qualquer situação onde:

a exposição à consequência muda os incentivos de quem toma risco.

Inclusive nossa querida War Room.

🧠 Information Asymmetry

Outro ingrediente:

quem toma decisão pode saber mais sobre:

risco

do que quem paga.

Exemplo:

fornecedor conhece limitação.

Cliente não.

Se contrato não exige transparência:

Moral Hazard aumenta.

☕ O famoso:

“Isso nunca aconteceu.”

Pergunta:

“Nos testes de vocês?”

Informação importa.

🧠 Observability between organizations

SLA sem telemetria compartilhada:

disputa.

Fornecedor:

“não foi conosco.”

Cliente:

“foi.”

Shared metrics ajudam.

🧠 Moral Hazard e black boxes

Quanto menos visível processo do fornecedor:

mais difícil alinhar.

Contratos precisam:

auditability.

Mas sem virar Need for Control infinito.

🧠 Trust but verify

De novo:

confiança.

Auditabilidade.

Incentivos.

Três elementos.

📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Moral Hazard ocorre quando quem assume um risco não suporta integralmente suas consequências.

Não significa necessariamente falta de ética; frequentemente é um problema de desenho de incentivos.

Risk Compensation fala da mudança de comportamento quando percebemos mais proteção; Moral Hazard acrescenta a questão de quem paga o downside.

Benefício local e custo coletivo são um sinal clássico.

SLAs, seguros, rollback, fornecedores e times de suporte não eliminam risco; podem transferir parte da consequência.

Outsourcing de execução não é outsourcing automático de accountability.

Projetos deveriam continuar ligados ao resultado após o Go-Live.

Shared KPIs entre Dev, Ops e negócio ajudam a reduzir externalização de custos.

On-call, hypercare, showback e post-implementation reviews aproximam decisão e consequência.

HITL pode virar teatro de responsabilidade se o humano não tiver tempo, informação ou poder real para decidir.

Accountability não é culpa.

E principalmente:

se quem decide recebe a recompensa e quem executa, suporta ou corrige recebe a maior parte do prejuízo, não espere que palestras sobre responsabilidade consertem o problema — mude os incentivos.

🕰️ De volta às 08:37

O gerente ainda quer:

Big Bang.

Nosso jovem pergunta:

— Se fizermos, quem fica no hypercare?

— Operações.

— Só?

— Bem...

— Quem definiu o escopo?

— Projeto.

— Então projeto fica também?

Silêncio.

O Doctor olha para o gerente.

— É uma excelente pergunta.

O gerente pensa.

— Tudo bem. Projeto fica.

— E quem aprova risco?

— Business owner.

— E rollback?

— DBA e aplicação juntos.

— Agora podemos fazer Big Bang?

Nosso jovem responde:

— Agora podemos discutir Big Bang com as pessoas que realmente carregarão o resultado.

Isso muda a conversa.

🔧 A decisão muda

Depois de revisar:

impacto;

rollback;

staffing,

decidem:

não fazer Big Bang.

Dividem:

3 waves.

Canary.

Hypercare conjunto.

Por quê?

Curiosamente:

quando as pessoas que capturavam o benefício também começaram a enxergar e carregar o custo...

o apetite por risco mudou.

Não precisou sermão.

Só:

incentivo alinhado.

🥚 Easter Egg final

Na manhã seguinte aparece:

BELLACOSA.BIAS(MORAL-HAZARD)

Dentro:

       IF DECISION-OWNER NOT = RISK-OWNER
           PERFORM CHECK-INCENTIVES
       END-IF.

       IF BENEFIT-GOES-LOCAL
          AND COST-GOES-GLOBAL
           PERFORM ALIGN-ACCOUNTABILITY
       END-IF.

       IF SOMEONE-SAYS
          'OPS-WILL-FIX-IT'
           PERFORM INVITE-THEM-TO-HYPERCARE
       END-IF.

Comentário:

* MY UPSIDE.
* YOUR DOWNSIDE.
* BAD DESIGN.

Outro:

* OUTSOURCING
* DOES NOT DELETE
* ACCOUNTABILITY.

Outro:

* SLA CREDIT
* DOES NOT RESTORE
* LOST TIME.

Mais um:

* WHO DECIDES?
* WHO PAYS?

E naturalmente:

* DALEKS PREFER
* OTHER SPECIES
* TO PAY THE DOWNSIDE.

Nosso jovem fecha o membro.

Horas depois alguém propõe:

— Podemos cortar os testes finais. Se der problema, QA pega.

Ele responde:

— Talvez QA pegue.

— Então?

— Quem ganha o prazo economizado?

— Nós.

— E quem recebe o retrabalho?

Silêncio.

— QA.

— Então antes de cortar...

Pausa.

— vamos descobrir se estamos realmente removendo trabalho ou apenas mandando nossa conta para o próximo time.

A mudança continua.

Os testes também.

Mais tarde, outra automação permite remover parte deles com segurança.

Desta vez:

dados justificam.

Não terceirização silenciosa de risco.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica uma última frase:

Uma organização aprende de verdade quando quem escolhe o risco não consegue simplesmente despachar a consequência para outra fila.

E talvez Moral Hazard possa ser resumido em uma pergunta muito simples:

“Se você tivesse que pagar integralmente a conta dessa decisão, ainda escolheria a mesma coisa?”

Se a resposta mudar...

há algo importante escondido no desenho do sistema.

☕🌀

Next stop: Principal-Agent Problem — quando quem toma uma decisão em nome da organização possui objetivos, informações e incentivos diferentes daqueles de quem realmente depende do resultado.

Translate

quinta-feira, 13 de dezembro de 2012