APRENDER. PRATICAR. EVOLUIR.1. Transformar restrições em candidatos de compute
Começa por uma ficha de requisitos por componente. No exemplo fictício, uma API de consulta acompanha um motor legado cujo fornecedor exige um driver instalado no sistema operativo. A primeira vaga não permite alterar esse motor. Uma VM é um candidato para conservar o controlo necessário, mas ainda falta confirmar suporte, licenças, capacidade e manutenção. A API pode ter outra opção de alojamento. A decisão deve incluir integração e esforço de operação, em vez de comparar apenas o preço unitário. Para cada alternativa, escreve a restrição que satisfaz, a responsabilidade que fica com a equipa e a evidência ainda necessária. O PM transforma essa responsabilidade em owner, esforço e janela de trabalho. Uma escolha tecnicamente possível continua incompleta se ninguém consegue mantê-la depois da passagem a RUN.
2. Escolher a fronteira de controlo dos containers
Um container descreve empacotamento, mas não determina sozinho a plataforma. Se a solução exige um operator próprio a usar APIs Kubernetes, inclui AKS na comparação. Se os serviços só precisam de alojamento gerido e não exigem essas APIs, avalia Container Apps contra os requisitos reais. Depois trata o isolamento. No exercício, duas equipas internas de confiança recebem namespaces, mas continuam a precisar de políticas de rede e permissões adequadas. Noutro componente, código não confiável exige privilégios incompatíveis com o cluster interno; essa fronteira pede uma análise mais forte, incluindo clusters separados. Não uses a contagem de namespaces como prova de isolamento. Pede à equipa que explique que ação um consumidor pode tentar, que controlo a impede e que ensaio demonstra esse resultado. Regista também o custo operacional das fronteiras escolhidas.
3. Separar pedido aceite de trabalho concluído
Uma exportação fictícia demora oito minutos. O consumidor precisa de saber que o pedido foi aceite e, mais tarde, de obter o resultado. Um contrato assíncrono com identificador, estado consultável e falha explícita evita manter a interação dependente de uma única resposta HTTP longa. Escolhe depois o mecanismo de execução: trabalho finito pode corresponder a um job; um consumidor contínuo tem outro ciclo. Documenta o que acontece se o processo termina a meio, se o pedido se repete ou se a plataforma interrompe a execução. Um timeout sem limite configurado não torna a memória durável. O exercício pede uma sequência observável: aceitar duravelmente, executar, validar e publicar o resultado. Uma confirmação de aceitação não deve aparecer ao utilizador como conclusão. O suporte precisa de distinguir esses estados para responder corretamente durante um incidente.
4. Aceitar resultados de processamento repartido
O processamento fictício tem um manifesto fechado: partições A, B e C, todas na versão v7. Cada saída tem identidade, versão e estado de validação. Depois de um retry, existem A-v7, uma segunda cópia de A-v7 e B-v7. Três ficheiros não satisfazem três partições. O código abaixo modela esta regra de aceitação; rejeita duplicados, partições inesperadas, versões erradas e resultados inválidos. Não representa a API de nenhum serviço nem simula concorrência distribuída. Num desenho Batch, o scheduler organiza execução, enquanto a aplicação define o contrato dos resultados. O owner deve decidir como recuperar apenas o trabalho em falta ou publicar um conjunto novo de forma controlada. A estimativa financeira inclui os recursos consumidos e o tempo de utilização. Mesmo um serviço sem taxa adicional pode executar trabalho com custos relevantes de compute, storage e rede.
5. Desenhar políticas e atualidade no percurso real
Segue um pedido desde o consumidor. Se a validação está apenas no gateway, uma ligação direta ao backend não a atravessa. Desenha esse segundo percurso e decide como restringi-lo ou protegê-lo. Depois verifica a atualidade dos dados entregues. No exemplo, uma cache local conserva um limite antigo enquanto outro processo altera a base. Uma taxa elevada de cache hit pode coexistir com decisões erradas. O contrato deve especificar onde é tolerável ler informação antiga e onde é necessária uma leitura com atualidade demonstrada. Ensaios com escritores externos e instâncias diferentes revelam lacunas que um teste isolado não mostra. A revisão da cache também inclui ciclo de vida: a migração para Azure Managed Redis exige confirmar o cliente, a autenticação e o endpoint. Provisionar o destino é uma etapa; aceitar o comportamento da aplicação requer outra evidência.
6. Escolher encaminhamento por protocolo e âmbito
A ficha de rede deve indicar protocolo, âmbito, terminação e requisito de saúde. No exercício, o portal público usa HTTP/S em várias regiões, enquanto um serviço interno usa UDP numa região. A seleção deve refletir essa diferença. Confirma as capacidades atuais antes de excluir opções: Application Gateway também apresenta suporte TCP/TLS, e Load Balancer tem opções além do âmbito regional. Traffic Manager trabalha através de DNS, pelo que os clientes podem continuar a usar um endereço em cache durante uma mudança. O ensaio deve observar esse comportamento e o efeito sobre o serviço. Também revê o endpoint de saúde: responder sempre 200 pode esconder uma dependência essencial indisponível. A evidência relevante é conseguir servir o percurso acordado. Uma probe frequente que mede a coisa errada continua a dar um sinal insuficiente.
7. Interpretar avaliações e dependências de migração
Uma avaliação reflete dados e pressupostos de um momento. No caso fictício, a recolha foi completa durante cinco dias tranquilos, mas excluiu o fecho mensal. A cobertura de dados pode ser elevada e, ainda assim, o período não representar a carga que decide a capacidade necessária. O PM pede medições representativas, revisão dos pressupostos e ensaio do destino. O mesmo cuidado aplica-se ao mapa de dependências: uma integração mensal ausente durante dois dias de observação não deixou de existir. Concilia ligações observadas com configuração, horários e owners. Ao dividir uma aplicação por vagas, mede o percurso híbrido temporário, incluindo latência e falhas de ligação. A duração dessa fase tem efeito no orçamento e no suporte. Uma lista de servidores migrados deve ser acompanhada de evidência sobre os serviços de negócio que continuam a funcionar.
8. Preparar passagem, rollback e desativação
Uma cópia de teste pode conservar credenciais e jobs da origem. Antes de a arrancar, impede envios ao parceiro real e prepara destinos autorizados para o ensaio. Na passagem de produção, define qual ambiente pode escrever e como tratar trabalho em curso. Mudar DNS não desliga um scheduler. Se o destino já aceitou instruções novas, voltar ao snapshot antigo exige tratar esses dados; o rollback de tráfego não os transporta. O plano fora de horas deve reservar tempo para reconciliar, decidir e recuperar dentro da janela aprovada. No exercício, restam vinte minutos e a reconciliação exige trinta; não assumes uma extensão por ninguém responder. Por fim, a desativação precisa de critérios de aceitação, recuperação e retenção, owner e data. RUN deve receber procedimentos ensaiados e capacidade de decisão, além do inventário de recursos.
# Fictional closed-manifest acceptance model; no Azure calls or concurrency claims.
def accepts(expected, version, outputs):
if not expected or len(expected) != len(set(expected)):
raise ValueError("expected IDs must be nonempty and unique")
seen = set()
for item in outputs:
key = item["id"]
if key not in expected or key in seen:
return False
if item["version"] != version or item["valid"] is not True:
return False
seen.add(key)
return seen == set(expected)
def output(key, version="v7", valid=True):
return {"id": key, "version": version, "valid": valid}
manifest = ["A", "B", "C"]
assert accepts(manifest, "v7", [output(x) for x in manifest])
assert not accepts(manifest, "v7", [output("A"), output("A"), output("B")])
assert not accepts(manifest, "v7", [output("A"), output("B")])
assert not accepts(manifest, "v7", [output("A"), output("B"), output("D")])
assert not accepts(manifest, "v7", [output("A"), output("B"), output("C", "v6")])
assert not accepts(manifest, "v7", [output("A"), output("B"), output("C", valid=False)])
assert accepts(manifest, "v7", [output("C"), output("A"), output("B")])
assert not accepts(manifest, "v7", [])
print("eight fictional manifest checks passed")
Exercício fictício: o manifesto exige A, B e C na versão v7. Duas saídas de A e uma de B não autorizam publicação. Identifica o trabalho em falta e desenha uma repetição que preserve os resultados válidos.
Armadilhas comuns
Escolher pelo nome do serviço; aceitar só o arranque da VM; contar ficheiros sem verificar identidade; ignorar efeitos de jobs copiados; tratar rollback de tráfego como recuperação de dados.
Tópicos relacionados: Processamento idempotente · Governação de mudanças · Capacidade e FinOps · Aceitação operacional
Escolhe compute por restrições e capacidade de operação. Aceita trabalho pelos resultados. Migra com dependências conhecidas, escrita controlada e recuperação demonstrada.
Referência: Choose an Azure compute service · AZ-305 objectives 2026-04-17