Ir para o conteúdo

Projeto independente de P&D · Colônia

Regras como dados

As regras de decisão são versionadas independentemente do código da aplicação, e cada decisão mantém a procedência da versão das regras que a produziu.

Não normativo

Versão do Companion
1.0
Corresponde ao COADF Core
2.2
Status
Atual
Última revisão
Princípios do COADF
P-8

Propriedade de arquitetura

O COADF P-8, tal como publicado: as regras contra as quais uma decisão é medida são dados, o motor que as avalia não muda quando uma regra muda, e um registro de decisão fica preso à versão do conjunto de regras que o produziu, o que estende o rastro do P-4 até a procedência das regras. O próprio COADF nomeia o estado da técnica: conjuntos de regras recarregáveis, com registros de decisão ligados à sua versão, já existem, e o Open Policy Agent é o exemplo evidente.

O COADF reserva parte do P-8, e diz isso em sua página de princípios. Nada nesta página descreve essa parte. Os exemplos usam um assunto deliberadamente genérico: quais funcionalidades um ambiente de deploy pode habilitar.

Por que importa

As regras mudam com mais frequência que o código, e por razões diferentes: a orientação de um regulador, um contrato, um mercado novo. Quando uma regra vive no código, cada mudança é uma liberação, vários serviços se afastam uns dos outros, e ninguém consegue dizer qual versão de uma regra produziu uma decisão tomada no trimestre passado.

O último problema é o caro. Uma decisão que não pode ser reconstruída não pode ser explicada, e uma decisão que não pode ser explicada não pode ser defendida.

Estratégias de implementação válidas

A forma é pequena: a aplicação pergunta por meio de uma interface que é dela, a interface consulta material de políticas versionado, e a decisão que volta carrega a revisão desse material.

Arquitetura de exemplo · Não normativa

Regras como dados

Exemplo de arquitetura, não normativo: uma aplicação consulta uma interface de política, que consulta um motor; o motor lê material de política versionado e devolve uma resposta registrada com sua revisão.Uma aplicação envia sua pergunta, como entrada, a uma interface de política que pertence à aplicação. A interface consulta um motor de política, que não muda quando as regras mudam. O motor lê o material de política versionado, revisão r, como dados. A resposta do motor é registrada como um registro de decisão que carrega a resposta e a revisão r.AplicaçãoInterfacede políticapertencente àaplicaçãoMotor de políticainalterado quandoas regras mudamMaterialde políticadados versionados,revisão rRegistro de decisãoresposta erevisão rentradalido como dadosresposta
  • Fluxo de dados neste exemplo
A aplicação pergunta por meio de uma interface que é dela. O motor não muda quando as regras mudam; o material é dado versionado, e cada resposta é registrada com a revisão que a produziu.

Descrição textual. Uma aplicação envia sua pergunta, como entrada, a uma interface de política que pertence à aplicação. A interface consulta um motor de política, que não muda quando as regras mudam. O motor lê o material de política versionado, revisão r, como dados. A resposta do motor é registrada como um registro de decisão que carrega a resposta e a revisão r.

  • Uma interface de políticas que pertence à aplicação. A aplicação faz uma pergunta nos seus próprios termos, e o motor fica atrás de um adaptador.
  • Material de políticas versionado. Regras e seus dados são artefatos com um identificador por revisão, com deploy independente da aplicação.
  • A revisão em cada decisão. O registro de decisão carrega a resposta, a revisão e o suficiente da entrada para reproduzi-la.
  • Revisões antigas mantidas recuperáveis. Uma reprodução precisa do material como ele era, não como ele é.
  • Avaliação reproduzível. Uma política que busca dados ou lê o relógio enquanto avalia não pode ser reproduzida só a partir da sua entrada e da sua revisão. Esses fatos devem entrar como entrada, e ser registrados.
  • O motor também versionado. Uma atualização do motor pode mudar o significado: o OPA 1.0 tornou obrigatórias as palavras-chave if e contains, por exemplo. A versão do motor deve ser registrada onde quer que a reprodução importe.
  • Falha controlada. Uma revisão desconhecida, uma revisão ausente, uma resposta malformada ou um motor inalcançável produz um desfecho que o dono da regra escolheu de antemão, nunca um padrão não registrado. Não existe uma resposta certa universal: recusar a ação é o certo para uma regra de acesso a funcionalidades como a do exemplo do perfil Python; para outra decisão, quem é dono dela define o que significa falha, e registra a escolha.

Opções de tecnologia

Modos de falha

  1. Regras duplicadas ou fixas no código em vários serviços

    Cada cópia é alterada no seu próprio ritmo, e a mesma requisição é permitida num lugar e recusada em outro.

  2. A revisão não guardada com o resultado

    A decisão existe; quais regras a produziram, não.

  3. Recarregar uma regra muda o significado de decisões históricas

    Um relatório recalcula as decisões do mês passado com as regras de hoje e as apresenta como sendo do mês passado.

  4. Ambientes rodando revisões diferentes sem procedência

    Durante uma atualização gradual, versões antigas e novas rodam ao mesmo tempo, e um ConfigMap lido por variáveis de ambiente não é atualizado até o pod reiniciar. Por um tempo, duas revisões respondem, e só o registro de decisão consegue dizer qual delas respondeu.

  5. Uma decisão antiga não pode ser reconstruída

    O material foi sobrescrito, ou a avaliação dependia de dados buscados no momento em que rodou.

  6. Indefinido lido como resposta

    Em Rego, uma regra cuja entrada está ausente é indefinida, e um valor padrão responde no lugar dela. Uma chave de entrada escrita errado cai, portanto, silenciosamente no padrão, o que os próprios testes do exemplo fixam. Um teste de contrato do lado de quem chama pega o erro de grafia.

  7. Um cache de decisões que ignora a revisão

    Respostas guardadas em cache a partir do material antigo sobrevivem ao rollout do novo.

  8. Um motor inalcançável tratado como permissão

    Um cliente que permite quando o motor não responde transforma uma indisponibilidade numa política.

Verificação

  • Teste unitário

    Passa quando: Os próprios testes das regras rodam contra o seu material: opa test executa toda regra com o prefixo test_, e uma tabela de regras tem o equivalente.

    Prova de dentes: Alterar o material: os testes que fixam as respostas antigas falham enquanto a regra em si permanece inalterada.

  • Teste de integração

    Passa quando: Toda decisão registrada nomeia uma revisão, igual à revisão do material carregado.

    Prova de dentes: Carregar material sem revisão: o cliente se recusa a registrar uma decisão.

  • Teste de integração

    Passa quando: A mesma entrada sob a mesma revisão dá a mesma resposta, reproduzida contra material arquivado.

  • Teste de contrato

    Passa quando: A entrada que a aplicação envia é a entrada que a política lê.

    Prova de dentes: Renomear um campo de entrada de um dos lados: o teste de contrato falha, em vez de a política cair no seu padrão.

  • Teste de implantação ou de admissão

    Passa quando: Cada ambiente informa a revisão que está rodando, e o informe é comparado com o registro de liberação.

  • Evidência manual

    Passa quando: Uma amostra de decisões históricas é reproduzida contra as revisões que elas registraram.

Realizações alternativas

  • Regras no código, com a revisão do build registrada em cada decisão. Viável para um sistema pequeno. Cada mudança de regra passa então a ser uma liberação, e o motor muda sempre que uma regra muda, o que o P-8 exclui.
  • Serviços de feature flags. Parecidos com políticas, e muitas vezes sem procedência de decisão: qual configuração de flags respondeu a uma dada requisição frequentemente não é registrado.
  • Um serviço de decisão de outra equipe, consumido pela mesma interface, com a revisão na resposta.

Limitações

  • O padrão dá procedência, não correção. Uma regra errada bem versionada continua errada.
  • Ele não cobre as partes do P-8 que o COADF não publica, nem como uma decisão de política encontra qualquer outro controle.
  • O Open Policy Agent é um motor de exemplo. Nada aqui o torna um requisito.

Fontes

COADF Engineering Companion 1.0 · não normativo · corresponde ao COADF Core 2.2

Direitos de publicação reservados. Nenhuma licença pública é concedida, no momento, para o COADF Engineering Companion 1.0 nem para seus exemplos de referência.

Status de propriedade intelectual e de publicação