 |
| Bellacosa Mainframe e a diffusion of responsibility |
☕ Um Café no Bellacosa Mainframe
Diffusion of Responsibility: Doctor Who, COBOL e o Dia em que Todo Mundo Viu o Alerta — Mas Ninguém Era o Responsável
Uma viagem pela TARDIS dos incidentes para entender por que quanto mais pessoas recebem um problema, mais fácil pode ser acreditar que outra pessoa já está cuidando dele
08:57.
Segunda-feira.
Café quente.
Produção funcionando.
O Teams tranquilo.
Uma manhã suspeitosamente agradável.
Até que surge:
09:01:17
WARNING
PAYMENT QUEUE DEPTH > THRESHOLD
O monitoramento envia automaticamente a mensagem para:
Operações.
Aplicação.
Middleware.
CICS.
DBA.
Infraestrutura.
Gestão.
Suporte.
Vinte e três pessoas recebem.
Excelente.
Um sistema moderno.
Comunicação perfeita.
Visibilidade ampla.
09:04.
A fila continua crescendo.
QUEUE DEPTH: 4.312
João, da aplicação, vê.
Pensa:
“Operação certamente está olhando.”
Maria, de operações, vê.
Pensa:
“Isso parece problema da aplicação.”
Carlos, de middleware, recebe.
Pensa:
“Se for MQ de verdade, alguém vai me chamar.”
O gerente recebe no celular.
Pensa:
“A equipe técnica já está atuando.”
Nosso jovem programador COBOL vê a mensagem.
Olha a quantidade de pessoas no canal.
Vinte e três.
Pensa:
“Não vou atrapalhar. Certamente alguém mais experiente está cuidando.”
09:12.
QUEUE DEPTH: 12.891
Ninguém está cuidando.
09:17.
TIMEOUT RATE: +320%
09:19.
Usuários começam a reclamar.
09:22.
Alguém pergunta no Teams:
“Pessoal, alguém olhando isso?”
Silêncio.
Então...
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se no corredor.
A porta abre.
O Doctor sai.
Olha para o painel.
Olha para o Teams.
Conta os participantes.
— Vinte e três pessoas receberam o alerta?
— Sim.
— Quantas estão investigando?
Silêncio.
— Interessante.
Nosso programador responde:
— Achei que alguém estivesse.
O Doctor aponta para os demais.
— Eles também.
Pausa.
— Vocês construíram uma equipe tão grande que conseguiram criar uma pessoa imaginária chamada “alguém”.
Bem-vindo ao:
Diffusion of Responsibility
Ou:
Difusão de Responsabilidade
O fenômeno pelo qual a presença de várias pessoas pode reduzir a sensação individual de responsabilidade para agir.
Quanto mais fácil pensar:
“Outra pessoa fará”
mais perigoso fica descobrir que todas as outras pessoas pensaram exatamente a mesma coisa.
🌀 A TARDIS já colecionou muitos monstros
Nossa jornada está ficando perigosamente parecida com um bestiário de sistemas complexos.
Começamos pelo Swiss Cheese Model.
Aprendemos que barreiras imperfeitas podem falhar simultaneamente.
Depois:
Normalization of Deviance — aquilo que estava errado vai ficando familiar.
Hindsight Bias — depois do desastre todo mundo acredita que deveria ter percebido.
Confirmation Bias — encontramos aquilo que procuramos.
Anchoring Bias — a primeira explicação prende nossa atenção.
Groupthink — pessoas concordam porque as outras concordam.
Authority Gradient — alguém percebe, mas não consegue confrontar autoridade.
Plan Continuation Bias — continuamos porque já começamos.
Alarm Fatigue — recebemos tantos alertas que deixamos de ouvi-los.
Automation Bias — acreditamos demais na máquina.
Drift Into Failure — pequenas adaptações empurram todo o sistema lentamente para condições perigosas.
Agora encontramos outra peça.
O alerta funciona.
Não existe necessariamente fadiga.
A máquina detectou corretamente.
As pessoas viram.
O problema foi distribuído para tanta gente que a responsabilidade ficou...
distribuída também.
🧠 O que é Diffusion of Responsibility?
A ideia é bastante simples.
Imagine que você esteja sozinho numa sala.
Um alarme começa.
Você pensa:
“Preciso fazer alguma coisa.”
Agora imagine vinte pessoas.
O mesmo alarme aparece.
Você pode pensar:
“Alguém mais qualificado vai cuidar.”
Cada pessoa individualmente sente uma fração menor da responsabilidade.
Não precisamos literalmente calcular:
RESPONSABILIDADE / NÚMERO DE PESSOAS
A psicologia não funciona como COBOL.
Mas a sensação pode se comportar aproximadamente dessa maneira.
Uma responsabilidade claramente individual:
“Vagner, investigue este alerta.”
é muito diferente de:
“Pessoal, alguém consegue olhar?”
A segunda frase acabou de criar um funcionário imaginário chamado:
Alguém.
👥 O famoso Bystander Effect
Diffusion of Responsibility é fortemente relacionada ao chamado Bystander Effect, ou efeito espectador.
Estudos clássicos da psicologia social associados a John Darley e Bibb Latané investigaram por que indivíduos podem ter menor probabilidade de ajudar em certas situações quando outras pessoas também estão presentes.
A lógica psicológica inclui elementos como:
“Outra pessoa deve agir.”
ou:
“Se ninguém está reagindo, talvez não seja grave.”
Isso é fascinante porque se conecta imediatamente aos incidentes.
Uma War Room possui muitos espectadores.
Todos tecnicamente capazes.
Todos informados.
Mas capacidade coletiva não garante ação individual.
🚨 O alerta para “todos”
Existe uma frase operacional que deveria causar desconforto:
“Mandamos para todo mundo.”
Parece robusto.
Mas quem é o responsável?
Resposta:
“Todo mundo.”
Então talvez tenhamos um problema.
Porque:
Responsabilidade de todos pode virar responsabilidade de ninguém.
☕ Bellacosa Mainframe: o job que ninguém assumiu
Imagine:
JOB ABC123 ABENDED S0C7
Scheduler envia:
Aplicação.
Produção.
Suporte.
DBA.
Operador.
Email de distribuição.
Teams.
Telefone automático.
Fantástico.
Agora:
Operação pensa:
aplicação está vendo.
Aplicação pensa:
operador deve ter iniciado restart.
DBA pensa:
não parece Db2.
Gestão pensa:
equipes técnicas receberam.
Resultado:
35 minutos.
Nenhuma ação.
O problema não foi falta de notificação.
Foi falta de:
ownership.
🏷️ Ownership muda tudo
Compare:
ALERT:
ABC123 S0C7
RECIPIENTS:
OPERATIONS@EMPRESA
com:
ALERT:
ABC123 S0C7
OWNER:
BATCH PAYMENTS TEAM
ON-CALL:
MARIA
ACK REQUIRED: 5 MIN
ESCALATE AFTER: 10 MIN
A segunda versão responde à pergunta:
Quem precisa agir agora?
Isso vale ouro.
🧠 Informação e responsabilidade são coisas diferentes
Enviar informação não significa atribuir responsabilidade.
Você pode informar 200 pessoas.
Ainda precisa existir alguém dizendo:
“Eu tenho este incidente.”
Isso é uma distinção maravilhosa para quem começa em TI.
Broadcast
“Todos precisam saber.”
Assignment
“Você precisa agir.”
Não confunda.
👻 Easter Egg nº 1 — O companion imaginário
O Doctor pergunta:
— Quem deveria apertar o botão?
Companion A:
— Achei que fosse B.
Companion B:
— Eu achei que fosse o Doctor.
Doctor:
— E eu estava ocupado impedindo a destruição do espaço-tempo.
Pausa.
— Talvez devêssemos começar a colocar nomes nos botões.
TI aprendeu a mesma lição.
Ou deveria.
📣 “Alguém pode verificar?”
Essa frase aparece muito em chats operacionais:
“Alguém consegue verificar CICS?”
Cinco pessoas leem.
Ninguém responde.
Melhor:
“Carlos, consegue verificar CICS e retornar em 10 minutos?”
Agora temos:
responsável;
atividade;
expectativa.
Se Carlos não puder:
— Não consigo. Maria assume?
Responsabilidade transferida explicitamente.
🏃 O bastão precisa ser entregue
Imagine corrida de revezamento.
Não basta:
“Acho que o próximo corredor sabe que deve correr.”
Existe entrega do bastão.
Em incidentes deveria ser semelhante:
OWNER: CARLOS
↓
HANDOFF
↓
OWNER: MARIA
Nunca:
CARLOS
↓
“PESSOAL”
↓
???
O ??? é onde incidentes moram.
🔁 Handoff é uma transação
Para um programador COBOL, pense como uma transação.
Transferência de responsabilidade deveria possuir confirmação.
CARLOS:
“Maria, transfiro análise de MQ para você.”
MARIA:
“Recebido. Assumo MQ.”
Commit.
Sem confirmação:
rollback psicológico.
Ninguém sabe quem possui.
🧠 Two Generals Problem corporativo
Em sistemas distribuídos existe toda uma discussão sobre confirmação e coordenação.
Na organização temos versão humana:
Pessoa A:
“Mandei mensagem.”
Pessoa B:
“Não vi.”
Pessoa A:
“Mas mandei.”
Tecnicamente:
mensagem transmitida.
Operacionalmente:
responsabilidade não assumida.
Por isso acknowledgement importa.
✅ ACK novamente
No capítulo de Alarm Fatigue aprendemos:
ACK ≠ RESOLVED
Agora adicionamos:
DELIVERED ≠ OWNED
E:
READ ≠ ACTION
Essas três inequações deveriam estar na parede da War Room.
🧀 Diffusion of Responsibility encontra o Swiss Cheese
Uma fatia importante de segurança é:
resposta humana.
Monitor detecta.
Equipe recebe.
Parece barreira robusta.
Mas:
ninguém possui ownership.
Temos um buraco.
Pior.
Todos acreditam que a barreira existe.
Isso produz falsa confiança.
🚨 Alarm Fatigue + Diffusion of Responsibility
Agora os dois monstros se encontram.
Quatro mil alertas.
Todos enviados para vinte pessoas.
Cada pessoa pensa:
alguém pegará os importantes.
Perfeito.
Temos ruído distribuído para responsabilidade distribuída.
O verdadeiro alerta entra.
E desaparece.
🤖 Automation Bias + Diffusion of Responsibility
Sistema automático cria ticket.
Ótimo.
Ticket entra numa fila geral.
Todos confiam:
sistema direcionará corretamente.
Mas regra de roteamento está errada.
Ticket permanece sem owner.
Como foi criado automaticamente, todos assumem que o processo automático também garantiu tratamento.
Não garantiu.
Automação aumentou sensação de segurança.
Ownership continuou vazio.
👥 Groupthink também aparece
Equipe inteira vê ninguém reagindo.
Cada pessoa interpreta silêncio como:
provavelmente não é grave.
Esse mecanismo é próximo daquilo que psicólogos chamam de pluralistic ignorance.
Cada pessoa observa a ausência de reação das outras e usa isso como informação.
Internamente:
“Estou preocupado.”
Externamente:
ninguém age.
Então todos concluem:
“Talvez eu esteja exagerando.”
Agora o silêncio se autoalimenta.
😐 Pluralistic Ignorance
Imagine oito pessoas numa sala.
Todas sentem cheiro estranho.
Cada uma olha para as outras.
Ninguém reage.
Cada uma pensa:
“Se fosse perigoso, alguém estaria preocupado.”
Mas todos estão preocupados.
Fantástico.
Agora troque cheiro por:
QUEUE DEPTH +400%
War Room:
ninguém fala.
Mesmo mecanismo.
⚓ Anchoring Bias pode definir o dono errado
Primeiro chamado diz:
“Problema de rede.”
Todos:
— Network team cuidará.
A rede pensa:
— Não é nossa.
Mas ninguém realoca formalmente.
Agora incidente fica órfão.
O título inicial ancorou não apenas diagnóstico.
Ancorou ownership.
🪜 Authority Gradient e responsabilidade
Júnior percebe:
— Ninguém está olhando isso.
Mas pensa:
“O gerente certamente sabe.”
Ou:
“O Incident Commander já deve ter atribuído.”
Não pergunta.
Authority Gradient transforma dúvida em silêncio.
▶️ Plan Continuation Bias
Mudança em andamento.
Alerta surge.
Todos assumem que “alguém da validação” está analisando.
Ninguém interrompe plano.
Continua.
Mais um exemplo de como nossos monstros cooperam.
🌀 Drift Into Failure
Difusão de responsabilidade também pode se tornar estrutural ao longo do tempo.
Equipe pequena:
ownership claro.
Empresa cresce.
Mais times.
Mais fornecedores.
Mais camadas.
Agora:
Aplicação.
Plataforma.
Infra.
Cloud.
Mainframe.
Middleware.
Rede.
Segurança.
Fornecedor A.
Fornecedor B.
Quem é dono do fluxo ponta a ponta?
Resposta:
depende.
Essa resposta merece investigação.
🕸️ Complexidade organizacional cria fronteiras
Muitos incidentes vivem nas interfaces.
Time A:
meu componente está verde.
Time B:
o meu também.
Time C:
idem.
Usuário:
não funciona.
Cada equipe possui parte.
Ninguém possui jornada completa.
Isso é perigoso.
🗺️ Component Ownership versus Service Ownership
Você pode possuir:
CICS.
Db2.
MQ.
API.
Mas quem possui:
Pagamento do cliente?
Isso é diferente.
Serviços ponta a ponta precisam de responsabilidade além de componentes.
Caso contrário:
todos os componentes verdes.
Cliente vermelho.
💻 O COBOL está funcionando!
Programador:
— Meu programa retornou RC=00.
DBA:
— Db2 normal.
MQ:
— Mensagem entregue.
API:
— HTTP 200.
Cliente:
— Dinheiro não chegou.
Cada profissional está correto localmente.
O sistema está errado globalmente.
Drift Into Failure nos ensinou sobre racionalidade local.
Diffusion of Responsibility acrescenta:
ninguém pode estar olhando o todo.
🧠 O problema dos silos
Silos organizacionais não são apenas problema burocrático.
São risco técnico.
Quanto mais fragmentado:
mais handoffs;
mais fronteiras;
mais possibilidade de:
“não é comigo.”
Essa frase deveria ser tratada como evento operacional.
🚪 “Not my problem”
Às vezes realmente não é responsabilidade daquele time.
Tudo bem.
Mas resposta madura não é:
“Não é nosso.”
É:
“Não é nosso componente. Estou transferindo para X e confirmando que assumiram.”
O incidente precisa sair de uma mão e chegar a outra.
Não cair no chão.
🏷️ Incident Commander
É exatamente por isso que o papel de Incident Commander pode ser tão útil.
Não precisa ser o maior especialista técnico.
Sua função é garantir:
quem investiga o quê;
quem possui a próxima ação;
qual prazo;
qual hipótese;
qual decisão;
qual escalonamento.
Ou seja:
o Incident Commander combate difusão de responsabilidade.
🎬 War Room sem direção
Imagine:
15 especialistas falando.
Cada um executa alguma coisa.
Mas ninguém sabe:
quem decide;
quem registra;
quem atualiza;
quem comunica;
quem acompanha ação.
Isso não é equipe.
É multiplayer sem party leader.
E o boss está batendo.
🎮 Easter Egg nº 2 — Raid de RPG
Imagine uma raid.
Tank pensa:
healer vai puxar.
Healer pensa:
tank vai puxar.
DPS já começou.
Boss acorda.
Raid wipe.
No post-mortem:
“Quem puxou?”
Resposta:
“Ninguém.”
TI às vezes consegue reproduzir MMORPG com orçamento corporativo.
🧪 RACI pode ajudar — mas não salvar sozinho
Uma ferramenta conhecida:
RACI
Responsible.
Accountable.
Consulted.
Informed.
Pode ser útil para esclarecer funções.
Exemplo:
INCIDENTE DE PAGAMENTO
Responsible:
Payments Operations
Accountable:
Payments Manager
Consulted:
DB2, MQ, CICS
Informed:
Business, Service Desk
Muito melhor que:
todos envolvidos.
Mas cuidado.
Matriz no SharePoint não resolve automaticamente cultura.
Precisa refletir trabalho real.
🧠 Responsible versus Accountable
Uma distinção útil:
Responsible
faz o trabalho.
Accountable
responde pelo resultado e garante que exista dono.
Em incidentes críticos, alguém precisa possuir accountability.
Não necessariamente executar tudo.
📝 Single Threaded Owner
Outra ideia muito útil:
uma pessoa claramente responsável pela coordenação do problema.
Mesmo com dezenas de especialistas.
Não significa centralizar conhecimento.
Significa centralizar ownership.
🎯 Pergunta Bellacosa nº 1
Quando surgir incidente:
“Quem é o dono?”
Se resposta:
“A equipe.”
Pergunte novamente.
“Qual pessoa está coordenando?”
Nome.
🎯 Pergunta Bellacosa nº 2
Para cada atividade:
“Quem vai fazer e quando retorna?”
Não:
“Precisamos verificar MQ.”
Mas:
“Carlos verifica MQ e retorna às 09:30.”
Agora existe ação.
🎯 Pergunta Bellacosa nº 3
Depois de handoff:
“A outra pessoa confirmou que assumiu?”
Se não:
a responsabilidade ainda é sua.
Essa regra pode evitar muita coisa.
🎯 Pergunta Bellacosa nº 4
Quando dez pessoas recebem alerta:
“Quem precisa acordar por causa dele?”
Se ninguém:
talvez o alerta seja informativo.
Se alguém:
roteie diretamente.
🔔 Notifications devem refletir papéis
Nem todo mundo precisa pager.
Talvez:
Owner:
pager.
Especialistas:
Teams.
Gestão:
status periódico.
Usuários:
comunicação de impacto.
Um sistema que manda a mesma mensagem para todos não está necessariamente comunicando bem.
🧠 Broadcast cria espectadores
Quanto mais amplo o broadcast:
mais pessoas informadas.
Mas também pode criar:
mais espectadores passivos.
Se precisar de ação:
atribua.
🔥 Incêndio corporativo
Imagine prédio pegando fogo.
Mensagem:
“Pessoal, alguém chama os bombeiros?”
Você ficaria tranquilo?
Melhor:
“Maria, ligue para emergência. Carlos, evacue o andar. João, confirme.”
Incidentes precisam dessa clareza.
🛑 Role Assignment nos primeiros minutos
Uma War Room madura deveria rapidamente definir algo como:
INCIDENT COMMANDER: ANA
TECH LEAD: CARLOS
COMMS: JULIANA
SCRIBE: PEDRO
DB2: MARIA
MQ: ROBERTO
APPLICATION: LUCAS
Agora ninguém pergunta:
“Achei que alguém estava anotando.”
Temos Pedro.
Pobre Pedro.
Mas necessário.
✍️ O Scribe é mais importante do que parece
Durante crise:
ações acontecem rápido.
Sem registro:
hipóteses repetidas;
decisões esquecidas;
comandos duplicados;
handoffs confusos.
Scribe preserva memória coletiva.
Isso reduz difusão cognitiva.
📜 Decision Log novamente
09:13
Carlos assume MQ.
09:16
MQ channel healthy.
09:18
Maria verifica DB2 waits.
09:22
DB2 normal.
09:24
Hipótese muda para consumer.
Agora todo mundo sabe.
🚧 Evite investigação duplicada
Difusão de responsabilidade tem um primo estranho:
às vezes ninguém faz.
Outras vezes cinco pessoas fazem a mesma coisa.
Porque ninguém coordenou.
Resultado:
DBA investigado cinco vezes.
MQ ninguém olhou.
Ownership também evita duplicação.
🧮 Paralelismo precisa ser controlado
Mainframeiro entende paralelismo.
Você quer tarefas independentes.
THREAD A → DB2
THREAD B → MQ
THREAD C → APPLICATION
Não:
THREAD A → DB2
THREAD B → DB2
THREAD C → DB2
MQ → NINGUÉM
War Room também precisa scheduling.
📊 Action Board
Uma ferramenta incrivelmente simples:
AÇÃO OWNER PRAZO STATUS
MQ consumer Carlos 09:30 RUNNING
DB2 wait Maria 09:28 DONE
App logs João 09:32 RUNNING
Comms negócio Ana 09:35 OPEN
Acaba com boa parte da ambiguidade.
🧠 “Eu achei que...”
Uma frase favorita dos post-mortems:
“Eu achei que fulano estava fazendo.”
Alarmes.
Backups.
Validação.
Rollback.
Comunicação.
Esses “achei” são ouro investigativo.
Pergunte:
Por que o sistema permitiu que uma atividade crítica dependesse de suposição?
💾 Backup: o clássico
Todo mundo acredita:
infraestrutura faz backup.
Infra acredita:
aplicação valida restore.
Aplicação acredita:
backup é responsabilidade da infra.
Incidente.
Backup existe.
Restore nunca testado.
Diffusion of Responsibility mora feliz.
🔐 Segurança
Alerta de vulnerabilidade.
Security envia para aplicação.
Aplicação pensa:
plataforma corrigirá.
Plataforma:
código é aplicação.
90 dias depois:
continua aberto.
CVSS não liga para organograma.
🏦 Reconciliação financeira
Operação:
negócio valida valores.
Negócio:
TI valida processamento.
TI:
reconciliação é automática.
Automação:
erro.
Quem percebe?
Talvez o cliente.
Nunca faça do cliente seu mecanismo de observabilidade.
🧠 Customer as Monitor
Existe um anti-pattern terrível:
“Se der problema, usuário reclama.”
Isso significa:
cliente virou sistema de alerta.
Alarm Fatigue agradece.
Automation Bias agradece.
Diffusion of Responsibility também.
🤖 Agentes de IA e responsabilidade
Agora fica interessante.
Imagine múltiplos agentes:
Agent A analisa.
Agent B executa.
Agent C valida.
Quem é responsável pelo resultado?
Não diga:
“o agente.”
Responsabilidade organizacional continua humana.
Precisamos saber:
quem configurou;
quem autorizou;
quem monitora;
quem pode interromper;
quem responde por exceção.
🤖 Multi-Agent Diffusion
Agentes também podem criar versão tecnológica:
Agent A:
deleguei para B.
B:
classifiquei como responsabilidade de C.
C:
aguardando entrada de A.
Loop.
Nenhum humano percebe.
Então sistemas multiagentes precisam:
ownership;
state;
timeouts;
escalation;
orchestrator.
Viu como nossa teoria volta aos agentes?
🧭 Orchestrator como Incident Commander
Num sistema agentic:
orquestrador precisa saber:
quem está fazendo;
qual status;
quando expira;
quando escalar.
Exatamente como War Room.
Tecnologia muda.
Coordenação continua sendo coordenação.
⏰ Timeout de responsabilidade
Uma tarefa não deveria ficar eternamente:
STATUS: ASSIGNED
Sem resposta.
Defina timeout.
ACK REQUIRED: 5 MIN
ACTION UPDATE: 15 MIN
ESCALATE: 20 MIN
Responsabilidade precisa de relógio.
🧠 Escalation não é punição
Escalar significa:
a condição exige mais atenção.
Não:
alguém falhou moralmente.
Se escalonamento vira punição, pessoas escondem atraso.
Just Culture novamente.
🧪 Passo a passo para combater Diffusion of Responsibility
Passo 1 — Todo incidente precisa de owner
Uma pessoa.
Nome.
Não “time”.
Passo 2 — Toda ação precisa de owner
“Verificar banco”
não é ação completa.
Use:
“Maria verifica Db2 até 09:30.”
Passo 3 — Exija ACK
Assignment sem confirmação não terminou.
Passo 4 — Defina tempo
Responsabilidade sem deadline pode evaporar.
Passo 5 — Crie escalation path
Se owner não responde:
quem recebe?
Passo 6 — Separe FYI de ACTION REQUIRED
No assunto.
Na ferramenta.
Na cultura.
Passo 7 — Use Incident Commander
Principalmente em incidentes grandes.
Passo 8 — Registre handoffs
Não confie em memória.
Passo 9 — Audite filas sem owner
Tickets.
Alertas.
Vulnerabilidades.
Problemas.
Tudo que não possui dono é dívida operacional.
Passo 10 — Investigue “achei que alguém”
Toda vez que essa frase aparece no post-mortem, existe oportunidade de melhorar processo.
📬 FYI versus ACTION REQUIRED
Uma disciplina simples.
FYI:
Informação.
ACTION:
Pessoa específica precisa fazer algo.
Não misture.
Se tudo pede ação:
Alarm Fatigue.
Se nada especifica ação:
Diffusion of Responsibility.
🎯 O equilíbrio
Boa operação precisa de:
informação suficiente;
responsabilidade específica.
VISIBILIDADE AMPLA
+
OWNERSHIP CLARO
=
COORDENAÇÃO
Não precisamos esconder informação.
Precisamos evitar ambiguidade.
🧠 Dunbar não salva a War Room
Adicionar pessoas não aumenta indefinidamente capacidade.
Às vezes mais gente significa:
mais canais;
mais conversas;
mais suposições;
mais handoffs.
Existe custo de coordenação.
Um incidente com 50 pessoas pode ser mais difícil que com 10 especialistas bem organizados.
🚪 War Room precisa de porta
Nem todo mundo precisa falar.
Alguns podem acompanhar.
Roles:
core responders;
SMEs sob demanda;
stakeholders informados.
Isso reduz ruído.
🧠 Incident Command System
Estruturas de comando em emergência existem por uma razão:
quando tudo fica caótico, funções precisam ficar mais claras, não menos.
Tecnologia às vezes tenta resolver crise colocando cinquenta especialistas numa call.
Não é necessariamente coordenação.
Pode ser apenas Zoom cheio.
👻 Easter Egg nº 3 — 50 pessoas no Teams
War Room:
“Participants: 57”
Doctor:
— Quem está coordenando?
— Não sei.
— Quem está investigando MQ?
— Acho que alguém.
— Quem comunica usuários?
— Deve ter alguém.
Doctor:
— Então por que temos 57 pessoas?
Silêncio.
— Ah.
— O quê?
— Vocês estão usando quantidade como substituto de estrutura.
🧩 Diffusion of Responsibility no code review
PR com 12 reviewers.
Cada um pensa:
alguém fará review profundo.
Resultado:
12 approvals superficiais.
Compare com:
PRIMARY REVIEWER: Maria
SECURITY REVIEWER: Carlos
DB REVIEWER: Ana
Funções claras.
🧪 Testes
“Equipe é responsável pelos testes.”
Quem escreve?
Quem valida?
Quem dá sign-off?
Se ninguém sabe:
todo mundo pode acreditar que outra pessoa cobriu determinado cenário.
📚 Documentação
“Precisamos documentar.”
Todo mundo concorda.
Seis meses depois:
nenhum documento.
Por quê?
Porque tarefas coletivas abstratas não executam a si mesmas.
OWNER: João
DUE: sexta
A mágica administrativa.
🧠 Shared Responsibility precisa de fronteiras claras
Cloud popularizou expressão:
shared responsibility.
Importante.
Mas responsabilidade compartilhada não significa responsabilidade ambígua.
Precisamos saber:
provedor faz X.
cliente faz Y.
integração faz Z.
Toda fronteira precisa estar explícita.
☁️ “Achei que a cloud fazia backup”
Clássico.
Serviço fornece mecanismo.
Cliente precisa configurar.
Cliente pensa:
provider faz.
Incidente.
Surpresa.
Shared Responsibility mal compreendida vira Diffusion of Responsibility contratual.
🧠 Psychological Ownership
Quando alguém diz:
“Esse serviço é meu.”
normalmente presta mais atenção.
Isso é ownership psicológico.
Organizações maduras desenvolvem isso sem criar feudos.
Você quer:
“Eu cuido.”
Não:
“Só eu mexo.”
🚧 Ownership não pode virar silo
Cuidado.
Combater Diffusion of Responsibility não significa criar:
“Esse problema é seu, me deixa fora.”
Owner coordena.
Especialistas colaboram.
Responsabilidade clara + conhecimento distribuído.
Essa é a meta.
👨💻 Dica Bellacosa para o COBOL iniciante
Você encontra problema.
Manda no grupo:
“Pessoal, achei algo estranho.”
Não pare aí.
Se ninguém responder:
follow-up.
“Maria, você é owner dessa rotina? Posso abrir incidente e acompanhar?”
Ou assuma temporariamente:
“Vou iniciar análise e preciso de alguém de Db2.”
Não deixe descoberta importante evaporar em chat.
📢 Speak Up + Take Ownership
No Authority Gradient aprendemos a falar.
Agora precisamos aprender o próximo passo:
“Eu vi.”
não basta.
Talvez seja necessário:
“Eu assumo até transferir formalmente.”
Essa é uma poderosa mentalidade operacional.
🧠 Mas cuidado com heroísmo
Não queremos que uma pessoa assuma tudo.
Isso nos leva ao problema de heróis.
Owner não significa:
executar 27 tarefas.
Significa garantir que 27 tarefas possuam donos.
Essa diferença protege pessoas e sistemas.
🦸 Incident Commander não é Superman
Ele não resolve tudo.
Ele impede:
coisas esquecidas;
duplicação;
contradição;
responsabilidade órfã.
Orquestra.
Como JES para humanos.
😄 JES humano
Agora temos talvez um conceito digno do Bellacosa Mainframe:
Incident Commander é o JES da War Room.
Jobs chegam.
Prioridades.
Owners.
Estados.
Dependências.
O JES não executa o COBOL.
Coordena processamento.
Incident Commander também.
Há um Easter Egg mainframeiro que merecia existir.
🔄 Handoff de turno
Diffusion of Responsibility fica especialmente perigosa em mudança de turno.
Turno A:
turno B continuará.
Turno B:
achei que A tivesse encerrado.
Portanto handover precisa ser formal.
📋 Handover mínimo
INCIDENT:
INC-1234
CURRENT OWNER:
Ana
CURRENT STATE:
Queue stabilized, root cause open.
OPEN ACTIONS:
Carlos → consumer logs
Maria → reconciliation
NEXT DECISION:
10:30
RISKS:
Backlog remains.
Agora turno seguinte entra com contexto.
🕰️ Temporal Diffusion of Responsibility
Existe até uma versão temporal interessante:
“Amanhã resolvemos.”
Quem é amanhã?
Pessoas mudam.
Prioridades mudam.
Se tarefa futura não possui owner e deadline:
pode nunca existir.
🗃️ Backlog é cemitério de responsabilidades?
Pode ser.
Ações de post-mortem:
Improve monitoring.
Review process.
Update documentation.
Quem?
Quando?
Sem owner:
são desejos.
Não ações.
🔁 Melhoria contínua exige owner
Todo action item deveria ter:
ACTION
OWNER
DATE
SUCCESS CRITERIA
EVIDENCE
Caso contrário:
post-mortem produz PowerPoint.
Não melhoria.
🧠 Accountability sem blame
Precisamos distinguir.
Accountability:
responsabilidade clara pelo acompanhamento.
Blame:
busca simplista de culpado.
Você pode ter cultura blameless e ownership forte.
Aliás, deveria.
Blameless não significa:
ninguém é responsável.
Significa:
responsabilidade serve para coordenar e aprender, não para simplificar causas sistêmicas.
🧀 A fatia “ownership”
Vamos adicionar ao Swiss Cheese:
FATIA:
CLEAR OWNERSHIP
Buracos:
responsável desconhecido;
handoff incompleto;
alerta genérico;
on-call desatualizado;
equipe errada;
escalation inexistente.
Agora podemos fortalecer essa barreira.
🔍 Métricas interessantes
Meça:
alertas sem ACK;
tickets sem owner;
tempo até ownership;
handoffs falhos;
ações vencidas;
incidentes sem Incident Commander;
vulnerabilidades órfãs.
São indicadores organizacionais.
⏱️ Time to Ownership
Todo mundo mede:
MTTD — Mean Time to Detect.
MTTR — Mean Time to Restore.
Talvez devêssemos observar:
Time to Ownership
Quanto tempo entre:
problema detectado;
alguém claramente assumir?
Esse intervalo pode ser crítico.
📊 Exemplo
09:01 Alert
09:23 Owner assigned
22 minutos.
Talvez investigação técnica tenha durado apenas 10.
Então metade do incidente foi:
ninguém assumindo.
Descoberta valiosa.
🎯 Pergunta pós-incidente
Não pergunte apenas:
“Quando detectamos?”
Pergunte:
“Quando alguém assumiu responsabilidade explícita?”
Às vezes as respostas são muito diferentes.
🔬 RCA organizacional
Timeline:
09:01 alert generated
09:02 sent to distribution list
09:05 seen by operations
09:07 seen by application
09:12 second alert
09:19 user impact
09:22 someone asks who is checking
09:25 owner assigned
Root cause técnico:
consumer failed.
Contributing factor:
22 minutos sem owner.
Isso produz ação concreta:
melhorar roteamento e ownership.
🧠 Hindsight Bias retorna
Depois:
— Como ninguém fez nada?
Cuidado.
Talvez cada pessoa racionalmente acreditasse que outra era responsável.
Não basta dizer:
“Todos deveriam agir.”
Isso perpetua ambiguidade.
Melhor:
“Nosso design de ownership permitiu que todos acreditassem que outro agiria.”
Agora podemos corrigir.
🌀 Drift Into Failure retorna
Talvez antigamente houvesse um operador claramente responsável.
Depois reorganizações.
Outsourcing.
Novo fornecedor.
Cloud.
Novos times.
Responsabilidade ficou fragmentada.
Não houve decisão:
“Vamos perder ownership.”
A organização derivou.
Lembra?
Nossos monstros estão cada vez mais interligados.
🧬 Regeneração organizacional
Como regenerar após encontrar Diffusion of Responsibility?
Primeiro:
identifique serviços críticos.
Depois:
owner explícito.
On-call.
Escalation.
ACK.
Incident Commander.
Action board.
Handoffs formais.
Post-mortem actions com dono.
E principalmente:
ensine uma regra simples:
uma responsabilidade não foi transferida até que a próxima pessoa tenha aceitado.
Isso muda muita coisa.
📋 Checklist anti-Diffusion
Durante incidente:
[ ] Existe Incident Commander?
[ ] Existe owner técnico?
[ ] Cada ação possui uma pessoa?
[ ] Cada ação possui prazo?
[ ] Handoffs foram confirmados?
[ ] Alertas têm owner definido?
[ ] Existe escalation path?
[ ] FYI está separado de ACTION?
[ ] Alguém está registrando decisões?
[ ] Existe alguma tarefa que “todo mundo” deveria fazer?
[ ] Algum item está sem nome ao lado?
Se aparecer:
OWNER: ALL
talvez devêssemos conversar.
📓 Diário do Doctor
Se guardar apenas algumas ideias desta viagem, guarde estas:
Diffusion of Responsibility acontece quando várias pessoas presentes reduzem a sensação individual de responsabilidade para agir.
Informar não é atribuir responsabilidade.
Entregue não significa assumido.
Lido não significa tratado.
Todo incidente precisa de owner claro.
Toda ação precisa de pessoa e prazo.
Handoffs precisam de confirmação.
Broadcast amplo pode produzir espectadores.
Incident Commander reduz ambiguidade.
Responsabilidade clara é compatível com cultura blameless.
Silos tornam incidentes ponta a ponta especialmente vulneráveis.
E principalmente:
Se a resposta para “quem está cuidando?” é “alguém”, existe uma chance perigosamente grande de que a resposta real seja “ninguém”.
🕰️ De volta às 09:01
A TARDIS retorna.
VWORP.
O alerta acaba de chegar:
PAYMENT QUEUE DEPTH > THRESHOLD
Vinte e três pessoas recebem.
Nosso programador olha.
Desta vez não pensa:
“Alguém vai olhar.”
Escreve:
“Estou assumindo triagem inicial do alerta de PAYMENT QUEUE. Preciso de suporte MQ.”
Carlos responde:
“Assumo MQ.”
Maria:
“Fico com consumer.”
Incident Commander entra:
OWNER: JOÃO
MQ: CARLOS
CONSUMER: MARIA
NEXT UPDATE: 09:10
09:05.
Consumer parado.
09:07.
Causa identificada.
09:09.
Serviço restaurado.
Fila começa a cair.
Nenhum cliente percebe.
O gerente pergunta:
— Foi grave?
Nosso programador responde:
— Poderia ter sido.
— O que mudou?
Ele olha para o quadro.
Cada atividade possui um nome.
— Dessa vez ninguém ficou esperando “alguém”.
O Doctor sorri.
— Excelente.
— Isso foi tudo?
— Quase.
— O que falta?
O Doctor aponta para o post-mortem.
— Descobrir por que vocês precisaram de sorte nas vezes anteriores.
Naturalmente.
🥚 Easter Egg final
Horas depois aparece um dataset:
BELLACOSA.INCIDENTS(WHO)
Dentro:
IF OWNER = SPACES
MOVE 'DANGER' TO SYSTEM-STATUS
END-IF.
IF OWNER = 'EVERYONE'
MOVE 'NO-ONE' TO EFFECTIVE-OWNER
END-IF.
IF RESPONSIBILITY-TRANSFERRED
PERFORM WAIT-FOR-ACK
END-IF.
Comentário:
* SOMEBODY IS NOT A VALID USERID.
Nosso programador ri.
Outra linha:
* ASSIGN THE COMPANION.
Depois:
* BAD WOLF ACKNOWLEDGED.
E finalmente:
* DON'T ASK WHO COULD DO IT.
* ASK WHO WILL.
Ele fecha o membro.
Pouco depois chega um email:
“Pessoal, precisamos atualizar a documentação até sexta. Alguém consegue cuidar?”
Nosso programador olha.
Quarenta destinatários.
Sorri.
Responde:
“Posso assumir. Entrego uma primeira versão quinta às 15h. Carlos, consegue revisar depois?”
Carlos:
“Confirmado.”
Nada explodiu.
Nenhuma fila cresceu.
Nenhum pagamento falhou.
Mas alguma coisa mudou.
A responsabilidade deixou de ser uma nuvem.
Virou nome.
Prazo.
Confirmação.
Em algum lugar do espaço-tempo:
VWORP.
VWORP.
VWORP.
Porque o Doctor talvez tenha finalmente descoberto o maior inimigo de “alguém”:
uma pessoa claramente responsável.
☕🌀
Next stop: Normalcy Bias — quando o desastre já começou, os sinais estão diante de nós, mas nosso cérebro continua insistindo que provavelmente tudo voltará ao normal sozinho.
