 |
| Bellacosa Mainframe analisando logs |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
💀 ARC E O SMF DA EMPRESA INTEIRA — COMO CONSTRUIR A CAIXA-PRETA CORPORATIVA SEM CRIAR O BIG BROTHER
SMF, COBOL, RACF, CICS, Db2, IAM, APIs, Cloud, EDR, SIEM, OpenTelemetry, grafos, Zero Trust, fraude, privacidade — e o dia em que Arc descobriu que investigar um incidente não significa vigiar uma pessoa.
🎬 PRÓLOGO — ARC ENCONTROU UMA DUNGEON MUITO ESTRANHA
Arc já havia acordado em mundos piores.
Virar um cavaleiro esqueleto gigantesco usando uma armadura pesada definitivamente não estava entre as experiências mais comuns de um programador.
Mas aquilo era diferente.
Não havia goblins.
Não havia dragões.
Não havia necromantes.
Na frente dele existia apenas um terminal 3270.
Na tela:
SDSF PRIMARY OPTION MENU
COMMAND INPUT ===>Arc aproximou-se.
— Bellacosa-san... que espécie de magia ancestral é essa?
— Isso, meu caro esqueleto, é um mainframe.
Arc colocou a mão sobre a espada.
— Parece perigoso.
— E é. Digite qualquer coisa errada em produção numa sexta-feira às 17:58 e você descobrirá.
Arc prudentemente afastou a mão do teclado.
Foi então que apareceu nossa missão.
Uma empresa havia identificado uma transferência financeira suspeita.
O dinheiro passara por vários sistemas:
Internet
↓
API Gateway
↓
Cloud
↓
MQ
↓
CICS
↓
COBOL
↓
Db2
↓
PagamentoO problema era descobrir:
o que aconteceu antes da transferência?
Arc perguntou:
— Não existe algum registro dizendo isso?
Sorri.
— Existe uma coisa no mainframe chamada SMF.
— Então basta consultar o SMF?
— Não exatamente. Porque metade da história aconteceu fora do mainframe.
Arc olhou novamente para o terminal.
E então nasceu nossa pergunta:
🕵️ QUAL SERIA O “SMF” DE UMA EMPRESA INTEIRA?
🦖 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É SMF?
Se você está começando em COBOL e z/OS, provavelmente encontrará cedo ou tarde estas três letras:
SMF — System Management Facilities.
Simplificando bastante, podemos imaginar o SMF como um enorme mecanismo de registro de eventos do z/OS.
O sistema operacional e diversos componentes podem produzir registros descrevendo acontecimentos importantes.
Por exemplo:
JOB iniciou
JOB terminou
STEP executou
recurso foi utilizado
atividade de segurança ocorreu
dataset foi acessado
subsistema executou determinada operaçãoEsses registros possuem estruturas conhecidas.
Existem diferentes tipos e subtipos de registros SMF.
O resultado é algo extraordinariamente importante para operação, capacidade, auditoria, segurança, accounting, performance e investigação.
Imagine:
14:03:11 USER01 submeteu JOB12345
14:03:12 JOB12345 iniciou
14:03:13 STEP01 executou PROG001
14:03:14 PROG001 acessou recursos
14:03:18 STEP01 terminou
14:03:19 JOB12345 terminouAgora imagine que algo deu errado.
Você pode reconstruir parte da história.
Essa palavra será fundamental durante todo este artigo:
história.
Porque segurança moderna não deveria procurar apenas eventos isolados.
Ela deveria conseguir reconstruir sequências de acontecimentos.
🧙 CAPÍTULO 2 — ARC DESCOBRE QUE O MUNDO DISTRIBUÍDO É UMA BAGUNÇA
Arc achou aquilo simples.
— Então instalamos SMF em todos os computadores!
Infelizmente não funciona assim.
O ambiente corporativo moderno pode possuir:
Windows
Linux
macOS
Android
iOS
Azure
AWS
Google Cloud
Kubernetes
firewalls
VPN
ZTNA
Active Directory
Entra ID
API Gateways
Kafka
MQ
Oracle
Db2
PostgreSQL
CICS
IMS
z/OS
aplicações Java
aplicações COBOL
SaaS
e-mail
sistemas financeiros
controle de acesso físicoCada plataforma produz seus próprios registros.
Pior:
cada uma fala seu próprio dialeto.
Uma pode registrar:
USER=JOAOOutra:
principal=j.silva@empresaOutra:
uid=83921Outra:
RACFID=JSILVATalvez sejam todos a mesma pessoa.
Talvez não.
Bem-vindo à primeira dungeon.
🧩 CAPÍTULO 3 — O PROBLEMA NÃO É TER LOGS
Grandes empresas normalmente possuem uma quantidade monstruosa de logs.
A dificuldade é responder:
Como relacionar acontecimentos espalhados por dezenas de tecnologias?
Imagine nosso funcionário fictício USER042.
Às 08:01:
PHYSICAL ACCESS
identity=USER042
door=HQ-ENTRANCE
result=GRANTEDÀs 08:07:
IAM
identity=USER042
device=NOTEBOOK221
action=LOGIN
result=SUCCESS08:13:
EMAIL
identity=USER042
action=OPEN_ATTACHMENT
message=M88219308:14:
EDR
device=NOTEBOOK221
parent=OUTLOOK.EXE
process=POWERSHELL.EXE08:15:
IAM
identity=USER042
action=TOKEN_REQUEST
application=CLOUD08:17:
API
identity=USER042
endpoint=/customer/export
status=20008:18:
DB2
authid=APISRV1
table=CUSTOMER
operation=SELECT
rows=284931Separadamente, temos sete registros.
Mas Arc colocou os registros sobre a mesa e enxergou outra coisa:
EMAIL
↓
ATTACHMENT
↓
ENDPOINT
↓
POWERSHELL
↓
TOKEN
↓
API
↓
DB2
↓
284.931 ROWSAgora temos uma narrativa técnica.
E isso muda completamente a investigação.
🔗 CAPÍTULO 4 — CORRELAÇÃO É A VERDADEIRA MAGIA
Pense numa aplicação moderna chamando um programa COBOL.
O usuário abre o navegador:
Browserque chama:
API Gatewayque chama:
Java Microserviceque publica:
IBM MQque aciona:
CICSque executa:
PROGCOB1que finalmente executa:
UPDATE CONTA
SET SALDO = ...no Db2.
Cada plataforma pode conhecer apenas seu pedaço.
O navegador conhece uma sessão.
A API conhece uma requisição.
MQ conhece uma mensagem.
CICS conhece uma transação.
COBOL conhece dados recebidos.
Db2 conhece determinado acesso.
Precisamos transportar identificadores que permitam correlacionar tudo isso.
Algo conceitualmente semelhante a:
event_id
timestamp
actor_id
device_id
session_id
trace_id
transaction_id
source
target
action
resultImagine:
TRACE-ID=ABC99172atravessando:
API
↓
Java
↓
MQ
↓
CICS
↓
COBOL
↓
Db2Agora podemos reconstruir a jornada.
Essa ideia aproxima o velho universo transacional do mainframe das técnicas modernas de distributed tracing.
O OpenTelemetry trabalha justamente com conceitos de traces, métricas e logs e com convenções semânticas destinadas a tornar a telemetria mais consistente entre tecnologias.
O velho COBOLzeiro pode olhar isso e pensar:
— Rapaz... o mundo inventou um negócio sofisticado para descobrir por onde passou uma transação.
Sim.
Bem-vindo ao século XXI.
😎
💀 CAPÍTULO 5 — ARC DESCOBRE O CORPORATE SMF
Vamos dar um nome à nossa arquitetura:
CORPORATE EVENT FABRIC
Ela receberia eventos de diferentes domínios:
IAM ───────────────┐
Endpoint ──────────┤
E-mail ────────────┤
Network ───────────┤
Cloud ─────────────┤
API ───────────────┤
Applications ──────┤
Databases ─────────┼──► EVENT FABRIC
Payments ──────────┤
Physical Access ───┤
Kafka/MQ ──────────┤
RACF ──────────────┤
CICS ──────────────┤
Db2 ───────────────┤
SMF ───────────────┘Mas atenção.
Isso não significa simplesmente:
“Jogue todos os logs num SIEM.”
O SIEM seria apenas um dos consumidores.
Outros poderiam ser:
SOC
Incident Response
Fraud Detection
Forensics
IAM
Zero Trust
Compliance
Observability
SOAR
AI AgentsO Corporate Event Fabric seria uma espécie de memória factual corporativa.
👁️ CAPÍTULO 6 — E NASCE O BIG BROTHER
Arc ficou animado.
— Então podemos registrar absolutamente tudo!
Silêncio na sala.
— Arc...
— Sim?
— Foi exatamente aí que você quase criou o vilão da história.
Porque tecnicamente poderíamos produzir:
08:01 funcionário entrou
08:07 ligou notebook
08:11 abriu e-mail
08:31 acessou sistema
09:17 imprimiu documento
09:31 saiu da sala
09:47 entrou em outra sala
10:02 retornouIsso seria extraordinariamente poderoso para investigação.
Mas poderia facilmente virar:
FUNCIONÁRIO FICOU 47 MINUTOS INATIVO.
FUNCIONÁRIO CHEGOU 11 MINUTOS ATRASADO.
FUNCIONÁRIO FOI AO BANHEIRO 6 VEZES.Acabamos de atravessar uma fronteira.
Saímos de:
observabilidade
para:
vigilância.
A diferença não é apenas tecnológica.
É arquitetural, organizacional, jurídica, ética e cultural.
🛡️ CAPÍTULO 7 — REGISTRE EVENTOS, NÃO VIDAS
Aqui surge uma regra fundamental.
O Corporate SMF não deveria perguntar constantemente:
Onde está João?
Ele deveria registrar acontecimentos necessários para finalidades claramente estabelecidas.
Por exemplo, talvez não seja necessário armazenar:
VAGNER entrou no DATACENTER.Podemos registrar:
actor=ENTITY-A91F27
zone=DATACENTER
action=ENTRY
result=GRANTED
timestamp=02:14:31A relação:
ENTITY-A91F27 = pessoa realpode ficar protegida em outro domínio.
Somente uma investigação devidamente autorizada poderia solicitar a resolução da identidade.
Isso cria algo muito interessante:
pseudonimização operacional.
O sistema consegue correlacionar:
ENTITY-A91F27através de vários eventos sem necessariamente revelar imediatamente quem está por trás daquele identificador.
🧅 CAPÍTULO 8 — AS TRÊS CAMADAS DA CEBOLA DE ARC
Arc sugeriu dividir a arquitetura.
Desta vez o esqueleto acertou.
Camada 1 — EVIDENCE
Aqui registramos fatos.
event_id=9917821
actor=ENTITY-A91F27
device=DEVICE-882
action=READ
resource=DB:CUSTOMER
result=SUCCESS
timestamp=...Nada de:
USER_IS_EVIL=YESou:
EMPLOYEE_SUSPICIOUS=87%O evento deve dizer:
o que aconteceu.
Camada 2 — DETECTION
Agora podemos correlacionar acontecimentos.
Exemplo:
NEW DEVICE
+
UNUSUAL HOUR
+
PRIVILEGE ELEVATION
+
MASSIVE EXPORTResultado:
RISK_EVENT=R991Observe a diferença.
Não estamos dizendo:
USER=CRIMINALEstamos dizendo:
ESTA SEQUÊNCIA MERECE INVESTIGAÇÃO.Isso é profundamente diferente.
Camada 3 — INVESTIGATION
Somente uma investigação autorizada acessaria uma timeline ampliada:
RISK_EVENT
↓
RELATED EVENTS
↓
DEVICES
↓
IDENTITIES
↓
RESOURCES
↓
FULL TIMELINEAssim separamos:
registro factual → detecção → investigação.
🕸️ CAPÍTULO 9 — ARC ENTRA NA DUNGEON DOS GRAFOS
Agora vem uma das partes mais interessantes.
Não pense apenas em linhas de log.
Pense em nós e relacionamentos.
Temos:
USER
DEVICE
TOKEN
GROUP
API
APPLICATION
QUEUE
CICS TRANSACTION
COBOL PROGRAM
DATABASE
ACCOUNT
PAYMENTE relações:
USER ─uses────────► DEVICE
USER ─member_of───► GROUP
USER ─owns────────► TOKEN
TOKEN ─calls──────► API
API ─publishes────► MQ
MQ ─triggers──────► CICS
CICS ─executes────► COBOL
COBOL ─accesses───► DB2Isso cria um Event Graph.
Mas podemos ir mais longe.
Podemos combinar:
IDENTITY GRAPH
+
PRIVILEGE GRAPH
+
RESOURCE GRAPH
+
EVENT GRAPH
+
TEMPORAL GRAPHAí a investigação muda completamente.
Em vez de procurar:
USER042em 38 ferramentas diferentes, perguntamos:
Quais caminhos relacionam USER042 ao pagamento PAY991 durante a janela de 30 minutos anterior ao evento?
Isso é praticamente investigação forense como graph traversal.
💰 CAPÍTULO 10 — FRAUDE DEIXA DE SER UMA TRANSAÇÃO
Sistemas antifraude tradicionalmente podem observar algo como:
PIX
valor=800000
destino=NOVO
horario=02:11E calcular risco.
Mas nosso Corporate SMF permite perguntar:
O que aconteceu antes desse PIX?
Talvez encontremos:
01:51 phishing
↓
01:55 attachment opened
↓
01:56 PowerShell
↓
02:01 credential/token
↓
02:03 VPN
↓
02:07 privilege elevation
↓
02:09 API
↓
02:10 MQ
↓
02:10 CICS
↓
02:10 COBOL
↓
02:11 PAYMENTAgora a pergunta deixou de ser:
“Esta transação é estranha?”
Passou a ser:
“Qual história produziu esta transação?”
Essa mudança é gigantesca.
🏢 CAPÍTULO 11 — QUANDO O MUNDO FÍSICO ENCONTRA O DIGITAL
Controle físico pode enriquecer investigações.
Imagine:
02:03 VPN LOGIN
country=BRe simultaneamente:
02:04 BADGE ENTRY
location=LONDONNão precisamos concluir automaticamente:
FRAUDE!
Talvez exista explicação.
Credencial compartilhada.
Erro de relógio.
Sistema de badge mal integrado.
VPN.
Conta técnica.
Evento duplicado.
Mas podemos produzir:
ANOMALY:
incompatible physical/digital presenceO sistema apresenta a inconsistência.
O investigador decide o significado.
Essa separação é fundamental.
🔐 CAPÍTULO 12 — ZERO TRUST ENCONTRA O CORPORATE SMF
Antigamente poderíamos pensar:
LOGIN SUCCESS
↓
TRUSTEDZero Trust muda isso.
A autenticação é apenas uma evidência.
Podemos ter:
IDENTITY OK
DEVICE OK
MFA OK
LOCATION UNUSUAL
RESOURCE CRITICAL
BEHAVIOR UNUSUAL
TRANSACTION HIGH VALUEA política poderia responder:
STEP-UP AUTHENTICATIONou:
ALLOW + MONITORou:
DENYO Corporate Event Fabric fornece contexto para decisões desse tipo.
📦 CAPÍTULO 13 — NÃO COPIE O UNIVERSO
Outro princípio fundamental:
metadado antes de conteúdo.
No e-mail talvez precisemos registrar:
sender_hash
recipient_hash
message_id
attachment_hash
attachment_type
timestamp
delivery_resultNão precisamos necessariamente guardar:
BODY COMPLETO DO EMAILPara banco de dados, talvez seja suficiente:
actor
database
table
operation
rows
query_fingerprintem vez de copiar:
CPF
SALARIO
ENDERECO
DADOS PESSOAISO Corporate SMF deveria saber que uma interação ocorreu.
Não necessariamente possuir uma cópia de tudo que participou dela.
Isso reduz:
exposição;
armazenamento;
impacto de vazamentos;
risco de privacidade;
complexidade regulatória.
🧊 CAPÍTULO 14 — HOT, WARM, COLD E ARCHIVE
Existe ainda um problema brutal:
volume.
Uma empresa grande pode gerar quantidades absurdas de eventos.
Portanto podemos trabalhar com camadas:
HOT
alta resolução
horas/dias
WARM
eventos normalizados
semanas/meses
COLD
eventos relevantes
meses/anos
ARCHIVE
retenção regulatóriaE existe uma técnica particularmente interessante:
Progressive Evidence Preservation
Normalmente:
TELEMETRY=NORMALSurge um incidente:
RISK DETECTEDEntão aumentamos temporariamente:
TELEMETRY=DETAILEDe preservamos evidências relacionadas.
É quase como colocar:
DISPLAY TRACE=ONquando algo começa a cheirar estranho.
O velho operador de mainframe já conhece essa filosofia há décadas.
🧨 CAPÍTULO 15 — MAS E SE O ATACANTE APAGAR O LOG?
Arc levantou a mão.
— Mestre, se eu dominar o servidor, posso apagar meus rastros?
Muito bem observado.
Se o atacante controla:
SERVER01não podemos depender exclusivamente de:
SERVER01.LOGO ideal é transportar eventos rapidamente para outro domínio:
SERVER01
│
▼
COLLECTOR
│
▼
IMMUTABLE EVENT STOREPodemos acrescentar mecanismos como:
append-only
WORM
hashing
signatures
restricted deletion
segregation of duties
independent credentialsE surge uma regra deliciosa:
O CORPORATE SMF PRECISA TER UM SMF DO CORPORATE SMF.
Sim.
Recursão.
😎
Se alguém alterar políticas de retenção:
registre.
Se alguém consultar uma investigação:
registre.
Se alguém exportar eventos:
registre.
Se alguém tentar apagar eventos:
registre.
🕵️ CAPÍTULO 16 — QUEM VIGIA O INVESTIGADOR?
Aqui mora um dos controles mais importantes.
Imagine:
SEARCH
employee=FULANO
period=365 daysEssa consulta é extremamente invasiva.
Portanto ela também deveria gerar evidência:
AUDIT_ACCESS
investigator=SECURITY17
case=INC82991
reason=FRAUD
scope=TIMELINE
timestamp=...Para casos especialmente sensíveis poderíamos exigir:
SOC
+
COMPLIANCE
+
CASE-IDantes de revelar identidade.
É o princípio das duas chaves.
Nenhum administrador deveria possuir sozinho o equivalente corporativo a:
SELECT *
FROM HUMANITY;Arc tentou executar.
Resultado:
SQLCODE = -911
REASON:
DIVINE PRIVACY DEADLOCKEis nosso easter egg.
🧭 CAPÍTULO 17 — COMO COMEÇAR SEM CRIAR UM DATA LAKE DE LIXO
Erro clássico:
“Vamos coletar tudo!”
Seis meses depois:
PETABYTES DE LOG
+
FATURA DE CLOUD
+
NINGUÉM SABE O QUE PROCURARComece com perguntas.
Passo 1 — Identidade
QUEM?Passo 2 — Dispositivo
DE ONDE?Passo 3 — Recurso
ACESSOU O QUÊ?Passo 4 — Ação
FEZ O QUÊ?Passo 5 — Resultado
FUNCIONOU?Só depois acrescente contexto.
Uma implementação poderia evoluir assim:
FASE 1
IAM + Endpoint + VPN
FASE 2
Cloud + API + Network
FASE 3
Applications + Databases + MQ/Kafka
FASE 4
RACF + SMF + CICS + IMS + Db2
FASE 5
Payments + Email Metadata + Physical AccessCada nova fonte precisa responder:
Qual pergunta de segurança, operação, auditoria ou investigação isso nos ajuda a responder?
Se a resposta for:
“Nenhuma, mas o log existe.”
Talvez não devamos ingeri-lo.
🪪 CAPÍTULO 18 — A DUNGEON MAIS DIFÍCIL: IDENTIDADE
João pode ser:
joao.silva
jsilva
JOSILVA
U883921
RACF=JSILVA
badge=192882
email=joao.silva@...Tudo pode representar uma pessoa.
Mas:
APISRV1pode representar uma aplicação.
E:
CERTIFICATE-X91pode representar uma workload.
Precisamos distinguir:
HUMAN IDENTITY
SERVICE IDENTITY
DEVICE IDENTITY
WORKLOAD IDENTITY
APPLICATION IDENTITYDaí surge o Identity Graph.
PERSON
├── RACF ID
├── CLOUD ID
├── EMAIL ID
├── BADGE ID
└── DEVICE LOGINEnquanto:
APPLICATION
├── SERVICE ACCOUNT
├── CERTIFICATE
├── API KEY
└── WORKLOAD IDSem essa resolução, correlação corporativa rapidamente vira caos.
⚠️ CAPÍTULO 19 — ANOMALIA NÃO É CULPA
Esse princípio merece letras garrafais:
UMA ANOMALIA É UMA PERGUNTA, NÃO UMA SENTENÇA.
Suponha:
login 03:00
+
new device
+
large exportPode ser ataque.
Pode ser administrador trabalhando numa emergência.
Pode ser processo automatizado mal classificado.
Pode ser migração.
Pode ser teste.
Pode ser erro de relógio.
Pode ser falso positivo.
Portanto:
EVENT
↓
CORRELATION
↓
ANOMALY
↓
INVESTIGATION
↓
CONCLUSIONNunca:
ANOMALY
↓
GUILTYEssa distinção protege pessoas e melhora a própria segurança.
👁️ CAPÍTULO 20 — OBSERVABILIDADE NÃO É VIGILÂNCIA
Finalmente Arc compreendeu a diferença.
Observabilidade corporativa
Pergunta:
O que aconteceu com o sistema?
Características:
event-centric
resource-centric
purpose-limited
security-oriented
auditableVigilância corporativa
Pergunta:
O que esta pessoa está fazendo o tempo inteiro?
Características:
person-centric
continuous
open-ended
behavioralUma arquitetura saudável deveria possuir barreiras explícitas contra usos incompatíveis com sua finalidade.
O fato de ser tecnicamente possível inferir algo não significa que devamos fazê-lo.
Essa talvez seja a maior lição deste artigo.
💀 CAPÍTULO 21 — ARC FINALMENTE ENXERGA A DUNGEON INTEIRA
No final da investigação tínhamos:
CORPORATE MEMORY
IAM ───────────────┐
Endpoint ──────────┤
Network ───────────┤
Cloud ─────────────┤
API ───────────────┤
Application ───────┤
Database ──────────┼──► NORMALIZATION
Payments ──────────┤ │
Email Metadata ────┤ ▼
Physical Access ───┤ EVENT GRAPH
MQ/Kafka ──────────┤ │
RACF/CICS/Db2 ─────┤ ▼
SMF ───────────────┘ CORRELATION
│
┌────────┴────────┐
▼ ▼
DETECTION INVESTIGATION
│ │
└────────┬────────┘
▼
EVIDENCEMas poderíamos descrevê-lo ainda melhor:
CORPORATE SMF
=
EVENT STORE
+
IDENTITY GRAPH
+
PRIVILEGE GRAPH
+
RESOURCE GRAPH
+
TEMPORAL GRAPH
+
GOVERNANCEE perceba a última palavra.
Governance.
Sem ela, construímos o Big Brother.
Com ela, podemos construir uma poderosa caixa-preta corporativa.
☕ EPÍLOGO — O QUE O MAINFRAME JÁ SABIA
Arc levantou-se diante do 3270.
Depois de atravessar IAM, endpoints, APIs, cloud, MQ, CICS, COBOL, Db2, pagamentos, controle físico, grafos e Zero Trust, finalmente compreendeu.
— Bellacosa-san, então o objetivo não é observar todo mundo?
— Não.
— Nem guardar tudo?
— Também não.
— Então qual é?
Olhei novamente para o SDSF.
A resposta estava ali desde o começo.
Quando alguma coisa importante acontecer, deixe evidência suficiente para reconstruir o que aconteceu.
Esse princípio atravessou décadas de computação.
No mainframe temos uma cultura fortíssima de registros operacionais.
No mundo distribuído estamos tentando recuperar essa visão através de logs estruturados, tracing, observabilidade, telemetria, SIEM, EDR, cloud audit, IAM e tantas outras tecnologias.
O desafio agora é conectá-las.
Não queremos perguntar:
O QUE O FUNCIONÁRIO FEZ DURANTE TODO O DIA?Queremos conseguir perguntar:
O QUE EXPLICA ESTE INCIDENTE?Então podemos reconstruir:
quem
↓
usou qual identidade
↓
em qual dispositivo
↓
obteve qual privilégio
↓
atravessou qual caminho
↓
chamou qual API
↓
publicou qual mensagem
↓
acionou qual transação CICS
↓
executou qual COBOL
↓
acessou qual registro Db2
↓
originou qual pagamento
↓
em qual instanteEsse é o verdadeiro poder do conceito.
O SMF corporativo não seria simplesmente outro SIEM.
Seria uma camada de memória e evidência capaz de conectar os mundos físico, distribuído, cloud e mainframe.
Uma espécie de gravador de voo da empresa.
Se o avião corporativo sofrer uma pane, queremos reconstruir os últimos acontecimentos.
Queremos saber quais controles funcionaram.
Quais falharam.
Qual identidade apareceu.
Qual privilégio foi utilizado.
Qual API foi chamada.
Qual mensagem entrou no MQ.
Qual transação chegou ao CICS.
Qual programa COBOL executou.
Qual registro mudou.
E qual pagamento saiu.
Mas não precisamos passar o voo inteiro espionando se o passageiro pediu café duas ou três vezes.
Arc colocou o elmo.
A dungeon estava encerrada.
Antes de sair, porém, digitou no terminal:
//ARCJOB JOB CLASS=A,MSGCLASS=X
//STEP01 EXEC PGM=BIGBROTHERO JES respondeu:
IEF452I ARCJOB - JOB NOT RUN - JCL ERRORArc olhou para mim.
— Errei a JCL?
— Não.
— Então?
— O sistema tem governança.
Arc permaneceu alguns segundos em silêncio.
Então começou a rir.
E em algum dataset perdido do z/OS apareceu mais um registro.
Porque no mainframe...
até o esqueleto deixa rastro.
☕💀🖥️
Bellacosa Mainframe — porque observabilidade sem contexto é apenas uma montanha de logs; contexto sem governança pode virar vigilância; e um bom COBOLzeiro sabe que, quando a produção explode às 03:17 da manhã, a primeira pergunta continua sendo a mesma: “onde está o log?”
