APRENDER. PRATICAR. EVOLUIR.1. Definir a unidade de valor antes da poupança
Uma equipa fictícia prepara uma proposta para reduzir o custo de processamento de instruções. O resultado útil é uma instrução válida concluída antes do prazo, sem duplicação de efeitos. Define essa unidade com o negócio e conserva-a entre alternativas. Uma tentativa iniciada, uma mensagem colocada numa fila e uma entrega reconciliada não são a mesma coisa. Se o volume ou a qualidade mudar, explica essa mudança antes de comparar percentagens. O gestor técnico deve conseguir ligar cada rubrica a um serviço e a um responsável. No exercício, os custos são unidades fictícias, sem correspondência a preços Google Cloud. Inclui computação de todas as tentativas, transferência e telemetria. Acrescentarias outras rubricas numa proposta real, como armazenamento, licenças, suporte ou trabalho de migração, quando aplicáveis. Escreve também o período e o critério de sucesso. Uma alternativa que custa menos mas entrega menos instruções dentro do prazo pode falhar a aceitação. Esta disciplina dá ao comité uma comparação reproduzível e evita apresentar redução numa rubrica como poupança total. Mantém a baseline e a origem das contagens para que FINOPS e APS possam rever o mesmo raciocínio.
2. Usar perfis para escolher o ensaio
Antes de comprar CPU, identifica onde o pedido passa tempo. Num serviço Java, muito tempo decorrido com pouco tempo de CPU pode indicar espera por uma dependência, lock ou outra condição. Correlaciona o perfil com o percurso que apresenta demora. CPU adicional pode ser útil num bloco intensivo em instruções, mas não demonstra melhoria de uma espera externa. Define a hipótese, a mudança pequena e a medição de resultado. Mantém a mesma versão, carga e dependência no ensaio sempre que isso seja necessário para isolar o efeito. Num serviço Go, allocated heap representa alocações ao longo de um intervalo, incluindo memória já libertada. Um total elevado com heap vivo estável pode indicar churn e trabalho de garbage collection; não prova sozinho que tudo ficou retido. Compara os tipos de perfil suportados pela linguagem e conserva a janela observada. Evita usar uma captura isolada para explicar todo o ciclo de negócio. No relatório de otimização, indica a evidência de desempenho que justifica a proposta e o resultado que a invalidaria. O material desta aula interpreta perfis descritos; não recolhe perfis reais nem executa cargas em produção.
3. Ligar configuração à unidade faturada
Num node pool Standard sem Autopilot, reduzir requests dos Pods não altera automaticamente o tamanho nem a duração das VMs que continuam ligadas. Pode permitir melhor distribuição e consolidação, mas é necessário demonstrar a redução dos recursos faturados. Confirma limites do autoscaler, possibilidade de movimentar os Pods e capacidade restante antes de retirar nós. Não reduzas requests apenas para fazer caber trabalho que depois fica sem recursos. A proposta deve conter tanto evidência de eficiência como critérios de desempenho e recuperação. Em Cloud Run, rever o modo de billing exige perceber quando a aplicação precisa de CPU. Trabalho obrigatório iniciado em memória depois da resposta não fica seguro apenas por se escolher um modo de cobrança. Request-based billing não fornece a premissa de CPU sempre alocada; instance-based billing também não transforma memória local em entrega duradoura. Desenha o mecanismo assíncrono e a recuperação de falhas. Para tráfego esporádico, compara o custo de instâncias mínimas com a latência do primeiro pedido depois de inatividade. Um ensaio só com tráfego contínuo não testa esse requisito. Regista o modo concreto de execução e faturação, evitando generalizar regras de um produto para outro.
4. Separar utilização, cobertura e elegibilidade
Define os denominadores antes de apresentar um compromisso. No modelo da aula, compram-se 100 unidades por hora, usam-se 80 dessas unidades e o consumo elegível total é 160. A utilização do compromisso é 80/100, ou 80%; a cobertura do consumo é 80/160, ou 50%. Um indicador pode melhorar enquanto o outro piora. Nenhum dos dois, isoladamente, é a poupança líquida, porque essa comparação precisa de preços, encargos e alternativa sem compromisso. Explicita também se as unidades são recursos, despesa ou outra medida, para não somar grandezas incompatíveis. Um compromisso Compute Engine baseado em recursos tem âmbito de região e configuração. Mover a aplicação para outra região não transporta automaticamente essa cobertura, nem eliminar a VM cancela a obrigação adquirida. Verifica os termos aplicáveis e a elegibilidade do destino. Distingue este mecanismo de compromissos flexíveis baseados em despesa. No plano do projeto, liga a decisão de compra às datas de migração, retirada e estabilização da procura. Não derives um compromisso plurianual de uma única média sem conhecer o perfil e a evolução do serviço. O exercício não recomenda nem executa qualquer compra.
5. Observar cada hora e cada recurso reservado
Considera cobertura de 100 unidades em cada uma de duas horas. O consumo elegível é 60 na primeira e 140 na segunda. A média de 100 por hora esconde 40 unidades de compromisso sem utilização e 40 unidades de consumo fora da cobertura. No modelo não existe transferência entre horas. Faz a correspondência em cada intervalo e só depois agrega. O mesmo cuidado aplica-se ao cenário de migração: uma baseline mensal aparentemente estável pode conter períodos em que a carga não é elegível para o compromisso que se pretende usar. Reservas de capacidade também precisam de um proprietário e de uma revisão de necessidade. Uma reserva Compute Engine que continua a existir pode gerar custo mesmo sem VMs consumidoras. Isso não implica que deva ser apagada: pode suportar uma necessidade de recuperação previamente aprovada. Documenta a razão, o horizonte e o critério de revisão. Quando uma VM consome a reserva, evita contar duas vezes o mesmo recurso reservado no modelo de custo. Se propuseres libertar capacidade, coordena a decisão com quem responde pelo plano de continuidade. Poupança demonstrada e capacidade de recuperação devem ser avaliadas no mesmo contexto operacional.
6. Reconciliar exportações e custos adicionais
Uma linha de exportação tem cost=120 e créditos de −15 e −5. O resultado líquido é 100. Se expandires os dois créditos e somares cost em ambas as linhas resultantes, obténs 220, porque contaste 120 duas vezes. Agrega os créditos por linha original ou usa outra transformação que preserve essa cardinalidade. Testa também linhas sem créditos e com vários créditos. Antes de apresentar números reais, confirma período de utilização ou fatura, moeda, âmbito e tipos de rubrica incluídos. O exemplo aritmético não pretende reconciliar todos os detalhes de uma fatura cloud. Num exercício separado, mover processamento reduz computação em 48 unidades por dia, mas acrescenta 70 de transferência. Mantendo volume, qualidade e outros custos, há aumento líquido de 22. Avalia origem, destino e produto de rede com as regras atuais, sem assumir que toda a transferência interna é gratuita. Para logs armazenados em dois buckets faturáveis, considera ambos os destinos e retenções. Um insertId igual não elimina automaticamente os custos das duas cópias. Revê redundância útil, investigação e conservação com os responsáveis; uma exclusão para reduzir despesa deve preservar a evidência de que a operação precisa.
7. Laboratório: comparar entregas válidas
Guarda o código como run.py e executa python3 run.py com Python 3.13. A baseline custa 420 de computação, 80 de rede e 40 de telemetria, entregando 50 resultados válidos dentro do prazo. O total é 540 e o custo por resultado é 10,8. A alternativa incomplete custa 520 mas só entrega 40; custa 13 por resultado válido e falha o requisito de 50. A candidate custa 485, entrega 50 e produz 9,7 por resultado. Os custos de computação já incluem todas as tentativas: não multipliques novamente pelo contador de attempts. Prevê primeiro as respostas e depois lê o JSON. no_delivery devolve null para custo unitário, pois não há denominador válido. O programa verifica 61 quantidades de entrega, 441 pares de consumo horário e cinco quantidades de créditos, além de rejeitar seis entradas inválidas. Compara creditNet=100 com naiveExpandedNet=220. As contagens são fornecidas como verdade do exercício, e os preços são fictícios. O programa não executa SQL, APIs de faturação ou uma previsão estatística de retries. Numa proposta real, seria ainda necessário demonstrar a origem e a qualidade das contagens, medir incerteza e validar a execução da alternativa.
8. Apresentar a decisão e acompanhar o resultado
No caso final, o comité recebe uma proposta que omite rede e duplica custos ao expandir créditos. Corrige ambos os problemas antes de recomendar aprovação. Não uses o erro de duplicação como uma contingência escondida: se é necessária margem para incerteza, apresenta-a separadamente e explica a base. Guarda as hipóteses que permitem comparar as alternativas e indica o que ainda depende de ensaio. A equipa de desenvolvimento pode confirmar comportamento, APS valida operação e FINOPS ajuda a reconciliar unidades e encargos. Depois da alteração, acompanha custo total, entregas válidas no prazo, latência e capacidade de recuperação. Compara com a baseline durante períodos representativos e investiga desvios em vez de os diluir numa média. Define quem decide continuar, corrigir ou reverter. Em inglês, pratica uma conclusão precisa: “Compute spend is lower, but network charges make the overall proposal more expensive under the current assumptions.” O resumo da aula é definir valor, medir o limite real, identificar a unidade faturada, verificar elegibilidade e reconciliar os dados antes de declarar poupança. Estas decisões ligam desempenho, gestão financeira e responsabilidade pelo serviço em produção.
"""Original fictional cost comparison. No billing API, SQL engine or purchase."""
from fractions import Fraction
from hashlib import sha256
from pathlib import Path
import json
import platform
def natural(value):
if type(value) is not int or value < 0:
raise ValueError('expected a nonnegative integer')
return value
def assess(compute, network, telemetry, valid_on_time, required, attempts):
for value in [compute,network,telemetry,valid_on_time,required,attempts]:
natural(value)
if valid_on_time > attempts or required == 0:
raise ValueError('invalid completion or requirement')
total = compute+network+telemetry # compute already includes every retry.
return {'total':total,'valid_on_time':valid_on_time,'attempts':attempts,
'cost_per_valid':str(Fraction(total,valid_on_time)) if valid_on_time else None,
'requirement_met':valid_on_time >= required}
def hourly(commitment, usage):
natural(commitment)
if commitment == 0 or not usage:
raise ValueError('positive commitment and nonempty window required')
for value in usage:natural(value)
used = sum(min(commitment,value) for value in usage)
bought = commitment*len(usage)
total = sum(usage)
return {'used':used,'bought':bought,'usage':total,'unused':bought-used,
'uncovered':total-used,'utilization':str(Fraction(used,bought)),
'coverage':str(Fraction(used,total)) if total else None}
def net_row(cost, credits):
natural(cost)
if any(type(c) is not int or c > 0 for c in credits):
raise ValueError('this fixture accepts nonpositive integer credits only')
return cost+sum(credits)
def run():
plans={'baseline':assess(420,80,40,50,50,60),
'incomplete':assess(300,180,40,40,50,75),
'candidate':assess(360,90,35,50,50,55),
'no_delivery':assess(20,5,5,0,50,5)}
assert plans['baseline']['cost_per_valid']=='54/5'
assert plans['incomplete']['cost_per_valid']=='13' and not plans['incomplete']['requirement_met']
assert plans['candidate']['cost_per_valid']=='97/10' and plans['candidate']['requirement_met']
assert plans['no_delivery']['cost_per_valid'] is None
commitment=hourly(100,[60,140])
assert commitment==dict(used=160,bought=200,usage=200,unused=40,uncovered=40,utilization='4/5',coverage='4/5')
assert Fraction(80,100)==Fraction(4,5) and Fraction(80,160)==Fraction(1,2)
assert net_row(120,[-15,-5])==100
duplicated=2*120-15-5
assert duplicated==220 and 70-48==22
credit_cases=0
for count in range(5):
credits=[-3]*count
assert net_row(120,credits)==120-3*count
credit_cases+=1
commitment_cases=0
for first in range(0,201,10):
for second in range(0,201,10):
result=hourly(100,[first,second])
assert result['used']+result['unused']==200
assert result['used']+result['uncovered']==first+second
assert 0<=result['used']<=200
commitment_cases+=1
deadline_cases=0
for valid in range(61):
result=assess(420,80,40,valid,50,60)
assert result['requirement_met']==(valid>=50)
assert (result['cost_per_valid'] is None)==(valid==0)
deadline_cases+=1
invalid=0
for args in [(-1,0,0,1,1,1),(True,0,0,1,1,1),(1.5,0,0,1,1,1),(1,0,0,2,1,1),(1,0,0,1,0,1),(1,0,0,-1,1,1)]:
try:assess(*args)
except ValueError:invalid+=1
assert invalid==6
return {'scriptSha256':sha256(Path(__file__).read_bytes()).hexdigest(),
'pythonVersion':platform.python_version(),'plans':plans,'commitment':commitment,
'creditNet':100,'naiveExpandedNet':duplicated,'migrationNetIncrease':22,
'creditCases':credit_cases,'commitmentCases':commitment_cases,
'deadlineCases':deadline_cases,'invalidPlanCases':invalid,
'network':False,'persistentWrites':False,'vendorExecution':False,
'independentVerification':False,
'limitations':'Fictional integer cost units and trusted completion counts. No real tariffs, taxes, full invoice reconciliation, stochastic retry forecast, SQL execution, billing API or resource purchase.'}
if __name__=='__main__':print(json.dumps(run(),ensure_ascii=False,indent=2))
Poupar 48 unidades de computação e acrescentar 70 de rede aumenta o custo total em 22.
Armadilhas comuns
Confundir requests com cobrança, cobertura com utilização e poupança local com custo total, ou duplicar custos ao expandir créditos.
Tópicos relacionados: SRE e capacidade de recuperação · Observabilidade e conservação de evidência · Gestão de projetos e caso de negócio
Uma poupança defensável conserva a unidade de valor, inclui os custos relevantes e demonstra o resultado operacional.
Referência: Profiling concepts · Current linked guide; edition date unconfirmed (2026-09-30 inspection)