 |
| Bellacosa Mainframe e o DevOps sem misterios |
☕ Um Café no Bellacosa Mainframe
DevOps sem Mistérios para o Programador COBOL Padawan
Da Tela Verde à Ponte da USS Enterprise: como desenvolvimento, operações, qualidade e negócio aprenderam a trabalhar na mesma missão
“As necessidades de muitos superam as necessidades de poucos.”
— Sr. Spock
Imagine que você acabou de entrar para a tripulação de uma gigantesca nave estelar chamada IBM Z Enterprise.
Você é um jovem programador COBOL. Seu uniforme ainda está impecável, seu crachá de acesso ao TSO acabou de ser criado e você ainda consulta uma pequena cola para lembrar a diferença entre DISP=SHR, DISP=OLD e DISP=MOD.
Sua primeira missão parece simples:
Alterar um programa COBOL para incluir um novo campo no relatório de clientes.
Você abre o fonte no ISPF, modifica a WORKING-STORAGE, ajusta o PROCEDURE DIVISION, compila o programa e realiza um teste rápido.
Tudo funciona perfeitamente.
Orgulhoso, você informa ao líder:
— Capitão, a alteração está pronta!
Mas então começa a verdadeira viagem.
A mudança precisa ser compilada no ambiente correto. Depois, deve passar pelos testes unitários, testes integrados, homologação, validação do banco de dados, análise de segurança, aprovação do negócio e, finalmente, implantação em produção.
De repente, a pequena alteração em um relatório se transforma em uma missão interplanetária envolvendo programadores, analistas de qualidade, DBAs, operadores, especialistas em CICS, administradores de segurança, gestores, usuários e o sempre misterioso profissional que sabe exatamente qual biblioteca de carga está sendo utilizada pelo job de produção.
É nesse momento que o programador COBOL Padawan descobre uma verdade fundamental:
Escrever código é apenas uma parte da engenharia de software.
O restante da missão envolve entregar esse código de maneira segura, previsível, rápida, rastreável e confiável.
É justamente nesse espaço que entra o DevOps.
Prepare seu café, ajuste o terminal 3270 e ocupe seu posto na ponte. Hoje vamos explorar DevOps não como uma palavra da moda, mas como uma mudança profunda na forma de construir, testar, entregar e operar sistemas.
1. Afinal, o que é DevOps?
O nome DevOps nasce da união de duas palavras:
Development, desenvolvimento;
Operations, operações.
Entretanto, interpretar DevOps apenas como uma união entre desenvolvedores e operadores seria uma simplificação perigosa.
DevOps é uma combinação de:
cultura;
colaboração;
automação;
integração contínua;
entrega contínua;
testes;
segurança;
observabilidade;
métricas;
feedback;
responsabilidade compartilhada.
Seu objetivo é reduzir a distância entre a criação de uma mudança e sua disponibilização segura para o usuário.
Em termos simples, DevOps tenta responder à seguinte pergunta:
Como podemos entregar software com maior frequência sem transformar produção em um campo de batalha klingon?
A resposta não está apenas em comprar ferramentas.
Uma empresa pode instalar Jenkins, Git, Docker, Kubernetes, Ansible, Zowe e dezenas de plataformas modernas e, ainda assim, continuar sem praticar DevOps.
Isso acontece porque DevOps não começa na tecnologia.
Ele começa na forma como as pessoas trabalham.
2. O antigo conflito entre desenvolvimento e operações
Durante décadas, muitas organizações trabalharam com uma forte separação entre equipes.
O desenvolvimento escrevia o código.
A qualidade testava.
A infraestrutura instalava.
A operação executava.
A segurança auditava.
O negócio reclamava.
Cada área possuía seus próprios objetivos.
O desenvolvedor queria entregar rapidamente.
A operação queria evitar mudanças.
A qualidade queria mais tempo para testar.
A segurança queria mais controles.
O gestor queria cumprir o prazo.
O usuário queria que tudo funcionasse imediatamente.
Era como uma nave em que cada oficial estivesse tentando definir um destino diferente.
O engenheiro dizia:
— Precisamos desligar os motores para manutenção.
O capitão respondia:
— Não podemos parar a nave.
O oficial científico alertava:
— A probabilidade de falha aumentou para 73,4%.
E o setor comercial perguntava:
— Conseguimos lançar a nova funcionalidade ainda hoje?
Essa fragmentação gerava conflitos, atrasos e erros.
Quando uma aplicação falhava em produção, surgia o famoso jogo de responsabilidades:
“O código funcionava em desenvolvimento.”
“A infraestrutura estava normal.”
“Os testes foram aprovados.”
“O problema está no banco.”
“O problema está na rede.”
“O usuário executou errado.”
“O job utilizou uma versão antiga da load library.”
DevOps tenta substituir essa cultura de culpa por uma cultura de colaboração.
Em vez de perguntar:
Quem causou o problema?
A equipe passa a perguntar:
Como o sistema permitiu que esse problema chegasse até aqui?
Essa mudança de pergunta é poderosa.
Ela desloca o foco da pessoa para o processo.
3. DevOps é uma filosofia de responsabilidade compartilhada
Em DevOps, o software não é abandonado depois que o programador termina a codificação.
A equipe acompanha todo o ciclo de vida:
Planejar
↓
Codificar
↓
Construir
↓
Testar
↓
Liberar
↓
Implantar
↓
Operar
↓
Monitorar
↓
Aprender
↓
Planejar novamente
Esse fluxo costuma ser representado como um símbolo de infinito.
A ideia é simples: o processo nunca termina.
Após colocar uma funcionalidade em produção, a organização coleta informações sobre seu comportamento.
Ela observa:
quantidade de erros;
tempo de resposta;
consumo de CPU;
número de usuários;
transações executadas;
falhas de banco;
abends;
reclamações;
custo operacional;
impacto no negócio.
Esses dados retornam ao planejamento e influenciam a próxima melhoria.
No universo Star Trek, podemos imaginar esse ciclo como o funcionamento da ponte da Enterprise.
A tripulação define a missão, calcula a rota, executa a viagem, monitora os sensores, identifica anomalias e ajusta o curso.
Nenhum capitão sensato ordenaria velocidade de dobra sem observar os motores, os escudos e os sensores.
Entretanto, algumas organizações fazem exatamente isso com sistemas de produção.
Implantam mudanças e esperam que tudo dê certo.
DevOps substitui esperança por engenharia.
4. Por que DevOps surgiu?
O movimento DevOps ganhou força no final dos anos 2000, principalmente como uma reação aos problemas encontrados em projetos de software grandes e lentos.
Empresas percebiam que poderiam passar meses desenvolvendo uma solução e descobrir, no final, que:
o cliente já não precisava mais dela;
os requisitos haviam mudado;
a integração não funcionava;
o ambiente de produção era diferente;
o deploy era complexo;
a equipe não conseguia recuperar rapidamente uma falha.
No modelo tradicional, grandes alterações eram acumuladas em enormes pacotes de implantação.
Quanto maior o pacote, maior o risco.
Imagine uma manutenção com:
180 programas COBOL;
60 copybooks;
25 tabelas Db2;
14 mapas BMS;
40 jobs JCL;
alterações em PROCs;
novos arquivos VSAM;
mudanças de segurança;
atualizações de parâmetros CICS.
Colocar tudo isso em produção de uma única vez é como realizar manutenção nos motores, nos escudos, no computador central e no sistema de suporte de vida simultaneamente.
Talvez funcione.
Mas não é uma estratégia confortável.
DevOps incentiva alterações menores, mais frequentes e mais fáceis de validar.
Uma pequena mudança tende a ser:
mais simples de entender;
mais fácil de testar;
mais rápida de aprovar;
mais segura de implantar;
mais fácil de reverter.
5. CI: integração contínua
Um dos pilares mais conhecidos do DevOps é a Continuous Integration, ou integração contínua.
Integração contínua significa integrar alterações de código frequentemente, em vez de esperar semanas ou meses para reunir o trabalho de vários desenvolvedores.
Imagine três programadores alterando o mesmo programa COBOL.
Ana modifica o cálculo de juros.
Carlos altera a leitura do arquivo VSAM.
Marina adiciona uma chamada para um subprograma.
Se cada um trabalhar isoladamente durante um mês, a integração final pode se transformar em um episódio de guerra temporal.
As linhas modificadas entram em conflito.
Um copybook está desatualizado.
Uma variável foi renomeada.
A interface de um CALL foi alterada.
O programa de Ana compila com uma versão do copybook, enquanto o programa de Carlos utiliza outra.
Na integração contínua, essas alterações são incorporadas com maior frequência.
Cada integração pode disparar automaticamente:
obtenção do código;
verificação das dependências;
compilação;
link-edit;
execução de testes;
análise de qualidade;
geração de relatórios;
armazenamento dos artefatos.
No mainframe moderno, ferramentas como Git, IBM Dependency Based Build, Jenkins, GitHub Actions, GitLab CI, Azure DevOps e soluções de gerenciamento de mudanças podem participar desse fluxo.
6. Um exemplo de pipeline COBOL
Vamos imaginar um fluxo simplificado.
O programador modifica um fonte COBOL e envia a alteração para o repositório.
O pipeline começa.
Commit no Git
↓
Validação do fonte
↓
Identificação das dependências
↓
Compilação COBOL
↓
Pré-compilação Db2, se necessária
↓
Link-edit
↓
Execução de testes unitários
↓
Análise estática
↓
Deploy em ambiente de testes
↓
Testes integrados
↓
Aprovação
↓
Promoção para produção
Em um programa Db2, o fluxo pode incluir:
pré-compilação SQL;
compilação COBOL;
linkedição;
criação ou atualização de package;
execução de
BIND PACKAGE;validação do plano;
testes de SQL;
análise de desempenho.
Em uma aplicação CICS, pode envolver:
compilação do mapa BMS;
compilação do programa;
geração do módulo de carga;
atualização da definição;
instalação do recurso;
novo
NEWCOPY;testes de transação.
Perceba que o pipeline não substitui o conhecimento técnico.
Ele organiza e automatiza esse conhecimento.
Automatizar uma compilação COBOL incorreta apenas produz erros em maior velocidade.
7. Continuous Delivery e Continuous Deployment
Esses dois conceitos são parecidos, mas não são idênticos.
Continuous Delivery
Na entrega contínua, o sistema é mantido em estado potencialmente implantável.
O pipeline prepara, testa e valida a mudança.
Entretanto, a entrada em produção ainda pode depender de uma aprovação humana.
Em ambientes bancários, governamentais ou altamente regulados, isso é comum.
O fluxo pode ser:
Build aprovado
↓
Testes aprovados
↓
Homologação aprovada
↓
Gestor autoriza
↓
Produção
Continuous Deployment
Na implantação contínua, toda mudança que passa pelos controles pode chegar automaticamente à produção.
Isso exige:
testes maduros;
grande automação;
forte observabilidade;
rollback confiável;
arquitetura preparada;
baixo acoplamento;
confiança nos controles.
Nem toda organização precisa implantar automaticamente em produção.
DevOps não obriga uma empresa a remover aprovações.
O objetivo é remover atrasos desnecessários e tornar o fluxo mais confiável.
No IBM Z, é perfeitamente possível praticar DevOps mantendo governança, segregação de funções e auditoria.
8. DevOps não significa ausência de controle
Este é um dos maiores medos em ambientes corporativos.
Algumas pessoas escutam “entrega contínua” e imaginam programadores enviando alterações diretamente para produção às duas horas da tarde de uma sexta-feira.
Isso não é DevOps.
Isso é imprudência.
DevOps não elimina controles.
DevOps automatiza controles.
Em vez de depender de uma lista manual, o pipeline pode verificar:
se o código foi revisado;
se os testes passaram;
se não há vulnerabilidades críticas;
se o artefato foi aprovado;
se a versão está identificada;
se existe plano de reversão;
se as dependências estão corretas;
se o ambiente está disponível.
O objetivo não é abrir os portões da nave.
É instalar sensores melhores nas portas.
9. Testes contínuos
No modelo tradicional, testes costumavam ocorrer perto do final do projeto.
Esse atraso era perigoso.
Um erro descoberto tarde pode exigir mudanças em:
código;
arquitetura;
banco;
documentação;
cronograma;
treinamento;
contratos.
DevOps aproxima os testes do momento em que o código é criado.
Isso é frequentemente associado ao conceito de shift left.
Imagine uma linha do tempo:
Requisito → Código → Build → Teste → Produção
Mover a qualidade para a esquerda significa testar mais cedo.
Para um programa COBOL, podem existir:
testes unitários;
testes de arquivos;
testes de copybooks;
testes de subprogramas;
testes de integração com Db2;
testes de transações CICS;
testes de processamento IMS;
testes de regressão;
testes de performance;
testes de segurança.
Ferramentas como ZUnit, IBM COBOL Check, Galasa, Z Virtual Test Platform e frameworks personalizados ajudam a automatizar parte desse processo.
Um programa simples de cálculo pode ser testado com entradas conhecidas.
Por exemplo:
Valor: 1000
Taxa: 2%
Resultado esperado: 1020
Se uma mudança alterar o resultado para 1200, o pipeline deve detectar a anomalia antes que ela alcance produção.
O teste automatizado funciona como o computador da Enterprise alertando:
“Capitão, a trajetória calculada colide com um asteroide.”
10. Automação: o motor de dobra do DevOps
A automação permite executar tarefas repetitivas com consistência.
No mainframe, muitas rotinas sempre foram automatizadas por:
JCL;
PROCs;
schedulers;
REXX;
CLIST;
utilities;
ferramentas de gerenciamento de mudanças.
Por isso, é incorreto afirmar que o mainframe nunca teve automação.
Na verdade, o ambiente IBM Z automatiza processamento há décadas.
O que mudou foi a integração entre automações.
No passado, poderíamos ter:
um JCL para compilar;
outro para linkar;
um operador executando;
um analista conferindo o spool;
um e-mail pedindo aprovação;
uma planilha registrando a versão;
um segundo JCL promovendo o módulo.
No modelo moderno, essas etapas podem fazer parte de um fluxo integrado.
A automação reduz:
digitação repetitiva;
erros humanos;
variações entre execuções;
dependência de conhecimento informal;
tempo de espera;
risco operacional.
Mas existe uma regra importante:
Não automatize o caos.
Antes de automatizar, compreenda o processo.
Se o processo possui dez aprovações inúteis, automatizá-las não resolve o problema.
Você terá apenas um desperdício mais rápido.
11. O poder das alterações pequenas
Uma das práticas mais importantes do DevOps é reduzir o tamanho das mudanças.
Suponha que um release contenha 100 alterações.
Se ocorrer uma falha, qual delas causou o problema?
Agora imagine um release com apenas duas mudanças pequenas.
A investigação se torna muito mais simples.
Alterações menores favorecem:
revisão;
teste;
diagnóstico;
rollback;
compreensão;
comunicação.
Isso combina perfeitamente com a lógica vulcana.
Uma mudança pequena possui menos variáveis desconhecidas.
Logo, a probabilidade de localizar uma falha aumenta.
12. Observabilidade: os sensores de longo alcance
Depois que o software entra em produção, a missão não termina.
É preciso observar seu comportamento.
Monitoramento informa que algo está errado.
Observabilidade ajuda a explicar por que está errado.
Os principais sinais de observabilidade são:
métricas;
logs;
traces;
eventos.
No mainframe, já convivemos com uma enorme riqueza de dados operacionais.
Podemos utilizar:
SMF;
RMF;
SDSF;
SYSLOG;
CICS statistics;
CICS monitoring;
Db2 accounting;
Db2 statistics;
IMS logs;
OMEGAMON;
mensagens JES;
dumps;
registros de segurança.
Um programador COBOL iniciante pode pensar que SMF e RMF são assuntos exclusivos de sysprogs.
Entretanto, esses dados podem explicar diretamente o comportamento de uma aplicação.
Por exemplo:
aumento do tempo de CPU;
crescimento de I/O;
excesso de chamadas Db2;
espera por lock;
contenção em arquivo;
aumento de abends;
tempo de resposta CICS;
crescimento de filas.
Se uma nova versão do programa consome o dobro de CPU, a observabilidade deve revelar isso.
Os sensores da nave precisam estar ligados.
13. DevOps orientado por dados
Decisões DevOps não devem depender apenas de opiniões.
A equipe pode medir:
frequência de implantação;
tempo entre alteração e produção;
percentual de mudanças com falha;
tempo de recuperação;
quantidade de incidentes;
defeitos por release;
duração dos testes;
tempo de aprovação;
retrabalho.
Quatro indicadores são frequentemente utilizados para avaliar o desempenho de entrega:
Frequência de implantação
Com que frequência a organização consegue colocar mudanças em produção?
Lead time for changes
Quanto tempo passa entre a criação de uma mudança e sua disponibilidade?
Change failure rate
Quantas mudanças provocam falhas, incidentes ou rollback?
Mean time to restore
Quanto tempo é necessário para restaurar o serviço depois de um problema?
Observe que DevOps não mede apenas velocidade.
Também mede estabilidade.
Uma equipe que implanta 50 vezes por dia, mas provoca 20 incidentes, não é necessariamente madura.
14. Por que o Project Manager deve se importar?
Em um projeto tradicional, o gerente pode acompanhar:
prazo;
orçamento;
escopo;
pessoas;
tarefas.
No contexto DevOps, ele também precisa compreender o fluxo real de entrega.
Não basta dizer:
“A programação está 90% concluída.”
Essa frase pode esconder muitos problemas.
O código pode estar pronto, mas:
os testes não foram automatizados;
o ambiente não está configurado;
o package Db2 não foi validado;
a segurança não aprovou;
o rollback não existe;
o monitoramento não foi preparado;
a operação não foi treinada.
O PM moderno precisa perguntar:
Onde está o gargalo?
Quanto tempo uma mudança espera por aprovação?
Qual etapa possui mais retrabalho?
Quantos defeitos escapam para produção?
O deploy é reproduzível?
O rollback foi testado?
As métricas estão disponíveis?
O usuário está recebendo valor?
O gerente deixa de administrar apenas cronogramas e passa a administrar fluxo, risco e valor.
15. Customer-centric delivery
DevOps também aproxima a tecnologia do cliente.
O objetivo não é apenas entregar funcionalidades.
É entregar valor.
Imagine que o negócio pede um novo relatório com 40 campos.
A equipe desenvolve durante três meses.
Após a entrega, descobre-se que os usuários consultam apenas cinco campos.
Uma abordagem orientada por feedback poderia entregar uma versão menor em duas semanas, observar o uso e evoluir com base em dados reais.
Esse processo reduz desperdício.
Em Star Trek, uma missão não é considerada bem-sucedida apenas porque a nave chegou ao destino.
Ela precisa cumprir seu objetivo.
Da mesma forma, um projeto não é sucesso apenas porque o código entrou em produção.
Ele precisa resolver um problema real.
16. DevSecOps: segurança dentro da missão
Segurança não pode ser uma inspeção realizada apenas no final.
DevSecOps integra segurança ao ciclo de desenvolvimento.
O pipeline pode verificar:
senhas expostas;
credenciais em fontes;
bibliotecas vulneráveis;
permissões excessivas;
falhas de configuração;
código inseguro;
violações de políticas.
No mainframe, isso envolve temas como:
RACF;
SAF;
ACEE;
perfis de datasets;
permissões em USS;
acesso a transações CICS;
privilégios Db2;
APF;
auditoria SMF;
segregação de funções.
Um programa pode funcionar corretamente e ainda ser inseguro.
Por exemplo, um job com acesso desnecessário a uma base sensível representa um risco, mesmo que nunca tenha falhado.
Segurança é parte da qualidade.
17. DevOps no mundo IBM Z
O mainframe não é inimigo do DevOps.
Na verdade, muitos de seus princípios já existiam no ambiente há décadas.
O IBM Z sempre valorizou:
controle de mudanças;
versionamento;
rastreabilidade;
automação;
disponibilidade;
processamento previsível;
auditoria;
separação de ambientes;
recuperação.
Ferramentas tradicionais como Endevor, ChangeMan e ISPW organizaram durante anos a promoção de componentes entre ambientes.
O que o DevOps moderno acrescenta é uma integração maior com:
Git;
APIs;
pipelines;
testes automatizados;
infraestrutura como código;
observabilidade integrada;
ferramentas de colaboração.
Hoje podemos encontrar tecnologias como:
IBM Dependency Based Build;
IBM z/OS Connect;
Zowe CLI;
Ansible;
Jenkins;
GitHub Actions;
UrbanCode Deploy;
IBM Developer for z/OS;
IBM Z Open Editor;
Galasa;
ZUnit;
watsonx Code Assistant for Z.
O objetivo não é apagar a experiência acumulada do mainframe.
É conectá-la ao fluxo moderno de engenharia.
18. Exemplo completo: uma mudança COBOL em ambiente DevOps
Vamos acompanhar uma missão.
Etapa 1 — Planejamento
O usuário solicita um novo indicador no extrato.
A equipe define:
requisito;
critério de aceite;
impacto;
risco;
componentes envolvidos.
Etapa 2 — Desenvolvimento
O programador cria uma branch no Git.
Ele altera:
programa COBOL;
copybook;
teste unitário;
documentação.
Etapa 3 — Commit
Ao enviar a mudança, o pipeline é iniciado.
Etapa 4 — Build
A ferramenta identifica as dependências.
O programa é:
pré-compilado;
compilado;
linkado;
armazenado como artefato versionado.
Etapa 5 — Testes
São executados:
testes unitários;
testes de regressão;
testes de SQL;
validação de interface.
Etapa 6 — Análise
A solução verifica:
padrões de código;
vulnerabilidades;
erros;
cobertura de testes;
dependências.
Etapa 7 — Deploy em testes
O módulo é promovido para o ambiente de qualidade.
Etapa 8 — Homologação
O usuário valida o comportamento.
Etapa 9 — Aprovação
O responsável autoriza a implantação.
Etapa 10 — Produção
O artefato já testado é promovido.
Não se recompila um novo módulo na produção.
Implanta-se o mesmo artefato validado.
Etapa 11 — Monitoramento
A equipe observa:
abends;
CPU;
tempo de resposta;
SQL;
volume de transações;
erros funcionais.
Etapa 12 — Feedback
Os resultados alimentam a próxima melhoria.
Esse fluxo é o símbolo do infinito aplicado ao COBOL.
19. Dicas para o programador COBOL Padawan
Aprenda Git sem abandonar o ISPF
Git não substitui seu conhecimento de COBOL.
Ele organiza versões, colaboração e histórico.
Entenda o pipeline
Não trate o pipeline como uma caixa preta.
Saiba:
como o programa é compilado;
quais parâmetros são utilizados;
onde o load module é gerado;
quais testes são executados;
como ocorre a promoção.
Escreva mudanças pequenas
Evite misturar correções, melhorias e refatorações enormes no mesmo pacote.
Crie testes repetíveis
Um teste que depende da memória de uma pessoa não é confiável.
Leia o spool
Mesmo com ferramentas modernas, o spool continua sendo uma fonte preciosa de informação.
Conheça a produção
Você não precisa ser operador, mas precisa entender onde seu programa executa.
Documente dependências
Copybooks, tabelas, arquivos, subprogramas e transações devem ser conhecidos.
Pense em rollback
Antes de implantar, saiba como retornar.
Observe métricas
Um programa funcional pode consumir recursos excessivos.
Converse com outras equipes
DevOps depende mais de comunicação do que de ferramentas.
20. Erros comuns ao adotar DevOps
Comprar ferramentas sem mudar processos
A empresa instala plataformas modernas, mas mantém silos e aprovações burocráticas.
Automatizar processos ruins
Um fluxo desnecessariamente complexo continua ruim, mesmo automatizado.
Ignorar o legado
Tentar impor modelos de nuvem ao mainframe sem entender suas características gera resistência e risco.
Eliminar controles importantes
Velocidade não justifica ausência de governança.
Medir produtividade por quantidade de commits
Mais commits não significam mais valor.
Culpar pessoas por falhas sistêmicas
Uma cultura de medo impede aprendizado.
Não investir em testes
Pipeline sem testes é apenas transporte automatizado de problemas.
Não preparar rollback
Toda mudança pode falhar.
A engenharia madura reconhece essa possibilidade.
21. Curiosidades e easter eggs da Federação DevOps
🥚 O termo DevOps ganhou força por volta de 2009, associado ao movimento que buscava aproximar desenvolvimento e operações.
🥚 O lema “You build it, you run it” defende que a equipe que constrói um serviço também deve acompanhar sua operação.
🥚 O símbolo infinito de DevOps representa um ciclo contínuo, não uma sequência com começo e fim rígidos.
🥚 O mainframe já utilizava automação, controle de versão, promoção e auditoria muito antes de a palavra DevOps se tornar popular.
🥚 Um JCL bem escrito é uma forma histórica de automação operacional.
🥚 Um PROC reutilizável possui o mesmo espírito de padronização encontrado em pipelines modernos.
🥚 SMF pode ser visto como uma espécie de diário de bordo da nave IBM Z.
🥚 O SDSF é praticamente a sala de controle onde podemos acompanhar as missões batch em andamento.
🥚 Um abend sem logs é como uma anomalia espacial sem leitura dos sensores.
🥚 Um deploy realizado sem rollback é semelhante a entrar em velocidade de dobra sem calcular uma rota de retorno.
22. O que DevOps não é
DevOps não é:
apenas Jenkins;
apenas Git;
apenas nuvem;
apenas containers;
apenas automação;
ausência de documentação;
fim da governança;
desculpa para implantar sem testes;
obrigação de colocar tudo em produção automaticamente;
guerra contra o mainframe.
DevOps é a combinação equilibrada entre pessoas, processos e tecnologia.
23. A grande lição do Sr. Spock
Spock provavelmente enxergaria DevOps como uma consequência lógica da engenharia.
Separar completamente quem constrói de quem opera cria perda de informação.
Acumular grandes alterações aumenta risco.
Depender de processos manuais aumenta variação.
Ignorar dados reduz a qualidade da decisão.
Logo, a solução racional é:
colaborar;
automatizar;
medir;
testar;
observar;
aprender;
melhorar.
Mas Spock também lembraria que lógica não significa ausência de humanidade.
DevOps depende de confiança.
As pessoas precisam poder relatar erros sem medo.
Precisam compartilhar conhecimento.
Precisam pedir ajuda.
Precisam reconhecer que sistemas complexos falham de maneiras inesperadas.
O ambiente mais automatizado do universo ainda depende de equipes capazes de conversar.
Conclusão: da tela verde à entrega contínua
DevOps não nasceu para transformar programadores em operadores nem para obrigar todas as empresas a implantar centenas de vezes por dia.
Ele nasceu para resolver um problema antigo: a fragmentação da engenharia de software.
Para o programador COBOL iniciante, compreender DevOps significa enxergar além do fonte.
Seu programa faz parte de um ecossistema.
Ele depende de:
compiladores;
bibliotecas;
JCLs;
bancos de dados;
filas;
arquivos;
transações;
permissões;
operações;
métricas;
pessoas.
Uma alteração só está realmente concluída quando chega ao usuário com segurança, produz o resultado esperado e pode ser operada de maneira confiável.
No IBM Z, DevOps não representa a destruição do passado.
Representa a evolução de práticas que o mainframe já conhece muito bem.
A disciplina dos processos tradicionais pode se unir à velocidade dos pipelines modernos.
O conhecimento do programador COBOL pode se integrar ao Git, ao Jenkins, ao Ansible, ao Zowe e à observabilidade.
A tela verde pode conversar com a nuvem.
O batch pode participar de uma esteira automatizada.
O programa de 30 anos pode receber testes modernos.
A tradição e a inovação não precisam ser inimigas.
Como diria o Capitão Kirk antes de ordenar uma nova missão:
“O risco faz parte do jogo quando queremos avançar.”
E como Spock provavelmente acrescentaria:
“Contudo, capitão, riscos calculados, monitorados e automatizados apresentam uma probabilidade consideravelmente maior de sucesso.”
Essa é a essência do DevOps.
Não correr de maneira irresponsável.
Mas construir uma nave melhor, integrar a tripulação, automatizar os procedimentos, observar os sensores e avançar com confiança.
Vida longa e próspera aos seus pipelines. 🖖
Sem comentários:
Enviar um comentário