 |
| Bellacosa Mainframe e o teste de api |
☕ Um Café no Bellacosa Mainframe
🤖 NATHAN BATEMAN E A API QUE ACHAVA QUE ERA HUMANA
HTTP, REST, JSON, Postman, OpenAPI, testes positivos e negativos, OAuth, RACF, Db2, CICS, COBOL, contratos, performance, segurança, CI/CD, observabilidade — e o dia em que um programador COBOL descobriu que receber 200 OK não provava absolutamente nada.
Sob a tutela de Nathan Bateman, de Ex Machina — porque, se existe alguém capaz de olhar para uma interface aparentemente perfeita e perguntar “mas o que realmente está acontecendo atrás dela?”, é Nathan.
🎬 PRÓLOGO — BEM-VINDO À CASA, PROGRAMADOR
A porta se fecha atrás de você.
Não existe maçaneta.
À sua frente há vidro, concreto, câmeras, servidores e uma quantidade desconfortável de tecnologia escondida nas paredes.
Nathan coloca uma cerveja sobre a mesa.
— Você programa COBOL?
— Sim.
— CICS?
— Sim.
— Db2?
— Também.
Ele sorri.
— Excelente. Então hoje você vai testar uma API.
Você olha para ele como se tivesse acabado de pedir para compilar Java usando um IBM 029.
API?
REST?
JSON?
Bearer Token?
OpenAPI?
Postman?
Você passou anos pensando em:
COBOL
JCL
CICS
Db2
VSAM
RACF
MQE agora aparece uma tela mostrando:
POST /api/v1/paymentsNathan aponta para o monitor.
{
"account": "123456",
"amount": 500.00
}Depois surge:
HTTP/1.1 200 OKNathan pergunta:
— Funcionou?
Você responde imediatamente:
— Sim.
Ele sorri novamente.
Era uma armadilha.
Porque acabamos de cometer um dos erros mais perigosos em testes de APIs:
confundir uma resposta tecnicamente bem-sucedida com uma transação de negócio corretamente executada.
Bem-vindo ao laboratório.
Hoje não vamos apenas aprender API Testing.
Vamos descobrir o que existe atrás do vidro.
🧠 CAPÍTULO 1 — A API É AVA?
Em Ex Machina, Caleb inicialmente vê Ava através de uma interface.
Existe uma parede entre eles.
Ele conversa com ela.
Ela responde.
Pergunta:
Caleb
↓
interface
↓
AvaPara Caleb, aquilo parece simples.
Mas por trás da interface existe uma quantidade enorme de tecnologia que ele não vê.
Uma API funciona de maneira parecida.
Imagine um aplicativo bancário.
O usuário toca:
CONSULTAR SALDO
O aplicativo envia:
GET /accounts/12345/balanceRecebe:
{
"account": "12345",
"balance": 7342.91
}Para o celular, acabou.
Mas nós somos profissionais de mainframe.
Queremos abrir a parede.
Talvez exista:
APP MOBILE
↓
INTERNET
↓
API GATEWAY
↓
z/OS CONNECT
↓
CICS
↓
COBOL
↓
DB2Ou:
API
↓
IMS
↓
COBOL
↓
IMS DBOu ainda:
API
↓
CICS
↓
COBOL
↓
MQ
↓
OUTRO SISTEMAEssa é a primeira lição.
API não substitui necessariamente o mainframe. API pode simplesmente fornecer uma nova porta para chegar até ele.
🔌 CAPÍTULO 2 — API NÃO É MÁGICA
API significa Application Programming Interface.
Em termos simples, ela estabelece uma forma definida para dois softwares conversarem.
Temos:
CLIENTE
|
REQUEST
↓
API
|
PROCESSAMENTO
↓
RESPONSE
|
↓
CLIENTEPara quem vem do COBOL, isso não deveria parecer tão alienígena.
Pense numa COMMAREA.
Um programa recebe uma estrutura:
01 WS-REQUEST.
05 WS-CUSTOMER-ID PIC 9(10).
05 WS-OPERATION PIC X(01).Processa e devolve:
01 WS-RESPONSE.
05 WS-RETURN-CODE PIC 9(04).
05 WS-NAME PIC X(40).
05 WS-BALANCE PIC S9(9)V99 COMP-3.Uma API também recebe dados e devolve dados.
A representação mudou.
Podemos receber:
{
"customerId": 123456
}e responder:
{
"name": "BELLACOSA",
"balance": 317.00
}O jovem programador olha para JSON e pensa:
— Moderníssimo!
O veterano COBOL olha e pensa:
— É um layout de dados usando chaves, colchetes e bastante marketing.
Nathan provavelmente aprovaria a segunda resposta.
🌐 CAPÍTULO 3 — HTTP: O PROTOCOLO QUE CARREGA A CONVERSA
Muitas APIs REST utilizam HTTP.
Uma requisição pode conter:
URL
METHOD
HEADERS
QUERY PARAMETERS
BODYExemplo:
POST /customers HTTP/1.1
Host: api.banco.com
Content-Type: application/json
Authorization: Bearer eyJ...Body:
{
"name": "Caleb",
"age": 26
}Observe as peças.
Endpoint é o endereço lógico do recurso:
/customersHeaders carregam informações adicionais:
Content-Type
Authorization
Accept
Correlation-IDBody contém os dados enviados.
Isso nos leva aos verbos HTTP.
🛠️ CAPÍTULO 4 — GET, POST, PUT, PATCH E DELETE
Os cinco verbos mais importantes para nosso iniciante são:
GET consultar
POST criar/processar
PUT substituir
PATCH alterar parcialmente
DELETE removerPodemos construir uma analogia COBOL/Db2 apenas para aprendizado:
GET ≈ SELECT
POST ≈ INSERT/operação
PUT ≈ UPDATE completo
PATCH ≈ UPDATE parcial
DELETE ≈ DELETEMas escreva em letras enormes no caderno:
ANALOGIA NÃO É EQUIVALÊNCIA.
Considere:
POST /paymentsEle talvez execute:
POST
↓
z/OS Connect
↓
CICS
↓
COBOL
├── SELECT DB2
├── UPDATE DB2
├── INSERT DB2
├── MQ PUT
└── COMMITPortanto POST não significa necessariamente INSERT.
Ele significa que estamos solicitando determinada operação segundo o contrato daquela API.
🚦 CAPÍTULO 5 — STATUS CODE É O RETURN CODE DA INTERNET?
Mais uma analogia útil, mas imperfeita.
O mainframer conhece:
RC=0000
RC=0004
RC=0008
RC=0012
S0C7
S0C4HTTP possui famílias de códigos:
1xx → informação
2xx → sucesso
3xx → redirecionamento
4xx → problema relacionado à requisição
5xx → falha do servidorAlguns essenciais:
200 OK
201 Created
204 No Content
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
429 Too Many Requests
500 Internal Server Error
503 Service UnavailableMas aqui Nathan interrompe a aula.
— Você recebeu 200. Então funcionou?
Não necessariamente.
Veja:
HTTP/1.1 200 OK{
"transaction": "FAILED",
"reason": "INSUFFICIENT_FUNDS"
}HTTP funcionou.
A API respondeu.
Mas a operação de negócio falhou.
Temos, portanto, pelo menos três perguntas diferentes:
TRANSPORTE
HTTP funcionou?
↓
CONTRATO
Resposta possui a estrutura correta?
↓
NEGÓCIO
A operação produziu o resultado correto?Esse pequeno detalhe separa teste superficial de teste sério.
📜 CAPÍTULO 6 — OPENAPI: O COPYBOOK DO MUNDO REST?
Calma.
Não literalmente.
Mas para ensinar COBOL é uma analogia fantástica.
Um copybook pode definir:
01 CUSTOMER.
05 CUSTOMER-ID PIC 9(10).
05 CUSTOMER-NAME PIC X(40).
05 CUSTOMER-STATUS PIC X(01).Uma especificação OpenAPI pode descrever uma representação semelhante:
Customer:
type: object
required:
- customerId
- customerName
properties:
customerId:
type: integer
customerName:
type: string
status:
type: stringAntes de testar uma API, leia sua documentação.
Procure:
endpoints
métodos
parâmetros
headers
schemas
autenticação
exemplos
responses
errosNão comece clicando freneticamente em Send no Postman.
Primeiro descubra qual deveria ser o comportamento.
Teste sem requisito vira adivinhação automatizada.
🧪 CAPÍTULO 7 — POSTMAN: O TERMINAL 3270 DO EXPLORADOR DE APIs
Imagine esta evolução:
3270
↓
CICS
↓
COBOLAgora:
Postman
↓
HTTP
↓
API
↓
z/OS Connect
↓
CICS
↓
COBOLO Postman permite montar requisições, headers, parâmetros, autenticação e body, além de examinar respostas e organizar chamadas em collections.
Comece simples.
Faça:
GET /customers/123Clique em Send.
Não comemore ainda.
Inspecione:
status code
headers
body
schema
response time
business rulesUma resposta não deve ser considerada correta simplesmente porque apareceu alguma coisa na tela.
😊 CAPÍTULO 8 — HAPPY PATH: PRIMEIRO PROVE QUE AVA CONSEGUE CONVERSAR
O teste positivo verifica comportamento esperado com entradas válidas.
Exemplo:
POST /customers{
"name": "Nathan Bateman",
"type": "PREMIUM"
}Esperamos talvez:
201 Createde:
{
"customerId": 12345,
"name": "Nathan Bateman",
"type": "PREMIUM"
}Validamos:
dados válidos
fluxo correto
permissão adequada
resultado esperado
persistência corretaÓtimo.
Mas isso prova apenas que o sistema funciona quando todos se comportam.
Produção não possui essa delicadeza.
😈 CAPÍTULO 9 — O TESTE COMEÇA QUANDO AS COISAS DÃO ERRADO
Agora Nathan fica interessado.
Envie:
{
"amount": -500
}Depois:
{
"amount": "CINCO REAIS"
}Depois:
{}Depois:
{
"amount": null
}Teste:
campos ausentes;
tipos inválidos;
limites;
JSON malformado;
dados duplicados;
métodos não suportados;
valores negativos;
valores enormes;
strings vazias;
recursos inexistentes;
credenciais inválidas.
O sistema bom não é aquele que apenas sabe funcionar.
É aquele que sabe falhar corretamente.
💣 CAPÍTULO 10 — PIC 9(7)V99 ENCONTRA JSON
Aqui aparece um problema particularmente interessante para mainframers.
COBOL:
05 WS-AMOUNT PIC 9(7)V99.API:
{
"amount": 999999999999999999.99
}Quem impede isso?
Gateway?
Schema?
z/OS Connect?
Programa intermediário?
COBOL?
Db2?
E se ninguém impedir?
Esse é um maravilhoso teste de boundary.
Teste:
0
0.01
9999999.99
10000000.00
-0.01
NULL
"ABC"A fronteira é justamente onde muitos defeitos ficam escondidos.
🔐 CAPÍTULO 11 — "QUEM É VOCÊ?" NÃO É "O QUE VOCÊ PODE FAZER?"
Autenticação:
Quem é você?
Autorização:
O que você pode acessar?
Essa distinção é vital.
No IBM Z podemos encontrar uma cadeia como:
OAuth/OIDC
↓
API Gateway
↓
token
↓
z/OS
↓
SAF
↓
RACFMas autenticar alguém não significa permitir qualquer operação.
Teste:
sem token
token inválido
token expirado
token correto
scope incorreto
usuário sem privilégio
usuário privilegiado
recurso de outro usuárioUm 401 e um 403 não significam exatamente a mesma coisa.
E existe uma pergunta ainda mais interessante:
Um usuário autorizado para consultar seus dados consegue trocar
/123por/124e consultar dados de outra pessoa?
Isso testa autorização no nível do objeto, não apenas login.
🧬 CAPÍTULO 12 — TEST DATA: NÃO USE PRODUÇÃO COMO PARQUINHO
Dados de teste precisam ser:
controlados
repetíveis
realistas
seguros
isolados
limpáveisNo mainframe isso pode ser particularmente delicado.
Existem ambientes com dados acumulados durante décadas.
Você encontrará:
EBCDIC
COMP
COMP-3
campos redefinidos
datas históricas
códigos descontinuados
valores especiais
copybooks antigos
registros migradosE existe ainda segurança e privacidade.
Mascarar dados sensíveis é fundamental quando dados semelhantes aos de produção precisam alimentar testes.
E nunca coloque senha, token ou segredo dentro do script:
PASSWORD=SUPERSECRET123Nathan certamente encontraria.
O auditor também.
🗄️ CAPÍTULO 13 — DATABASE VALIDATION: OLHE ATRÁS DO VIDRO
Agora chegamos ao coração do problema.
Você envia:
POST /transfers{
"from": "100001",
"to": "200002",
"amount": 500.00
}Recebe:
200 OKFim?
Não.
Precisamos descobrir o efeito.
Antes:
A = 2000
B = 1000Depois:
A = 1500
B = 1500Precisamos validar:
débito correto
crédito correto
nenhum registro duplicado
histórico criado
mensagem MQ correta
audit trail
commitAgora provoque uma falha depois do débito e antes do crédito.
O resultado correto provavelmente deverá envolver:
ROLLBACKe não:
A = 1500
B = 1000Essa é a diferença entre testar uma tela JSON e testar uma transação.
🔄 CAPÍTULO 14 — COMMIT, ROLLBACK E A UNIT OF WORK
Mainframe conhece esse problema há décadas.
Uma API pode iniciar uma cadeia:
REQUEST
↓
CICS
↓
COBOL
↓
DB2
↓
MQAgora surgem perguntas realmente interessantes:
O que pertence à mesma unidade de trabalho?
Quando ocorre COMMIT?
O que acontece se MQ falhar?
E se Db2 estiver indisponível?
E se a API sofrer timeout?
E se o cliente repetir a chamada?Chegamos à palavra que deveria estar colada no monitor de qualquer desenvolvedor de pagamentos:
IDEMPOTÊNCIA
Imagine:
03:16:55 pagamento enviado
03:17:00 processamento iniciado
03:17:10 timeoutO aplicativo não sabe se funcionou.
Então repete.
Se o backend executar novamente:
R$500
R$500acabamos de cobrar duas vezes.
Uma estratégia pode envolver uma chave de idempotência:
Idempotency-Key: PAY-ABC-123O backend reconhece a repetição.
E sim: 03:17 apareceu por acaso.
Quem acompanha o Bellacosa Mainframe sabe que acidentes temporais desse tipo costumam ser cuidadosamente planejados. ☕
📐 CAPÍTULO 15 — CONTRACT TESTING: AVA MUDOU A LINGUAGEM
Hoje:
{
"customerId": 123,
"status": "ACTIVE"
}Amanhã alguém decide "modernizar":
{
"customerNumber": 123,
"customerStatus": "ACTIVE"
}O serviço continua funcionando.
Mas dez consumidores quebram.
É o equivalente moderno do sujeito que altera um copybook compartilhado sem estudar impacto e depois pergunta por que metade da madrugada está em conference call.
Contract testing procura detectar mudanças incompatíveis antes que cheguem aos consumidores.
Aqui o mainframer possui uma vantagem cultural enorme.
Ele já conhece o medo saudável de:
"Quem mais usa isso?"
🏎️ CAPÍTULO 16 — PERFORMANCE: 120 MILISSEGUNDOS NÃO CONTAM TODA A HISTÓRIA
Uma API responde em:
120 msExcelente.
Com um usuário.
Agora tente 100.
1.000.
10.000.
50.000.
Precisamos observar:
latency — tempo de resposta;
throughput — quantidade processada;
error rate — percentual de falhas;
concurrency — usuários/operações simultâneos.
Existem ainda quatro cenários clássicos:
LOAD
carga normal esperada
SPIKE
explosão repentina
STRESS
além do limite normal
SOAK
carga sustentada durante longo períodoNo IBM Z, não pare no tempo HTTP.
Investigue:
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
↓
CPU / I/O / LOCKSPode ser que HTTP esteja apenas mostrando o sintoma.
🕵️ CAPÍTULO 17 — SEGURANÇA: NATHAN NÃO CONFIA NA INTERFACE
API Security Testing precisa procurar problemas como:
autenticação
autorização
input validation
rate limiting
exposição de dados
configurações insegurasNo mainframe adicionamos outra camada:
SAF
RACF
TLS
AT-TLS
certificados
SMF
proteção CICS
privilégios Db2
permissões USS
segregação de funções
auditoriaUm erro particularmente perigoso é retornar informação demais.
Exemplo:
{
"name": "USER",
"balance": 500,
"internalRacfUser": "ABC123",
"databaseHost": "PRODDB2",
"debugMessage": "SQLCODE -..."
}Talvez três desses campos jamais devessem sair dali.
Erro também é dado.
Log também é dado.
Stack trace também é dado.
Portanto teste o que o sistema revela quando falha.
🤖 CAPÍTULO 18 — AUTOMATIZE, MAS NÃO AUTOMATIZE BURRICE
Depois dos testes manuais estáveis, automatizamos.
Ferramentas possíveis incluem:
Postman/Newman
REST Assured
Playwright API
SuperTestUm framework saudável separa:
config/
api-clients/
test-data/
tests/
reports/Isso evita aquele script de 4.000 linhas onde URL, senha, payload, teste, relatório e provavelmente o CPF do desenvolvedor estão todos misturados.
Automação boa precisa ser:
repetível
independente
legível
determinística
diagnosticável
manutenívelAutomatizar um teste ruim produz um teste ruim que roda mais rápido.
🏭 CAPÍTULO 19 — CI/CD: O COBOL ENTRA NA ESTEIRA
Agora o teste deixa de depender de alguém clicar em Send.
Podemos ter:
COMMIT
↓
BUILD
↓
UNIT TEST
↓
API TEST
↓
CONTRACT TEST
↓
SECURITY CHECK
↓
DEPLOY DEV
↓
INTEGRATION TEST
↓
QUALITY GATE
↓
PROMOTIONIsso também é DevOps no mainframe.
COBOL não precisa deixar de ser COBOL.
CICS não precisa fingir que é Kubernetes.
Db2 não precisa colocar boné para trás.
O objetivo é introduzir práticas modernas de engenharia em torno das plataformas adequadas.
🔭 CAPÍTULO 20 — OBSERVABILIDADE: AVA RESPONDEU, MAS O QUE ELA ESTAVA FAZENDO?
Chegamos ao estágio mais interessante.
Testes dizem:
"Sob estas condições, obtive este resultado."
Observabilidade pergunta:
"O que o sistema está realmente fazendo?"
Precisamos de evidências.
logs
metrics
traces
request IDs
test reports
artifactsNo IBM Z temos uma riqueza enorme de telemetria:
SMF
RMF
CICS statistics
Db2 accounting
Db2 statistics
MQ statistics
WLM
logs
network telemetryImagine colocar:
X-Request-ID: CALEB-0317e acompanhar:
CALEB-0317
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2De repente não temos apenas:
"A API demorou 4 segundos."
Temos:
"A requisição chegou ao z/OS, entrou na transação CICS, esperou determinado recurso e a maior parte do tempo foi consumida naquela etapa."
Isso muda completamente a investigação.
🧪 CAPÍTULO 21 — O LABORATÓRIO FINAL DE NATHAN
Sua missão é testar:
POST /accounts/transferPayload:
{
"from": "100001",
"to": "200002",
"amount": 500.00
}Arquitetura:
CLIENT
↓
HTTPS
↓
API GATEWAY
↓
z/OS CONNECT
↓
CICS
↓
COBOL
↓
DB2
↓
MQComece pelo happy path.
Depois execute:
conta origem inexistente
conta destino inexistente
saldo insuficiente
amount = 0
amount negativo
amount máximo
amount acima do máximo
amount como texto
campo ausente
JSON quebrado
token ausente
token expirado
scope incorreto
usuário sem autorização
requisição duplicada
timeout
Db2 indisponível
MQ indisponível
100 requests simultâneos
1.000 requests
spike
soakDepois de cada cenário, pergunte:
HTTP correto?
JSON correto?
Schema correto?
Regra de negócio correta?
Db2 correto?
MQ correto?
Commit correto?
Rollback correto?
RACF correto?
Logs corretos?
SMF mostra o esperado?
Performance aceitável?
Dados sensíveis protegidos?Agora você não está mais testando simplesmente uma API.
Está testando um serviço de negócio distribuído de ponta a ponta.
🧠 CAPÍTULO 22 — O TESTE DE TURING DO MAINFRAME
Nathan volta à sala.
Na tela aparecem duas respostas:
{
"status": "SUCCESS"
}e:
{
"status": "SUCCESS"
}São idênticas.
Nathan pergunta:
— Qual delas está correta?
Você não responde.
Abre o Db2.
Verifica a transação CICS.
Consulta evidências.
Confere MQ.
Verifica autorização.
Procura duplicidades.
Analisa logs.
Correlaciona Request ID.
Observa métricas.
Confere o contrato.
Finalmente responde:
— A primeira.
Nathan pergunta:
— Como sabe?
E aí está toda a diferença:
— Porque eu não confiei na interface. Eu validei o sistema.
☕ EPÍLOGO — A API NÃO PRECISAVA SER HUMANA
Existe uma deliciosa ironia nessa história.
Muitos conceitos vendidos como absolutamente modernos são problemas que o mundo mainframe enfrenta há décadas.
Hoje dizemos:
schemaO mainframer lembra de layouts e copybooks.
Hoje:
transaction consistencyEle pensa em unit of work, commit e rollback.
Hoje:
authorizationEle pensa em SAF/RACF e também nas regras de autorização da aplicação.
Hoje:
observabilityEle pergunta:
— Quais registros SMF temos?
Hoje:
high availabilityEle sorri.
Hoje:
backward compatibilityAgora ele começa a rir.
Isso não significa que REST, OpenAPI, OAuth, CI/CD ou observabilidade moderna sejam apenas nomes novos para tecnologias antigas. Não são.
Significa algo mais interessante.
Os problemas fundamentais da computação permanecem surpreendentemente constantes:
Quem pediu?
Pode pedir?
Os dados são válidos?
O processamento aconteceu?
A informação foi persistida?
A transação terminou inteira?
Se falhou, voltou ao estado consistente?
Se repetiu, duplicou?
Quanto demorou?
Quantas conseguimos processar?
Quem consegue observar isso?
Quem consegue alterar isso?
Conseguimos provar depois o que aconteceu?
E aqui está talvez a maior lição para o programador COBOL iniciante.
Não tenha medo quando alguém colocar na sua frente:
REST
JSON
OAuth
OpenAPI
Postman
CI/CD
ObservabilityVocê não está abandonando tudo o que aprendeu.
Está aumentando seu campo de visão.
Ontem você enxergava:
3270
↓
CICS
↓
COBOL
↓
DB2Hoje precisa enxergar:
INTERNET
│
▼
API GATEWAY
│
▼
z/OS CONNECT
│
┌────────┴────────┐
▼ ▼
CICS IMS
│ │
└───────┬─────────┘
▼
COBOL
│
┌───────────┼───────────┐
▼ ▼ ▼
DB2 VSAM MQ
│ │ │
└───────────┼───────────┘
▼
COMMIT/ROLLBACK
│
▼
RESPONSE JSONE ao redor de tudo isso:
SECURITY
│
▼
┌───────────────────┐
│ │
RACF/SAF OAuth
│ │
└─────────┬─────────┘
│
▼
AUDIT
│
▼
OBSERVABILITY
│
┌───────┼────────┐
▼ ▼ ▼
SMF LOGS METRICSEssa é a arquitetura que o teste precisa enxergar.
A API é apenas o vidro.
Atrás dela existe uma máquina inteira.
🥚 EASTER EGG — 03:17
Às 03:17, todas as luzes do laboratório apagam.
O programador COBOL continua sentado.
Nathan pergunta:
— Você não está preocupado?
— Não.
— Por quê?
Ele aponta para o monitor.
HTTP 200Nathan sorri.
O programador responde:
— Também não confio nisso.
Abre outra janela.
CICS: OK
DB2 : COMMIT
MQ : MESSAGE PUT
RACF: AUTHORIZED
SMF : RECORDEDEntão pega o café.
— Agora sim.
Porque no Bellacosa Mainframe existe uma regra que Nathan Bateman aprenderia rapidamente:
Não importa o quão bonita seja a interface, o quão perfeito seja o JSON ou quantos
200 OKapareçam na tela. Em sistemas de missão crítica, confiança não vem da aparência da resposta. Vem da evidência de que toda a cadeia fez exatamente aquilo que deveria fazer.
E talvez esse seja o verdadeiro Teste de Turing de uma API mainframe:
não descobrir se ela consegue parecer inteligente,
mas provar que, quando ninguém está olhando, ela continua sendo correta, segura, consistente, observável e confiável.
☕ Um Café no Bellacosa Mainframe
Onde até Ava teria que apresentar evidência de COMMIT antes de receber acesso à produção.
