Um estado agregado não é uma lista de entregas
Num rollout StackSets, conserva os resultados de cada conta e região. SUCCEEDED no nível da operação significa que a tolerância de falhas não foi excedida; pode coexistir com instâncias que falharam. No exercício, 18 destinos foram atualizados e dois falharam dentro da tolerância. O requisito do projeto continua a exigir os 20. Reporta 18/20, identifica os dois destinos e atribui correção e validação. Não renomeies a tolerância técnica como aceitação de risco de negócio. A tolerância controla a continuação da operação; a aceitação depende de critérios e autoridade próprios. Guarda IDs, versões anterior e pretendida, erro, responsável e próximo passo. Esta informação permite ao turno seguinte distinguir uma falha já conhecida de uma regressão nova.
Limitar o impacto e conhecer o âmbito
Define a sequência de regiões, a concorrência e os critérios de interrupção antes de começar. Em Strict Failure Tolerance, a concorrência efetiva inicial fica limitada pela tolerância mais um, além do máximo configurado; falhas podem reduzi-la. Percentagens de tolerância são arredondadas para baixo. São limites operacionais, não estimativas exatas de duração. Em permissões geridas pelo serviço, a conta de gestão não recebe as stacks, mesmo numa seleção da organização inteira. A documentação também atribui alcance organizacional amplo ao administrador delegado de StackSets; selecionar uma OU num rollout não cria por si só uma fronteira de delegação. No desenho, separa o âmbito autorizado da execução atual e prepara o baseline da conta de gestão através de um processo próprio.
Exercício guiado: decisão após uma entrega parcial
O requisito fictício exige o agente de monitorização v7 em quatro contas antes do fecho. Os resultados mostram A e B em v7, C com erro de quota e D cancelada. O PM não deve declarar conclusão nem repetir cegamente a operação. Confirma o estado atual de cada stack, corrige a condição de C e prepara a atualização dos destinos pendentes com observação. Se for necessário regressar, avalia o efeito de v7 já ativo em A e B e usa um procedimento aprovado. Uma falha noutro destino não demonstra reversão automática de toda a organização. Para APS, o registo de transição deve mostrar a população mista, os alertas esperados e quem decide continuar ou recuar antes do cut-off.
Cobertura e integridade respondem a perguntas diferentes
Um trail com eventos de gestão não garante registo de GetObject ou PutObject nos ficheiros de reconciliação. Eventos de dados precisam de seleção explícita e têm encargos adicionais. Especifica recursos, operações e necessidade de leitura/escrita antes de otimizar volume. No exercício, o requisito inclui consultas e alterações; um seletor só de escrita deixa uma lacuna. Para integridade, ativar a função de validação permite gerar digests, mas não executa a validação dos ficheiros. Guarda o resultado da verificação, o intervalo e as limitações. Mesmo uma validação bem-sucedida não recupera eventos que nunca foram recolhidos. No relatório, separa quatro decisões: o que recolher, como confirmar entrega, como validar integridade e quem acompanha custo e desvios. Assim, um recibo técnico deixa de ser confundido com evidência completa do requisito.
Rollout worksheet (fictional)
A / eu-west-1 : v7 / SUCCEEDED
B / eu-west-1 : v7 / SUCCEEDED
C / eu-west-1 : v6 / FAILED (quota)
D / eu-west-1 : v6 / CANCELLED
Business acceptance: v7 validated on A, B, C, D
Current acceptance: incomplete; preserve mixed-version inventoryO dashboard mostra sucesso, mas duas contas continuam no baseline antigo e as leituras dos ficheiros não estão registadas. São duas condições de aceitação distintas.
Armadilhas comuns
Confundir tolerância com aprovação; assumir rollback global; esquecer a conta de gestão; contar digests como validação executada; reduzir custos removendo eventos exigidos.
Tópicos relacionados: Limites de governação entre contas
Aceita resultados observados por destino e evidência adequada à pergunta que precisas de responder.
Referência: StackSets concepts · SAP-C02