 |
| Bellacosa Mainframe e a engenharia militar parte iii |
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Capítulo III — A Cadeia de Comando, os Mestres e o Programador que Descobriu que Conhecimento Também é uma Fortaleza
Quando um Programador COBOL Descobre que o Maior Ativo de um Mainframe Não Está no Hardware — Está nas Pessoas que Sabem Como Mantê-lo Vivo
O sino do castelo tocou antes do amanhecer.
Não anunciava guerra.
Nem incêndio.
Nem invasão.
Anunciava treinamento.
Centenas de jovens atravessaram o pátio carregando espadas de madeira, arcos desmontados, cordas, escudos e armaduras ainda grandes demais para seus corpos.
Nenhum deles pisaria em um campo de batalha naquele dia.
O mestre sabia disso.
Mesmo assim, ordenou:
— Formação!
Os aprendizes correram.
Alguns ficaram fora da linha.
Outros seguravam a espada de maneira errada.
Alguns reclamavam do frio.
Um deles perguntou:
— Mestre... por que treinamos tanto se talvez nunca enfrentemos uma guerra?
O velho samurai sorriu.
— Porque o dia em que a guerra chegar será exatamente o dia em que não haverá tempo para aprender.
Séculos depois...
03h17 da madrugada.
Um telefone tocou dentro da equipe de produção.
Um programa crítico havia parado.
O analista recém-contratado abriu o código COBOL pela primeira vez.
Mais de quarenta mil linhas.
Centenas de parágrafos.
Copybooks desconhecidos.
Chamadas para módulos sem documentação.
Ele perguntou ao veterano:
— Onde está o manual?
O veterano respondeu calmamente:
— Parte está nos documentos.
Outra parte está nos comentários.
Mas a parte mais importante...
...está na cabeça das pessoas.
Naquele instante o jovem descobriu que estava entrando em uma organização muito parecida com um antigo clã samurai.
Porque sistemas críticos não sobrevivem apenas graças ao software.
Eles sobrevivem graças à transmissão contínua de conhecimento.
Hoje nosso café será sobre pessoas.
Porque toda fortaleza é construída com pedras.
Mas somente continua de pé quando existe alguém que sabe como reconstruí-la.
1. Nenhum exército é formado apenas por guerreiros
Quando pensamos em guerras antigas, normalmente imaginamos:
samurais
cavaleiros
arqueiros
lanceiros
Entretanto, um exército real era infinitamente mais complexo.
Existiam:
engenheiros
carpinteiros
médicos
cozinheiros
mensageiros
escribas
cartógrafos
ferreiros
criadores de cavalos
responsáveis pelos suprimentos
estrategistas
diplomatas
administradores
Sem eles, o melhor espadachim morreria de fome antes de encontrar o inimigo.
O mesmo acontece dentro de um ambiente IBM Z.
O usuário normalmente vê apenas a aplicação.
Mas atrás dela existe um verdadeiro exército tecnológico.
2. O castelo chamado Data Center
Imagine um grande banco.
O cliente faz uma transferência pelo celular.
A operação parece simples.
Entretanto, atrás daquela tela trabalham dezenas de especialistas.
Entre eles:
Desenvolvedor COBOL
Constrói e mantém a lógica do negócio.
É quem escreve as regras que processam milhões de operações.
Analista de Negócio
Traduz necessidades empresariais.
Ele conhece leis, produtos, contratos e processos.
Sem ele o desenvolvedor escreve código correto para resolver o problema errado.
DBA Db2
Protege o banco de dados.
Decide índices.
Analisa planos.
Controla desempenho.
Evita bloqueios.
É o guardião dos arquivos imperiais.
Administrador CICS
Mantém a cidade funcionando.
Controla regiões.
Transações.
Performance.
Recuperação.
Disponibilidade.
Sysprog z/OS
É o arquiteto da fortaleza.
Controla:
sistema operacional
memória
segurança
discos
consoles
IPL
subsistemas
Quando tudo parece impossível...
...normalmente alguém chama o sysprog.
Storage Administrator
Cuida dos depósitos.
Volumes.
Snapshots.
Replicação.
Backups.
Recovery.
Hoje, com IBM FlashSystem, também protege contra ransomware utilizando snapshots imutáveis e mecanismos acelerados por hardware.
Operação
Os operadores observam consoles.
Respondem alertas.
Executam procedimentos.
Acionam especialistas.
Eles são os sentinelas das muralhas.
Segurança
RACF.
Certificados.
Criptografia.
Auditoria.
Permissões.
Eles controlam quem entra e quem permanece do lado de fora dos portões.
Redes
Mantêm as estradas abertas.
Sem rede...
nenhuma mensagem chega.
Perceba.
Nenhum deles consegue substituir completamente o outro.
Assim como em um exército.
3. Cadeia de comando
Existe um princípio militar extremamente antigo.
Toda ordem precisa possuir:
origem
destino
responsável
confirmação
Caso contrário...
surge o caos.
No desenvolvimento ocorre exatamente igual.
Quem aprovou?
Quem pediu?
Quem implementou?
Quem testou?
Quem implantou?
Quem autorizou produção?
Quem responde se algo der errado?
Quando essas respostas não existem...
aparece uma frase muito conhecida.
Achei que outra equipe faria isso.
Em engenharia...
"achei" costuma aparecer poucos minutos antes do incidente.
4. O Senpai
Os animes mostram constantemente a figura do Senpai.
Ele não é apenas alguém mais velho.
É alguém que percorreu aquele caminho.
Conhece armadilhas.
Erros.
Atalhos.
Consequências.
Curiosamente...
o universo mainframe possui inúmeros senpais.
São profissionais que trabalharam:
20...
30...
40 anos...
nos mesmos sistemas.
Eles sabem coisas que documentação nenhuma explica.
Por exemplo.
"Jamais altere esse arquivo durante o fechamento do trimestre."
Por quê?
Talvez ninguém saiba explicar imediatamente.
Mas vinte anos atrás uma alteração semelhante parou todo o processamento nacional.
Esse conhecimento permanece vivo.
5. O Kohai
O Kohai é o aprendiz.
Ele possui energia.
Curiosidade.
Novas ideias.
Conhece tecnologias recentes.
Mas ainda não conhece o terreno.
Essa relação é importante porque funciona nos dois sentidos.
O veterano ensina experiência.
O iniciante traz inovação.
Quando existe respeito...
ambos evoluem.
Quando existe arrogância...
o conhecimento deixa de circular.
6. O perigo do Herói
Existe um personagem muito comum nas empresas.
"O cara que resolve tudo."
Todos conhecem alguém assim.
Ele sabe:
JCL
COBOL
CICS
Db2
RACF
MQ
REXX
Storage
JES2
Quando ele entra de férias...
o Data Center inteiro fica nervoso.
Isso parece bom.
Na realidade...
é extremamente perigoso.
Na engenharia militar existe um conceito chamado:
Single Point of Failure
Um único ponto cuja perda compromete toda a missão.
Pessoas também podem se tornar Single Point of Failure.
7. Goblin Slayer nunca luta sozinho
Muita gente acredita que Goblin Slayer vence porque é forte.
Na realidade...
ele vence porque organiza recursos.
Ele sabe exatamente:
quem ilumina.
quem protege.
quem lança magia.
quem fecha a retaguarda.
quem observa o teto.
quem verifica armadilhas.
Ele distribui funções.
Não tenta fazer tudo.
Esse é um enorme ensinamento para arquitetura de sistemas.
Equipes excelentes distribuem responsabilidades.
Não concentram tudo em um único indivíduo.
8. O erro do programador solitário
Imagine um desenvolvedor que pensa:
"Não preciso documentar."
"Eu lembro."
Durante alguns meses isso funciona.
Depois...
ele muda de projeto.
Sai da empresa.
Aposenta-se.
Fica doente.
Agora imagine outro cenário.
Existe documentação.
Fluxogramas.
Comentários úteis.
Diagramas.
Playbooks.
Runbooks.
Procedimentos.
Agora o conhecimento pertence ao castelo.
Não ao guerreiro.
Essa diferença separa organizações maduras de organizações dependentes de heróis.
9. A cultura japonesa e o treinamento
Durante nossa conversa discutimos se muitos animes parecem possuir uma estrutura quase militar.
Existe uma razão cultural interessante.
Diversas narrativas japonesas valorizam:
repetição
disciplina
aperfeiçoamento contínuo
respeito aos mestres
responsabilidade coletiva
treinamento constante
Isso não significa militarismo.
Significa valorização da preparação.
Um bombeiro treina diariamente.
Um cirurgião treina.
Um piloto treina.
Um operador nuclear treina.
Um programador COBOL também deveria treinar.
Não apenas escrever código novo.
Mas estudar incidentes antigos.
Analisar ABENDs históricos.
Entender decisões arquiteturais.
Ler programas clássicos.
A prática deliberada produz confiança.
10. O Estado poderia usar essa estrutura?
Na conversa anterior discutimos justamente isso.
Narrativas possuem enorme poder educativo.
Imagine ensinar segurança digital utilizando um mangá.
Ao invés de simplesmente dizer:
"Nunca compartilhe senhas."
O protagonista perde acesso ao castelo porque entregou sua credencial ao vilão.
A criança nunca esquecerá aquela cena.
A história ensina comportamento.
O mesmo vale para:
primeiros socorros.
educação financeira.
combate a incêndios.
proteção ambiental.
defesa civil.
Mas existe um limite importante.
Quando a narrativa deixa de estimular reflexão e passa apenas a exigir obediência...
ela deixa de ser educação.
A educação amplia a capacidade de decidir.
A propaganda reduz as alternativas.
Esse equilíbrio precisa sempre existir.
11. O mestre que não queria discípulos
Existe outro risco.
Alguns profissionais escondem conhecimento.
Acreditam que assim permanecerão indispensáveis.
No curto prazo...
funciona.
No longo prazo...
todos perdem.
Imagine um castelo onde somente uma pessoa sabe abrir o portão principal.
Ela adoece.
Agora o castelo inteiro está preso.
Conhecimento escondido enfraquece a organização.
Conhecimento compartilhado fortalece toda a fortaleza.
12. O verdadeiro mestre
Nos animes encontramos vários mestres memoráveis.
Mas quase todos possuem uma característica comum.
Eles desejam ser superados.
O mestre verdadeiro ensina para tornar-se desnecessário.
Na tecnologia acontece igual.
Quando um especialista forma novos especialistas...
ele amplia a capacidade da organização.
Quando guarda tudo para si...
apenas aumenta sua carga de trabalho.
13. Easter Egg — O Comentário Perdido
Conta uma antiga lenda dos Data Centers que existia um módulo COBOL contendo apenas um comentário.
* SE VOCE NAO ENTENDER ESTE PARAGRAFO,
* PROCURE O SR. TANAKA.
Anos depois...
o Sr. Tanaka aposentou-se.
Ninguém alterou o comentário.
Décadas passaram.
Novos desenvolvedores perguntavam:
— Quem era Tanaka?
Ninguém sabia.
Até que um antigo operador revelou.
Tanaka não era o autor do programa.
Era quem conhecia o motivo daquela rotina existir.
O comentário era um lembrete de que conhecimento não mora apenas no código.
Ele mora nas pessoas.
Depois daquele incidente o comentário foi alterado.
* DOCUMENTACAO:
* WIKI MAINFRAME
* CAPITULO 18
* PROCESSO CONTABIL ESPECIAL
A lenda diz que, naquele dia, o castelo tornou-se um pouco mais forte.
14. Checklist do jovem samurai COBOL
Antes de alterar qualquer sistema pergunte:
✔ Quem realmente entende este processo?
✔ Existe documentação?
✔ Existe histórico?
✔ Quem consome esta informação?
✔ Quem aprova?
✔ Existe especialista de negócio?
✔ Existe plano de recuperação?
✔ Estou aprendendo sozinho ou com alguém experiente?
✔ Estou deixando conhecimento para quem vier depois?
Curiosidade Histórica
No Japão feudal, muitos conhecimentos sobre construção de castelos, metalurgia, fabricação de espadas e técnicas de engenharia eram transmitidos de mestre para aprendiz durante décadas. Em diversos clãs, o maior patrimônio não era o arsenal, mas o saber acumulado de gerações.
Os grandes ambientes IBM Z seguem lógica semelhante. Embora contem com documentação técnica extensa, decisões arquitetônicas, procedimentos operacionais e lições aprendidas em incidentes reais frequentemente são preservados por profissionais experientes e depois incorporados a runbooks, padrões e treinamentos. Organizações maduras transformam essa experiência em conhecimento compartilhado para reduzir dependências individuais.
Conclusão — O Dia em que o Aprendiz Recebeu a Chave do Castelo
O inverno havia chegado.
O velho mestre caminhou lentamente até o portão principal.
Chamou o jovem aprendiz.
Sem dizer uma palavra, entregou-lhe um pesado molho de chaves.
O rapaz sorriu.
Achou que finalmente havia recebido poder.
O mestre balançou a cabeça.
— Não.
Você recebeu responsabilidade.
Estas chaves não abrem apenas portas.
Elas mantêm pessoas seguras.
Elas protegem alimentos.
Protegem famílias.
Protegem o futuro deste castelo.
Se um dia perdê-las...
não será apenas um cadeado que deixará de funcionar.
Será toda uma comunidade.
Anos depois...
o jovem programador encerrava seu turno.
Antes de desligar o terminal, escreveu um comentário detalhado no programa, atualizou a documentação da equipe, registrou o procedimento de recuperação e explicou ao colega mais novo por que aquele módulo não podia ser alterado durante o fechamento mensal.
O veterano observou em silêncio.
Sorriu discretamente.
Porque percebeu que algo havia mudado.
O rapaz já não era apenas um desenvolvedor COBOL.
Estava começando a tornar-se um guardião da fortaleza.
E compreendia, finalmente, que o verdadeiro legado de um engenheiro não é o código que escreve.
É o conhecimento que consegue transmitir antes que outra geração precise defender o mesmo castelo.
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Uma campanha completa sobre estratégia, logística, inteligência, segurança, liderança, continuidade, sistemas críticos, IBM Z e COBOL.
Um Data Center analisado como uma fortaleza em guerra
A série Engenharia Militar sem Mistérios para Programadores COBOL compara castelos, exércitos, muralhas, cadeias de comando, logística, inteligência e operações militares com os ambientes IBM Z responsáveis por bancos, governos, seguros, transportes e serviços essenciais.
Cada artigo apresenta uma parte dessa arquitetura: aplicações COBOL, Jobs JCL, transações CICS, bancos Db2, filas MQ, segurança RACF, monitoramento, contingência, liderança, documentação e continuidade operacional.
Índice da campanha
Links completos da série Engenharia Militar
Esta relação permanece disponível no HTML da página para mecanismos de busca, leitores de tela, navegadores sem JavaScript e ferramentas de arquivamento.
- Engenharia Militar sem Mistérios para Programadores COBOL
- Prólogo — O Chamado do Guardião
- Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar
- Capítulo II — Estratégia, Operação e Tática
- Capítulo III — A Cadeia de Comando
- Capítulo IV — Logística
- Capítulo V — As Muralhas Invisíveis
- Capítulo VI — Inteligência, Reconhecimento e Espionagem
- Capítulo VII — A Arte da Guerra Aplicada ao Mainframe
- Capítulo VIII — Liderança, Moral e Disciplina
- Capítulo IX — Inovação, Evolução e o Futuro
- Capítulo X — O Legado do Engenheiro
- Capítulo XI — O Guardião Invisível
- Capítulo XII — A Fortaleza Invisível
- Capítulo XIII — Os Sentinelas da Madrugada
- Capítulo XIV — A Civilização Invisível
- Capítulo XV — Engenharia de Cerco
- Glossário IBM Z + Engenharia Militar
- Apêndice A — Correspondências Históricas e Técnicas
- Os 10 Animes Mais Emblemáticos Sobre Engenharia Militar
- Os 10 Animes Mais Emblemáticos Sobre Logística Militar
- Os 10 Animes Mais Emblemáticos Sobre Tática Militar
- Os 10 Animes Mais Emblemáticos Sobre Estratégia Militar
- Especial — Guerrilha Urbana
- Especial — Guerrilha no Campo e na Floresta
Sem comentários:
Enviar um comentário