⏰🔥 SRE explicado para quem já foi acordado por batch quebrado

---

02:47 — Introdução: quando o telefone tocava e você já sabia

Antes de existir SRE, já existia plantão.
Antes de “on-call rotation”, já existia pager, telefone fixo e operador nervoso.
Antes de “incident postmortem”, já existia a pergunta clássica:

“O que mudou desde ontem?”

Site Reliability Engineering (SRE) não nasceu no Google.
Nasceu no trauma coletivo de quem precisava manter sistema crítico em pé, custe o que custar.

---

1️⃣ O que é SRE (traduzido para dialeto mainframe)

SRE é aplicar engenharia para garantir:

• Disponibilidade

• Performance

• Confiabilidade

• Previsibilidade

Não é suporte.
Não é operação reativa.
É disciplina.

📌 Mainframer entende assim:

“Não apagar incêndio. Evitar que ele comece.”

---

2️⃣ O mito: SRE é coisa de cloud 😈

Mentira.

Mainframe já fazia SRE com:

• SLAs rígidos

• Janelas de batch

• Planejamento de capacidade

• Controles de mudança

• Automação pesada

😈 Easter egg:
ITIL copiou metade disso e deu nome bonito.

---

3️⃣ SLIs, SLOs e SLAs (ou: como medir sem enganar)

SLI – Indicador

• Tempo de resposta

• Taxa de erro

• Throughput

SLO – Objetivo

• “99,9% das transações em até X ms”

SLA – Contrato

• Multa

• Diretoria

• Dor

📎 Mainframer traduz:

“Se o fechamento não roda, tem reunião amanhã.”

---

4️⃣ Error Budget: a parte que o negócio nunca entendeu 💣

Error Budget =
100% − SLO

Se o sistema pode falhar 0,1% do tempo:

• Você pode inovar

• Pode mudar

• Pode arriscar

Se estourar:

• Congela mudança

• Estabiliza

• Arruma casa

😈 Easter egg:
No mainframe isso se chamava “congelamento pré-fechamento”.

---

5️⃣ Postmortem sem caça às bruxas 🧠

SRE prega:

• Análise sem culpados

• Foco no processo

• Aprendizado real

Mainframer sabe:

“Sistema não quebra sozinho.”

📌 Curiosidade:
Quem caça culpado esconde problema.

---

6️⃣ Automação: batch, scripts e o futuro 🤖

SRE vive de automação:

• Deploy automático

• Rollback

• Self-healing

• Escala automática

Mainframe já fazia:

• JCL

• Restart automático

• Schedulers

• Abends tratados

😈 Easter egg:
JCL é Infrastructure as Code sem marketing.

---

7️⃣ Passo a passo para pensar como SRE (modo Bellacosa)

1️⃣ Defina o que é “funcionar”
2️⃣ Meça tudo que importa
3️⃣ Crie limites claros
4️⃣ Automatize o repetitivo
5️⃣ Aceite falhas pequenas
6️⃣ Aprenda com cada incidente
7️⃣ Melhore antes da próxima pancada

---

8️⃣ Guia de estudo para mainframers cansados 📚

Conceitos

• SRE

• SLIs / SLOs

• Error Budget

• Incident Management

• Chaos Engineering

Ferramentas modernas

• Instana

• PagerDuty

• Grafana

• Kubernetes (sim…)

---

9️⃣ Aplicações práticas no mundo híbrido

• Redução de chamadas noturnas

• Menos stress operacional

• Melhor diálogo com negócio

• Estabilidade com inovação

• Arquiteturas mais conscientes

🎯 Mainframer SRE vira pilar da empresa.

---

🔟 Curiosidades que doem 😬

• 100% disponível não existe

• Mudança sem métrica é aposta

• Automatizar erro escala desastre

• Confiabilidade custa tempo e dinheiro

📌 Verdade dura:
Sistema crítico exige humildade técnica.

---

11️⃣ Comentário final (05:31, céu clareando)

SRE não é moda.
É sobrevivência profissional.

Se você já:

• Dormiu mal por batch quebrado

• Evitou mudança perto do fechamento

• Confiou mais em histórico do que em promessa

Então você já era SRE, antes do nome existir.

🖤 El Jefe Midnight Lunch encerra a série:
Confiabilidade não se improvisa. Se constrói.

 

 

🔥 Error Handling Techniques no CICS

 

---

☕ Midnight Lunch, abend na tela e o silêncio mortal

São 12h58.
Usuário digita Enter.
A tela pisca.
ASRA.

No console, ninguém fala.
Alguém finalmente quebra o gelo:

“Isso não foi tratado…”

Hoje o almoço é pesado. Vamos falar de tratamento de erros no CICS — a diferença entre um sistema profissional e um sistema que vive de reza e IPL.

---

🏛️ História: quando erro virou disciplina

Nos primórdios, erro em CICS era simples:

• Deu problema → abend

• Debug → dump

• Corrige → volta pra produção

Com o crescimento de sistemas 24x7, isso virou inaceitável.
O CICS evoluiu e trouxe mecanismos formais de error handling, muito antes de try/catch virar moda.

📌 CICS não evita erro. Ele oferece ferramentas para dominá-lo.

---

🧠 Conceito essencial (grave isso)

Erro não tratado = falha arquitetural
Erro tratado = comportamento esperado

Mainframe não tolera improviso.

---

🧯 Principais técnicas de Error Handling no CICS

Vamos separar por camadas — como todo bom sistema corporativo.

---

1️⃣ RESP / RESP2 – o primeiro escudo

O que é?

Quase todo comando CICS retorna:

• RESP → código principal

• RESP2 → detalhe fino do erro

Exemplo

EXEC CICS READ FILE('ARQCLI')
     INTO(WS-REG)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC.

Boa prática

• Sempre testar RESP

• Nunca confiar que “vai dar certo”

📌 RESP ignorado é bug incubado.

---

2️⃣ HANDLE CONDITION – o guarda-costas antigo

O que é?

Permite capturar condições específicas e redirecionar o fluxo.

EXEC CICS HANDLE CONDITION
     NOTFND(LABEL-NOTFND)
     DUPREC(LABEL-DUP)
END-EXEC.

Vantagens

✔ Simples
✔ Muito usado em código legado

Riscos

❌ Global demais
❌ Difícil de rastrear
❌ Pode mascarar erro

📌 HANDLE CONDITION é faca de cozinha: útil, mas perigosa.

---

3️⃣ IGNORE CONDITION – o tapa pra debaixo do tapete

O que é?

Ignora explicitamente uma condição.

EXEC CICS IGNORE CONDITION NOTFND END-EXEC.

⚠️ Use só quando:

• A condição é esperada

• Você sabe exatamente o impacto

📌 IGNORE CONDITION sem comentário é crime técnico.

---

4️⃣ HANDLE ABEND – o airbag

O que é?

Intercepta abends CICS antes de matar a transação.

EXEC CICS HANDLE ABEND
     PROGRAM('ABENDPGM')
END-EXEC.

O que dá pra fazer?

• Logar contexto

• Gravar TDQ/TSQ

• Avisar monitoria

• Encerrar com dignidade

📌 HANDLE ABEND não evita o erro. Evita o caos.

---

5️⃣ ABEND explícito – erro controlado é maturidade

Às vezes, abendar é a decisão correta.

EXEC CICS ABEND ABCODE('APPL')
     NODUMP
END-EXEC.

Use quando:

• Integridade foi comprometida

• Continuar é mais perigoso

• Auditoria exige parada

📌 Abend consciente é melhor que sucesso falso.

---

🛠️ Passo a passo Bellacosa (como tratar erro direito)

1️⃣ Capture RESP / RESP2
2️⃣ Decida: recuperar ou encerrar
3️⃣ Registre contexto (log)
4️⃣ Informe o usuário de forma clara
5️⃣ Garanta consistência de dados

📌 Tratamento de erro também é UX.

---

⚠️ Erros clássicos (easter eggs mainframe)

🐣 RESP nunca testado
🐣 HANDLE CONDITION genérico demais
🐣 IGNORE CONDITION sem explicação
🐣 Dump infinito em produção
🐣 Abend sem log

📌 Todo ASRA famoso começou assim.

---

📦 Integração com TSQ, TDQ e logs

Boas práticas:

• TDQ para log de erro

• TSQ para contexto temporário

• SMF para auditoria

• Integração com monitoria (OMEGAMON, Instana)

📌 Erro que não é logado vai voltar.

---

📚 Guia de estudo para mainframers

Domine estes tópicos:

• CICS Conditions & RESP codes

• Abend codes (AEI0, ASRA, APCT)

• Program Control error handling

• Recovery & Backout

• Logging e monitoramento

📖 Manual essencial: CICS Application Programming Guide

---

🤓 Curiosidades de boteco mainframe

🍺 HANDLE CONDITION é mais antigo que Java
🍺 Muitos sistemas “estáveis” vivem à base de IGNORE CONDITION
🍺 O melhor log é o que nunca precisa ser lido
🍺 Já vi HANDLE ABEND salvar auditoria milionária

---

💬 Comentário El Jefe Midnight Lunch

“Erro não mata sistema.
Falta de tratamento, sim.”

---

🚀 Aplicações reais hoje

• Sistemas bancários 24x7

• Processamento de cartões

• Governo e seguradoras

• Plataformas críticas globais

---

🎯 Conclusão Bellacosa

CICS não exige perfeição.
Exige responsabilidade.

Quem trata erro direito:

• Dorme melhor

• Evita incidente grave

• Ganha respeito do operador

🔥 Error handling não é opcional. É caráter técnico.