 |
| Bellacosa Mainframe apresenta a serie sobre engenharia militar |
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Quando um Programador Descobre que Animes, Mangás, Mainframes e Exércitos Antigos Falam a Mesma Língua: Planejamento, Disciplina, Logística e Sobrevivência
O relógio marcava uma hora indecente da madrugada.
Na sala silenciosa, iluminada apenas pelo brilho esverdeado do terminal, um jovem programador COBOL observava um job parado na fila de execução. O sistema não havia sofrido um ABEND. Não havia mensagem de erro. Não existia dump para analisar.
Ainda assim, alguma coisa estava errada.
O programa deveria processar milhares de registros, atualizar contas, gerar relatórios e entregar arquivos para outros sistemas antes do início do expediente bancário. O código estava aparentemente correto. O JCL compilava. Os datasets existiam.
Mas o processamento não avançava.
Foi então que o veterano apareceu, carregando uma caneca de café e a expressão tranquila de quem já havia sobrevivido a muitos fechamentos mensais.
Ele olhou a tela e perguntou:
— Você verificou o terreno?
O jovem franziu a testa.
— Terreno? Isto é um mainframe, não uma guerra.
O veterano sorriu.
— Todo sistema crítico é um campo de operações. O código é apenas uma unidade. Existem suprimentos, rotas, dependências, comunicação, inteligência, comando e retirada. Quem olha somente para o programa está tentando vencer uma guerra observando apenas a espada.
Naquele instante, o programador descobriu que engenharia militar, animes, mangás e sistemas de informação possuíam muito mais em comum do que ele imaginava.
E é sobre isso que conversaremos neste café.
 |
| Bellacosa Mainframe o que é engenharia militar |
O que é engenharia militar?
Quando ouvimos a expressão “engenharia militar”, muitas pessoas imaginam soldados construindo pontes, abrindo estradas ou desarmando explosivos.
Essa imagem não está errada, mas é incompleta.
Engenharia militar é o uso coordenado de conhecimentos técnicos para permitir que uma força:
se desloque;
se proteja;
se comunique;
receba suprimentos;
atravesse obstáculos;
controle territórios;
sobreviva;
cumpra sua missão.
Ela envolve construção de fortificações, pontes, túneis, estradas, portos, pistas, sistemas de comunicação, abastecimento de água, energia, transporte, defesa e demolição.
Mas seu verdadeiro núcleo não está no concreto, no aço ou na pólvora.
Está no planejamento de condições para que uma operação seja possível.
Esse conceito é muito importante.
Um guerreiro pode ser excepcional, mas não atravessa um rio sem ponte. Uma tropa pode ser numerosa, mas não combate sem alimento. Um general pode ter um plano brilhante, mas fracassará se suas ordens não chegarem às unidades.
Na tecnologia acontece a mesma coisa.
Um programa COBOL pode estar perfeitamente escrito e ainda assim falhar por causa de:
arquivo inexistente;
volume insuficiente;
catálogo incorreto;
versão errada de copybook;
indisponibilidade do Db2;
fila MQ cheia;
plano de execução inadequado;
dependência não concluída;
autorização RACF insuficiente;
janela de processamento mal planejada.
Engenharia militar e engenharia de sistemas compartilham uma verdade desconfortável:
O melhor combatente não vence sozinho, e o melhor programa não funciona isoladamente.
O castelo chamado mainframe
Imagine um grande ambiente IBM Z como um castelo do período Sengoku.
No centro está a fortaleza principal, protegida por muralhas, fossos, portões e soldados.
No mainframe, essa fortaleza é formada por camadas:
hardware;
firmware;
hipervisores;
LPARs;
z/OS;
subsistemas;
segurança;
aplicações;
bancos de dados;
redes;
procedimentos operacionais.
Cada camada protege e sustenta as demais.
O RACF funciona como o controle dos portões. O WLM distribui recursos como um comandante distribuindo homens e provisões. O JES2 organiza as caravanas de jobs. O CICS recebe milhares de solicitações como uma cidade comercial protegida dentro das muralhas. O Db2 armazena registros como um arquivo imperial guardado por escribas.
E o programador COBOL?
Ele é uma mistura de artesão, escriba, engenheiro e estrategista.
Seu trabalho não é apenas escrever instruções.
É compreender como aquela instrução participa de um sistema muito maior.
A guerra raramente é vencida pela espada
Um dos maiores equívocos sobre conflitos militares é acreditar que guerras são decididas apenas em batalhas.
Na realidade, muitas guerras são decididas antes do combate.
São decididas por:
logística;
informação;
posicionamento;
preparação;
alianças;
moral;
capacidade de reposição;
tempo.
É exatamente isso que vemos em muitos animes e mangás.
O protagonista pode carregar uma espada gigantesca, possuir poderes especiais ou pilotar um robô colossal. Entretanto, quando a história é bem construída, o resultado depende de fatores muito mais complexos.
Em Shogun, por exemplo, poder não significa apenas possuir soldados. Poder significa compreender alianças, cerimônias, lealdades, rotas marítimas, religiões, comércio e informação.
A guerra acontece tanto no salão de chá quanto no campo de batalha.
Uma palavra pronunciada diante da pessoa errada pode causar mais destruição que uma carga de cavalaria.
No mainframe, uma alteração de parâmetro também pode ser mais perigosa que centenas de linhas de código.
O anime como tratado de formação
A percepção de que muitos animes parecem tratados militares não é absurda.
Eles frequentemente apresentam personagens sendo educados em:
disciplina;
hierarquia;
resistência;
cooperação;
respeito;
responsabilidade;
autocontrole;
análise do adversário;
preparação para situações críticas.
Isso não significa que todo anime seja propaganda militar.
O que acontece é que diversas narrativas japonesas valorizam a formação gradual do indivíduo dentro de um grupo.
O herói não nasce pronto.
Ele entra em uma escola, academia, clã, guilda, equipe ou organização. Recebe uma função. Aprende regras. Enfrenta testes. Falha. Observa os veteranos. Desenvolve habilidades. Assume responsabilidades.
Essa estrutura é muito semelhante à formação militar e também à formação profissional em ambientes críticos.
O programador COBOL iniciante passa por algo parecido:
aprende a navegar no ambiente;
compreende datasets;
estuda JCL;
conhece os padrões da empresa;
lê programas antigos;
acompanha execuções;
realiza pequenas alterações;
participa de testes;
aprende a analisar falhas;
passa a responder por processos maiores.
Ele não recebe uma katana. Recebe um acesso de desenvolvimento.
Mas o ritual de iniciação existe.
Senpai, mestre e cadeia de conhecimento
Nos animes, o veterano geralmente possui uma função essencial.
Ele não entrega todas as respostas. Em vez disso, ensina como pensar.
Essa relação entre mestre e aprendiz possui grande valor em ambientes mainframe, porque muitos conhecimentos não estão totalmente registrados em manuais.
Há informações que vivem na experiência:
por que determinado job não pode executar antes de outro;
por que um arquivo aparentemente obsoleto ainda existe;
por que uma rotina precisa ser chamada daquela maneira;
por que determinada tabela não pode ser atualizada durante certo horário;
por que um comentário de 1987 continua válido.
Esses conhecimentos formam uma espécie de tradição oral tecnológica.
Em um exército antigo, um comandante experiente conhecia rios, estações, terrenos e comportamentos inimigos.
Em um ambiente corporativo, o profissional veterano conhece calendários, dependências, riscos, exceções e cicatrizes históricas do sistema.
Ele sabe que o código pode parecer ilógico porque está protegendo uma regra criada após um incidente ocorrido há vinte anos.
O iniciante enxerga redundância.
O veterano enxerga uma muralha construída depois de uma invasão.
Logística: o coração invisível da vitória
Há uma frase frequentemente atribuída ao pensamento militar: amadores discutem estratégia; profissionais discutem logística.
Mesmo sem entrar na autoria ou na forma exata da frase, a ideia é poderosa.
Logística é garantir que recursos estejam no lugar certo, na quantidade certa e no momento certo.
Em uma campanha militar, isso significa:
comida;
água;
munição;
remédios;
transporte;
roupas;
ferramentas;
animais;
combustível.
No mainframe, a logística aparece como:
espaço em disco;
memória;
CPU;
arquivos;
tabelas;
filas;
calendários;
janelas batch;
disponibilidade de subsistemas;
capacidade de rede.
Um job que precisa ler dois bilhões de registros não é apenas um problema de programação.
É uma operação logística.
Quanto tempo ele terá?
Qual volume será utilizado?
Existe espaço para arquivos temporários?
O SORT conseguirá processar os dados?
O WLM concederá recursos suficientes?
O arquivo de saída caberá no dispositivo?
Outro sistema estará aguardando o resultado?
O verdadeiro engenheiro não pergunta apenas “o programa funciona?”.
Ele pergunta:
O ecossistema consegue sustentar o funcionamento?
Goblin Slayer e a engenharia da sobrevivência
Goblin Slayer oferece um exemplo quase didático de pensamento operacional.
O protagonista não depende de força bruta ou destino.
Ele observa:
entradas;
saídas;
terreno;
ventilação;
número provável de inimigos;
comportamento do adversário;
suprimentos disponíveis;
riscos para civis;
possibilidades de emboscada.
Ele leva cordas, tochas, armas secundárias e ferramentas aparentemente comuns.
Isso é engenharia militar aplicada a uma masmorra.
O aventureiro arrogante entra perguntando:
— Quantos goblins posso derrotar?
Goblin Slayer pergunta:
— Como impedir que algum deles escape?
Essa mudança de pergunta é fundamental.
No mainframe, o desenvolvedor inexperiente pergunta:
— Como faço esta alteração?
O profissional maduro pergunta:
— Como faço esta alteração sem afetar os demais processos?
Parece uma diferença pequena, mas separa programação de engenharia.
Reconhecimento: nunca atacar no escuro
Antes de uma operação, forças militares realizam reconhecimento.
Precisam conhecer:
terreno;
forças adversárias;
rotas;
obstáculos;
clima;
posições defensivas;
população local.
No desenvolvimento de sistemas, reconhecimento significa investigar antes de alterar.
Passo a passo para um reconhecimento técnico
Primeiro, localize o programa e descubra como ele é executado.
Depois, identifique os arquivos de entrada e saída.
Em seguida, procure chamadas para outros módulos.
Verifique copybooks, tabelas Db2, filas MQ, transações CICS e regras externas.
Analise o histórico de alterações.
Leia os jobs que executam antes e depois.
Converse com usuários e operadores.
Somente então toque no código.
Modificar um programa sem esse reconhecimento é como enviar uma tropa por uma floresta desconhecida porque alguém encontrou uma trilha no mapa.
Talvez funcione.
Talvez a trilha termine em um pântano.
Fortificações e defesa em profundidade
Fortalezas antigas raramente dependiam de uma única muralha.
Elas possuíam:
fossos;
terrenos inclinados;
muros externos;
portões reforçados;
torres;
corredores estreitos;
muralhas internas;
posições elevadas.
Se o inimigo superasse uma defesa, encontraria outra.
Esse princípio é chamado atualmente de defesa em profundidade.
Em sistemas de informação, ele aparece quando usamos várias camadas de proteção:
autenticação;
autorização;
criptografia;
segmentação;
monitoramento;
logs;
backups;
cópias imutáveis;
recuperação;
auditoria.
Depender de uma única proteção é como construir um castelo com um portão excelente e nenhuma muralha.
Um sistema seguro não presume que nenhuma camada falhará.
Ele presume que alguma camada eventualmente falhará e prepara as demais.
Essa mentalidade também vale para programação COBOL.
Uma rotina crítica pode possuir:
validação de entrada;
controle de faixa;
verificação de status de arquivo;
tratamento de SQLCODE;
rollback;
mensagens de diagnóstico;
rejeição de registros inválidos;
reconciliação posterior.
Cada controle é uma muralha.
Pontes, interfaces e integração
Uma das funções clássicas da engenharia militar é construir pontes.
Sem ponte, uma força fica presa de um lado do rio.
Nos sistemas, as pontes são interfaces.
Podem ser:
arquivos;
APIs;
mensagens;
chamadas de programa;
tabelas compartilhadas;
serviços;
conectores.
Uma integração mal projetada é uma ponte estreita demais para a carga que precisa atravessar.
Imagine um programa COBOL produzindo um arquivo para outro sistema.
É necessário definir:
formato;
tamanho;
codificação;
ordem;
frequência;
tratamento de erro;
reprocessamento;
duplicidade;
confirmação.
Não basta jogar dados do outro lado.
É necessário garantir que a ponte seja estável, monitorada e compreendida pelas duas margens.
Muitas falhas atribuídas a programas são, na verdade, falhas de fronteira.
O produtor acredita que entregou.
O consumidor acredita que receberá outro formato.
E o rio continua entre eles.
Cadeia de comando e governança
Em operações militares, ordens precisam ter origem clara.
Quem decide?
Quem executa?
Quem aprova?
Quem recebe informações?
Quem assume em caso de falha?
No desenvolvimento corporativo, isso se chama governança.
Uma mudança em produção normalmente envolve:
solicitante;
analista;
desenvolvedor;
testador;
gestor;
operador;
administrador;
equipe de segurança;
área de negócio.
Sem definição de papéis, o sistema entra em uma espécie de guerra feudal tecnológica: todos possuem responsabilidade parcial, mas ninguém controla o território inteiro.
O resultado são frases clássicas:
— Achei que a infraestrutura faria isso.
— Pensei que o usuário validaria.
— Imaginei que o job já estivesse agendado.
— Presumi que o backup fosse automático.
Em operações críticas, “presumi” é frequentemente o primeiro capítulo do relatório de incidente.
A importância da retirada
Um comandante inteligente não planeja apenas o ataque.
Planeja também a retirada.
Na tecnologia, a retirada é o rollback.
Antes de implantar uma mudança, pergunte:
Como voltaremos à versão anterior?
Os dados podem ser revertidos?
Existe backup?
Quanto tempo a recuperação exige?
Quem possui autoridade para interromper?
Qual condição determina o cancelamento?
Muitos projetos falham porque tratam rollback como pessimismo.
Mas planejar retirada não significa esperar derrota.
Significa respeitar a realidade.
Samurais, generais e sysprogs experientes sabem que coragem sem contingência é apenas imprudência usando armadura bonita.
O Estado poderia educar cidadãos por meio de animes e mangás?
Sim.
Histórias visuais são ferramentas poderosas de educação porque combinam:
emoção;
identificação;
repetição;
símbolos;
exemplos;
memória narrativa.
Um governo poderia utilizar mangás e animações para ensinar:
primeiros socorros;
prevenção de desastres;
cidadania;
segurança no trânsito;
educação financeira;
higiene;
preservação ambiental;
combate a incêndios;
uso responsável da tecnologia;
preparação para emergências.
Isso já ocorre, de diferentes formas, em campanhas públicas ao redor do mundo.
O formato é particularmente eficiente porque não parece uma aula tradicional.
Uma criança pode esquecer uma lista de procedimentos.
Mas poderá lembrar-se de um personagem que protegeu seus amigos ao seguir esses procedimentos.
A narrativa transforma instrução em experiência emocional.
Educação ou propaganda?
Aqui surge a questão mais delicada.
O mesmo instrumento capaz de ensinar também pode manipular.
A diferença não está no desenho, no mangá ou na animação.
Está no objetivo e no método.
Uma obra educativa oferece informações, apresenta consequências e estimula responsabilidade.
Uma obra propagandística tende a:
simplificar conflitos;
transformar adversários em monstros;
eliminar ambiguidades;
glorificar autoridade;
punir questionamento;
criar inimigos absolutos;
apresentar obediência como virtude universal.
A educação diz:
Pense, compreenda e escolha com responsabilidade.
A propaganda diz:
Sinta, obedeça e não investigue.
Naturalmente, nenhuma obra é completamente neutra. Toda história carrega valores. Até a decisão de quem será o protagonista e quem será o vilão já produz uma visão do mundo.
Por isso, a melhor defesa contra propaganda não é proibir histórias.
É ensinar leitura crítica.
Como analisar um anime como um engenheiro
O programador COBOL pode transformar qualquer anime em um exercício de análise de sistemas.
Primeiro passo: identifique a missão
O que os personagens realmente precisam alcançar?
Não confunda objetivo declarado com objetivo operacional.
“Derrotar o vilão” pode significar, na prática, proteger uma cidade, recuperar informação ou impedir uma invasão.
Segundo passo: identifique os recursos
Quais pessoas, armas, conhecimentos, alianças e tecnologias estão disponíveis?
Terceiro passo: identifique as restrições
Tempo, terreno, regras, política, moral, energia, distância e informação limitada.
Quarto passo: observe a cadeia de comando
Quem decide? Quem executa? Quem discorda? Quem possui informação?
Quinto passo: procure pontos únicos de falha
Existe um personagem sem o qual todo o plano desmorona?
Existe uma rota única?
Existe dependência de uma informação não confirmada?
Sexto passo: examine o plano de contingência
O que acontece quando o plano inicial falha?
Sétimo passo: analise a logística
Como os personagens comem, descansam, transportam equipamentos e mantêm comunicação?
Você perceberá rapidamente que muitas histórias ignoram a logística. Outras, como Goblin Slayer, Kingdom, Legend of the Galactic Heroes e determinados arcos de Attack on Titan, transformam logística em parte central da narrativa.
Kaizen, treinamento e repetição
Animes frequentemente apresentam longos ciclos de treinamento.
O personagem repete movimentos até que eles se tornem naturais.
Isso possui relação com disciplina militar, artes marciais e o princípio japonês de aperfeiçoamento contínuo.
No mainframe, kaizen não significa reescrever tudo.
Significa melhorar progressivamente:
mensagens mais claras;
melhor tratamento de erro;
documentação atualizada;
automação de testes;
redução de dependências;
monitoramento mais preciso;
procedimentos de recuperação.
O profissional maduro não despreza o sistema antigo.
Ele o estuda, compreende e melhora sem destruir o conhecimento acumulado.
Modernização sem reconhecimento é invasão.
Modernização com conhecimento é engenharia.
Easter egg: a mensagem escondida no copybook
Conta-se que, em uma antiga instalação, havia um copybook utilizado por centenas de programas.
Na última linha aparecia o comentário:
* NÃO REMOVER. O CASTELO CAI.
Durante anos ninguém soube explicar sua origem.
Um novo programador, determinado a “limpar o legado”, removeu o campo aparentemente inútil.
O programa compilou.
Os testes passaram.
Na produção, um sistema externo começou a ler os registros com deslocamento incorreto. Valores monetários apareceram em campos de data, códigos de agência viraram números de conta e um arquivo inteiro precisou ser restaurado.
O comentário não era superstição.
Era uma mensagem deixada por um engenheiro que conhecia a ponte, embora ninguém mais se lembrasse do rio.
Moral da história:
Antes de remover uma pedra antiga, descubra o que ela sustenta.
Curiosidade: muralhas também direcionam
Uma fortificação não serve apenas para bloquear.
Ela também conduz o inimigo para onde o defensor deseja.
Portões, corredores e fossos canalizam movimentos.
Na segurança digital, fazemos algo semelhante com:
segmentação;
permissões;
fluxos autorizados;
zonas de confiança;
validações;
APIs controladas.
Um bom sistema não apenas impede comportamentos proibidos.
Ele facilita o caminho correto.
Quando o caminho oficial é complicado demais, usuários criam atalhos. Salvam senhas em arquivos, compartilham acessos e realizam processos manuais.
Uma muralha mal desenhada produz túneis clandestinos.
O verdadeiro ensinamento militar dos animes
Talvez a maior lição não seja obedecer.
É compreender que ações possuem consequências coletivas.
O soldado que abandona sua posição pode expor toda a unidade.
O programador que altera um campo sem verificar consumidores pode afetar dezenas de sistemas.
O operador que ignora uma mensagem pode atrasar o processamento de milhares de clientes.
Responsabilidade não é medo.
É consciência de interdependência.
Muitos animes ensinam isso quando mostram personagens deixando de agir como indivíduos isolados e começando a compreender seu lugar dentro de algo maior.
Essa é uma forma de educação militar, mas também é educação social, profissional e ética.
Entre disciplina e pensamento crítico
A disciplina é necessária em sistemas críticos.
Mas disciplina sem pensamento crítico pode transformar procedimentos em rituais vazios.
Um bom profissional respeita padrões, mas também pergunta:
por que este padrão existe?
ele ainda protege o sistema?
existem condições novas?
o procedimento cobre este cenário?
há evidências de que funciona?
Em Shogun, os personagens sobrevivem não apenas porque obedecem, mas porque compreendem códigos culturais, intenções ocultas e relações de poder.
Quem apenas segue palavras pode cair em armadilhas.
Quem entende o contexto consegue interpretar o verdadeiro significado da ordem.
No mainframe também é assim.
Executar um comando é simples.
Saber quando não executá-lo é experiência.
Conclusão: o campo de batalha invisível
A engenharia militar ensina que nenhuma missão existe isoladamente.
Sempre haverá terreno, suprimentos, comunicação, defesa, comando, inteligência e contingência.
Os animes e mangás frequentemente transformam essas ideias em histórias de formação. Seus personagens treinam, falham, cooperam e aprendem a agir sob pressão.
Um Estado pode utilizar essas narrativas para educar cidadãos, transmitir valores e preparar populações. Isso pode produzir excelentes campanhas de segurança, saúde e cidadania. Porém, o mesmo instrumento pode ser usado para simplificar o mundo, manipular emoções e substituir pensamento por obediência.
A diferença está na presença ou ausência de liberdade crítica.
Para o programador COBOL iniciante, a lição é extraordinariamente prática.
Não trate o programa como uma ilha.
Veja o terreno.
Conheça as rotas.
Identifique aliados e dependências.
Proteja as fronteiras.
Prepare suprimentos.
Teste as pontes.
Defina a retirada.
Documente os riscos.
E nunca entre em produção acreditando que coragem compensará falta de preparação.
Na madrugada, o veterano finalmente apontou para a tela.
O job não avançava porque aguardava um arquivo produzido por outro sistema. Esse sistema estava parado porque uma transferência havia falhado. A transferência falhara porque uma credencial havia expirado.
O código COBOL estava perfeito.
A campanha é que havia perdido sua rota de suprimentos.
O jovem programador respirou fundo e compreendeu.
Não estava apenas aprendendo uma linguagem.
Estava aprendendo a defender uma fortaleza.
O veterano ergueu a caneca e disse:
— Bem-vindo ao clã.
Em algum ponto distante do data center, um drive começou a girar.
E o castelo voltou a respirar.
Este texto também pode ser adaptado para uma série em capítulos, com seções específicas sobre logística, cadeia de comando, fortificações, propaganda e estratégia nos animes.
☕ 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