 |
| Bellacosa Mainfrmae e a engenharia militar parte vii |
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Capítulo VII — A Arte da Guerra Aplicada ao Mainframe: Planejamento, Contingência e Continuidade
Quando um Programador COBOL Descobre que um Sistema Crítico Não é Aquele que Nunca Falha... É Aquele que Continua Funcionando Mesmo Depois da Falha
O vento soprava forte naquela manhã.
As bandeiras do castelo tremulavam de maneira incomum.
O jovem comandante aproximou-se do velho engenheiro.
— As muralhas estão prontas.
— Excelente.
— Os arqueiros também.
— Muito bom.
— Os depósitos estão cheios.
— Ótimo.
O jovem sorriu.
— Então estamos preparados.
O velho fechou lentamente o mapa.
— Não.
O rapaz estranhou.
— Ainda falta alguma coisa?
O engenheiro apontou para uma pequena passagem desenhada atrás da fortaleza.
— Sim.
Ainda falta descobrir como sobreviveremos caso tudo dê errado.
O jovem permaneceu em silêncio.
— Todo comandante inteligente planeja duas batalhas.
A primeira...
é aquela que espera vencer.
A segunda...
é aquela que espera nunca precisar lutar.
Séculos depois...
05h12 da madrugada.
Um grande banco processava milhões de transações.
Subitamente...
um subsistema tornou-se indisponível.
Alarmes começaram a soar.
Operadores correram para os consoles.
O programador recém-chegado perguntou:
— O sistema caiu?
O veterano respondeu serenamente.
— Não.
Agora vamos descobrir se ele realmente foi bem projetado.
Pegue seu café.
Hoje aprenderemos que a maior qualidade de um engenheiro não é impedir problemas.
É impedir que pequenos problemas se transformem em grandes desastres.
1. O mito da perfeição
Existe um mito extremamente perigoso na tecnologia.
"O sistema perfeito nunca falha."
Isso nunca existiu.
Hardware falha.
Discos falham.
Cabos rompem.
Usuários cometem erros.
Programadores cometem erros.
Energia acaba.
Links caem.
Centros de processamento sofrem incidentes.
A pergunta correta nunca foi:
"Como impedir qualquer falha?"
A pergunta correta é:
"Como continuar funcionando apesar delas?"
2. Continuidade sempre foi engenharia militar
Imagine um castelo medieval.
O comandante pergunta.
E se o poço for contaminado?
E se a ponte cair?
E se faltar arroz?
E se o inverno durar mais?
E se o mensageiro não voltar?
E se perdermos metade dos arqueiros?
Essas perguntas parecem pessimistas.
Na verdade...
são planejamento.
O mesmo raciocínio vale para sistemas críticos.
3. A engenharia da contingência
Contingência significa possuir um plano alternativo.
Na prática.
Plano A falhou.
Qual será o Plano B?
Se o servidor parar...
qual ambiente assume?
Se o arquivo não chegar...
qual procedimento será executado?
Se o banco ficar indisponível...
quem será avisado?
Se um lote falhar às quatro da manhã...
quem possui autoridade para reiniciar?
Planejamento elimina improvisação.
4. O Plano de Batalha
Nenhum comandante sério entra em guerra com apenas um plano.
Existe:
Plano Principal.
Plano Alternativo.
Plano de Retirada.
Plano de Reforço.
Plano de Recuperação.
Plano de Comunicação.
Nas empresas ocorre exatamente igual.
Mudanças críticas normalmente incluem:
janela.
rollback.
responsáveis.
contatos.
evidências.
critérios de interrupção.
pontos de validação.
A implantação começa muito antes do deploy.
5. O JCL também é planejamento
Um iniciante costuma enxergar o JCL apenas como comandos.
Mas observe.
//STEP010 EXEC PGM=CALCCONTA
//IFERRO IF (STEP010.RC > 4) THEN
//ABORT EXEC PGM=NOTIFICA
//ENDIF
Esse pequeno trecho mostra algo importante.
O autor não pensou apenas no sucesso.
Pensou também no fracasso.
Toda boa arquitetura possui caminhos alternativos.
6. O conceito de Checkpoint
Imagine uma longa viagem.
Você percorreu quinhentos quilômetros.
Subitamente o veículo quebra.
Precisa voltar ao início?
Claro que não.
Você continua do ponto onde parou.
Checkpoint significa exatamente isso.
No processamento batch...
ele evita reprocessamentos gigantescos.
Também reduz riscos.
Economiza tempo.
Facilita recuperação.
É uma das ideias mais elegantes da engenharia operacional.
7. Rollback — A retirada organizada
Na História militar, retirar tropas não significa derrota.
Retirada organizada salva vidas.
Preserva recursos.
Permite reorganização.
Na tecnologia chamamos isso de rollback.
Imagine uma implantação.
Algo inesperado acontece.
Existe uma versão anterior funcionando.
O rollback devolve rapidamente a operação ao estado estável.
Sem ele...
cada implantação torna-se uma aposta.
8. O poder da redundância
Observe uma ponte antiga.
Muitas utilizam diversos pilares.
Por quê?
Porque um único apoio representa risco.
A redundância aparece em praticamente toda engenharia crítica.
Motores duplicados.
Freios independentes.
Geradores.
Linhas elétricas.
Links.
No IBM Z encontramos conceitos semelhantes.
LPARs.
Storage redundante.
Canais.
Replicação.
Dispositivos alternativos.
O objetivo nunca foi desperdiçar recursos.
Foi garantir continuidade.
9. O Data Center nunca dorme
Enquanto milhões dormem...
centenas de sistemas continuam trabalhando.
Compensações bancárias.
Pagamentos.
Folhas salariais.
Processamentos fiscais.
Backups.
Sincronizações.
Replicações.
A continuidade operacional depende justamente da capacidade de manter esses processos ativos durante anos.
Esse talvez seja um dos maiores méritos do mainframe.
Ele foi concebido para continuidade.
10. O Plano de Comunicação
Em guerras antigas...
um mensageiro perdido podia alterar toda a campanha.
Hoje ocorre o mesmo.
Imagine uma indisponibilidade.
Quem será informado primeiro?
Operação?
Gestão?
Cliente?
Fornecedor?
Equipe de banco?
Equipe de segurança?
Sem comunicação...
pequenos incidentes tornam-se crises.
11. O Castelo possuía passagens secretas
Muitos castelos japoneses possuíam:
rotas ocultas.
depósitos subterrâneos.
passagens de emergência.
Elas raramente eram utilizadas.
Mas quando necessárias...
salvavam o castelo.
Na tecnologia essas passagens recebem outros nomes.
Site secundário.
Disaster Recovery.
Replicação.
Backup offline.
Snapshots.
Cold Site.
Warm Site.
Hot Site.
Quase ninguém lembra deles durante dias tranquilos.
Até o momento em que se tornam indispensáveis.
12. Goblin Slayer e os Planos Alternativos
Goblin Slayer dificilmente depende de uma única estratégia.
Se fogo não funcionar...
usa água.
Se espada não resolver...
usa armadilhas.
Se o corredor for estreito...
muda o posicionamento.
Ele adapta continuamente o plano.
Esse comportamento é típico de grandes engenheiros.
Planejam.
Observam.
Ajustam.
Executam.
13. Shogun e a paciência
Em Shogun, frequentemente o maior poder não pertence ao exército mais forte.
Pertence ao líder mais paciente.
Ele espera.
Observa.
Constrói alianças.
Prepara recursos.
Quando finalmente age...
grande parte da vitória já foi construída.
Na arquitetura acontece igual.
A preparação invisível normalmente representa a maior parte do trabalho.
14. O Tempo de Recuperação
Existem duas perguntas fundamentais.
Quanto dado posso perder?
Quanto tempo posso permanecer parado?
Essas perguntas definem prioridades.
Uma instituição financeira possui exigências muito diferentes de um pequeno sistema interno.
Cada organização precisa conhecer seus objetivos de continuidade antes que um incidente aconteça.
Porque durante a crise não existe tempo para discutir princípios.
15. Exercícios de Guerra
Os exércitos treinam continuamente.
Mesmo em tempos de paz.
Por quê?
Porque ninguém aprende procedimentos complexos durante uma emergência.
As empresas maduras fazem exatamente igual.
Testam:
restauração.
backup.
failover.
recuperação.
comunicação.
planos de desastre.
Esses testes revelam problemas invisíveis.
16. O ABEND da Sexta-feira
Existe uma antiga tradição entre programadores.
Evitar implantações críticas na sexta-feira.
Não porque sexta seja amaldiçoada.
Mas porque equipes diminuem.
Especialistas podem estar ausentes.
Fornecedores respondem mais lentamente.
Toda engenharia considera disponibilidade de recursos humanos.
Pessoas também fazem parte da infraestrutura.
17. O Livro das Lições Aprendidas
Após cada campanha militar...
bons comandantes registravam:
erros.
acertos.
perdas.
estratégias.
decisões.
Esses registros formavam conhecimento para futuras gerações.
No Data Center deveria ocorrer o mesmo.
Após cada incidente perguntar.
O que aconteceu?
Por quê?
Como detectamos?
Como evitar?
Como recuperar mais rapidamente?
Cada incidente bem documentado fortalece a organização.
18. Curiosidade Histórica
Durante a construção de grandes fortalezas japonesas, era comum existir planejamento para situações extremas, incluindo armazenamento prolongado de alimentos, fontes alternativas de água, rotas internas protegidas e áreas destinadas à reorganização das tropas durante cercos. O objetivo não era apenas resistir ao primeiro ataque, mas manter capacidade operacional mesmo após semanas ou meses de pressão contínua.
Em ambientes IBM Z, conceitos como Disaster Recovery, replicação geográfica, backups testados, alta disponibilidade e procedimentos de recuperação seguem exatamente essa lógica: garantir continuidade da missão mesmo diante de eventos inesperados.
19. Easter Egg — O Job que Nunca Precisou do Plano B
Conta uma velha história dos operadores que existia um procedimento chamado:
RECOVERY-PROCEDURE-17
Durante vinte anos...
ninguém o executou.
Alguns chegaram a sugerir removê-lo.
"Está ocupando espaço."
"Jamais será utilizado."
Até que uma madrugada...
uma falha elétrica atingiu parte do Data Center.
O procedimento foi aberto.
Cada passo estava documentado.
Cada responsável conhecia sua função.
Em poucas horas...
o processamento foi restabelecido.
Na reunião de encerramento, um veterano escreveu apenas uma frase.
Os melhores planos de contingência
são justamente aqueles que quase nunca precisam ser utilizados.
20. Checklist do Engenheiro da Continuidade
Antes de considerar um sistema realmente preparado, pergunte:
✔ Existe plano de rollback?
✔ Existe checkpoint?
✔ O backup foi testado?
✔ O procedimento de recuperação está documentado?
✔ Os contatos de emergência estão atualizados?
✔ Existe ambiente alternativo?
✔ Há monitoramento contínuo?
✔ O tempo máximo de indisponibilidade é conhecido?
✔ A perda máxima aceitável de dados foi definida?
✔ Os testes simulam incidentes reais?
✔ As equipes treinam regularmente?
✔ As lições aprendidas são registradas?
Conclusão — O Castelo Sobreviveu ao Inverno
O inverno mais rigoroso das últimas décadas finalmente terminou.
O inimigo nunca conseguiu romper as muralhas.
Mas essa não foi a maior vitória.
O verdadeiro triunfo aconteceu porque, durante meses de cerco:
os poços permaneceram limpos.
os celeiros continuaram abastecidos.
as passagens secretas permaneceram ocultas.
as mensagens chegaram aos aliados.
os ferreiros continuaram trabalhando.
os médicos atenderam os feridos.
o comandante nunca precisou improvisar.
Quando a primavera voltou, o jovem samurai perguntou:
— Mestre... afinal, qual foi a batalha mais importante?
O velho engenheiro respondeu sem olhar para as muralhas.
— Aquela que vencemos antes de ela acontecer.
Na sala de operações, o relógio marcava 06h03.
O processamento noturno terminara.
Nenhum cliente percebeu que um subsistema havia falhado durante a madrugada.
Nenhuma transação foi perdida.
Nenhum pagamento deixou de ser realizado.
Nenhum relatório precisou ser refeito.
O incidente existiu.
Mas a continuidade venceu.
O jovem programador fechou seu terminal.
Agora compreendia algo que levara anos para seus mestres aprenderem.
Escrever um programa COBOL é uma habilidade.
Construir um sistema resiliente é engenharia.
E garantir que ele continue funcionando quando tudo parece dar errado...
...é a arte que separa um simples desenvolvedor de um verdadeiro guardião dos sistemas críticos.
Porque, no fim de toda campanha, os heróis mais importantes raramente são aqueles que empunharam a espada.
São aqueles que garantiram que, quando a tempestade chegasse, a fortaleza continuasse de pé.
☕ 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