Bellacosa Mainframe estuda o case Mega City

---

📘 Mega City – Case Study Review (Completo)

🎯 Visão Geral do Projeto

O projeto Mega City Commuter Application tem como objetivo desenvolver um aplicativo para apoiar os deslocamentos urbanos, integrando dados do Department of Transportation (DOT) para melhorar a experiência dos usuários.

🎯 Objetivo Principal do App

✅ Allow commuters to determine optimal routes

❌ Não é:

• Previsão do tempo

• Horários de voo

• Sistema ferroviário isolado

---

🧭 Principais Artefatos do Projeto

1️⃣ Agile Project Charter

Finalidade:

• Define objetivos

• Alinha negócio + tecnologia

• Explica o porquê do projeto

📌 Pergunta típica de prova:

“Which document ensures objectives are clear and aligns business and technical teams?”
✅ Agile Project Charter

---

2️⃣ Product Roadmap

Finalidade:

• Visão visual e de alto nível

• Organiza entregáveis por fases e meses

• Indica quando o produto será testado e lançado

📅 Data de lançamento do App (prova):
✅ October

📌 Responsável pela criação:
✅ Project Manager

---

3️⃣ Working Agreement

Finalidade:

• Define regras de convivência

• Cria transparência, expectativas e objetivos comuns

• Focado em como o time trabalha

👤 Quem lidera a criação:
✅ Scrum Master – Anant Kumar

📌 Nunca é imposto, sempre criado pelo time

---

4️⃣ Product Backlog

Finalidade:

• Repositório de todos os User Stories

• Base para planejamento de Sprints

👤 Responsável:
✅ Product Owner – Anant Kumar

📌 Dica de prova:

Quem gerencia e prioriza = Product Owner

---

👥 Papéis-Chave no Case Mega City

🔹 Product Owner

• Define o que será construído

• Gerencia o Product Backlog

✅ Anant Kumar

---

🔹 Scrum Master

• Facilita reuniões

• Remove impedimentos

• Garante adesão ao Scrum

• Lidera o Working Agreement

✅ Anant Kumar (em perguntas específicas do curso)

---

🔹 Subject Matter Expert (SME)

Responsável por garantir que requisitos técnicos e funcionais sejam atendidos.

📍 SME do DOT:
✅ Hiroshi Tanaka

📌 Sempre associado a:

• Dados do DOT

• Funcionalidade específica do domínio

---

📊 Stacey Matrix (Análise Crítica)

📌 Parâmetros Avaliados:

• Level of Agreement

• Technology Complexity

---

🧠 Interpretação para prova

Cenário	Abordagem Correta
Alta concordância + baixa complexidade	Waterfall
Baixa concordância + alta complexidade	✅ Agile / Scrum
Trabalho contínuo	Kanban

📌 No Mega City:

Low agreement + High complexity
✅ Agile / Scrum

---

🧩 Resumo Rápido (Cola de Prova 📝)

• Objetivo do App: Rotas ideais para commuters

• Roadmap: Visual + meses + lançamento em October

• Charter: Alinha negócio e tecnologia

• Working Agreement: Criado pelo time, liderado pelo Scrum Master

• Product Backlog: Responsabilidade do Product Owner

• SME DOT: Hiroshi Tanaka

• Stacey Analysis: Low agreement + High complexity → Agile/Scrum

---

Se quiser, no próximo passo posso:

• Criar um quadro comparativo (tabela) só com quem faz o quê

• Simular questões de prova estilo Coursera

• Ou montar um resumo em inglês, pronto para revisão final 📚

 

🧠 “SMF como fonte de verdade para observabilidade corporativa”

Porque antes de existir observability platform, já existia evidência

---

☕ 01:38 — Quando o gráfico mente, mas o SMF não

Todo mainframer aprende cedo uma verdade incômoda:
logs contam histórias, métricas sugerem hipóteses, mas o SMF registra fatos.

Enquanto o mundo distribuído ainda debate o que é single source of truth,
o z/OS já resolveu isso há décadas — e deu o nome de System Management Facility.

---

🧬 Um pouco de história (quando observabilidade não tinha marketing)

O SMF nasceu para:

• auditoria

• cobrança

• capacidade

• performance

• rastreabilidade

Não para “monitorar bonito”,
mas para provar o que aconteceu.

📌 Comentário Bellacosa:
SMF nunca foi sexy. Foi confiável. E isso envelhece melhor.

---

🔍 O que o SMF realmente é (traduzindo para cloudês)

No mundo moderno:

• Logs

• Metrics

• Traces

No z/OS:

• Tudo isso… em um formato só

• Com timestamp confiável

• Com contexto de sistema

• Com impacto mensurável

🔥 Tradução direta:
SMF é observabilidade com evidência jurídica.

---

🧠 SMF como “fonte de verdade”

Por que o SMF é a source of truth?

✔️ É gerado pelo sistema operacional
✔️ Não depende da aplicação “colaborar”
✔️ Não perde evento por backpressure
✔️ Não é amostrado
✔️ Não é opinativo

😈 Easter egg:
Se o SMF não viu, provavelmente não aconteceu.

---

📊 Comparação honesta: SMF x Observabilidade moderna

Observabilidade moderna	SMF
Métricas amostradas	Dados completos
Traces instrumentados	Evidência sistêmica
Logs verbosos	Registros estruturados
Dashboards	Capacidade histórica
Alertas	Diagnóstico pós-morte

📌 Comentário ácido:
Dashboard serve para avisar.
SMF serve para explicar.

---

🧭 Passo a passo mental: usando SMF como observabilidade

1️⃣ Coleta contínua (SMF ativo é pré-requisito)
2️⃣ Classificação por tipo (CPU, I/O, CICS, DB2, MQ…)
3️⃣ Correlação temporal
4️⃣ Análise de impacto real
5️⃣ Conclusão baseada em dado, não sensação

🔥 Regra de ouro:
Sem correlação, métrica vira superstição.

---

🧩 SMF e aplicações distribuídas (onde os mundos se encontram)

Hoje, arquiteturas são:

• híbridas

• distribuídas

• event-driven

O SMF entra como:

• referência de carga real

• baseline de comportamento

• âncora de verdade

📌 Exemplo prático:
Quando a API “fica lenta”, o SMF diz:

• se foi CPU

• se foi I/O

• se foi concorrência

• ou se foi culpa de quem chamou demais

---

📚 Guia de estudo para o mainframer moderno

Conceitos essenciais

• Observabilidade ≠ Monitoramento

• Correlação ≠ Alerta

• Evidência ≠ Opinião

• Capacidade ≠ Pico momentâneo

Exercício recomendado

👉 Pegue um incidente passado
👉 Releia só o SMF
👉 Ignore dashboards
👉 Reescreva a RCA

O resultado costuma ser… desconfortável — e correto.

---

🎯 Aplicações reais no mundo corporativo

• Auditoria e compliance

• Capacity planning sério

• SRE corporativo

• Integração com AIOps

• Base para observabilidade híbrida

🔥 Comentário Bellacosa:
Todo AIOps sério começa com dado confiável.
E dado confiável tem sobrenome: SMF.

---

🖤 Epílogo — 03:27, incidente encerrado

Quando o ruído some,
quando o gráfico contradiz o discurso,
quando a RCA precisa sobreviver a auditoria…

é o SMF que fica.

El Jefe Midnight Lunch assina:
“Observabilidade é saber. SMF é provar.”

 

 

🧱🔥 Resiliência explicada para quem já reconstruiu sistema no susto

---

04:41 — Introdução: quando tudo caiu… e você teve que levantar

Se você é mainframer e já reconstruiu sistema no susto, você não leu sobre resiliência — você viveu.
Foi aquela madrugada em que:

• o batch não fechou,

• a base ficou inconsistente,

• o telefone não parava,

• e alguém disse: “Tem que voltar hoje.”

Resiliência não é “não cair”.
É cair, levantar e continuar sem perder a alma do sistema.

---

1️⃣ O que é resiliência (sem frase de LinkedIn)

Resiliência é a capacidade de um sistema:

• Absorver falhas

• Continuar funcionando (mesmo degradado)

• Se recuperar rapidamente

• Aprender com o impacto

📌 Dialeto mainframe:

“Não importa o tamanho do estrago. O sistema volta.”

---

2️⃣ Um pouco de história: resiliência antes da cloud 🕰️

Antes de:

• microservices,

• containers,

• multi-cloud,

já existia:

• Sysplex

• Fallback

• Restart automático

• Controle de ponto de consistência

😈 Easter egg histórico:
Checkpoint de batch era resiliência antes de virar palestra.

---

3️⃣ Resiliência ≠ Alta disponibilidade 🧠

Alta disponibilidade:

• Evita parada

Resiliência:

• Aceita que vai parar

• Planeja a volta

• Minimiza impacto

👉 Mainframer sempre soube:

“Disponível sem consistência é ilusão.”

---

4️⃣ Onde a resiliência mora nas aplicações distribuídas

• Retry com critério

• Timeout bem definido

• Circuit breaker

• Bulkhead

• Fallback funcional

• Reprocessamento

📎 Tradução raiz:

“Se falhar, não propaga. Isola e continua.”

---

5️⃣ Passo a passo para construir resiliência (modo Bellacosa)

1️⃣ Assuma que vai falhar
2️⃣ Defina o que pode falhar
3️⃣ Separe falha crítica de falha tolerável
4️⃣ Implemente contenção
5️⃣ Garanta reprocessamento
6️⃣ Teste recuperação
7️⃣ Documente
8️⃣ Treine
9️⃣ Repita

💣 Dica Bellacosa:
Sistema que só funciona em estado perfeito não é resiliente.

---

6️⃣ Reprocessamento: o herói esquecido 🦸

Mainframer conhece:

• Restart step

• Batch reentrante

• Controle por chave

No mundo distribuído:

• Replay de eventos

• Dead letter queues

• Compensações

😈 Easter egg:
Quem sabe reprocessar não tem medo de falha.

---

7️⃣ Guia de estudo para mainframers sobreviventes 📚

Conceitos

• Resiliência

• Falha parcial

• Circuit breaker

• Bulkhead

• Retry com backoff

• Eventual consistency

Ferramentas

• Resilience4j

• Istio

• Kubernetes

• Kafka

• IBM MQ

---

8️⃣ Aplicações práticas no mundo real

• Ambientes híbridos estáveis

• Sistemas financeiros

• Integração legado + cloud

• Redução de incidentes graves

• Continuidade de negócio

🎯 Mainframer resiliente vira arquiteto natural.

---

9️⃣ Curiosidades que só quem viveu entende 👀

• Sistema que nunca falhou não foi testado

• Restart é mais importante que start

• Documentação de recuperação vale ouro

• Treinamento salva madrugada

📌 Verdade dura:
Resiliência custa projeto, tempo e humildade.

---

🔟 Comentário final (06:22, café requentado)

Resiliência não é luxo.
É requisito mínimo para sistemas que importam.

Se você já:

• Reconstruiu base sob pressão

• Voltou sistema com gambiarra consciente

• Aprendeu mais com falha do que com sucesso

Então você carrega resiliência no DNA.

🖤 El Jefe Midnight Lunch fecha com honra:
Sistemas fortes não são os que não caem. São os que sempre voltam.