☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

terça-feira, 7 de setembro de 2010

Gazeta Esportiva: John Belushi, COBOL e o Jornal que Transformava Segunda-feira em War Room

 

Bellacosa Mainframe e o jornal gazeta esportiva

☕ Um Café no Bellacosa Mainframe

Gazeta Esportiva: John Belushi, COBOL e o Jornal que Transformava Segunda-feira em War Room

⚽ Futebol, rádio, bancas, tabelas, resultados, São Silvestre, Corinthians, Palmeiras, Santos, São Paulo e a extraordinária época em que descobrir o placar de um jogo podia exigir comprar um jornal — enquanto John Belushi berrava que o juiz era ladrão

Se o Notícias Populares era a interface brasileira para descobrir quem havia matado quem, onde apareceu o lobisomem e se o Bebê-Diabo havia sido visto novamente no telhado de alguma residência paulistana...

existia outra máquina de papel rodando em produção.

Só que essa processava uma matéria-prima ainda mais perigosa.

FUTEBOL.

Seu nome:

A GAZETA ESPORTIVA

E antes que algum jovem desenvolvedor COBOL pergunte:

— Bellacosa, mas era apenas um jornal de esportes?

HAHAHAHAHAHAHAHA.

Meu caro...

Dizer que a Gazeta Esportiva era “um jornal de esportes” é como dizer que um IBM Z é “um computador grande”.

Tecnicamente correto.

Culturalmente criminoso.

Durante décadas, a Gazeta Esportiva foi banco de dados, arquivo histórico, placar, agenda, tabela de classificação, serviço estatístico, catálogo de jogadores, calendário esportivo e combustível para discussões capazes de destruir amizades antes mesmo da invenção das redes sociais.

Se Quentin Tarantino foi nosso guia para o Notícias Populares, aqui precisamos de alguém diferente.

Precisamos de um homem capaz de olhar para uma derrota por 1 a 0 e reagir como se o Império Romano tivesse acabado.

Precisamos de:

JOHN BELUSHI.

Camisa parcialmente aberta.

Gravata torta.

Café na mão.

Gazeta Esportiva debaixo do braço.

Ele invade a redação:

QUEM ESCALOU ESSE TIME?!

Bem-vindo.

O batch de domingo acabou.

Segunda-feira começou.

E o SYSOUT tem 64 páginas.


CAPÍTULO I — ANTES DO GOOGLE EXISTIA PAPEL

Precisamos novamente transportar o jovem programador para uma época estranha.

Uma época em que você não podia perguntar:

“Quem ganhou o jogo ontem?”

para um retângulo luminoso no bolso.

Não havia Google.

Não havia OneFootball.

Não havia SofaScore.

Não havia ESPN no celular.

Não havia notificações push.

Não havia grupo do WhatsApp.

Não havia X.

Não havia geolocalização do jogador.

Não havia mapa de calor.

Não havia xG.

Não havia VAR.

Aliás...

talvez devêssemos ter parado no “não havia VAR” e apreciado alguns segundos de silêncio.

Você queria informação esportiva?

Havia rádio.

Televisão.

E havia:

JORNAL.

Na manhã seguinte, o torcedor caminhava até a banca.

E lá estava ela.

A Gazeta Esportiva.

O equivalente esportivo de executar:

DISPLAY MATCH-RESULTS
DISPLAY LEAGUE-TABLE
DISPLAY PLAYER-RATINGS
DISPLAY NEXT-ROUND
DISPLAY COMPLETE-DISASTER

Só que impresso.


CAPÍTULO II — TUDO COMEÇOU COM UM QUARTO DE PÁGINA

A origem da Gazeta Esportiva é quase uma aula de escalabilidade.

Em 1918, já sob a administração de Cásper Líbero, o jornal A Gazeta criou uma pequena seção dedicada aos esportes.

Tamanho?

Aproximadamente:

UM QUARTO DE PÁGINA.

Isso mesmo.

O monstro começou como feature pequena.

A popularidade cresceu.

E em 24 de dezembro de 1928, aquela seção evoluiu para um suplemento esportivo, então chamado A Gazeta — Edição Esportiva.

O COBOLzeiro reconhece imediatamente.

V1.0
COLUNA ESPORTIVA

V2.0
SUPLEMENTO

V3.0
JORNAL INDEPENDENTE

V4.0
PORTAL WEB

Nunca subestime aquele programinha de 400 linhas que alguém chama de:

“solução temporária”.


CAPÍTULO III — CÁSPER LÍBERO, O ARQUITETO

Para compreender a Gazeta Esportiva precisamos conhecer Cásper Líbero.

Ele adquiriu A Gazeta em 1918 e iniciou uma série de transformações editoriais. Esporte tornou-se uma das áreas nas quais investiu intensamente.

Mas sua importância vai muito além de simplesmente publicar resultados.

Cásper percebeu algo fundamental:

ESPORTE É CONTEÚDO E EVENTO.

Essa combinação é poderosíssima.

Você não apenas cobre uma competição.

Você pode ajudar a criá-la.

A marca Gazeta ficou ligada a eventos esportivos que atravessariam gerações.

O caso mais extraordinário?

CORRIDA INTERNACIONAL DE SÃO SILVESTRE.

Criada em 1925.

Também surgiu a tradicional Prova Ciclística Nove de Julho, criada em 1933.

Isso significa que o ecossistema não era:

EVENTO
  |
  v
JORNAL COBRE

Era muito mais interessante:

JORNAL
  |
  +----> PROMOVE EVENTO
  |
  +----> COBRE EVENTO
  |
  +----> CRIA AUDIÊNCIA
  |
  +----> FORTALECE MARCA
  |
  +----> AUMENTA INTERESSE

Hoje chamaríamos isso de:

ecossistema de conteúdo.

Em 1925 chamavam de:

trabalhar.


CAPÍTULO IV — A TRAGÉDIA DE CÁSPER

Cásper Líbero não chegou a ver a Gazeta Esportiva transformar-se no grande diário independente que se tornaria.

Ele morreu em 27 de agosto de 1943, em um acidente aéreo na Baía de Guanabara.

Mas deixou algo extraordinário.

Um testamento determinando a criação de uma fundação.

Como não teve filhos, seu patrimônio foi destinado à instituição que preservaria seu projeto de comunicação.

Nasceu a:

FUNDAÇÃO CÁSPER LÍBERO.

Instituída em 1944, ela permanece responsável por um ecossistema que inclui Gazeta Esportiva, TV Gazeta, Rádio Gazeta, Faculdade Cásper Líbero e outras atividades.

Isso diferencia profundamente a história empresarial da Gazeta.

Não estamos falando simplesmente de:

PROPRIETÁRIO
   |
HERDEIROS
   |
VENDA

Existe uma estrutura institucional criada a partir da vontade testamentária de seu fundador.

É quase um:

PERFORM LEGADO
    UNTIL FOREVER
END-PERFORM.

CAPÍTULO V — 10 DE OUTUBRO DE 1947: GO LIVE

Chegamos ao grande deployment.

10 de outubro de 1947.

A Gazeta Esportiva deixa definitivamente sua condição de suplemento e torna-se um jornal diário independente dedicado ao esporte.

O projeto havia sido pensado antes.

A Copa de 1938 parecia uma oportunidade.

Depois veio a Segunda Guerra Mundial.

Houve nova tentativa em 1943.

Então Cásper morreu.

Finalmente:

1947.

GO LIVE.

A primeira edição diária apresentava o jornal como moderno, dinâmico e comprometido com independência e ética jornalística.

E nasceu uma expressão que se tornaria praticamente identidade:

“O MAIS COMPLETO.”

Isso era marketing.

Mas havia uma ambição real por trás.

Não se pretendia falar apenas de futebol.

A proposta era cobrir:

futebol,

atletismo,

basquete,

automobilismo,

ciclismo,

boxe,

natação,

tênis

e muitas outras modalidades.

Era uma espécie de:

SPORTS.*

CAPÍTULO VI — MAS VAMOS PARAR DE FINGIR: FUTEBOL ERA O MONSTRO

Sim.

Havia outras modalidades.

Mas estamos no Brasil.

Portanto chega John Belushi chutando a porta:

E O CORINTHIANS?!

HAHAHAHAHAHA.

Futebol era inevitavelmente o grande motor de atenção.

Corinthians.

Palmeiras.

São Paulo.

Santos.

Portuguesa.

Clubes do interior.

Seleção Brasileira.

Campeonatos estaduais.

Nacionais.

Mundiais.

Transferências.

Escalações.

Crises.

Cartolas.

Técnicos.

Juízes.

E aquela instituição brasileira que existe desde antes de a humanidade dominar o fogo:

A CORNETA.


CAPÍTULO VII — A BANCA ERA O SOFASCORE

Voltemos à banca.

Segunda-feira de manhã.

São Paulo.

Um trabalhador chega.

Vê a Gazeta.

A manchete anuncia a rodada.

Ele não precisa comprar imediatamente.

Olha.

Outro sujeito para.

Mais um.

— Você viu o jogo?

— Vi.

— Aquilo não foi pênalti.

Pronto.

THREAD CRIADA.

Outro responde:

— Foi pênalti sim.

ENGAGEMENT +100%.

Chega um palmeirense.

CONFLITO DETECTADO.

Chega um corintiano.

CPU 97%.

Chega um santista lembrando do Pelé.

HISTORICAL QUERY STARTED.

Chega o dono da banca:

— Vocês vão comprar o jornal ou vão ficar discutindo aí?

A rede social brasileira já funcionava perfeitamente.

Sem Internet.


CAPÍTULO VIII — A SEGUNDA-FEIRA ERA O WAR ROOM

O domingo terminava.

Mas o futebol não.

Na segunda-feira começava:

A AUTÓPSIA.

Quem jogou bem?

Quem jogou mal?

O juiz errou?

O técnico enlouqueceu?

O atacante perdeu gol?

Quem foi expulso?

Como ficou a classificação?

Quem joga na próxima rodada?

Era praticamente uma reunião pós-incidente.

INCIDENT:
DERROTA POR 3 X 0

SEVERITY:
SEV-1

ROOT CAUSE:
EM INVESTIGAÇÃO

POSSIBLE CAUSES:
- técnico
- goleiro
- zagueiro
- gramado
- juiz
- diretoria
- Mercúrio retrógrado

John Belushi sobe na mesa:

— NÃO FOI DERROTA!

Todos olham.

— FOI SABOTAGEM!


CAPÍTULO IX — A GAZETA ERA BANCO DE DADOS

Aqui entra o COBOL.

Para gerações inteiras, jornal esportivo era também:

DATASET.

Resultados.

Classificações.

Artilharia.

Escalações.

Calendários.

Estatísticas.

Histórico.

Você queria saber como estava o campeonato?

Não executava API.

Consultava tabela.

01 CAMPEONATO.
   05 TIME.
   05 PONTOS.
   05 JOGOS.
   05 VITORIAS.
   05 EMPATES.
   05 DERROTAS.
   05 GOLS-PRO.
   05 GOLS-CONTRA.

A tabela classificatória era praticamente um arquivo sequencial que todo brasileiro sabia interpretar.

Curiosamente, milhões de pessoas que jamais ouviram falar em banco relacional entendiam perfeitamente:

ordenação, agregação, chave, ranking e atualização incremental.


CAPÍTULO X — 1958: BRASIL CAMPEÃO

Então acontece 1958.

Brasil campeão mundial.

Pelé.

Garrincha.

Didi.

Nilton Santos.

Bellini.

Suécia.

O futebol brasileiro explode simbolicamente.

Segundo registros históricos, a Gazeta alcançou cerca de 400 mil exemplares nas grandes tiragens associadas à Copa de 1958.

Imagine imprimir centenas de milhares de jornais.

Não é pageview.

Não é request HTTP.

Cada cópia exige:

papel,

tinta,

máquina,

energia,

operários,

caminhão,

distribuição,

banca.

É infraestrutura física.


CAPÍTULO XI — 1970: O MAINFRAME ENTRA EM OVERLOAD

E então chegamos ao México.

Pelé.

Jairzinho.

Tostão.

Rivelino.

Carlos Alberto Torres.

Brasil tricampeão.

A Seleção que virou mitologia.

Em 23 de junho de 1970, a Gazeta Esportiva registrou seu recorde histórico:

534.530 EXEMPLARES.

Em um único dia.

MEIO MILHÃO.

John Belushi olha para a rotativa.

— MAIS PAPEL!

— Não cabe!

— MAIS TINTA!

— Estamos no limite!

— ENTÃO OVERCLOCKA A ROTATIVA!

Isso é escala.


CAPÍTULO XII — A COR DO JORNAL ERA A PAIXÃO

A experiência do jornal esportivo não era apenas informacional.

Era ritual.

Comprar.

Dobrar.

Carregar debaixo do braço.

Ler no ônibus.

Ler no bar.

Ler no trabalho escondido.

Deixar sobre a mesa.

Recortar.

Guardar.

Um resultado esportivo deixava de ser efêmero porque adquiria suporte físico.

A vitória do seu time existia em papel.

A derrota também.

Infelizmente.

E aquela página podia sobreviver décadas.


CAPÍTULO XIII — “ME DÁ A GAZETA”

Essa frase fazia sentido por si só.

O jornaleiro sabia.

A marca havia conquistado aquilo que toda empresa deseja:

atalho mental.

Gazeta = esporte.

Assim como determinados produtos tornam-se quase sinônimos de categoria, a Gazeta ocupava um lugar particular no imaginário esportivo paulista.

E isso era especialmente poderoso numa cidade onde futebol não era passatempo.

Era:

IDENTITY MANAGEMENT SYSTEM.

CAPÍTULO XIV — E O INTERIOR?

Aqui há outro ponto importante.

A Gazeta não se limitava ao eixo dos quatro grandes clubes paulistas.

A imprensa esportiva impressa possuía espaço para acompanhar campeonatos, clubes e modalidades que hoje podem desaparecer rapidamente da homepage porque não geram cliques suficientes.

Guarani.

Ponte Preta.

XV de Piracicaba.

Ferroviária.

Botafogo de Ribeirão Preto.

Comercial.

Noroeste.

Portuguesa Santista.

São Bento.

Juventus.

América.

E tantos outros.

O papel tinha limite físico.

Mas o jornal esportivo precisava construir uma visão relativamente ampla do ecossistema.

Isso ajudou a preservar uma quantidade monumental de memória esportiva.


CAPÍTULO XV — E A SÃO SILVESTRE?

Aqui o legado sai da página e invade a rua.

A Corrida Internacional de São Silvestre permanece uma das marcas esportivas mais reconhecíveis associadas ao legado de Cásper Líbero.

Criada em 1925, atravessou décadas e continua sendo realizada.

Pense nisso.

Um veículo de comunicação ajudou a criar um evento.

O evento virou tradição.

A tradição sobreviveu ao jornal impresso.

Isso é branding com RETENTION PERIOD = CENTURY.


CAPÍTULO XVI — O TROFÉU INVISÍVEL DA MEMÓRIA

A Gazeta também esteve ligada à criação e distribuição de premiações esportivas, entre elas a tradicional Taça dos Invictos, associada a equipes que mantinham longas sequências sem derrota.

Isso revela outra função da imprensa esportiva:

ela não apenas relata o esporte.

Ela ajuda a construir:

mitologia.

Recordes precisam ser lembrados.

Sequências precisam ser comparadas.

Heróis precisam de narrativas.

Rivalidades precisam de arquivo.

O jornal funciona como memória externa do torcedor.


CAPÍTULO XVII — O TORCEDOR ERA O ALGORITMO DE RECOMENDAÇÃO

Hoje:

IF USER = CORINTHIANS
   RECOMMEND CORINTHIANS-CONTENT
END-IF

Na banca?

O torcedor olhava a primeira página.

Se o clube estivesse em destaque:

CLICK = BUY

Se o rival tivesse perdido vergonhosamente:

CLICK = BUY
SHARE = BUY-AND-SHOW-FRIENDS

HAHAHAHA.

Esse segundo caso provavelmente possuía CTR extraordinário.


CAPÍTULO XVIII — O HUMOR DO FUTEBOL

Aqui John Belushi assume definitivamente a redação.

Porque futebol brasileiro nunca foi apenas análise.

É absurdo.

Um sujeito passa a semana inteira dizendo:

— Futebol é só entretenimento.

Domingo, 17h43:

EU NÃO ACREDITO NESSE DESGRAÇADO!

Cinco minutos depois:

— Nunca mais assisto futebol.

Quarta-feira:

— Que horas é o jogo?

Essa é uma máquina de estados fantástica:

STATE 01 = ESPERANÇA
STATE 02 = ANSIEDADE
STATE 03 = EUFORIA
STATE 04 = ÓDIO
STATE 05 = DEPRESSÃO
STATE 06 = NUNCA-MAIS
STATE 07 = PRÓXIMA-RODADA

GO TO STATE-01.

Loop infinito.


CAPÍTULO XIX — RÁDIO, TV, JORNAL: UM ECOSSISTEMA

Outra diferença fundamental da Gazeta está no ecossistema construído pela Fundação.

Jornal.

Rádio.

Televisão.

Faculdade.

Agência.

Eventos.

Hoje falaríamos em:

OMNICHANNEL.

A Fundação Cásper Líbero mantém até hoje esse complexo de comunicação no edifício da Avenida Paulista, incluindo TV Gazeta, Rádio Gazeta, Faculdade Cásper Líbero e Gazeta Esportiva digital.

A Gazeta não era apenas uma publicação isolada.

Era parte de uma arquitetura.


CAPÍTULO XX — ENTÃO CHEGA A INTERNET

E novamente nosso velho conhecido aparece.

TCP/IP.

Em 1997, segundo a própria Fundação, a Gazeta Esportiva começou sua entrada na Internet, inicialmente reproduzindo conteúdo do impresso. Outra retrospectiva oficial situa o lançamento do portal independente em 1998. As duas datas refletem etapas diferentes da migração digital.

Isso é interessante porque mostra a transição acontecendo em tempo real.

Primeiro:

PAPER → HTML

Depois:

DIGITAL-FIRST

E finalmente:

REAL-TIME

CAPÍTULO XXI — O INIMIGO DO JORNAL ESPORTIVO CHAMAVA-SE LATÊNCIA

Pense no problema.

Um jogo termina às 22h.

O jornal precisa:

fechar texto,

editar,

diagramar,

imprimir,

distribuir.

A Internet diz:

— Gol.

Agora.

Cartão vermelho.

Agora.

Fim do jogo.

Agora.

Classificação atualizada.

Agora.

Para informação esportiva, a diferença entre:

amanhã

e

agora

é brutal.

O produto possuía um problema arquitetural que nenhuma manchete conseguiria eliminar:

LATENCY = HOURS

contra:

LATENCY = SECONDS

CAPÍTULO XXII — 2001: ABEND

No início do século XXI, a situação financeira do jornal havia se tornado crítica.

Em outubro de 2001, a Fundação anunciou a decisão de encerrar a edição impressa e transferir seu conteúdo para a Internet. A Folha registrou naquele momento uma tiragem média inferior a 14 mil exemplares.

Compare.

1970:

534.530

2001:

menos de 14.000 em média

Isso não é queda.

Isso é:

IEC030I B37

O dataset ficou sem espaço para continuar fingindo que estava tudo bem.


CAPÍTULO XXIII — A ÚLTIMA CAPA

Em 19 de novembro de 2001, circulou a edição número:

27.162

A última edição impressa diária.

A manchete?

“O Futuro é Hoje!”

Poucas manchetes poderiam ser mais apropriadas.

No dia seguinte, a operação esportiva passava definitivamente para o ambiente digital.

O jornal morreu?

O suporte morreu.

A marca continuou.

E isso é muito diferente.


CAPÍTULO XXIV — MODERNIZAÇÃO SEM REWRITE

Agora o programador COBOL começa a sorrir.

Porque reconheceu tudo.

BUSINESS LOGIC:
COBRIR ESPORTES

OLD INTERFACE:
PAPEL

NEW INTERFACE:
WEB

Não foi necessário executar:

DELETE FROM BRAND;

Executou-se:

ALTER ACCESS METHOD.

Essa é uma aula maravilhosa de modernização.

A função continua.

A tecnologia muda.


CAPÍTULO XXV — O QUE MORREU?

Morreu o ritual diário específico.

O jornal debaixo do braço.

A banca como endpoint.

A tabela impressa.

O resultado congelado no papel.

A fotografia que você recortava.

A edição guardada porque seu clube foi campeão.

O sujeito lendo por cima do seu ombro no ônibus.

O jornal aberto sobre a mesa do boteco.

E talvez uma das experiências mais deliciosamente analógicas:

virar a página procurando seu time.


CAPÍTULO XXVI — O QUE NÃO MUDOU ABSOLUTAMENTE NADA?

Agora prepare-se.

1958:

— O juiz roubou.

2026:

— O juiz roubou.

1970:

— O técnico escalou errado.

2026:

— O técnico escalou errado.

1985:

— Esse presidente está destruindo o clube.

2026:

— Esse presidente está destruindo o clube.

1994:

— Esse jogador não vale tudo isso.

2026:

— Esse jogador não vale tudo isso.

O suporte tecnológico evoluiu.

O torcedor recebeu:

Internet,

smartphone,

streaming,

4K,

VAR,

GPS,

estatística avançada,

inteligência artificial,

tracking,

big data.

E usa tudo isso para concluir:

“O JUIZ É CEGO.”

Magnífico.


CAPÍTULO XXVII — A GAZETA ERA O REDDIT DO BOTECO

O jornal sozinho não era a comunidade.

Ele era o gatilho da comunidade.

A pessoa lia.

Comentava.

Discutia.

Levava ao trabalho.

Mostrava ao colega.

Discordava.

Guardava.

Recortava.

A informação saía do papel e entrava na conversa.

Hoje chamamos isso de:

engagement.

Na época chamava:

— Você viu a Gazeta?


CAPÍTULO XXVIII — JOHN BELUSHI DESCOBRE O VAR

Nosso guia finalmente chega ao futebol moderno.

Belushi observa uma sala com 37 monitores.

Linhas.

Replay.

Zoom.

Câmeras.

Computadores.

Comunicação eletrônica.

Ele pergunta:

— Tudo isso serve para decidir se foi pênalti?

— Sim.

— E funciona?

Silêncio.

Belushi pega uma Gazeta Esportiva de 1970.

— Na minha época bastava xingar o juiz!

O COBOLzeiro responde:

— Tecnicamente ainda basta.


CAPÍTULO XXIX — O ARQUIVO É UMA MÁQUINA DO TEMPO

Existe algo que frequentemente esquecemos quando falamos sobre jornais antigos.

Eles são bancos de memória.

Uma edição da Gazeta Esportiva não guarda apenas resultados.

Guarda:

ortografia,

publicidade,

preços,

nomes,

clubes desaparecidos,

estádios modificados,

patrocinadores,

uniformes,

jogadores esquecidos,

modalidades,

expectativas,

frustrações.

Você abre uma edição de 1958 e não está simplesmente lendo sobre futebol.

Está executando:

RESTORE BRASIL
FROM BACKUP
DATE '1958';

Isso é patrimônio histórico.


CAPÍTULO XXX — O GRANDE EASTER EGG: O ESPORTE SEMPRE FOI DATA-DRIVEN

Hoje adoramos falar:

data analytics no futebol.

Mas esporte sempre foi uma gigantesca fábrica de dados.

Gols.

Pontos.

Vitórias.

Derrotas.

Tempo.

Distância.

Recordes.

Classificação.

Artilharia.

Aproveitamento.

Média.

O jornal esportivo era uma camada de apresentação desse banco de dados.

Hoje temos dashboards.

Antes tínhamos tabelas.

Hoje temos APIs.

Antes tínhamos repórteres telefonando.

Hoje temos feeds em tempo real.

Antes tínhamos fechamento.

A arquitetura mudou.

O domínio continua assustadoramente parecido.


CAPÍTULO XXXI — NOTÍCIAS POPULARES X GAZETA ESPORTIVA

Agora coloque os dois jornais lado a lado numa banca imaginária.

À esquerda:

NOTÍCIAS POPULARES

NASCEU O DIABO!

À direita:

GAZETA ESPORTIVA

CORINTHIANS PERDE CLÁSSICO!

Um corintiano olha para ambos.

Compra o Notícias Populares.

Porque naquele momento:

o Bebê-Diabo parece uma notícia menos traumática.

HAHAHAHAHAHA.

Mas há uma conexão séria.

Os dois compreendiam a força da banca.

Da manchete.

Da identidade do público.

Da leitura compartilhada.

Da informação como ritual.

E principalmente:

da emoção.


CAPÍTULO XXXII — A BANCA COMO HOMEPAGE DA CIDADE

Imagine novamente São Paulo.

Década de 1970.

Ônibus.

Fumaça.

Buzinas.

Padaria.

Café.

Cigarro.

Banca.

Jornais pendurados.

Você passa.

Em alguns segundos recebe:

política,

economia,

crime,

esporte,

celebridade,

emprego,

classificados.

A banca era:

PORTAL.

Só que fisicamente instalado na calçada.

Cada jornal era um aplicativo.

Cada manchete era uma notificação.

Cada capa disputava atenção.

Cada comprador era conversão.

E a Gazeta tinha uma vantagem extraordinária:

o torcedor já chegava emocionalmente autenticado.


CAPÍTULO XXXIII — O LEGADO

O legado da Gazeta Esportiva é maior que seu período impresso.

Ele inclui a contribuição histórica para o jornalismo esportivo brasileiro, sua ligação com eventos como São Silvestre e Nove de Julho, o arquivo acumulado durante décadas e a continuidade da marca no ambiente digital.

Mas existe um legado menos tangível.

Ela pertence a uma época em que a relação com informação possuía:

peso.

Literalmente.

Você carregava informação.

Dobrava informação.

Emprestava informação.

Guardava informação.

Jogava informação fora.

A notícia tinha cheiro de tinta.


EPÍLOGO — BELUSHI, O COBOLZEIRO E A ÚLTIMA SEGUNDA-FEIRA

São Paulo.

Segunda-feira.

Sete horas da manhã.

Um bar perto de uma estação.

Café.

Pão na chapa.

Um homem entra carregando a Gazeta Esportiva.

Abre sobre o balcão.

Outro olha.

— Quanto foi?

— Dois a zero.

— Quem fez?

Ele aponta para a página.

Chega outro.

— Esse time não tem meio-campo.

Outro responde:

— Você não entende nada de futebol.

Pronto.

A rede entrou em produção.

Não existe Wi-Fi.

Não existe smartphone.

Não existe login.

Não existe perfil.

Não existe algoritmo.

Mas existe:

USER-A
USER-B
USER-C
CONTENT
ENGAGEMENT
COMMUNITY

John Belushi entra.

Olha o jornal.

Olha o placar.

Derruba o café.

DOIS A ZERO?!

O bar inteiro olha.

Belushi sobe numa cadeira.

— Acabou! Este clube morreu! Nunca mais assisto futebol! Nunca mais compro jornal! Nunca mais discuto escalação!

Silêncio.

O balconista pergunta:

— Quarta tem jogo, não tem?

Belushi desce lentamente.

Pega a Gazeta.

Folheia.

— Oito e meia.

Senta.

Pede outro café.

E talvez essa seja a melhor definição possível da Gazeta Esportiva.

Ela não vendia apenas resultados.

Vendia o próximo capítulo.

A derrota de domingo não encerrava nada.

Produzia a segunda-feira.

A segunda-feira produzia discussão.

A discussão produzia expectativa.

A expectativa produzia quarta-feira.

Quarta produzia outro jogo.

Outro resultado.

Outra manchete.

Outra Gazeta.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. TORCEDOR-BRASILEIRO.

       PROCEDURE DIVISION.

       JOGA.
           PERFORM ESPERAR-JOGO.
           PERFORM ASSISTIR-JOGO.
           PERFORM RECLAMAR-DO-JUIZ.
           PERFORM DISCUTIR-ESCALACAO.
           PERFORM LER-GAZETA.
           PERFORM PROMETER-NUNCA-MAIS.

           GO TO JOGA.

Um programador junior observa horrorizado:

— Bellacosa! Isso é um GO TO infinito!

Exatamente.

Está em produção há mais de cem anos.

Não mexa.

Ninguém sabe todas as dependências.

A Gazeta Esportiva impressa executou sua última edição em 2001.

Mas o programa continua.

A banca virou portal.

A tabela virou widget.

O rádio virou streaming.

A fotografia virou vídeo.

A coluna virou feed.

O fechamento virou atualização contínua.

O leitor virou usuário.

O assinante virou audiência.

A discussão do bar virou comentário.

O arquivo virou database.

O jornal virou URL.

Mas domingo à tarde, quando a bola bate na mão de alguém dentro da área...

todo o avanço tecnológico da humanidade é descartado.

Milhões de brasileiros executam simultaneamente:

IF PENALTI-CONTRA-MEU-TIME
    DISPLAY 'FOI SEM QUERER'
ELSE
    DISPLAY 'PENALTI CLARISSIMO'
END-IF.

Esse código jamais passou por revisão.

Jamais passará.

John Belushi pega o jornal.

O COBOLzeiro pega o café.

A rotativa começa a girar.

CLAC. CLAC. CLAC. CLAC.

534.530 exemplares.

Uma cidade acordando.

Uma banca abrindo.

Um torcedor procurando a manchete.

E um programa centenário chamado:

PAIXÃO PELO ESPORTE

continua executando.

RC=0000.

Alarm Fatigue: Doctor Who, COBOL e o Dia em que o Sistema Gritou Tanto que Ninguém Mais Escutou

Bellacosa Mainframe e o alarm fatigue

☕ Um Café no Bellacosa Mainframe

Alarm Fatigue: Doctor Who, COBOL e o Dia em que o Sistema Gritou Tanto que Ninguém Mais Escutou

Uma viagem pela TARDIS dos incidentes para entender como excesso de alertas transforma monitoramento em ruído e prepara o caminho para falhas reais

07:58.

Sala de operação.

Café recém-passado.

SDSF aberto.

Painéis verdes.

Tudo parece tranquilo.

Até que começam as mensagens.

WARNING STORAGE 78%
WARNING QUEUE DEPTH HIGH
WARNING JOB DELAYED
WARNING RETRY DETECTED
WARNING DB2 WAIT
WARNING MQ CHANNEL
WARNING CPU THRESHOLD
WARNING TIMEOUT
WARNING DATASET USAGE
WARNING APPLICATION RESPONSE

Nosso programador COBOL iniciante olha para a tela.

— Tem bastante alerta.

O operador veterano responde:

— Normal.

09:11.

Mais alertas.

WARNING STORAGE 81%
WARNING JOB ABC123 RC=04
WARNING MQ RETRY
WARNING TIMEOUT
WARNING CPU SPIKE

O jovem pergunta:

— Precisamos investigar?

— Esses aí aparecem sempre.

11:42.

O alarme soa novamente.

O operador fecha.

13:07.

Outro.

Fecha.

14:18.

Outro.

Fecha.

14:37.

Mais um.

Fecha.

14:52.

Produção começa a falhar.

O operador olha para o painel.

Há uma mensagem piscando há 23 minutos.

CRITICAL:
QUEUE DEPTH RISING RAPIDLY
CONSUMER NOT RESPONDING

Ele não viu.

Na verdade, viu.

Mas seu cérebro decidiu que era apenas mais uma mensagem entre centenas.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se entre dois consoles.

A porta abre.

O Doctor sai.

Olha para os alarmes.

Olha para o operador.

Olha para a tela.

— Por que ninguém respondeu?

O operador suspira.

— Porque isso apita o tempo todo.

O Doctor observa uma sequência de warnings.

— Então vocês construíram um sistema para avisar quando algo está errado...

Pausa.

— ...e depois ensinaram as pessoas a ignorá-lo.

Silêncio.

O Doctor sorri daquela maneira pouco tranquilizadora.

— Fascinante.

Bem-vindo ao:



Alarm Fatigue

Ou:

Fadiga de Alarmes

O fenômeno pelo qual exposição excessiva a alertas, avisos e notificações reduz progressivamente nossa capacidade de perceber quais realmente importam.


🌀 Onde estamos na nossa jornada?

Até agora nossa TARDIS dos incidentes encontrou:

Swiss Cheese Model — várias barreiras podem falhar.

Normalization of Deviance — desvios repetidos deixam de parecer anormais.

Hindsight Bias — depois do incidente, tudo parece óbvio.

Confirmation Bias — procuramos evidências que confirmem nossas crenças.

Anchoring Bias — a primeira informação pesa demais.

Groupthink — o grupo converge rápido demais.

Authority Gradient — alguém percebe o risco, mas não sente liberdade para desafiar autoridade.

Plan Continuation Bias — mesmo quando o plano deveria parar, continuamos.

Agora encontramos uma falha diferente.

O sistema possui sensores.

Possui alertas.

Possui monitoramento.

Possui dashboards.

Mas existe informação demais.

E quando tudo grita:

nada grita.


🚨 O que é Alarm Fatigue?

Alarm Fatigue acontece quando uma pessoa é exposta a tantos alertas que começa a:

ignorar;

silenciar;

filtrar;

postergar;

automatizar respostas;

ou perder sensibilidade a eles.

O processo pode ser representado assim:

ALERTA
  ↓
ATENÇÃO
  ↓
OUTRO ALERTA
  ↓
OUTRO
  ↓
OUTRO
  ↓
REPETIÇÃO
  ↓
HABITUAÇÃO
  ↓
ALERTA VIRA RUÍDO

Então chega um alerta realmente importante.

Mas ele parece igual aos anteriores.

O sistema avisou.

O humano não reagiu.

No post-mortem alguém pergunta:

“Mas o alerta estava lá. Como ninguém viu?”

Resposta:

porque havia outros 847.


🧠 Nosso cérebro não foi projetado para viver dentro de um dashboard

Humanos são excelentes em detectar novidade.

Um barulho inesperado chama atenção.

Um barulho constante desaparece mentalmente.

Imagine morar perto de uma estrada.

Na primeira noite:

cada caminhão incomoda.

Depois de semanas:

você quase não percebe.

Isso é habituação.

Agora aplique a um ambiente operacional.

Primeiro warning:

atenção.

Centésimo warning:

rotina.

Milésimo:

paisagem.


☕ O RC=04 retorna outra vez

Nosso velho amigo:

JOB04217 ENDED - RC=0004

Primeira ocorrência:

— Vamos investigar.

Segunda:

— De novo?

Décima:

— Esse é conhecido.

Centésima:

ninguém olha.

Um dia o mesmo RC=04 representa condição diferente.

Ninguém percebe.

Alarm Fatigue acabou de se misturar com:

Normalization of Deviance.

A mensagem perdeu poder porque se tornou familiar.


🧀 Swiss Cheese + Alarm Fatigue

No Swiss Cheese Model, uma das barreiras pode ser:

monitoramento.

A ideia é:

falha acontece;

monitoramento detecta;

humano reage;

incidente é interrompido.

Mas se o monitoramento produz ruído demais:

FALHA
 ↓
ALERTA
 ↓
ALERTA IGNORADO
 ↓
PROPAGAÇÃO

A fatia existe.

Formalmente.

Tecnicamente.

Mas possui um buraco enorme.


📟 Monitoramento que ninguém usa não é defesa

Uma organização pode dizer:

“Temos alertas para isso.”

Ótimo.

Pergunta seguinte:

“Alguém consegue identificar esse alerta no meio dos outros?”

Se resposta for não, temos uma defesa teórica.

É como possuir extintor enterrado atrás de cinquenta caixas.

Está lá.

Mas talvez não sirva quando o fogo começar.


👻 Easter Egg nº 1 — Daleks demais

Imagine Doctor Who.

Um Dalek aparece.

Todos correm.

Dois Daleks.

Pânico.

Agora imagine mil Daleks entrando na sala diariamente apenas para dizer:

“Bom dia.”

Depois de seis meses, talvez alguém comece a ignorá-los.

Até o dia em que um diz:

EXTERMINATE.

E ninguém levanta os olhos.

Esse é Alarm Fatigue.


📢 Warning, Critical, Info, Error… tudo vermelho

Outro problema comum:

todos os alertas parecem igualmente importantes.

Exemplo:

WARNING: TEMP FILE CREATED

WARNING: CPU 72%

WARNING: USER RETRY

WARNING: CORE BANKING DOWN

Se visualmente todos usam:

vermelho;

sirene;

email;

SMS;

pager;

Teams;

então prioridade desaparece.

Hierarquia de severidade precisa ser real.


🎨 Semântica visual importa

Pense:

INFO
algo útil.

NOTICE
observe.

WARNING
há risco.

CRITICAL
ação imediata.

Se tudo vira CRITICAL:

CRITICAL deixa de significar crítico.

O mesmo acontece quando todo ticket é:

URGENTE.

Depois de algum tempo:

urgente significa normal.


🧠 Alarm Fatigue não é preguiça

É importante entender isso.

Quando alguém ignora alarmes repetidos, pode parecer negligência.

Mas frequentemente existe um problema de design.

Se o sistema dispara centenas de falsos positivos, humanos naturalmente criam atalhos.

Começam a:

fechar automaticamente;

silenciar canais;

criar filtros;

reconhecer sem investigar.

A organização treinou esse comportamento.

Então dizer:

“Operador deveria prestar mais atenção”

pode ser uma correção muito pobre.


🔔 False Positive é caro

Imagine um alerta que dispara 100 vezes.

99 são irrelevantes.

1 é real.

O sistema parece ter sensibilidade alta.

Mas operacionalmente pode ser ruim.

Porque cada falso positivo consome:

atenção;

tempo;

credibilidade.

Existe um recurso invisível em operação:

confiança no alerta.

Se o alerta perde credibilidade, perde função.


📉 Precisão operacional

Um bom alerta deveria fazer alguém pensar:

“Quando isso aparece, vale a pena olhar.”

Se operador pensa:

“Ah, esse de novo.”

Temos problema.

Não basta medir:

quantos alertas existem.

Precisamos medir:

quantos são acionáveis.


🎯 Actionable Alert

Um alerta bom responde algumas perguntas.

O que aconteceu?

MQ QUEUE DEPTH > 20.000

Onde?

QUEUE: PAYMENT.REQUEST

Desde quando?

SINCE: 14:31

Por que importa?

CONSUMER RATE < PRODUCER RATE

O que fazer?

CHECK CONSUMER PAYMENT01

Isso é melhor que:

WARNING MQ

Obrigado, sistema.

Muito esclarecedor.


🧙 Easter Egg nº 2 — “Something went wrong”

Todo profissional já encontrou uma mensagem maravilhosa:

AN ERROR OCCURRED.

Ou:

SOMETHING WENT WRONG.

Excelente.

Algo.

Em algum lugar.

Fez alguma coisa.

Observabilidade nível oráculo grego.

Mensagens precisam ajudar investigação.

Não apenas comunicar tristeza.


💻 Alarm Fatigue no mundo COBOL

Nosso programador iniciante pode encontrar alertas em:

JCL;

SDSF;

CICS;

Db2;

MQ;

storage;

WLM;

SMF;

monitoramento corporativo;

scheduler;

APM;

scripts;

emails;

tickets.

Imagine uma operação com milhares de jobs.

Se cada RC=04 gerar incidente:

ninguém sobreviverá.

Então precisamos distinguir:

RC=04 esperado;

RC=04 inesperado;

RC=04 crescente;

RC=04 em job crítico;

RC=04 correlacionado com outro sintoma.

Contexto importa.


🧠 O mesmo valor pode ter significados diferentes

Exemplo:

CPU 80%

Isso é alerta?

Depende.

Em determinado LPAR:

normal.

Em outro:

anormal.

Durante fechamento:

esperado.

Às 04:00:

talvez estranho.

Logo, threshold fixo pode gerar ruído.

Baseline contextual é melhor.


📈 Alertar tendência pode ser melhor que limite

Exemplo:

dataset:

segunda: 72%

terça: 74%

quarta: 77%

quinta: 81%

sexta: 86%

Talvez o mais importante não seja:

USAGE > 90%

Mas:

GROWTH RATE ABNORMAL

Porque sinais fracos vivem em tendência.


🔍 O sistema não deveria apenas perguntar “quebrou?”

Deveria perguntar:

“Está se comportando diferente?”

Essa distinção é fundamental.

Um job ainda RC=00 pode estar:

20% mais lento;

consumindo dobro de I/O;

gerando mais retries;

rejeitando mais registros.

Ainda não falhou.

Mas está falando conosco.


📊 Baseline retorna à TARDIS

Nos capítulos anteriores vimos baseline.

Agora ele vira arma contra Alarm Fatigue.

Se um comportamento é normal:

não alerte desnecessariamente.

Se mudou significativamente:

alerte.

Isso reduz ruído.


🚨 Alertas estáticos versus inteligentes

Alerta estático:

QUEUE > 1000

Alerta contextual:

QUEUE > NORMAL_BASELINE
AND
GROWTH RATE > X
AND
CONSUMER RATE FALLING

O segundo pode ser muito mais valioso.

Porque tenta detectar situação.

Não apenas número.


🧠 Correlation Engine

Em ambientes grandes, vários alertas podem representar uma única causa.

Exemplo:

TIMEOUT
CPU HIGH
QUEUE HIGH
DB2 WAIT
APPLICATION ERROR

Cinco alertas.

Mas talvez tudo venha de:

consumer downstream degradado.

Se ferramenta correlaciona:

POSSIBLE ROOT INCIDENT:
DOWNSTREAM CONSUMER DEGRADED

reduz ruído.


🧩 Event Storm

Quando um componente falha, pode gerar tempestade de eventos.

Primeiro:

MQ consumer para.

Depois:

fila cresce.

Depois:

timeouts.

Depois:

retries.

Depois:

CPU aumenta.

Depois:

Db2 recebe carga.

Depois:

usuários reclamam.

Se cada consequência gera alerta separado, War Room recebe uma avalanche.

O verdadeiro trabalho é identificar:

qual foi o primeiro dominó.


🕰️ Timeline ajuda novamente

Construa:

14:31 CONSUMER DEGRADED
14:32 QUEUE +20%
14:34 TIMEOUTS
14:35 RETRIES
14:37 CPU +30%
14:40 USER ERRORS

Agora a história aparece.

Sem timeline:

cinco alarmes independentes.

Com timeline:

uma cadeia.


🔊 Alarm Flooding

Durante incidente sério, quantidade de alarmes pode aumentar justamente quando atenção é mais necessária.

Isso cria paradoxo:

quanto pior a situação,

mais informação chega,

menos capacidade temos de processá-la.

Por isso ferramentas e processos precisam filtrar.


🚦 Severity precisa representar ação

Uma classificação útil deveria ter consequência.

Por exemplo:

SEV4
informativo.

SEV3
investigar em horário normal.

SEV2
ação rápida.

SEV1
resposta imediata / incidente.

Se SEV1 acontece quarenta vezes por dia, sua severidade não significa nada.


📱 Notificação é interrupção

Todo alerta possui custo cognitivo.

Email.

SMS.

Pager.

Teams.

Telefone.

Cada interrupção quebra foco.

Logo:

mais alertas não significam automaticamente mais segurança.

Às vezes significam menos.


🔕 Silenciar não é necessariamente ruim

À primeira vista parece perigoso.

Mas eliminar alerta inútil pode aumentar segurança.

Se comprovadamente não é acionável:

remova;

reclassifique;

agruppe;

corrija.

A pior solução é mantê-lo eternamente porque:

“Talvez um dia seja útil.”

Você está cobrando atenção todos os dias.


🧪 Como saber se um alerta merece existir?

Pergunte:

  1. O que ele detecta?

  2. Quem deve agir?

  3. Qual ação deve acontecer?

  4. Em quanto tempo?

  5. Qual risco reduz?

  6. Quantas vezes dispara?

  7. Quantas vezes é falso?

  8. Quantas vezes resultou em ação útil?

Se ninguém sabe responder:

talvez seja apenas ruído institucional.


📝 Alert Ownership

Todo alerta importante deveria ter dono.

Não necessariamente uma pessoa específica, mas equipe.

Exemplo:

ALERT:
CICS RESPONSE > 3S

OWNER:
CICS OPERATIONS

RUNBOOK:
CICS-RESP-001

Sem ownership:

todos recebem.

Ninguém assume.


👥 “Todo mundo recebeu” = “ninguém recebeu”

Esse fenômeno é clássico.

Mensagem enviada para vinte pessoas.

Cada uma pensa:

“Alguém vai olhar.”

Resultado:

ninguém olha.

Melhor:

alerta roteado claramente.

Responsabilidade explícita.


🧠 Diffusion of Responsibility

Aqui entramos em outro fenômeno psicológico:

difusão de responsabilidade.

Quanto mais pessoas recebem um alerta sem dono claro, menor pode ser a sensação individual de responsabilidade.

Alarm Fatigue encontra psicologia social.

Mais um monstro esperando episódio.


📚 Runbook

Alerta sem ação conhecida causa hesitação.

Alerta com runbook:

1. Check queue depth.
2. Check consumer status.
3. Compare producer/consumer rate.
4. Restart only if condition X.
5. Escalate if Y.

Isso reduz esforço cognitivo.

Especialmente às três da manhã.


💤 Alarm Fatigue + fadiga humana

Às 14:00:

cem alertas já cansam.

Às 03:00:

pior.

Cansaço aumenta chance de:

ignorar;

clicar errado;

confundir severidade;

esquecer follow-up.

Por isso turno, handover e descanso são controles de segurança.


☕ O operador e o botão ACK

Existe um botão extremamente perigoso em sistemas de monitoramento:

ACKNOWLEDGE

Reconhecer não significa resolver.

Mas psicologicamente:

alerta desaparece.

Sensação de tarefa concluída.

Então precisamos distinguir:

ACKNOWLEDGED

de:

RESOLVED

Muito importante.


✅ O prazer do check verde

Nosso cérebro gosta de fechar coisas.

Ticket.

Alerta.

Checklist.

Se botão ACK remove incômodo, existe incentivo para usá-lo cedo demais.

Design de ferramenta influencia comportamento.


🧠 Confirmation Bias + Alarm Fatigue

Equipe acha que problema é rede.

Recebe cinquenta alertas.

Filtra mentalmente apenas os de rede.

Os demais parecem ruído.

Confirmation Bias seleciona dentro da tempestade.

Você pode ignorar exatamente o alerta correto porque não combina com a teoria atual.


⚓ Anchoring + Alarm Fatigue

Primeiro alerta:

DB2 WARNING

Vira âncora.

Depois chegam outros cinquenta.

Equipe continua olhando Db2.

O alerta realmente importante de MQ aparece no meio.

Ignorado.


👥 Groupthink + Alarm Fatigue

Sala inteira decide:

“Esses warnings são conhecidos.”

Pronto.

Consenso normalizou ruído.

Agora pessoa nova que pergunta:

— Mas esse é diferente...

pode ser silenciada.

Groupthink protege a fadiga.


🪜 Authority Gradient + Alarm Fatigue

Júnior:

— Esse alerta mudou de comportamento.

Sênior:

— Pode ignorar.

Júnior:

— Ok.

Esse “ok” pode custar caro.

Authority Gradient fecha mais um buraco.


▶️ Plan Continuation Bias + Alarm Fatigue

Mudança em andamento.

Alertas começam.

Equipe diz:

— Deve ser efeito temporário da implantação.

Continua.

Mais alertas.

— Quando terminar estabiliza.

Continua.

Até não estabilizar.

Plan Continuation Bias usa Alarm Fatigue como combustível.


🧠 Alarm Fatigue e Normalization of Deviance são parentes próximos

A diferença é sutil.

Normalization of Deviance:

comportamento anormal vira aceitável.

Alarm Fatigue:

sinalização repetida perde capacidade de chamar atenção.

Frequentemente caminham juntos.

Exemplo:

warning aparece todo dia.

Normalizamos a condição.

Depois cansamos do alerta.

Resultado:

silenciamos.

Agora o sistema perdeu uma barreira.


🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Esse alerta pode ignorar.”

Pergunte:

“Então por que ele ainda existe?”

Talvez haja ótima resposta.

Se não houver:

investigue.


🎯 Pergunta Bellacosa nº 2

Quando um alerta dispara frequentemente:

“Qual porcentagem dessas ocorrências exige ação?”

Se for muito baixa:

tuning.


🎯 Pergunta Bellacosa nº 3

Pergunte:

“Se esse alerta aparecesse sozinho às 03:00, eu acordaria alguém?”

Se não:

talvez não deveria pager.


🧪 Passo a passo para combater Alarm Fatigue

Passo 1 — Inventarie alertas

Liste:

nome;

fonte;

severidade;

frequência;

owner;

ação.

Você pode descobrir coisas assustadoras.


Passo 2 — Meça volume

Quantos alertas:

por hora;

por turno;

por serviço;

por severidade?

Sem medir, ruído parece normal.


Passo 3 — Identifique top talkers

Quais cinco alertas geram mais notificações?

Talvez 80% do ruído venha de poucos itens.

Corrija primeiro.


Passo 4 — Analise false positives

Quantos alertas não exigem ação?

Esses estão gastando confiança.


Passo 5 — Elimine duplicação

O mesmo problema dispara:

email;

SMS;

Teams;

PagerDuty;

ticket?

Talvez esteja criando quatro interrupções para um evento.


Passo 6 — Agrupe eventos correlacionados

Uma causa.

Um incidente.

Não vinte alarmes.


Passo 7 — Ajuste thresholds

Use baseline real.

Evite números arbitrários herdados de 2009.


Passo 8 — Melhore mensagens

Inclua:

o que;

onde;

quando;

impacto;

próximo passo.


Passo 9 — Defina ownership

Quem age?

Sem dono, alerta vira decoração.


Passo 10 — Revise periodicamente

Sistema muda.

Carga muda.

Arquitetura muda.

Alerta que fazia sentido dois anos atrás pode hoje ser ruído.


🔁 Alarm Review

Uma boa prática operacional:

reunião periódica apenas para alertas.

Pergunte:

  • quais dispararam mais?

  • quais foram úteis?

  • quais foram ignorados?

  • quais chegaram tarde?

  • quais faltaram?

Observabilidade também precisa de melhoria contínua.


📊 Uma métrica maravilhosa: alert-to-action ratio

Imagine:

1.000 alertas.

20 ações reais.

Temos problema.

Agora:

50 alertas.

40 ações reais.

Muito melhor.

Meta não é “monitorar tudo”.

É criar informação operacionalmente útil.


🧠 Precision versus Recall

Existe trade-off.

Se alertarmos qualquer suspeita:

alta sensibilidade;

muitos falsos positivos.

Se alertarmos só quando certeza é enorme:

podemos perder sinais precoces.

Não existe configuração perfeita.

Precisamos equilibrar.

Isso depende do risco.

Sistema nuclear não usa mesma tolerância de blog pessoal.


🏦 Em sistemas bancários

Alguns alertas precisam ser extremamente sensíveis.

Exemplo:

duplicidade financeira.

fraude.

reconciliação.

Mas mesmo aí:

agrupamento;

priorização;

contexto;

ownership

continuam essenciais.


🔐 Em cybersecurity

SOC conhece Alarm Fatigue profundamente.

Ferramentas podem gerar milhares de eventos.

Se analistas recebem sinal demais:

ameaça verdadeira pode se esconder.

Então segurança moderna investe em:

correlation;

enrichment;

risk scoring;

priorização.

Mesmo problema.

Outra roupa.


🏥 Medicina novamente ensina informática

Alarm Fatigue também é estudada fortemente em ambientes de saúde.

Monitores podem produzir muitos alarmes.

Profissionais expostos repetidamente podem perder sensibilidade.

A lição para TI é clara:

um alarme não é seguro apenas porque existe.

Ele precisa ser percebido, interpretado e gerar ação adequada.


🚨 Designing for Humans

Aqui está o ponto central.

Observabilidade não é apenas engenharia de métricas.

É também engenharia humana.

Precisamos perguntar:

O operador consegue usar isso?

Não:

Conseguimos tecnicamente gerar alerta?

Essa diferença é enorme.


🧠 Alertas também precisam de UX

Interface importa.

Agrupamento.

Cor.

Som.

Prioridade.

Contexto.

Ordenação.

Tudo influencia percepção.

Um painel pode tecnicamente conter toda informação necessária e ainda ser péssimo.


📺 Christmas Tree Dashboard

Existe aquele dashboard maravilhoso:

verde;

amarelo;

vermelho;

azul;

roxo;

piscando;

vinte gráficos.

Parece árvore de Natal.

Impressiona em apresentação.

Durante incidente:

talvez inútil.

Observabilidade boa não é a que possui mais gráficos.

É a que reduz tempo para compreender situação.


🧯 Menos pode ser mais seguro

Isso parece contraintuitivo.

Remover alertas pode aumentar segurança.

Porque aumenta signal-to-noise ratio.

Você não quer silêncio.

Quer sinal claro.


📡 Signal-to-Noise Ratio

Pense:

SINAL ÚTIL
-----------
RUÍDO

Quanto maior:

melhor.

Se dobramos quantidade de alertas sem aumentar informação útil:

ratio piora.


🧠 O alerta perfeito não existe

Alertas precisam evoluir.

Incidente novo ensina:

faltou alerta.

Criamos.

Depois observamos:

dispara demais.

Ajustamos.

Esse é loop de melhoria:

DETECTAR
↓
USAR
↓
MEDIR
↓
AJUSTAR
↓
VALIDAR

Observabilidade é produto vivo.


🧬 Regeneração organizacional

Como regenerar depois de encontrar Alarm Fatigue?

Primeiro:

pare de culpar exclusivamente o operador.

Depois:

meça ruído.

Remova falsos positivos.

Agrupe eventos.

Ajuste thresholds.

Melhore mensagens.

Defina owner.

Crie runbooks.

Revise severidade.

Treine resposta.

E acompanhe:

qual alerta realmente produz ação?


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Alarm Fatigue acontece quando alertas demais reduzem nossa sensibilidade aos alertas importantes.

Um alerta ignorado repetidamente está ensinando comportamento.

False positive consome confiança.

Se tudo é crítico, nada é crítico.

Monitoramento sem ação clara é decoração.

Alertas precisam de ownership.

ACK não significa resolução.

Contexto é melhor que threshold cego.

Agrupar causas reduz tempestade de eventos.

Signal-to-noise ratio importa tanto quanto cobertura.

E principalmente:

Um sistema que grita o tempo inteiro não é necessariamente mais seguro. Talvez apenas esteja ensinando todos a não ouvir.


🕰️ De volta às 14:29

A TARDIS desaparece.

Nosso programador continua olhando para o painel.

Ele resolve pesquisar alertas das últimas 24 horas.

Resultado:

TOTAL ALERTS: 4.812
ACTIONABLE: 37

Ele arregala os olhos.

— Quatro mil?

O operador responde:

— Dia tranquilo.

O jovem começa a separar.

Descobre que três tipos de warning representam 71% de todas as mensagens.

Um deles vem de uma configuração antiga.

Outro dispara em comportamento normal.

O terceiro possui threshold inadequado.

A equipe corrige.

Na semana seguinte:

TOTAL ALERTS: 684
ACTIONABLE: 41

Menos alertas.

Mais ações úteis.

Curioso.

Então aparece:

CRITICAL:
PAYMENT QUEUE GROWTH ABNORMAL

O operador olha imediatamente.

— Esse é novo.

Abre.

Consumer degradado.

Equipe age.

Fila estabilizada.

Nenhum incidente.

Nosso programador sorri.

O operador pega o café.

— Gostei desse alerta.

Essa frase parece banal.

Mas é enorme.

Porque significa:

o alerta recuperou credibilidade.


🥚 Easter Egg final

Mais tarde, aparece um estranho membro:

BELLACOSA.ALERTS(SILENCE)

Dentro:

       IF ALERT-COUNT > HUMAN-CAPACITY
           PERFORM REDUCE-NOISE
       END-IF.

       IF EVERYTHING = 'CRITICAL'
           MOVE 'NOTHING' TO CRITICAL-MEANING
       END-IF.

Abaixo:

* SIGNALS SHOULD INFORM.
* NOT PUNISH.

Outro comentário:

* DON'T BLINK.
* BUT ALSO DON'T BEEP 4,000 TIMES.

Nosso programador ri.

Então encontra a última linha:

* BAD WOLF ACKNOWLEDGED THIS ALERT.

Status:

ACKNOWLEDGED: YES
RESOLVED: NO

Ele imediatamente reabre.

Aprendeu rápido.

O telefone toca.

Novo warning.

Ele não pergunta:

“Posso ignorar?”

Pergunta:

“Esse alerta exige alguma ação?”

Se sim:

age.

Se não:

abre uma tarefa para corrigir o alerta.

Porque finalmente entendeu que manter monitoramento saudável também é trabalho de produção.

E talvez esse seja o grande segredo:

não basta construir sensores.

Precisamos cuidar da capacidade humana de acreditar neles.

VWORP.

VWORP.

VWORP.

Ao longe, a TARDIS desaparece.

No quadro da operação fica uma frase:

Sinais fracos precisam ser audíveis antes de virarem incidentes fortes.

☕🌀

Next stop: Automation Bias — quando a máquina diz “está tudo certo” e nós paramos de acreditar nos próprios olhos.

segunda-feira, 6 de setembro de 2010

A Louca e a Piedosa — como Brasil e Portugal instalaram duas versões diferentes de D. Maria I

Bellacosa Mainframe e a duas versoes da mesma pessoa D. Maria I

☕ Um Café no Bellacosa Mainframe

A Louca e a Piedosa — como Brasil e Portugal instalaram duas versões diferentes de D. Maria I

👑 A mesma rainha atravessou o Atlântico. Em Portugal ficou a memória de Maria, a Piedosa. No Brasil aprendemos Maria, a Louca. Entre as duas existe uma mulher soterrada por Pombal, revoluções, culpa religiosa, doença, Napoleão e dois séculos de historiografia.

Há personagens históricos que possuem uma biografia.

D. Maria I conseguiu duas.

Se você cresceu no Brasil, provavelmente conheceu uma senhora chamada:

D. Maria I, a Louca.

Ela aparece nos livros escolares quase como personagem secundária da história de D. João VI.

A rainha enlouqueceu.

O filho virou príncipe regente.

Napoleão invadiu Portugal.

A família real embarcou às pressas.

Maria chegou ao Rio de Janeiro.

Fim.

NEXT CHAPTER.

Mas atravesse o Atlântico, entre em Portugal e comece a conversar sobre a mesma mulher.

De repente aparece:

D. Maria I, a Piedosa.

Piedosa?

Peraí.

Onde foi parar a louca?

E mais interessante:

onde foi parar aquela rainha quase incapaz que muitos brasileiros aprenderam a imaginar?

Foi justamente esse choque que me fascinou ao conhecer melhor Portugal.

Porque não estamos diante de duas mulheres.

Estamos diante de dois países executando versões diferentes da mesma memória histórica.

//MARIA    JOB 'HISTORIA'

//BRASIL   EXEC PGM=MEMORIA
//PARM     DD *
MARIA_I=A_LOUCA
/*

//PORTUGAL EXEC PGM=MEMORIA
//PARM     DD *
MARIA_I=A_PIEDOSA
/*

SYSTEM:
WARNING — SAME PERSON

E quando aparece esse tipo de inconsistência no banco histórico...

☕ pega o café.

Porque vale abrir o dump.


🇵🇹 Antes da Louca existiu uma rainha perfeitamente funcional

Maria Francisca Isabel Josefa Antónia Gertrudes Rita Joana nasceu em Lisboa em 17 de dezembro de 1734.

Era filha do futuro rei D. José I e de D. Mariana Vitória.

Quando nasceu, ninguém estava esperando que se transformasse numa personagem trágica.

Muito menos que dois séculos depois um país inteiro praticamente resumisse sua existência a uma doença que se manifestaria depois de décadas de vida.

Esse é nosso primeiro problema.

Quando chamamos alguém simplesmente de “Maria, a Louca”, fazemos uma operação historiográfica brutal:

VIDA COMPLETA
████████████████████████████████████

DOENÇA
                         ███████████

MEMÓRIA POPULAR BRASILEIRA
                         █████████████████████

A parte final engoliu todo o resto.

E antes dela existe uma mulher profundamente religiosa, politicamente inserida na corte portuguesa e preparada para ocupar posição dinástica central.

Quando D. José I morreu, em 1777, Maria tornou-se rainha.

E aí aconteceu uma coisa importantíssima:

acabou a era política do Marquês de Pombal.


🧐 Entra em cena Sebastião José de Carvalho e Melo

Para entender a memória de Maria precisamos colocar outro personagem no tabuleiro:

o Marquês de Pombal.

Pombal havia sido o grande ministro de D. José I.

Terremoto de Lisboa de 1755.

Reconstrução.

Reformas administrativas.

Educação.

Economia.

Companhias monopolistas.

Expulsão dos jesuítas.

Centralização do poder.

Processo dos Távoras.

Pombal tornou-se uma das figuras mais poderosas e controversas da história portuguesa.

E aqui nasce uma armadilha historiográfica maravilhosa:

dependendo daquilo que você pensa sobre Pombal, Maria muda de personagem.

Se Pombal é:

grande modernizador racionalista enfrentando forças retrógradas,

então Maria pode aparecer como:

rainha religiosa conservadora que desmontou o projeto modernizador.

Mas se Pombal é:

autoritário brutal que concentrou poder, perseguiu adversários e utilizou violência política,

Maria pode aparecer como:

a rainha que corrigiu abusos do regime anterior.

Mesma mudança política.

Duas interfaces.


🔄 1777: ROLLBACK POMBAL

A ascensão de Maria iniciou aquilo que ficou conhecido como Viradeira.

O nome já é maravilhoso.

Mudou o rei.

Mudou o grupo político.

Mudaram ministros.

Prisioneiros políticos foram libertados.

Pombal perdeu o poder e foi afastado da corte.

Para quem estava associado ao regime anterior, aquilo podia parecer uma enorme purga.

Para vítimas do pombalismo, parecia reparação.

E Maria tinha razões pessoais e políticas para desconfiar daquele homem.

Pombal havia exercido poder extraordinário durante o reinado de seu pai.

O processo dos Távoras, especialmente, deixou uma marca profunda na monarquia portuguesa.

Então Maria assumiu e basicamente executou:

UPDATE PORTUGAL
SET POLICY = 'POST_POMBAL'
WHERE REIGN = 'MARIA_I';

Mas cuidado.

A Viradeira não significou simplesmente:

POMBAL = MODERNIDADE
MARIA  = IDADE_MEDIA

Essa interpretação é confortável demais.

Várias estruturas administrativas e reformas continuaram.

O Estado português não acordou em 1777 e decidiu reinstalar 1450.


🇧🇷 E aqui surge uma hipótese deliciosa

Durante nossa conversa apareceu uma pergunta que merece investigação histórica muito mais profunda:

será que parte da imagem particularmente negativa de Maria transmitida no Brasil foi alimentada pela memória de grupos ligados ao mundo pombalino?

É uma hipótese.

Não devemos transformá-la em fato sem documentação.

Mas é uma excelente pergunta.

Porque a circulação de funcionários, famílias, comerciantes, militares e administradores entre Portugal e Brasil carregava também memórias políticas.

Pessoas não migram somente com malas.

Trazem:

idioma
religião
receitas
ressentimentos
lealdades
inimigos
histórias
versões do passado

E versões históricas sobrevivem de maneira extraordinária.

Talvez haja aí material para investigar como diferentes tradições historiográficas brasileiras consolidaram a expressão “Maria, a Louca”, enquanto a memória portuguesa preservou também “Maria, a Piedosa”.

Não precisamos inventar uma conspiração pombalina.

A pergunta já é fascinante.


⛪ Por que “a Piedosa”?

Porque Maria era profundamente religiosa.

E não “religiosa” no sentido moderno de:

vai à missa domingo.

Estamos falando de uma princesa criada no ambiente católico das monarquias europeias do século XVIII, em que religião, consciência moral, legitimidade política e vida cotidiana estavam profundamente misturadas.

Maria possuía intensa devoção.

Essa religiosidade tornou-se parte central de sua imagem pública.

Daí:

Maria, a Piedosa.

Mas aquilo que inicialmente sustentava sua identidade posteriormente participaria também de seu sofrimento.

Porque Maria aparentemente desenvolveu angústias religiosas intensas, acompanhadas por medo, culpa e preocupação com salvação e condenação.

E então começam as perdas.


💀 O sistema começa a perder componentes

A vida pessoal de Maria foi atingida por uma sequência terrível de mortes.

Seu marido, D. Pedro III, morreu em 1786.

Seu filho mais velho e herdeiro, D. José, príncipe do Brasil, morreu em 1788, vítima de varíola.

Outras perdas familiares e acontecimentos traumáticos se acumularam.

E havia ainda a memória política do reinado anterior e das execuções associadas ao processo dos Távoras.

Maria parece ter desenvolvido obsessões relacionadas à culpa e à condenação.

Hoje é extremamente perigoso fazer diagnóstico psiquiátrico retrospectivo com segurança.

Não temos D. Maria numa clínica moderna.

Não temos prontuário segundo critérios contemporâneos.

Não podemos simplesmente executar:

SELECT diagnosis
FROM DSM_5
WHERE patient='Maria I'
AND year=1792;

Mas sabemos que sua condição mental deteriorou-se seriamente.

E, por volta de 1792, tornou-se incapaz de exercer normalmente as funções de governo.

Seu filho João passou progressivamente a assumir a direção do Estado.


🤴 Entra D. João

Sim.

Aquele D. João.

O futuro D. João VI.

Outro personagem vítima de versões nacionais completamente diferentes.

No imaginário brasileiro durante muito tempo:

gordo, medroso, comedor de frango, fugiu de Napoleão.

Quando começamos a estudar seriamente o contexto:

príncipe governando uma monarquia europeia presa entre França e Inglaterra, realizando uma transferência transatlântica de corte que preservaria a dinastia e transformaria completamente o Brasil.

É outro artigo inteiro.

E talvez justamente por D. João tornar-se protagonista, Maria tenha sido reduzida no Brasil a:

“a mãe louca de D. João.”

Isso é historiograficamente devastador.

A mulher que havia governado Portugal desde 1777 passa a existir apenas como obstáculo biográfico na história do filho.


🧠 “Louca” não é diagnóstico

Aqui precisamos fazer uma parada importante.

Durante séculos, palavras como:

louco, demente, insano, alienado

foram utilizadas de maneiras muito diferentes das categorias médicas contemporâneas.

Quando dizemos hoje:

“Maria era louca”

estamos comprimindo uma condição humana complexa numa caricatura.

Ela efetivamente sofreu uma doença mental incapacitante.

Isso é historicamente relevante.

Mas transformar a doença em nome da pessoa é outra operação.

Imagine alguém governando durante anos, tomando decisões, participando da administração de um império e vivendo inúmeras experiências.

Depois desenvolve uma doença.

E a posteridade executa:

RENAME PERSON
TO DISEASE;

É praticamente isso que ocorreu.


🇫🇷 E então aparece Napoleão

Como se a vida daquela família ainda estivesse tranquila demais.

A Revolução Francesa havia destruído o equilíbrio político europeu.

Depois veio Napoleão.

Portugal possuía um problema geopolítico quase insolúvel.

De um lado:

🇫🇷 França

Do outro:

🇬🇧 Grã-Bretanha

Portugal possuía uma antiga e importantíssima relação com os britânicos.

Napoleão queria impor o Bloqueio Continental contra a Inglaterra.

Portugal tentou ganhar tempo.

Diplomacia.

Negociação.

Ambiguidade.

Mais diplomacia.

Mais tempo.

Até que o relógio acabou.

Em 1807, forças francesas comandadas por Junot avançaram sobre Portugal.


🚢 E a corte faz uma coisa absolutamente insana

A família real portuguesa decide atravessar o Atlântico.

Hoje costumamos dizer:

“A família real fugiu para o Brasil.”

Tecnicamente, sim.

Mas essa formulação esconde a escala da operação.

Não foi:

D. João
D. Maria
duas malas
Uber para o aeroporto

🤣

Foi a transferência de uma corte monárquica, acompanhada por grande quantidade de pessoas, instituições, documentos, recursos e aparato estatal.

A capital política do império português atravessou o oceano.

E dentro daquela frota estava a rainha.

Maria I.

A mulher cuja incapacidade havia obrigado o filho a governar.


😱 “Não corram tanto! Vão pensar que estamos fugindo!”

Existe uma frase famosa atribuída a Maria durante a partida, segundo a tradição:

não deveriam correr daquela maneira, pois poderiam pensar que estavam fugindo.

É maravilhosa.

Talvez maravilhosa demais.

Como sempre, precisamos separar documentação contemporânea de tradição posterior.

Mas perceba por que a frase sobrevive.

Porque transforma a “rainha louca” em alguém que, por um instante, enxerga perfeitamente o absurdo da situação.

Todo mundo correndo.

Carruagens.

Bagagens.

Soldados.

Navios esperando.

Franceses aproximando-se.

E a senhora supostamente considerada incapaz dizendo:

“Tenham compostura, pelo amor de Deus.”

🤣

Se aconteceu exatamente assim ou não, tornou-se uma excelente peça de teatro histórico.


🇵🇹 Portugal ficou

E aqui está uma parte que me impressionou profundamente ao conhecer fisicamente esses lugares.

A família real atravessou o oceano.

Portugal não atravessou.

Ficaram cidades.

Aldeias.

Camponeses.

Militares.

Padres.

Mulheres.

Crianças.

Estradas.

Pontes.

Armazéns.

E vieram os franceses.

Depois britânicos.

Depois portugueses reorganizados.

Vieram invasões sucessivas.

Guerrilha.

Repressão.

Fome.

Destruição.

Política de terra arrasada.

Linhas de Torres Vedras.

Massena.

Wellington.

E uma população inteira tentando sobreviver no meio.

Quando você anda por lugares como Amarante ou pelas regiões associadas às Linhas de Torres Vedras, a história deixa de parecer aquele parágrafo escolar:

“A família real transferiu-se para o Brasil em 1808.”

A frase fica pequena demais.

Image

Image

Image

Image

A pergunta muda:

o que aconteceu com quem ficou?

E então D. João também começa a parecer diferente.


🇧🇷 Enquanto isso, Maria chega ao Rio

Em 1808, a corte portuguesa chegou ao Brasil.

E acontece uma inversão histórica extraordinária:

a colônia passa a receber a monarquia da metrópole.

Maria, já incapacitada, torna-se uma figura estranha naquele cenário.

Era a rainha.

Mas não governava.

Possuía a dignidade máxima.

Mas o filho exercia o poder.

Estava viva.

Mas politicamente pertencia a outro tempo.

E para os brasileiros que conviveram com sua imagem nesse período, aquela era a Maria que conheceram.

Não a jovem princesa.

Não a rainha de 1777.

Não a mulher que afastou Pombal.

Não a soberana ativa.

Mas a senhora idosa e mentalmente doente vivendo no Rio de Janeiro.

E talvez esteja aí uma das explicações mais simples para a divergência das memórias nacionais.


💡 Portugal conheceu o começo da história. O Brasil conheceu o final.

Essa é uma chave poderosa.

Portugal tinha memória de:

MARIA
│
├── princesa
├── sucessora
├── rainha
├── Viradeira
├── governo
├── religiosidade
└── doença

O Brasil recebeu:

MARIA
│
└── doença
    └── corte no Rio

É como assistir somente aos últimos vinte minutos de um filme e depois escrever a biografia da protagonista.

Naturalmente as percepções serão diferentes.


👑 1815: a rainha de um novo Reino

E há uma ironia maravilhosa.

Em 1815, foi criado o Reino Unido de Portugal, Brasil e Algarves.

Portanto aquela velha rainha, incapacitada e vivendo no Rio de Janeiro, tornou-se formalmente soberana de uma entidade política na qual o Brasil deixava de ser simplesmente colônia e era elevado à condição de reino.

Maria I tornou-se:

Rainha do Reino Unido de Portugal, Brasil e Algarves.

A mulher que no imaginário brasileiro ficaria reduzida a “a Louca” estava no trono durante uma das maiores mudanças de status político da história brasileira.

Ela morreu no Rio de Janeiro em 20 de março de 1816.

D. João tornou-se rei.

D. João VI.


⚰️ E Maria atravessaria o Atlântico novamente

Primeiro veio viva.

Depois voltou morta.

Seus restos mortais foram posteriormente trasladados para Portugal e depositados na Basílica da Estrela, em Lisboa — igreja cuja história está profundamente ligada à própria Maria.

É uma espécie de simetria estranha:

PORTUGAL
   │
   │ 1807
   ▼
ATLÂNTICO
   │
   ▼
BRASIL
   │
   │ morte — 1816
   │
   ▼
ATLÂNTICO
   │
   ▼
PORTUGAL

O corpo voltou.

A reputação, porém, ficou dividida entre os dois lados do oceano.


🧠 Hindsight Bias entra novamente na sala

Depois que sabemos que Maria desenvolveu grave doença mental, começamos a reinterpretar episódios anteriores procurando sinais.

Isso é perigosíssimo.

É o mesmo mecanismo que discutimos quando falamos de incidentes de TI:

“Era óbvio que aconteceria.”

Depois do incidente, todo log parece profético.

Antes dele, ninguém sabia qual linha seria importante.

Com Maria acontece algo semelhante.

Sabemos como terminou sua vida.

Então somos tentados a procurar:

religiosidade excessiva!

medo!

culpa!

comportamento estranho!

estava ficando louca!

Calma.

Pessoas religiosas no século XVIII eram...

religiosas.

Precisamos evitar transformar retrospectivamente cada característica da personalidade numa manifestação precoce da doença posterior.


🗺️ E voltamos ao nosso velho problema: quem controla a legenda?

Essa conversa inteira começou muito antes de Maria.

Falamos de leões que escultores nunca tinham visto.

Falamos do rinoceronte que Dürer nunca viu.

Falamos dos monstros colocados nos mapas quando faltavam informações.

E agora encontramos outra versão do mesmo problema:

personagens históricos também são representações.

O Brasil recebeu determinado conjunto de informações sobre Maria.

Portugal preservou outro.

Cada sociedade treinou seu próprio modelo cultural.

TRAINING DATA: BRASIL

Maria velha
Maria doente
D. João regente
fuga da corte
Rio de Janeiro

OUTPUT:

"D. Maria, a Louca"

Enquanto:

TRAINING DATA: PORTUGAL

Maria princesa
Maria rainha
Viradeira
religiosidade
Basílica da Estrela
governo
doença

OUTPUT:

"D. Maria, a Piedosa"

Nenhum modelo contém sozinho a pessoa inteira.


👻 E talvez a verdadeira Maria esteja entre as duas

Essa é a parte que considero mais bonita.

Maria provavelmente não era:

nem apenas a Louca

nem

apenas a Piedosa.

Era uma mulher do século XVIII.

Princesa.

Filha.

Esposa.

Mãe.

Rainha.

Católica profundamente devota.

Adversária política do mundo pombalino.

Soberana de um império.

Mulher submetida a perdas pessoais terríveis.

Pessoa que desenvolveu grave sofrimento mental.

Rainha incapaz.

Passageira involuntária de uma das mais extraordinárias transferências de poder da história.

E finalmente uma senhora que morreu a milhares de quilômetros da cidade onde nasceu.

É muito mais interessante que o apelido.


🇧🇷🇵🇹 Dois países, dois arquivos

Talvez seja por isso que viajar seja tão importante para compreender história.

Você pode ler durante quarenta anos:

D. Maria I, a Louca.

Depois atravessa o Atlântico e encontra:

D. Maria I, a Piedosa.

E acontece aquele maravilhoso:

IEC141I HISTORICAL DATASET CONFLICT

🤣

Você começa a perguntar.

E a pergunta vale mais que decorar outra data.

Porque percebe que história nacional não é necessariamente mentira.

É seleção.

Portugal selecionou determinadas memórias.

Brasil selecionou outras.

A escola simplificou.

A literatura reforçou.

Caricaturas sobreviveram.

Apelidos comprimiram vidas inteiras.

E depois de duzentos anos parece que sempre foi assim.


☕ O Café Bellacosa

Talvez a maior injustiça feita a D. Maria I não tenha sido chamá-la de louca.

Ela realmente sofreu uma doença mental incapacitante.

A injustiça foi transformar essa doença na síntese de sua existência.

É como encontrar alguém no último capítulo e decidir que aquilo explica o livro inteiro.

Portugal também construiu sua versão.

A Piedosa enfatiza religiosidade, devoção e determinado imaginário da soberana.

Também é uma simplificação.

Entre as duas existe uma personagem muito mais interessante.

Uma rainha que chegou ao poder depois de um dos ministros mais poderosos da história portuguesa.

Uma mulher que participou da reversão de parte daquele sistema.

Uma soberana profundamente religiosa.

Uma mãe que enterrou pessoas que amava.

Uma pessoa cuja mente posteriormente entrou em colapso.

Uma rainha que assistiu, já incapaz de governar, à Revolução Francesa destruir o velho mundo europeu.

Que viu Napoleão ameaçar seu reino.

Que atravessou um oceano.

Que terminou seus dias no Rio de Janeiro.

E que, sem poder governar efetivamente, ainda estava viva quando o Brasil deixou formalmente de ser apenas colônia e tornou-se parte do Reino Unido de Portugal, Brasil e Algarves.

Não é pouca biografia.

Mas nós conseguimos compactá-la em:

Maria, a Louca.


🖥️ $HASP395 MARIAI JOB ENDED

//MARIAI   JOB 'MEMORIA'
//STEP01   EXEC PGM=PRINCESS
//STEP02   EXEC PGM=QUEEN
//STEP03   EXEC PGM=VIRADEIRA
//STEP04   EXEC PGM=GRIEF
//STEP05   EXEC PGM=ILLNESS
//STEP06   EXEC PGM=NAPOLEON
//STEP07   EXEC PGM=ATLANTIC
//STEP08   EXEC PGM=BRAZIL

PORTUGAL:
MARIA_I = "A PIEDOSA"

BRAZIL:
MARIA_I = "A LOUCA"

HISTORIAN:
COMPARE DATASETS...

RESULT:
SAME WOMAN.
DIFFERENT MEMORY.

E talvez essa seja a melhor conclusão.

D. Maria I não precisa ser absolvida.

Não precisa ser condenada.

Nem precisamos escolher qual dos dois apelidos está “correto”.

Precisamos fazer algo muito mais difícil:

devolver-lhe a complexidade.

Porque quando Brasil e Portugal instalaram versões diferentes de Maria, cada um preservou um fragmento.

A mulher verdadeira ficou escondida entre os dois.

E talvez viajar, conversar, comparar documentos e desconfiar das versões prontas sirva justamente para isso:

executar, de vez em quando,

RESTORE HUMANITY
FROM HISTORY_BACKUP;

RC=00. ☕👑🇵🇹🇧🇷

domingo, 5 de setembro de 2010

🧠 Uma visão Padawan Storage Engineer, sente-se.

 

Bellacosa Mainframe fala sobre Storage 
Engineer em ibm mainframe zos

🧠 Uma visão Padawan Storage Engineer, sente-se.

Hoje o papo é sério, profundo e cheio de easter eggs:
Monitoramento de Disco em Ambiente IBM Mainframe (z/OS)
(ou: como evitar que o DASD te acorde às 02:37 da manhã)


📜 História rápida (porque storage tem memória longa)

Antes de “elastic storage”, já existia DASD.
E não era luxo: era engenharia.

No mundo mainframe:

  • Disco sempre foi caro

  • I/O sempre foi crítico

  • Planejamento sempre foi obrigatório

Por isso o z/OS nasceu obcecado por controle:

  • Trilhas

  • Cilindros

  • Extents

  • Catálogo

  • Alocação
    Nada é por acaso. Nada é “default inocente”.


💿 DASD – não é disco, é contrato

DASD (Direct Access Storage Device) não é só mídia.
É um modelo lógico estável há décadas.

Mesmo que hoje o storage seja:

  • Flash

  • NVMe

  • Storage definido por software

  • DS8K com magia negra dentro

👉 Para o z/OS, continua sendo 3390.

🧠 Easter Egg clássico:

Você pode trocar todo o storage físico…
…mas o JCL de 1999 continua funcionando.


🧱 3390 – o idioma nativo do z/OS

Estrutura lógica

  • Track

  • Cylinder

  • Volume

  • Extent

Tipos mais comuns:

  • 3390-3 → o feijão com arroz

  • 3390-9 → mais conforto

  • 3390-27 / 54 → ambientes grandes

  • EAV (EAS) → milhões de cylinders

⚠️ Padawan alerta:
EAV resolve espaço, não resolve desorganização.


👀 Por que monitorar disco não é opcional?

Porque no mainframe:

  • Disco cheio não avisa

  • Fragmentação cobra juros

  • Catálogo corrompido vira outage

  • Storage mal planejado vira reunião com diretoria


📊 O que um Storage Engineer DEVE monitorar

🔢 1. Utilização de Volume

  • < 70% → zen

  • 70–85% → atenção

  • 85% → plano de ação

  • 90% → você já perdeu


🧩 2. Fragmentação

  • Muitos extents = mais I/O

  • Sequential sofre

  • VSAM sofre mais ainda

  • Sort chora em silêncio

🧠 Easter Egg:

Fragmentação não mata hoje.
Ela te mata no pico do fechamento mensal.


🧮 3. Número de extents

  • Dataset com 100+ extents é alerta

  • 200+ extents é cirurgia

  • Extents demais = alocação ruim ou volume saturado


📚 4. Catálogo

  • Catálogo cheio = caos

  • Catálogo fragmentado = lentidão

  • Catálogo sem backup = pedido de demissão indireto

Comandos:

LISTCAT ALL

🧠 5. Storage Groups (DFSMS)

Você monitora:

  • Capacidade total

  • Balanceamento

  • Tendência de crescimento

  • Volume “quente”

Comandos úteis:

D SMS,SG D SMS,VOL

🛠️ Ferramentas nativas (o mínimo que você deve dominar)

📟 SDSF

  • DA

  • /D U,DASD,ONLINE

Visual rápido, mas não substitui análise.


🧾 IDCAMS

O velho sábio que nunca mente:

LISTCAT VOLUME(VOL001) ALL

Mostra:

  • Extents

  • Datasets órfãos

  • Fragmentação

  • Bagunça histórica


🧪 SMF (onde mora a verdade)

Se você quer ser engenheiro de verdade, vá para:

  • SMF 42 (DFSMS)

  • SMF 78 (Storage)

  • SMF 14/15 (dataset activity)

📌 Hot take Bellacosa™:

Quem não olha SMF, administra no escuro.


🧙‍♂️ Ferramentas enterprise (o lado premium da Força)

  • IBM OMEGAMON

  • BMC MainView

  • Broadcom SYSVIEW

Alertas comuns:

  • Volume acima do threshold

  • Storage Group desequilibrado

  • Crescimento anormal

  • Tendência explosiva


🧪 Caso real (história de guerra)

Batch falhando aleatoriamente.
Erro muda todo dia.

Causa real:

  • Volume temporário com 88%

  • Crescimento não monitorado

  • Sort concorrente em pico

Correção:

  • Redistribuição de volumes

  • Aumento de pool

  • Monitoramento de tendência

📌 Moral:
Storage não quebra.
Ele acumula dívida técnica.


🧠 Curiosidades que só storage engineer aprende sofrendo

  • Dataset “temporário” criado em 2003 ainda ativo

  • Volume “de teste” com dado crítico

  • SMS class herdada de outro CPD

  • Storage flash com comportamento de fita (sim, acontece)


🧭 Dicas Bellacosa Mainframe™ para Padawan Storage

✔️ Monitore tendência, não só status
✔️ Espaço livre sem balanceamento é ilusão
✔️ EAV não é desculpa para relaxar
✔️ Catálogo merece carinho diário
✔️ Documente storage group (ninguém faz, todos sofrem)
✔️ Nunca confie em “esse volume sempre foi assim”


☕ Encerrando o café…

Ser Storage Engineer no z/OS não é só administrar disco.
É:

  • Prever

  • Planejar

  • Equilibrar

  • Proteger

  • E evitar que alguém te ligue fora do horário 😄

💬 “No mainframe, storage não é onde os dados moram.
É onde a estabilidade vive.”

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...