Mostrar mensagens com a etiqueta controle. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta controle. Mostrar todas as mensagens

domingo, 18 de janeiro de 2026

Single Source of Truth (SSOT): a verdade nua, crua… e versionada

 

Bellacosa Mainframe e o conceito de single source of truth

Single Source of Truth (SSOT): a verdade nua, crua… e versionada

Se existe um conceito que todo arquiteto, analista, DBA, operador e até estagiário já ouviu — e todo mundo acha que já tem — esse conceito é o tal do Single Source of Truth.
Spoiler: quase ninguém tem de verdade. E no mainframe isso é ainda mais sagrado (e mais difícil).

Senta que lá vem história.


🧠 Origem: quando a verdade ainda cabia em um arquivo VSAM

Antes de buzzwords, cloud, data mesh e dashboards coloridos, o SSOT já existia — só não tinha nome chique.

Nos anos 60/70, no mundo IBM Mainframe, a regra era simples:

“Existe um dado oficial. O resto é cópia, relatório ou dor de cabeça.”

  • Um master file VSAM

  • Um DB2 table owner bem definido

  • Um CICS que mandava na regra de negócio

Se o saldo do cliente estava no arquivo X, qualquer outro valor estava errado, não “divergente”.

👉 Isso era SSOT by design, não por moda.


📜 Definição curta (para colar na parede da sala)

Single Source of Truth é a fonte única, autorizada e confiável de um dado, regra ou estado de negócio.

  • Não é só onde o dado está

  • É quem manda nele

  • É quem pode mudar

  • É quem responde quando dá problema

No mainframe, isso sempre foi levado a sério porque…
💸 erro de dado = dinheiro real sumindo.


🏗️ SSOT no Mainframe: raiz forte, galhos controlados

No mundo IBM Mainframe, o SSOT normalmente assume estas formas:

  • 📦 DB2 → verdade transacional

  • 📁 VSAM KSDS/ESDS → registros mestres históricos

  • 🧠 CICS → verdade das regras online

  • 📊 SMF/RMF → verdade operacional

  • 🔐 RACF → verdade de segurança (e ponto final)

E aqui vai a regra de ouro, estilo Bellacosa:

Se dois sistemas “mandam” no mesmo dado… nenhum manda.


⚠️ O problema moderno: todo mundo quer sua própria verdade

Com a chegada de:

  • Data Lakes

  • BI Self-Service

  • Microservices

  • Replicações near-real-time

  • APIs para tudo

Nasceu o monstro de três cabeças:

🧟 A Verdade Paralela
🧟 A Verdade de Cache
🧟 A Verdade do PowerPoint

Cada área passa a ter:

  • “Meu dado”

  • “Meu relatório”

  • “Minha métrica”

E quando os números não batem…

👉 a culpa é do mainframe, claro 😏


🧩 Formatos de SSOT (sim, existem vários)

1️⃣ SSOT Transacional

  • Fonte: DB2 / CICS

  • Uso: sistemas core

  • Alta integridade

  • Baixa tolerância a erro

💡 Mainframe é rei aqui.


2️⃣ SSOT Analítico

  • Fonte: DW / Lakehouse

  • Uso: BI, KPIs

  • Risco: latência e transformação

⚠️ Não confundir com verdade operacional.


3️⃣ SSOT de Configuração

  • Fonte: repositórios únicos

  • Ex: parâmetros, tabelas de domínio

🧨 Dica: tabela “copiada” em cada sistema não é SSOT.


4️⃣ SSOT de Governança

  • Catálogos de dados

  • Data lineage

  • Glossário corporativo

📚 Onde a verdade é documentada, não só armazenada.


🛠️ Dicas práticas (da trincheira, não do slide)

✔️ Defina ownership real

“Quem acorda às 3h da manhã se der erro?”

✔️ Separe dado de consumo

  • Origem ≠ réplica ≠ cache

✔️ Documente a verdade

  • Se não está escrito, vira lenda urbana.

✔️ Controle quem escreve

  • Ler é democrático. Escrever não.

✔️ Mainframe como âncora

  • Sistemas modernos orbitam. O core não flutua.


💣 Riscos clássicos (a lista da vergonha)

  • ❌ Duas bases “oficiais”

  • ❌ ETL que “corrige” dado

  • ❌ BI explicando divergência em reunião

  • ❌ Regra de negócio fora do core

  • ❌ “É só um relatório…”

⚠️ Relatório nunca é inocente.


🧪 Curiosidades & Easter Eggs

🥚 Easter Egg #1

Muitos sistemas “modernos” recriam SSOT… e descobrem 30 anos depois o que o CICS já fazia.

🥚 Easter Egg #2

RACF é um dos SSOTs mais respeitados da empresa — ninguém questiona.

🥚 Easter Egg #3

O termo SSOT ficou famoso com BI, mas nasceu no batch noturno.


🧠 Reflexão final (El Jefe mode ON)

SSOT não é tecnologia.
É disciplina organizacional.

Você pode ter:

  • Cloud

  • Kafka

  • Lakehouse

  • AI

  • Dashboard bonito

Mas se não souber qual dado é o oficial

👉 Você só tem várias mentiras bem organizadas.


☕🌙 Midnight Lunch Thought
No fim do dia (ou da madrugada):
quem controla a verdade controla o sistema.
E historicamente…
o mainframe sempre soube disso.


quarta-feira, 18 de outubro de 2017

Quem construiu a maquete ferroviária de Campinas?

A cabine 2 abriga uma ferrovia em seu interior

Um grupo de amigos há 10 anos atrás juntaram-se e começaram a trabalhar para por em pratica um sonho. Construir uma ferrovia em escala, com um trabalho sem parar, construíram mais de 300 metros de trilhos distribuídos em 3 níveis, criaram um diorama que representa a Estação Central de Campinas com varias estruturas, uma refinaria de petróleo, armazéns e silos, casa e botecos, pessoas e animais. 

No material ferroviário existem diversas locomotiva a vapor, elétricas e diesel,  vagões de carga e carruagens de passageiro, lindo de ser ver, perde-se a noção do tempo, assistindo o vai e vem das composições, o comboio parte da plataforma principal, gruas se movimentam com contentores.

O grau de realismo espanta vendo a vegetação rasteiro, as arvores, as construções com desgaste do tempo, as pontes em madeira, pontes em ferro. Tudo construído com profissionalismo e esmero para para comporem o cenário.

Quem curte maquetes em escala H0 tem a obrigação de visitar o complexo da Fepasa em Campinas. Aqui na sala de controle existe uma ferrovia em miniatura que encantara a todos. 

O que é a Cabine de controle número 2?

É uma construção singular, situada na Estação Ferroviária de Campinas no sentido interior, próximo a a antiga plataforma da Mogiana. Sua função era controlar os movimentos das locomotivas e locomotoras nos diversos ramais que existiam na estação, através de alavancas mecanizadas abria-se ou fechava-se um desvio para outro trilho. Em suas paredes havia mostradores analógicos que indicavam o status da linha e a movimentação no local. O mostradores eram eletro-mecânicos numa era em que tudo era a válvulas, testemunhas de um tempo em que não existiam computadores nem celulares.






segunda-feira, 4 de janeiro de 2016

Barco de controle remoto na lagoa do Parque da Juventude

Speedy a lancha amarela navegando na lagoa.

Os brinquedos de controle remoto são uma tentação, feito para crianças mas usada para adultos se divertirem. :)

Eu e o formiguinha costumamos brincar na lagoa do parque, ligamos a lancha e vamos la... é uma diversão ver o barquinho vencendo a agua, principalmente por q o espaço é controlado, então qualquer problemas entramos no rasinho e pegamos o barco.


O lado curioso é que normalmente escolhemos um lado vazio da lagoa, porem após algum tempo brincando surge aquela garotada toda, uns mais afoitos, outros mais calmos e é sempre aquela confusão.

O formiguinha se irrita e logo começa , vamos embora, ou as vezes ele grita Vaguinhooooo, sei que deve ter algum menino importunando.

sexta-feira, 1 de outubro de 2010

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz

 

Bellacosa Mainframe apresenta o RACF 

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz 

Se você já perdeu acesso ao próprio TSO, já bloqueou produção com um PERMIT mal dado, ou já ouviu

“foi só uma alteração de RACF…”
então este texto é para você.

Aqui não tem introdução infantil.
Aqui é RACF raiz, técnico, sistêmico e perigoso — do jeito que veterano respeita.


🕰️ História & Origem — por que o RACF nasceu paranoico

O RACF (Resource Access Control Facility) surge nos anos 70, quando a IBM percebeu que:

  • Controle por good behavior não escala

  • Segurança precisava ser centralizada

  • Auditoria não podia ser opcional

RACF foi desenhado para:

  • Negar por padrão

  • Controlar quem, o quê, quando e como

  • Integrar com o núcleo do z/OS

Verdade inconveniente:

RACF não confia nem no SYSADM. E está certo.


🔐 Por onde começar com Segurança (visão de veterano)

Segurança não começa no comando. Começa no modelo mental.

Princípios reais:

  • Least Privilege

  • Segregation of Duties

  • Accountability

  • Auditabilidade

🔥 Easter egg:
Ambiente “funcionando” ≠ ambiente “seguro”.


🏗️ A Estrutura de Grupos — o esqueleto invisível

Grupos RACF não são “organizacionais”.
São domínios de autoridade.

  • Grupos pais controlam filhos

  • OWNER ≠ SUPGROUP

  • Hierarquia mal desenhada vira bomba relógio

📌 Exemplo técnico:

ADDGROUP FINANCE SUPGROUP(SYS1) OWNER(SYS1)
ADDGROUP FINANCE.PAYROLL SUPGROUP(FINANCE)

Comentário ácido:

Grupo mal definido é privilégio eterno.


⌨️ Os Comandos RACF — bisturis, não martelos

  • ADDUSER / DELUSER

  • ADDGROUP / DELGROUP

  • CONNECT / REMOVE

  • PERMIT

  • ALTUSER / ALTGROUP

  • SETROPTS

🔥 Regra de Produção:

Se você não sabe desfazer, não execute.


🗑️ Definindo & Excluindo Grupos RACF

Criar grupo é fácil.
Excluir é trauma.

Antes de um DELGROUP:

  • Usuários conectados?

  • Perfis com OWNER?

  • DATASET PROFILE ownership?

  • Surpresas em ACL herdada?

Fofoquice técnica:
DELGROUP em produção é evento histórico.


👤 Definindo Usuários — mais que um ID

Um usuário RACF é:

  • Identidade

  • Responsabilidade

  • Risco

Campos críticos:

  • SPECIAL / OPERATIONS / AUDITOR

  • PASSWORD interval

  • REVOKE / RESUME

  • OMVS / DFP / CICS

📌 Exemplo:

ADDUSER JOSE NAME('JOSE SILVA') DFLTGRP(FINANCE) PASSDATE(30)

🔥 Easter egg:
Usuário genérico é pecado capital.


🔗 Conectando Usuários a Grupos

CONNECT é onde a segurança realmente acontece.

  • AUTHORITY (USE, READ, CONNECT, JOIN)

  • GROUP-SPECIAL

  • OWNER implícito

Verdade nua:

CONNECT errado é privilégio que ninguém vê.


🗂️ Perfis de Conjunto de Dados (DATASET PROFILES)

O coração do RACF clássico.

  • HLQ como fronteira de poder

  • DISCRETIONARY ≠ MANDATORY

  • UACC mal definido = vazamento

📌 Exemplo:

ADDSD 'FINANCE.PAYROLL.**' OWNER(FINANCE) UACC(NONE)
PERMIT 'FINANCE.PAYROLL.**' ID(PAYUSR) ACCESS(READ)

🔥 Curiosidade:
UACC(READ) já causou mais incidente que bug de COBOL.


🌐 Perfis Gerais de Recursos (CLASS Profiles)

Aqui o RACF vira onipresente:

  • CICS

  • IMS

  • MQ

  • SDSF

  • OPERCMDS

  • FACILITY

El Jefe warning:

Quem ignora classe FACILITY não entende z/OS moderno.


🧨 Recursos Especiais do RACF

  • SPECIAL

  • OPERATIONS

  • AUDITOR

  • TRUSTED

  • WARNING vs FAIL

🔥 Comentário venenoso:
SPECIAL demais é insegurança institucionalizada.


⚙️ O Comando SETROPTS — o painel nuclear

SETROPTS controla:

  • Ativação de classes

  • Auditoria

  • Regras globais

  • Password rules

📌 Exemplo:

SETROPTS CLASSACT(DATASET) RACLIST(DATASET) REFRESH

☕🔥 Regra sagrada:

SETROPTS sem planejamento vira outage invisível.


🔄 RACF Remote Sharing Facility (RRSF)

RACF em modo distribuído:

  • Compartilhamento de identidades

  • Replicação de perfis

  • Confiança entre sistemas

🔥 Curiosidade:
RRSF mal configurado espalha erro em escala industrial.


🔗 RACF e Sysplex — segurança em cluster

No Sysplex:

  • Database compartilhado

  • Consistência obrigatória

  • Propagação imediata

Verdade dura:

No Sysplex, erro local vira problema global.


🧪 Programas Utilitários RACF

Ferramentas para quem não vive no ISPF:

  • IRRDBU00

  • IRRUT200

  • IRRICE

  • unloads para auditoria

  • Análise offline

🔥 Easter egg veterano:
Auditor sério não confia só em LISTUSER.


🧠 Mentalidade de Segurança Mainframe (nível veterano)

✔️ Segurança é processo, não produto
✔️ Tudo que não está definido será explorado
✔️ RACF não protege sistema — protege negócio
✔️ Auditor não é inimigo
✔️ Log é prova histórica


🥚 Easter Eggs & Fofoquices RACF

  • Todo ambiente tem um ID “histórico”

  • Sempre existe um dataset que “ninguém sabe de quem é”

  • Segurança forte incomoda — e é esse o objetivo

  • Incidente sério sempre começa com:

    “Mas esse acesso sempre existiu…”


☕🔥 Conclusão — Manifesto El Jefe RACF

RACF não é:

  • Cadastro

  • Burocracia

  • Entrave

RACF é:

  • Arquitetura de confiança

  • Controle de risco

  • Linha final de defesa do z/OS

☕🔥 Se você domina RACF,
você não protege arquivos —
protege a empresa inteira.