 |
| Bellacosa Mainframe e a engenharia militar parte xv |
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Capítulo XV — Engenharia de Cerco
Quando um Programador COBOL Descobre que os Sistemas Críticos Raramente Morrem de Uma Só Vez... Eles São Cercados Lentamente
A névoa cobria o vale.
No alto da colina, a fortaleza permanecia imóvel.
As bandeiras ainda tremulavam.
As muralhas pareciam intactas.
Os soldados mantinham suas posições.
Quem observasse de longe concluiria rapidamente:
— Está tudo bem.
O velho engenheiro balançou a cabeça.
— Não.
O cerco começou há semanas.
O jovem comandante olhou novamente.
Não havia catapultas disparando.
Não existiam muralhas quebradas.
Nenhum portão havia sido derrubado.
— Mas onde está a batalha?
O mestre apontou para o horizonte.
— Você está procurando explosões.
Eu estou observando suprimentos.
Silêncio.
A água.
A comida.
O cansaço.
A disciplina.
A moral.
As pequenas rachaduras.
É assim que uma fortaleza costuma cair.
Nunca por causa do primeiro golpe.
Sempre pelo último.
Décadas depois...
09h17.
O painel de monitoramento mostrava tudo verde.
CPU em níveis normais.
Discos respondendo.
CICS ativo.
Db2 disponível.
MQ funcionando.
Os usuários continuavam trabalhando.
Mesmo assim...
o arquiteto chamou toda a equipe.
— Estamos sob ataque.
Os mais jovens estranharam.
— Mas nenhum sistema caiu.
O arquiteto respondeu calmamente.
— Ainda não.
O aumento de CPU começou há vinte dias.
As filas MQ cresceram lentamente.
O banco perdeu desempenho.
O espaço em disco diminuiu.
Os backups estão demorando mais.
Os jobs terminaram cinco minutos depois do normal.
Os usuários ainda não perceberam.
Mas o cerco começou.
Sirva mais um café.
Hoje aprenderemos que os maiores desastres raramente começam como desastres.
Começam como pequenos sinais ignorados.
1. O Cerco é uma Guerra de Paciência
Nas batalhas medievais, atacar muralhas era extremamente caro.
Perdiam-se homens.
Equipamentos.
Tempo.
Por isso, muitos comandantes preferiam outra estratégia.
Esperar.
Bloquear estradas.
Impedir alimentos.
Cortar água.
Interromper comunicações.
Enfraquecer lentamente a fortaleza.
Na tecnologia acontece exatamente igual.
Pouquíssimos ambientes entram em colapso instantaneamente.
Normalmente eles passam por um longo período de degradação.
O desastre apenas revela um problema que já existia havia muito tempo.
2. A Fome dos Sistemas
Uma fortaleza precisa de:
água.
comida.
madeira.
medicamentos.
Homens.
Um ambiente IBM Z também possui recursos essenciais.
CPU.
Memória.
Canal.
Disco.
Rede.
Locks.
Threads.
Buffers.
Storage.
Quando um desses recursos começa a faltar...
o cerco iniciou.
3. O Inimigo Invisível
Nem todo cerco possui um exército.
Alguns cercos são provocados por:
crescimento inesperado.
dados excessivos.
má indexação.
SQL ineficiente.
loops.
vazamentos de memória.
logs gigantescos.
jobs acumulados.
Mudanças aparentemente pequenas.
A maioria dos grandes incidentes nasce dessas pequenas decisões.
4. A Catapulta Moderna
Na Idade Média...
catapultas lançavam pedras.
Hoje...
os projéteis possuem outros nomes.
Ataques DDoS.
Ransomware.
Exploração de credenciais.
Carga inesperada.
Processamentos mal planejados.
Integrações descontroladas.
APIs sem limitação.
Cada um deles tenta romper uma parte diferente da muralha.
5. O Túnel Sob a Fortaleza
Os antigos sitiantes escavavam túneis.
Não atacavam o muro.
Atacavam seus alicerces.
No software ocorre algo semelhante.
Uma aplicação aparentemente saudável pode possuir:
Copybooks duplicados.
Regras contraditórias.
Dependências desconhecidas.
Interfaces abandonadas.
Bibliotecas antigas.
Tudo permanece funcionando...
até que alguém mexe justamente naquele ponto.
Então toda a estrutura treme.
6. O Cerco Psicológico
Uma fortaleza não era derrotada apenas pela fome.
Também pela exaustão.
Boatos.
Incertezas.
Medo.
Na engenharia existe equivalente.
Alarmes constantes.
Incidentes sucessivos.
Mudanças mal comunicadas.
Pressão.
Horas extras intermináveis.
A equipe cansada começa a cometer erros.
Às vezes...
o verdadeiro alvo nunca foi a infraestrutura.
Foi o fator humano.
7. O Espião Dentro das Muralhas
Muitos castelos caíram porque alguém abriu um portão.
Não por força.
Por confiança mal administrada.
Hoje encontramos equivalentes.
Senha compartilhada.
Conta privilegiada esquecida.
Permissão excessiva.
Token exposto.
Script automático sem controle.
A fortaleza continua robusta.
Mas alguém deixou a chave pendurada.
8. O Estoque Decide a Guerra
Durante um cerco...
o comandante calcula diariamente.
Quantos dias restam?
Quanto trigo?
Quanta água?
Quantas flechas?
No Mainframe fazemos exatamente igual.
Espaço em DASD.
Capacidade de fitas.
Buffers.
Storage.
Consumo de CPU.
Janela Batch.
Taxa de crescimento.
Capacity Planning não é luxo.
É logística de sobrevivência.
9. O Tempo Trabalha para os Dois Lados
Quem ataca também sofre.
Quem defende também.
O segredo está em administrar recursos melhor que o adversário.
Na produção isso significa:
priorizar.
adiar.
balancear.
redistribuir.
automatizar.
Eliminar desperdícios.
O WLM faz exatamente esse papel.
Ele é o estrategista silencioso do castelo.
10. Quando a Muralha Parece Perfeita
Existe um erro muito comum.
Pensar que segurança significa muralhas mais altas.
Na realidade...
uma fortaleza forte possui:
observação.
comunicação.
disciplina.
reserva.
planos alternativos.
Treinamento.
Na tecnologia chamamos isso de:
monitoramento.
observabilidade.
logs.
SMF.
RMF.
SIEM.
Alertas.
Automação.
Backup testado.
Plano de recuperação.
11. Goblin Slayer Nunca Invade Sem Estudar
Goblin Slayer raramente ataca imediatamente.
Primeiro observa.
Conta entradas.
Analisa saídas.
Estuda armadilhas.
Descobre horários.
Calcula riscos.
Somente depois age.
Essa metodologia é extremamente parecida com um troubleshooting eficiente.
Antes de alterar qualquer programa:
Observe.
Colete evidências.
Reproduza.
Confirme.
Documente.
Só então modifique.
12. Shogun e a Guerra de Resistência
Em Shogun, a vitória frequentemente pertence ao comandante mais paciente.
Não necessariamente ao mais agressivo.
A mesma lição vale para sistemas críticos.
Nem todo problema precisa de uma solução imediata.
Alguns exigem investigação cuidadosa.
Planejamento.
Execução controlada.
Validação.
A ansiedade costuma destruir mais ambientes do que o defeito original.
13. O Cerco Digital
Imagine um ambiente bancário.
Segunda-feira.
Tudo parece normal.
Mas...
Uma consulta SQL ficou 3% mais lenta.
Uma API recebeu 5% mais chamadas.
O disco cresceu 2%.
A fila MQ aumentou discretamente.
Os logs passaram a ocupar mais espaço.
Nenhum evento isolado preocupa.
Somados...
contam uma história.
A boa engenharia aprende a ler histórias antes que elas se transformem em tragédias.
14. Curiosidade Histórica
O cerco de Constantinopla, em 1453, demonstrou que nenhuma fortaleza é invulnerável. Durante semanas, os defensores resistiram graças à disciplina, ao planejamento e às reservas. O desfecho não ocorreu por um único fator, mas pela combinação de desgaste contínuo, inovação tecnológica, pressão logística e sucessivas decisões tomadas sob enorme tensão.
Nos ambientes IBM Z ocorre algo semelhante. Grandes incidentes raramente têm uma única causa. Investigações de produção costumam revelar uma cadeia de pequenos eventos: aumento gradual de carga, crescimento de dados, parametrizações inadequadas, mudanças recentes, recursos próximos do limite e dependências inesperadas. O papel da engenharia é interromper essa cadeia antes que ela se transforme em uma indisponibilidade.
15. Easter Egg — A Porta Nunca Trancada
Conta uma antiga história que uma fortaleza permaneceu invicta durante cento e vinte anos.
Depois caiu em uma única noite.
Os historiadores procuraram enormes falhas estruturais.
Não encontraram.
Descobriram apenas isto.
O responsável pelo fechamento do portão acreditava que outro soldado faria a inspeção final.
Ninguém fez.
Décadas depois...
um arquiteto encontrou um comentário esquecido em um PROC.
//* VERIFICAR ESPAÇO LIVRE ANTES DA EXECUÇÃO
//* IMPLEMENTAR DEPOIS
A observação havia sido escrita quinze anos antes.
Jamais foi implementada.
Naquela semana...
o volume atingiu 100%.
O ambiente parou.
Nenhuma tecnologia extraordinária causou o incidente.
Apenas uma pequena tarefa adiada repetidamente.
16. Checklist do Comandante Durante um Cerco
Antes que a produção entre em crise, pergunte:
✔ O consumo de CPU está crescendo?
✔ O espaço em disco acompanha o crescimento do negócio?
✔ As filas MQ aumentaram além do esperado?
✔ Os índices do Db2 continuam eficientes?
✔ Os backups ainda cabem na janela operacional?
✔ Existe monitoramento para recursos críticos?
✔ Os alertas são realmente analisados?
✔ O plano de recuperação foi testado?
✔ A documentação está atualizada?
✔ O conhecimento está distribuído entre a equipe?
✔ As mudanças recentes foram revisadas?
✔ Estamos reagindo aos sintomas ou tratando as causas?
Conclusão — A Vitória Antes da Batalha
O jovem comandante voltou a observar a fortaleza.
Agora compreendia.
A batalha nunca começava quando a primeira pedra atingia a muralha.
Ela começava semanas antes.
Quando alguém deixava de revisar os estoques.
Quando um relatório deixava de ser lido.
Quando pequenas rachaduras eram ignoradas.
Quando o excesso de confiança substituía a disciplina.
O velho engenheiro serviu mais uma xícara de café.
— Lembre-se sempre...
Os melhores comandantes não vencem porque lutam melhor.
Vencem porque percebem o cerco antes que os outros descubram que ele começou.
No Data Center acontece exatamente o mesmo.
Os maiores profissionais de Mainframe não são aqueles que resolvem os incidentes mais espetaculares.
São aqueles que impedem que eles aconteçam.
Porque toda fortaleza cai duas vezes.
Primeiro...
na atenção de seus guardiões.
Depois...
em suas muralhas.
E o verdadeiro engenheiro aprende a proteger ambas.
Ao terminar este capítulo, talvez você nunca mais veja um gráfico de CPU, uma fila MQ crescendo lentamente, um volume de disco próximo do limite ou um alerta aparentemente insignificante da mesma maneira.
Porque agora você sabe reconhecer o início de um cerco.
E quem identifica o cerco cedo o suficiente...
quase nunca precisa lutar a batalha final.
☕ 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
