APRENDER. PRATICAR. EVOLUIR.Seguir o pedido desde o nome até ao resultado
Uma revisão de infraestrutura útil começa por um pedido de negócio concreto. No nosso exemplo fictício, operações submete o fecho de um fundo e espera um resultado dentro de quinze minutos. Desenha o caminho: nome consultado, resolvedor, ligação de rede, backend, armazenamento e dependências externas. Para cada passo, identifica a prova disponível e aquilo que ainda não foi demonstrado. Um túnel disponível não prova resolução DNS; um backend healthy não prova preservação da sessão; uma task terminada não prova que o documento inteiro foi processado. Esta decomposição ajuda APS a coordenar rede, sistemas, middleware e desenvolvimento sem enviar o incidente indefinidamente entre equipas. Começa por um ensaio com um identificador de correlação e timestamps, preservando o contexto de origem. Depois repete num caminho degradado previsto. A pergunta de revisão é sempre qual requisito se mantém nesse estado. Não acrescentes uma promessa de resiliência com base num indicador que só descreve uma parte do caminho.
Distinguir resolução, encaminhamento e recursos NAT
Duas zonas privadas sobrepostas podem explicar um NXDOMAIN apesar de existir um registo numa delas. Para gateway.settlement.corp.example, a zona autorizada settlement.corp.example é mais específica do que corp.example. Se lhe faltar o registo, repetir a consulta não o procura automaticamente na zona menos específica. Regista a zona efetivamente selecionada antes de alterar rotas. Num forwarding on-premises, observa também a origem real do pacote: o retorno de 35.199.192.0/19 deve passar pela mesma VPC que originou a consulta. Uma rota apenas para a subnet da VM não cobre esse requisito. Já um erro OUT_OF_RESOURCES de Cloud NAT orienta a investigação para recursos de tradução, mesmo com poucos bits por segundo. Analisa utilização por VM, concorrência e reutilização de ligações. Estas são três investigações diferentes, com provas diferentes. Na reunião de incidente, pede uma observação que permita distinguir as hipóteses e uma alteração limitada que possa ser validada. Evita abrir permissões amplas ou aumentar retries antes de identificar o mecanismo que está a falhar.
Contar apenas a capacidade que pode servir
Capacidade utilizável depende de mais do que a soma dos recursos livres. Um Pod pode precisar de memória, de uma zona apropriada e de cumprir uma distribuição obrigatória ao mesmo tempo. Se os nós livres violarem DoNotSchedule e os restantes não tiverem memória, existe capacidade total mas não uma colocação válida. Alterar a regra para ScheduleAnyway muda o requisito; pode ser uma mitigação aprovada, mas não deve ser apresentada como prova do desenho original. Faz também a contagem física correta no orçamento: três nós por zona em três zonas representam nove VMs de nós. O control plane gerido não é outra parcela desse pool. No lado do tráfego, session affinity pode quebrar quando o backend deixa de estar disponível. Se a continuidade depende de estado, pergunta onde está a cópia recuperável desse estado e como outro backend a obtém. Usa o exercício para apresentar ao sponsor uma capacidade efetiva e as condições em que foi calculada, em vez de apenas um número de réplicas desejadas.
Ler requests, métricas e limites separadamente
O excerto YAML desta aula contém apenas recursos de um container e uma métrica HPA; não é um manifesto para aplicar. Com quatro Pods ready de um container, cada um com request de 500m e utilização média de 300m, a utilização relevante é 60% do request. Para alvo de 50%, a fórmula base dá ceil(4 × 60/50), ou cinco réplicas. Antes de executar uma conta, identifica o denominador: usar um núcleo inteiro produz uma conclusão diferente e errada para esta configuração. Esta conta não simula o controlador. Métricas em falta, tolerância, limites e políticas podem afetar a ação real; investiga-os no cluster. Memória tem outra interpretação: um container pode ser terminado por pressão no seu limite, mesmo com memória livre no nó. Um evento OOMKilled deve ser correlacionado com observações do cgroup e perfil de consumo. Pedir mais CPU ou mudar readiness não trata automaticamente essa causa. O objetivo do exercício é escolher a evidência relevante para cada mecanismo, não decorar um número de réplicas.
Validar armazenamento desde o guest até à recuperação
Aumentar um recurso de disco não demonstra que a aplicação ganhou espaço utilizável. Num Persistent Disk de dados que cresceu, confirma dispositivo, partição, filesystem e ponto de montagem. O procedimento de expansão depende do layout; não formates um filesystem com dados para resolver uma operação de crescimento em falta. Desempenho também tem fronteiras: quando o limite de throughput está na VM, duplicar o tamanho de um disco que já o excede não duplica a capacidade efetiva. Mede o caminho completo com o workload representativo. Para recuperação, snapshots independentes de dados e journal durante escritas não provam um mesmo estado lógico. Define coordenação da aplicação e demonstra recuperação conjunta. Finalmente, um mount Cloud Storage FUSE não deve ser aceite só porque a aplicação lista ficheiros. Se ela depende de file locking entre escritores, essa necessidade tem de orientar a escolha. Em cada caso, o aluno deve escrever uma condição de aceitação e um ensaio que possa refutar uma proposta tecnicamente plausível mas incompleta.
Orçamentar duração e memória de execução
Um timeout de task Cloud Run aplica-se a cada tentativa. Um job com timeout de dez minutos e dois retries não demonstra um prazo global de dez minutos, nem sequer de quinze. Regista duração das tentativas, intervalos e o instante em que o resultado útil fica disponível. Se existe uma janela de negócio, define um controlo apropriado para essa janela e decide o que acontece aos efeitos parciais antes de repetir. No serviço interativo, inclui ficheiros temporários no orçamento de memória: o filesystem gravável do container usa memória da instância. Um heap estável pode coexistir com consumo crescente de ficheiros retidos entre pedidos. Compara streaming, eliminação controlada e limites de acumulação segundo o formato e tamanho reais das exportações. Aumentar recursos pode ser necessário, mas deve acompanhar uma explicação do crescimento e das condições de carga. O handover a RUN deve incluir os sinais que distinguem timeout, pressão de memória e falha da dependência, com ações que mantenham rastreabilidade do resultado de negócio.
Verificar o significado dos resultados de IA
Disponibilidade de um endpoint de inferência não prova que o input tenha o significado usado no treino. No exemplo original, o treino transforma x em (x-10)/2, mas o serving usa x/100. Para 14, o modelo recebe 2 num caminho e 0,14 no outro. Alinha e versiona o pré-processamento no Predictor e ensaia exemplos conhecidos através do caminho real antes de atribuir a diferença à qualidade do modelo. Em Speech-to-Text, o boost de termos pode reduzir omissões e simultaneamente aumentar falsos positivos. O conjunto de avaliação precisa de chamadas com e sem esses termos, representando o impacto operacional de ambos os erros. Em OCR assíncrono, os resultados de um PDF podem ocupar vários ficheiros: o consumidor deve reconciliar páginas e erros nas respostas, sem assumir que o primeiro objeto representa todo o documento. Estas validações são parte da infraestrutura útil de um processo. Não transformes uma resposta HTTP, uma transcrição ou um texto extraído numa autorização automática para uma operação sensível.
Preparar uma decisão de aceitação defensável
O caso final reúne um nome que não resolve na aplicação e um batch que excede a janela, apesar de indicadores parciais verdes. Prepara uma nota curta para o comité: requisito, observação, consequência, ação e responsável. A correção DNS deve considerar os outros nomes da zona e os consumidores; uma eliminação apressada pode deslocar o problema. O ensaio temporal deve incluir retries e resultado útil, não só a duração de uma tentativa. Se o sponsor alterar o requisito, regista uma decisão explícita e os riscos aceites, sem reescrever retroativamente o ensaio como sucesso. O resumo técnico desta aula é seguir o caminho real, contar capacidade elegível, distinguir requests de limites, verificar semântica de armazenamento e medir conclusão funcional. Relaciona estes temas com observabilidade, change management e critérios de handover. Como exercício de comunicação, explica a decisão em inglês a uma equipa internacional sem depender de termos vagos como cloud ready. O interlocutor deve conseguir identificar o próximo ensaio e quem apresenta a prova.
# Guided excerpts only; not a deployable manifest.
# One container per Pod in the numerical exercise.
resources:
requests:
cpu: 500m
memory: 256Mi
limits:
memory: 512Mi
---
# HPA metric fragment; four ready Pods averaging 300m each.
type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
Uma aplicação não resolve o endpoint e o batch ultrapassa a janela: os indicadores de rede e de tentativas isoladas não demonstram a entrega útil.
Armadilhas comuns
Confundir réplicas desejadas com capacidade elegível, espaço de disco com filesystem, timeout por tentativa com deadline global e resultados parciais de IA com cobertura completa.
Tópicos relacionados: Capacidade e disponibilidade de workloads · Observabilidade e recuperação funcional · Migração e critérios de aceitação
Valida o caminho completo e o significado dos resultados; cada recurso deve ser dimensionado e aceite segundo a fronteira que realmente controla.
Referência: Cloud DNS zones overview · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)