APRENDER. PRATICAR. EVOLUIR.Desenhar a unidade de decisão
Num grupo fictício, três equipas partilham rede e ferramentas, mas respondem por aplicações diferentes. Um relatório por conta é útil para localizar despesas; não é necessariamente a vista de responsabilidade que a direção precisa. Começa por definir o serviço, o proprietário, o período e os custos incluídos. Mantém uma categoria explícita para valores ainda sem imputação. No comité, apresenta o total reconciliado, a parcela atribuída e a parcela por esclarecer. A decisão deve indicar quem resolve cada exceção e até quando. Não uses uma reorganização de centros de custo para anunciar eficiência técnica: mudar a equipa que paga não demonstra alteração de consumo. Este é um modelo didático de decisão, não um procedimento interno de qualquer banco.
Tornar a classificação verificável
Tags de recursos, tags de imputação de custos e regras de Cost Categories desempenham papéis diferentes. Confirma que as dimensões necessárias estão ativas no reporting e disponíveis para o período observado. Uma tag aplicada hoje não prova que o relatório consultado já a contém. Para uma direção distribuída por contas, define regras que representem o negócio sem deslocar workloads apenas para obter um gráfico. Se o total for 120 mil euros e as aplicações classificadas somarem 96 mil, a diferença de 24 mil continua a exigir explicação. Não a elimines do denominador. Documenta ainda como são tratados serviços comuns e alterações de responsabilidade, para que duas equipas consigam reproduzir o mesmo resultado.
Orçamento, tempo e compromisso
Um alerta de orçamento depende da chegada de dados de faturação e do processamento da notificação. Não deve ser vendido como bloqueio imediato de despesa. Define destinatário, prazo de resposta, ação permitida e impacto de eventual suspensão no serviço. Compara relatórios na mesma base: amortização, créditos, suporte, impostos, período e moeda podem alterar o número apresentado. No exercício, uma redução mensal de compute de 900 euros é acompanhada por 250 de transferência e 150 de operação. A poupança recorrente modelada é 500. Durante dois meses há ainda 600 mensais de coexistência: o saldo é 100 de custo adicional por mês. Estes valores são hipóteses originais, não preços AWS nem previsão financeira real.
Separar fronteiras administrativas e falhas
Contas distintas facilitam separação administrativa, mas não demonstram que todos os caminhos de execução estão isolados. Desenha o percurso de uma operação crítica e marca cada dependência partilhada: rede, identidade, configuração, dados e integrações. Depois escolhe um modo de falha concreto. Se as aplicações dependem do mesmo servidor numa AZ, a separação de contas não remove esse ponto comum. Para uma segunda região, verifica se os componentes necessários estão acessíveis sem a primeira. Uma aplicação que arranca mas não obtém configuração ainda não recuperou o serviço. Relaciona cada hipótese com evidência e responsável, em vez de aceitar apenas a contagem de regiões ou de servidores no diagrama.
Aceitar o serviço integrado
No caso fictício de fecho diário, cada aplicação passa o ensaio individual. Quando as três recuperam ao mesmo tempo, o gateway comum fica saturado e o prazo falha. O resultado conjunto prevalece sobre a soma de sucessos isolados para esse requisito. Regista a carga, a sequência, o tempo de espera e a evidência de conclusão a jusante. A mitigação pode ser capacidade adicional ou uma sequência aceite pelo negócio, mas precisa de demonstração. Não alteres silenciosamente o prazo no relatório. Reavalia a evidência depois de mudanças significativas, sobretudo quando introduzem dependências partilhadas. Um ensaio antigo continua útil como referência; não valida automaticamente a arquitetura atual.
Usar o simulado para orientar revisão
Os simulados deste percurso selecionam decisões originais já disponíveis nas aulas e nos casos. Os três formulários não repetem perguntas entre si, mas quem estudou o banco pode reconhecer itens. No fim, separa erros de conceito, leitura de restrições e gestão do tempo. Volta à aula e explica por que cada alternativa falha antes de repetir. Cada formulário tem 75 perguntas e 180 minutos contínuos, com explicações no final. Todas as perguntas contam na percentagem DR; não há conversão para pontuação escalada AWS. Cobrir as tarefas por mapeamento editorial não demonstra equivalência psicométrica nem cobertura exaustiva. Resume a decisão de arquitetura com requisito, hipótese, prova e limitação: esse hábito é útil tanto no estudo como numa reunião de produção.
compute_saving = 900
extra_transfer = 250
extra_operations = 150
coexistence_per_month = 600
months = 2
steady_saving = compute_saving - extra_transfer - extra_operations
transition_saving = months * (steady_saving - coexistence_per_month)
assert steady_saving == 500
assert transition_saving == -200
# Original bounded exercise; no AWS prices, taxes, discounting or other costs.Um fecho diário fictício passa por três aplicações e um gateway comum. Os ensaios isolados passam; a recuperação simultânea falha por capacidade.
Armadilhas comuns
Confundir alerta com limite rígido, imputação com poupança, contas com isolamento físico e arranque de servidores com recuperação do serviço.
Tópicos relacionados: Governação entre contas · FinOps e recuperação
Uma decisão verificável mantém o total de custos, o requisito de negócio e as dependências visíveis, incluindo o que ainda não foi demonstrado.
Referência: Cost allocation tags · SAP-C02