 |
| Bellacosa Mainframe e o capacity planning aplicado a pensão alimenticia |
☕ Um Café no Bellacosa Mainframe
O Homem que Resolveu a Pensão com Capacity Planning
Ou: quando o Red Team encontrou uma vulnerabilidade no ambiente familiar, o Blue Team chamou o advogado, o WLM redistribuiu os recursos — e o CAB aprovou uma mudança que exigia urologista
Existem histórias que começam num tribunal.
Outras começam num casamento.
Algumas começam com uma decisão ruim tomada às três da manhã.
Esta começa como quase todas as grandes histórias da civilização ocidental deveriam começar:
num boteco, em Itatiba, com uma Original sobre a mesa.
Não vou dar nomes porque nomes estragam excelentes histórias e enriquecem advogados.
Diremos apenas que nosso protagonista era um sujeito normal.
Trabalhava.
Tinha esposa.
Tinha filhos.
Pagava contas.
Provavelmente reclamava do preço da gasolina.
Talvez discutisse futebol.
Nada que justificasse abertura de incidente no ServiceNow.
Até que um dia o ambiente de produção recebeu uma atualização não prevista no roadmap.
Havia um filho fora do casamento.
E, com ele, chegou uma palavra capaz de transformar qualquer mesa de bar brasileira numa banca examinadora da Faculdade de Direito:
pensão.
Imediatamente aparece o especialista.
Ele sempre aparece.
Pode ser o dono do bar.
Pode ser o sujeito da mesa ao lado.
Pode ser o cunhado do primo do padeiro.
Mas aparecerá.
— Pensão é trinta por cento.
Não.
Respire.
Pegue sua cerveja.
Não existe uma lei brasileira dizendo que pensão alimentícia é obrigatoriamente 30% ou 1/3 da renda.
O Código Civil determina que os alimentos sejam fixados considerando as necessidades de quem os recebe e os recursos de quem deve prestá-los. O valor pode ser percentual, quantia fixa ou adotar outros critérios conforme o caso.
O próprio STJ tem inúmeros casos com percentuais diferentes, e recentemente reiterou que alterações familiares, inclusive nascimento de outros filhos, não provocam automaticamente redução: é necessário demonstrar concretamente mudança na capacidade financeira.
Portanto:
não existe SYS1.PARMLIB(PENSAO30).
Mas experimente explicar isso depois da segunda Original.
Boa sorte.
🍺 1. O workload que ninguém colocou no capacity planning
Nosso protagonista já tinha filhos dentro do casamento.
Essas crianças obviamente consumiam recursos.
Comida.
Escola.
Roupa.
Médico.
Transporte.
Casa.
Conta de luz.
Tênis que inexplicavelmente deixa de servir três semanas depois de comprado.
Material escolar cujo preço sugere que o caderno foi produzido artesanalmente por monges suíços.
Era um workload perfeitamente real.
Só havia uma diferença.
Esses custos estavam dentro da vida doméstica.
Não chegavam todo mês acompanhados de uma ordem judicial dizendo:
EXEC PGM=PENSAO
Então aparece outro filho, de outro relacionamento, e aquela obrigação passa a ter representação jurídica explícita.
Percentual.
Data.
Processo.
Valor.
Prazo.
Comprovante.
Subitamente nosso amigo descobriu uma das grandes verdades dos sistemas complexos:
Aquilo que existe e aquilo que o sistema consegue enxergar não são necessariamente a mesma coisa.
Os filhos do casamento já consumiam CPU.
Mas boa parte dessa CPU estava escondida dentro do enorme address space chamado:
FAMÍLIA.
O novo workload chegou etiquetado.
Mensurado.
Monitorado.
Com SLA.
E execução judicial disponível caso o SLA não fosse cumprido.
O WLM doméstico começou a chiar.
🔴 2. Entra o Red Team
É aqui que nossos chimpanzés sóbrios entram na sala.
🐒 O chimpanzé jurídico abre o Código Civil.
🐒 O chimpanzé financeiro abre uma planilha.
🐒 O chimpanzé COBOL pergunta por que ninguém documentou aquilo antes.
🐒 O chimpanzé do bar tenta abrir outra Original e é imediatamente removido do War Room.
O Red Team recebe uma única missão:
encontre todas as maneiras pelas quais esse ambiente pode cair.
Primeira pergunta:
— O novo pagamento cabe no orçamento?
Talvez.
Segunda:
— E os filhos que já existiam?
Continuam existindo.
Terceira:
— O sistema está enxergando corretamente todas as obrigações?
Aí começa a ficar interessante.
A Constituição brasileira não admite filhos de primeira e segunda classe. Filhos havidos ou não dentro do casamento possuem os mesmos direitos e qualificações.
Portanto, juridicamente, não existe:
FILHO_PROD
e
FILHO_DEV
Todos entraram em produção.
Todos têm SLA.
E ninguém pode simplesmente executar:
CANCEL CHILD
porque a conta ficou inconveniente.
O problema então não era eliminar uma obrigação.
Era fazer o sistema enxergar todas as obrigações adequadamente.
🔵 3. Blue Team chamado às pressas
O Blue Team entrou.
E, como frequentemente ocorre quando o Red Team encontra algo realmente sério, ninguém estava sorrindo.
A solução não seria:
— Não pago.
Isso é equivalente a resolver falta de espaço em DASD desligando o catálogo.
Funciona maravilhosamente até o telefone tocar.
Também não seria:
— Tenho outros filhos, então automaticamente pago menos.
Não funciona assim.
O STJ já deixou claro que constituir outra família ou ter outros filhos não basta, sozinho, para reduzir alimentos anteriormente fixados. É necessária demonstração concreta de alteração financeira.
Além disso, valores diferentes para filhos de relacionamentos diferentes podem existir quando as circunstâncias forem diferentes — por exemplo, necessidades distintas ou capacidades econômicas diferentes dos responsáveis. Igualdade entre filhos não significa obrigatoriamente copiar o mesmo número em todas as linhas da planilha.
Portanto o Blue Team precisava fazer aquilo que todo bom Blue Team faz:
telemetria.
Quanto entra?
Quanto sai?
Quantos dependentes existem?
Quanto custa cada núcleo?
Quais obrigações já estão formalizadas?
Quais despesas estão escondidas dentro da operação cotidiana?
Não era glamour.
Era SMF familiar.
⚖️ 4. Quando o divórcio virou observabilidade
E então chegamos à parte que, contada rapidamente num boteco, parece uma piada jurídica.
Nosso protagonista se divorciou.
Calma.
Não estamos dizendo:
“Divórcio reduz pensão.”
Não reduz automaticamente.
Também não estamos oferecendo:
“Faça um divórcio fictício e economize.”
Isso seria outro tipo de história, provavelmente terminando numa sala com iluminação fluorescente ruim.
O que aconteceu naquele caso concreto, segundo a história que chegou à nossa mesa, foi mais interessante.
Com o divórcio, obrigações que anteriormente estavam diluídas dentro da vida matrimonial passaram a ficar muito mais formalmente identificadas.
Os demais filhos continuavam sendo filhos.
Continuavam precisando de recursos.
Mas agora a arquitetura financeira familiar aparecia de maneira diferente perante o sistema.
Aquilo que antes era:
DESPESAS_GERAIS_DA_CASA
passou a poder ser apresentado de maneira muito mais explícita como:
OBRIGAÇÕES_COM_FILHO_A
OBRIGAÇÕES_COM_FILHO_B
OBRIGAÇÕES_COM_FILHO_C
Eis o momento em que nosso programador imaginário bate na mesa:
— AHÁ!
Não foi criado dinheiro novo.
Não desapareceram necessidades.
Mudou a observabilidade.
A capacidade do alimentante passou a ser analisada diante de um conjunto mais claramente demonstrável de obrigações.
O Código Civil inclusive permite revisão de alimentos quando muda a situação financeira de quem paga ou de quem recebe.
Era quase um caso de performance.
Você olha para o sistema e acredita que determinado address space está consumindo 30%.
Depois ativa a instrumentação correta.
Descobre que existem vários workloads concorrendo pelos mesmos recursos.
O problema não era necessariamente excesso de CPU.
Era capacity planning ruim.
🧮 5. WLM Family Edition
Imagine agora o WLM olhando para aquilo.
Temos recursos finitos.
Temos workloads legítimos.
Temos diferentes necessidades.
Temos prioridades constitucionais.
E temos alguém na mesa gritando:
— MAS É 30%!
O WLM responde:
“Cidadão, saia da sala.”
Não existe matemática mágica capaz de transformar Direito de Família numa divisão de pizza.
Se alguém ganha R$ 10.000, não significa automaticamente:
R$ 3.000 para criança A.
Depois outra aparece:
mais R$ 3.000.
Depois outra:
mais R$ 3.000.
Depois:
— O senhor ainda precisa comer?
Porque necessidades e possibilidades precisam ser examinadas concretamente.
Da mesma maneira, ninguém pode simplesmente dizer:
— Tenho quatro filhos, então cada um recebe exatamente 25% do orçamento infantil.
Um deles pode ter tratamento médico.
Outro pode estudar em circunstâncias diferentes.
Outro pode morar em cidade mais cara.
As condições econômicas dos respectivos pais e mães também importam.
O STJ já aceitou expressamente valores diferentes para filhos de relacionamentos distintos justamente quando as condições concretas justificavam.
O WLM não distribui tudo com ROUND ROBIN.
Ainda bem.
🔴 6. O Red Team não estava satisfeito
Depois de muito trabalho, a arquitetura aparentemente estabilizou.
Orçamento reorganizado.
Obrigações visíveis.
Advogados fazendo aquilo que advogados fazem.
Documentos.
Peticionamentos.
Planilhas.
Audiências.
Prazos.
Nosso protagonista respirou.
Blue Team abriu o dashboard.
Tudo verde.
CPU normal.
Paging controlado.
Sem ABENDs.
O gerente declarou:
INCIDENT RESOLVED.
O Red Team levantou a mão.
Silêncio.
Sempre desconfie quando o Red Team levanta a mão depois de todo mundo dizer que acabou.
— Temos uma vulnerabilidade residual.
Blue Team:
— Qual?
Red Team:
— O sistema ainda aceita novos workloads.
Ninguém disse nada.
O arquiteto conferiu o diagrama.
Era verdade.
Todo aquele esforço havia resolvido o incidente atual.
Mas a classe de incidente permanecia tecnicamente possível.
Novo relacionamento.
Nova gravidez.
Novo filho.
Nova obrigação.
Novo capacity planning.
Novo advogado.
Nova Original.
O Red Team escreveu no quadro:
ROOT CAUSE NOT ELIMINATED
Agora nosso amigo precisava tomar uma decisão.
Plano B?
Plano C?
Plano D?
Até Z?
Ou eliminar a superfície de ataque?
🏥 7. O Blue Team chamou o urologista
É aqui que a história deixa de ser Direito de Família e entra definitivamente para a história da engenharia.
Nosso protagonista analisou o post-mortem.
Leu o RCA.
Verificou o impacto.
Avaliou recorrência.
E decidiu:
vasectomia.
Pausa dramática.
Essa palavra precisa ficar sozinha.
Porque qualquer escritor que enterre uma punchline dessas dentro de um parágrafo merece perder acesso ao editor.
VASECTOMIA.
😂
O homem não aumentou o orçamento jurídico.
Não contratou advogado em regime de plantão.
Não criou um novo fundo de contingência.
Não implementou mais uma camada de observabilidade.
Ele simplesmente decidiu:
“Novos deployments desta categoria não serão mais necessários.”
🛠️ 8. Change Request URO-001
Naturalmente, nenhuma alteração séria entra em produção sem CAB.
Portanto imaginemos a documentação.
CHANGE ID: URO-001
Descrição: alteração da infraestrutura reprodutiva.
Categoria: Preventive Maintenance.
Motivo: redução permanente da superfície de risco.
Impacto esperado: bloqueio de novos provisionamentos biológicos.
Downtime: limitado.
Rollback: não tratar como trivial.
Owner: proprietário da infraestrutura.
Implementador: urologista devidamente habilitado.
Validação: espermograma conforme orientação médica.
Status: CHANGE APPROVED.
Aqui cabe um parêntese sério dentro da palhaçada.
Vasectomia não produz esterilidade imediatamente. Após o procedimento ainda pode haver espermatozoides residuais, razão pela qual deve ser seguido o acompanhamento médico e realizada a confirmação apropriada antes de abandonar outros métodos contraceptivos.
Sim.
Até o nosso CAB de boteco tem ambiente de homologação.
🐒 9. Os chimpanzés fazem o post-mortem
Chimpanzé jurídico:
— Obrigações existentes continuam existindo.
Correto.
Chimpanzé financeiro:
— A mudança não reduz retroativamente nenhuma obrigação.
Correto.
Chimpanzé de segurança:
— Mas reduz determinada classe de risco futuro.
Muito bem.
Chimpanzé COBOL:
— Podemos fechar o ticket?
Ainda não.
Chimpanzé do bar:
— AGORA posso abrir a Original?
Pode.
🍺 PSHHHT.
Começa o post-mortem.
O objetivo do post-mortem não é descobrir culpados.
Essa é uma diferença importante.
Filhos não são incidentes.
Crianças não são despesas indesejadas numa planilha.
E mulheres ou homens não precisam ser transformados em atacantes para que alguém pratique gestão de risco.
O incidente, aqui, é a ausência de planejamento diante das consequências possíveis das próprias decisões.
Essa diferença salva a história de virar chorume de rede social.
Red Team não significa:
“Todas as mulheres tentarão alguma coisa.”
Significa:
“Existe algum cenário possível capaz de causar um impacto que preciso compreender?”
Blue Team não significa:
“Como escapar das responsabilidades?”
Significa:
“Como cumprir responsabilidades sem destruir a estabilidade do restante do ambiente?”
Chaos Engineering não significa desejar o desastre.
Significa perguntar:
“Se acontecer, o sistema continua funcionando?”
🧠 10. O verdadeiro Chaos Engineering
É aqui que nossa história volta àquelas páginas imaginárias guardadas na gaveta.
O sujeito verdadeiramente paranoico pergunta:
— Qual é a probabilidade?
O Chaos Engineer responde:
— Não estou perguntando isso ainda.
Primeiro:
“É possível?”
Depois:
“Qual seria o impacto?”
E então:
“Tenho como absorver?”
Existem acontecimentos raríssimos que não merecem nenhum preparo porque o impacto seria pequeno.
Existem outros raríssimos cujo impacto seria tão gigantesco que algum plano B é absolutamente razoável.
Você não precisa acreditar que o datacenter pegará fogo amanhã para manter extintores.
Você não precisa acreditar que todos os discos falharão para fazer backup.
Você não precisa acreditar que seu relacionamento acabará para manter documentos patrimoniais organizados.
Você não precisa acreditar que terá outro filho para pensar seriamente sobre contracepção.
Planejamento não é previsão.
É humildade diante da possibilidade de que o universo tenha senso de humor.
🔴🔵 11. Red Team versus Blue Team
Vamos colocar os dois lados frente a frente.
RED TEAM: E se surgir uma obrigação financeira inesperada?
BLUE TEAM: Reserva e capacidade financeira.
RED TEAM: E se existirem outras obrigações que o sistema não esteja enxergando adequadamente?
BLUE TEAM: Documentação.
RED TEAM: E se a situação mudar?
BLUE TEAM: Revisão pelos meios legais adequados.
RED TEAM: E se o primeiro advogado estiver errado?
BLUE TEAM: Segunda opinião.
RED TEAM: E se outro filho nascer?
BLUE TEAM: Contracepção.
RED TEAM: E se a contracepção falhar?
Blue Team olha lentamente para o urologista.
Red Team fecha o notebook.
— Sem mais perguntas.
😂
☕ 12. A grande lição que ninguém pediu
Existe uma tendência moderna de chamar qualquer preparação para cenário desagradável de paranoia.
Talvez seja.
Mas existe uma diferença entre paranoia improdutiva e arquitetura resiliente.
A primeira faz você viver esperando o ataque.
A segunda permite viver normalmente porque o ataque não precisa mais ocupar sua cabeça todos os dias.
Esse talvez seja o detalhe mais bonito do bom planejamento.
O plano fica na gaveta.
Você não acorda toda manhã lendo o Disaster Recovery Manual.
Você simplesmente sabe que ele existe.
Relacionamentos continuam sendo relacionamentos.
Filhos continuam sendo filhos.
Amor continua sendo amor.
Mas ninguém precisa entregar acesso SPECIAL ao RACF apenas para provar confiança.
O mundo adulto tem contratos, seguros, backups, testamentos, reservas, redundâncias, procedimentos médicos e advogados justamente porque confiar na vida não significa presumir que ela sempre obedecerá ao roteiro.
🍺 Epílogo — Garçom, outra Original
Voltamos ao boteco.
A história terminou.
Na mesa havia copos vazios, guardanapos rabiscados e provavelmente um diagrama de arquitetura que jamais deveria ser apresentado numa conferência da IBM.
Alguém perguntou:
— Então depois do divórcio, advogado, pensão, revisão e toda aquela confusão... o que ele fez?
Nosso narrador bebeu um gole.
Olhou para a mesa.
E respondeu:
— Vasectomia.
Silêncio.
Um segundo.
Dois.
Alguém começou a rir.
Outro quase cuspiu a cerveja.
Um terceiro bateu na mesa.
E eu percebi que aquele homem havia aplicado à própria vida uma das lições mais antigas da engenharia:
Você pode passar a existência inteira criando planos B, C, D, E até Z.
Ou, em determinados casos, pode eliminar definitivamente uma classe inteira de incidente.
O Red Team encerrou o teste.
O Blue Team atualizou o runbook.
O WLM estabilizou os workloads existentes.
O CAB fechou a mudança.
O urologista recebeu seus honorários.
E ninguém mexeu nos direitos de nenhuma criança.
Olhei para o garçom.
— Amigo...
Ele já sabia.
Pegou outra garrafa.
— Original?
— Original.
Porque algumas histórias terminam com uma sentença judicial.
Outras terminam com uma lição de vida.
Esta terminou com uma cerveja e um Change Request aprovado.
E, convenhamos:
para uma retrospectiva de produção, não foi um resultado ruim.
Nota jurídica: esta é uma crônica inspirada em situação hipotética/anedótica e não constitui orientação jurídica individual. No Brasil, não há percentual legal obrigatório de 30% para pensão alimentícia; valores dependem das circunstâncias concretas, especialmente necessidades do alimentando e capacidade de quem presta os alimentos. Filhos havidos dentro ou fora do casamento possuem igualdade jurídica. Alterações relevantes na situação financeira podem fundamentar pedido judicial de revisão, mas divórcio ou nascimento de outros filhos não produzem redução automática.
