Em resumo: RACR (Requirements, Assumptions, Constraints, Risks — Requisitos, Premissas, Restrições e Riscos) registra o que o design precisa entregar e sobre o que ele se apoia. AMPRS (Availability, Manageability, Performance, Recoverability, Security) avalia como cada decisão afeta as cinco qualidades de infraestrutura. Use o RACR para enquadrar o problema, o AMPRS para julgar a resposta e rastreie cada decisão até os dois.
Enquanto me preparo para a certificação de VCF Architect, esbarrei em um tópico que vai muito além da prova. RACR e AMPRS são coisas que eu já aplico no dia a dia, muitas vezes sem dar nome, toda vez que avalio um design ou uma proposta. Estudar isso de forma estruturada me fez parar para refletir, e este post é o resultado dessa reflexão.
A maioria dos designs de infraestrutura não falha porque alguém escolheu o produto errado. Falha porque ninguém anotou por que uma escolha foi feita, o que se assumiu como verdade e quanto ela custaria em outro lugar. Seis meses depois alguém pergunta “por que esse cluster é estendido?” e a única resposta é “pareceu uma boa ideia”.
RACR e AMPRS são as duas lentes que uso para evitar isso. Elas vêm do mundo da metodologia de design VMware/VCDX, mas funcionam para qualquer coisa: um cluster vSphere, uma plataforma Kubernetes, uma estratégia de backup ou avaliar se uma proposta de fornecedor faz sentido.
O que é RACR?#
RACR é um método de enquadramento de design que classifica cada informação recebida em Requisitos, Premissas, Restrições e Riscos antes de qualquer solução ser escolhida.
Cada categoria tem um significado preciso, e misturá-las é o erro mais comum:
| Item | Definição | Exemplo |
|---|---|---|
| Requisito (Requirement) | Algo que o design precisa entregar. Funcional (o que faz) ou não funcional (quão bem faz). | “VMs Tier-1 devem tolerar a perda de um host sem impacto no serviço.” |
| Premissa (Assumption) | Algo que se acredita ser verdade, mas não foi verificado. Toda premissa precisa de um dono e de uma validação. | “O link WAN do cliente tem pelo menos 1 Gbps disponível para replicação.” |
| Restrição (Constraint) | Algo que limita as escolhas e não pode ser alterado pelo arquiteto. | “Deve reutilizar o storage Fibre Channel existente até 2028.” |
| Risco (Risk) | Algo que pode acontecer e prejudicar os objetivos do design, com uma mitigação. | “Um único storage é ponto único de falha para todos os clusters.” |
Regra prática: se dá para negociar, é requisito; se não dá, é restrição; se você não verificou, é premissa; se pode dar errado, é risco.
O que é AMPRS?#
AMPRS é um modelo de avaliação que mede cada decisão de design contra cinco qualidades de infraestrutura: Disponibilidade, Gerenciabilidade, Performance, Recuperabilidade e Segurança.
- Availability (Disponibilidade) — O serviço continua de pé quando componentes falham? (HA, redundância, domínios de falha)
- Manageability (Gerenciabilidade) — O time consegue operar no dia 2? (automação, monitoramento, ciclo de vida, conhecimento)
- Performance — Atende às metas de throughput, latência e capacidade sob carga real?
- Recoverability (Recuperabilidade) — Quando algo quebra de verdade, quão rápido e quão completo voltamos? (RPO/RTO, backup, DR)
- Security (Segurança) — Protege confidencialidade e integridade? (segmentação, identidade, hardening, compliance)
A ideia central: nenhuma decisão é neutra. Quase toda escolha melhora uma qualidade e cobra de outra. O AMPRS obriga você a dizer isso em voz alta.
Por que esses frameworks importam#
Sem estrutura, revisões de design viram debates entre preferências. Com RACR e AMPRS:
- Decisões ficam rastreáveis. Cada decisão cita o requisito que atende e a restrição que respeita.
- Premissas escondidas aparecem cedo. Uma premissa não validada é um risco esperando para acontecer, e o RACR a coloca na mesa.
- Trade-offs ficam explícitos. “Ganhamos Performance, perdemos Gerenciabilidade, e compensamos assim” é defensável. “É mais rápido” não é.
- Revisões ficam mais rápidas. Um revisor (ou uma banca VCDX) segue a lógica em vez de ter que fazer engenharia reversa dela.
Como RACR e AMPRS funcionam juntos#
Pense em um pipeline: o RACR define o espaço do problema, as decisões de design vivem dentro dele e o AMPRS avalia o impacto de cada decisão.
Passo 1: o RACR enquadra o problema#
Antes de desenhar qualquer diagrama, colete as informações dos stakeholders e classifique. Numere cada item (R01, A01, C01, RK01) para poder referenciá-lo depois.
Passo 2: decisões são tomadas contra o RACR#
Toda decisão deve responder: qual requisito isso atende e qual restrição a molda? Se uma decisão não se liga a nenhum requisito, questione por que ela existe.
Passo 3: o AMPRS mede o impacto#
Para cada decisão, marque o efeito em cada qualidade: positivo (+), negativo (−) ou neutro (0). Impactos negativos precisam ser aceitos com justificativa ou mitigados.
Passo 4: o ciclo se fecha#
Impactos negativos no AMPRS costumam gerar novos riscos, que voltam para o registro RACR. O design está “pronto” quando todo risco tem mitigação ou aceite explícito.
Exemplo prático: cluster estendido ou não?#
Digamos que a entrada seja: “o negócio quer zero perda de dados se um datacenter cair”. Classificando com RACR:
- R01: RPO = 0 para workloads Tier-1.
- R02: RTO ≤ 15 minutos.
- C01: Dois sites, a 40 km de distância, com fibra apagada existente.
- A01: Latência de ida e volta entre os sites abaixo de 5 ms (a validar com teste de rede).
- RK01: Cenário de split-brain se o witness ficar inacessível.
Duas opções, avaliadas com AMPRS:
| Qualidade | Opção A: vSAN stretched cluster | Opção B: replicação assíncrona + SRM |
|---|---|---|
| Disponibilidade | + Restart automático no site sobrevivente | 0 Exige orquestração de failover |
| Gerenciabilidade | − Witness host, regras de afinidade por site, upgrades mais complexos | + Clusters mais simples, runbooks no SRM |
| Performance | − Escritas síncronas adicionam latência entre sites | + Apenas latência de escrita local |
| Recuperabilidade | + RPO = 0, RTO em minutos | − RPO > 0 (não atende R01) |
| Segurança | 0 Mesmo domínio de confiança entre sites | 0 Igual |
A Opção B não atende R01, então está fora, apesar da vantagem de gerenciabilidade. A Opção A é escolhida, mas seus impactos negativos viram novas entradas: um risco de latência de escrita (mitigado validando A01) e um risco de gerenciabilidade (mitigado documentando a operação do witness). Esse é o método inteiro em uma tabela.
Erros comuns#
- Escrever soluções como requisitos. “Deve usar vSAN” não é requisito. É uma restrição (se realmente imposta) ou uma decisão que você ainda não justificou.
- Deixar premissas sem validação. Uma premissa sem dono e sem data de validação é só um risco que você escondeu.
- Tratar restrições como opcionais. Se orçamento ou hardware são fixos, é restrição. Projetar como se não fossem desperdiça o tempo de todo mundo.
- Marcar só os pontos positivos no AMPRS. Uma decisão só com “+” normalmente significa que a análise não foi honesta.
- Riscos sem mitigação. Listar o risco é metade do trabalho. Declare a mitigação ou o aceite explícito, e quem aceitou.
- Ignorar a Gerenciabilidade. É a qualidade que mais dói no dia 2 e a mais esquecida no dia 0.
FAQ#
O que significa RACR em design de infraestrutura? Requirements, Assumptions, Constraints e Risks: Requisitos, Premissas, Restrições e Riscos. É um método para classificar as entradas do design antes de escolher a solução, permitindo rastrear cada decisão até a necessidade do negócio e seus limites.
O que significa AMPRS? Availability, Manageability, Performance, Recoverability e Security: Disponibilidade, Gerenciabilidade, Performance, Recuperabilidade e Segurança. São as cinco qualidades de design usadas para avaliar o impacto positivo e negativo de cada decisão, popularizadas pela metodologia VMware VCDX.
Qual a diferença entre restrição e premissa? Restrição é uma limitação conhecida e fixa que o arquiteto não pode mudar, como um hardware existente. Premissa é algo que se acredita verdadeiro, mas ainda não foi verificado, como a banda disponível. Premissas exigem validação; restrições exigem respeito.
RACR e AMPRS servem só para designs VMware? Não. Surgiram na metodologia de design da VMware, mas se aplicam a qualquer infraestrutura: plataformas Kubernetes, landing zones em nuvem, redes, estratégias de backup ou avaliação de propostas de fornecedores. São ferramentas de raciocínio agnósticas de fornecedor.
Como documentar decisões de design usando AMPRS? Para cada decisão, registre a justificativa, os requisitos e restrições relacionados e o impacto em cada qualidade como positivo, negativo ou neutro. Todo impacto negativo deve apontar para uma mitigação ou para uma entrada no registro de riscos.
Conclusão#
O RACR diz o que você está resolvendo e sobre o que está apoiado. O AMPRS diz quanto cada resposta custa. Nenhum dos dois é complicado, e é justamente esse o ponto: o valor não está nas siglas, está na disciplina de escrever as coisas antes de discutir sobre elas. Na próxima revisão de design, inclusive a sua, faça duas perguntas para cada decisão: qual requisito motivou isso? e quanto custou em AMPRS? Se não houver resposta, você encontrou seu próximo trabalho.
