Configuração como dados

(Seção: Arquitetura e Protocolos)

1) Ideia e diferença de «configuração como código»

A configuração como dados (Configuration as Data, CaD) é uma representação da configuração como um modelo tipificado, declarado, validável, independente do código executável e gerido como dados de negócios, com versões, esquemas, migrações, áudio e testes.
Ao contrário de «configuração como código», onde a lógica da geração de configs vive em modelos/script, CaD exclui o imperativo da origem da verdade: nenhum ciclo, condição ou lógica oculta dentro dos configs. Todos são dados limpos + esquema rigoroso + políticas.

Objetivos essenciais: previsibilidade, capacidade de diff, segurança de mudanças, reversões rápidas, capacidade de entrega progressiva e controle automático de conformidade.

2) Princípios «config como dados»

1. Declaração e inequívoco: descrevemos o estado desejado e não os passos de realização.
2. Segurança e esquema: JSON Schema/Protobuf/Avro/ OpenAPI para contratos rigorosos.
3. Imutabilidade do artefato: imagens config são versionadas e assinadas (provenance).
4. Validação e política: no pipline, sintaxe → semântica → policy-as-código (OPA, regras).
5. Observação de configs: impressão digital em logs/métricas/traçados.
6. Divisão de responsabilidade: dados (config), esquema (contrato), política (restrições), controlador (implementação).
7. Modularidade e camadas: globais, regionais, tenant-, alimentos, níveis de fiche, com previsíveis merjes e prioridades.

3) Simulação de configuração: esquema como contrato

Famílias de entidades: rotação, limites, fichiflags, tarifas, segmentos AB, quotas, regras de risco, finnações, etc.
Tipos: enum/oneOf explícitos, faixas, regex, integridade de referência (ref/ID).
Versioning de diagramas: 'v1 → v1beta2 → v2' (plano deprecation, migração).
Defaulting/Mutation: omissões seguras na fase de validação; Ordem de utilização determinada.
Constraint-s: restrições de negócios (por exemplo, 'rateLimit <= 2000 rps' por tenant).

yaml apiVersion: config. example. io/v1 kind: RateLimitPolicy metadata:
scope: tenant:acme spec:
targets:
- service: checkout endpoint: /api/pay method: POST limit:
unit: second value: 500 burst: 200 strategy: tokenBucket

4) Camadas, herança e resolução de conflitos

Иерархия: `global → region → environment → tenant → product → cohort → user`.
Regras do Merja: Declaratório - «último vencedor» (override) ou estratégico (merge/patch/replace per field).
Validação nas interseções: proibindo chaves em conflito, exigindo override explícito.
A visualização do config efetivo final é obrigatória (difs determinados).

5) Ciclo de vida de configuração (GitOps-paradigma)

1. Origem da verdade: repositório com dados + esquemas + políticas.

• verificação de sintaxe (lint),
• validação de esquema,
• verificações semânticas/testes,
• policy-as-código (por exemplo, OPA/Rego),
• migrações seguras (Consulte no 7),
• assinar e publicar o snapshot.
• 3. Promoção: PR-ami entre os diretórios 'dave/qa/staging/prod' ou os anéis 'ring-0/.../ring-N'.
• 4. Entregas: Controladores/operadores puxam snapshots frescos, aplicam através de um ciclo recôncil.
• 5. Auditoria e reversibilidade: todas as alterações são traçadas; retrocesso - revert commit/rollback snapshot.

6) Entrega e distribuição de configs

Estático (pull-on-start): Carregamos o download no início, reiniciando para atualização.
Dinâmico (watch/stream): etcd/Consul/ZooKeeper, Kubernetes API/CRD, seu próprio Config Service.
Protocolos: gRPC/REST com ETag/If-None-Match, long-poll/watch, snapshots + difs incorporadas.
Armazenamento de armazenamento local com TTL e assinatura; câmbio atômico (duplo tampão).
Sequência: strong (líder/quórum) vs eventual (edge/IoT). Para sistemas críticos, quórum + RA.
Apresentações globais por região/anel (ring-deploy), com limite de zoons simultâneos.

7) Migração de dados de configuração

• Expand: Introduza novos campos sem quebrar os consumidores.
• Migrate: backphils/conversores (quebra-gerentes de migração, idempotidade).
• Contract: Removendo o que é obsoleto quando todos os controladores estão na nova versão do esquema.
• Regra de compatibilidade: a velha lógica compreende o novo, o novo, o antigo período de transição.

8) Política, conformidade e segurança

Policy-as-código: Rego/Conftest/OPA Gatekeeper - Proibições de valores perigosos (por exemplo, 'timeout = 0', desativação de TLS, quotas ilimitadas).
RBAC/ABAC: quem pode alterar quais seções e em que camadas.
Afirmação multilateral (four-eyes) para segmentos sensíveis (pagamentos/limites).
Segredos: armazenados fora de configs compartilhados (KMS, Vault, SOPS), apenas links/arbitragens no configh.
Assinaturas e credibilidade: verificação de entregas (attestações), proibição de snapshots não assinados.
Saneamento: protecção contra injation em modelos e renderização.

9) Observabilidade, SLO e gerenciamento de risco

Marcas de config na telemetria: 'a.config _ digest, config _ versão, ring, scope a.' em logs/métricas/trailers.
Golden-métricas de pelúcia config: tempo de utilização, taxa de sucesso, número de saques, tempo de consistência.
Gates na localização de configs, como para o código - passos canários e auto-pare de degradação SLO.
Dogfooding: primeiro internal/beta-cocorta.

10) Hot-reload, transacionalidade e segurança de aplicação

Atomic switch: A nova configuração é preparada na memória → uma mudança unificada.
Dry-run: Validamos e simulamos a aplicação (incluindo conflito de campos/políticas).
Partial failure: estratégia - «tudo ou nada» para componentes relacionados ou descrição clara das degradações.
Backoff/Retry: Em caso de erro de aplicação, um retrocesso seguro e uma repetição com atraso exponencial.

11) Ficheflagi como um subconjunto de configs

Os fichiflags são dados de config com políticas especiais: targeting por segmento, restrições de raio de inclusão, kill-switch.
Requisitos: semântica definida, auditoria, default seguro, compatibilidade de versões cliente/servidor.

12) Ferramentas e mídias

Mídia: JSON/YAML/TOML/Protobuf/Avro (mais frequentemente Protobuf/JSON).
Render/composição: Kustomize/Helm/Jsonnet (como geradores, mas o resultado são dados limpos).
Armazéns/pneus: Git, registos OCI (como artefatos), armazéns S3 compatíveis, etcd/Consul/KV.
Controladores: seus próprios operadores, GitOps, Sidecar-Config Provedores.
Policy: OPA/Rego, Kiverno-tais mecanismos.

13) Folhas de cheque

Projeto

• Esquema em primeiro lugar (JSON Schema/Proto), descrito tipos/restrições/default.
• Versionização e migração de esquemas estão documentados.
• A hierarquia das camadas e a estratégia de merja foram definidas e testadas.

Pipeline

• Lint → schema-validate → semantic tests → policy-check → sign → publish.
• Dry-run e visualização de config efetivo para revisores.
• Varredura de canais de configs com carros-gates SLO.

Prod

• Há 'config _ digest' nos logs/métricas.
• Reverter a configuração é o mesmo botão do pod de código.
• Os snapshots/bacapes de configs e o histórico de auditoria estão disponíveis e verificados.

14) Frequentes anti-pattern

Imperativo em configh: Condições/script/modelos com lógica - inalcançáveis e imprevisíveis.
Mistura segredos e configurações gerais em um único arquivo/repositório.
Merj opaco: Não está claro de onde veio o valor final.
Falta de esquema, «valia tudo» ⇒ bagaço de venda.
Edição global sem anéis/canarinhos: degradação instantânea para todos.
À deriva dos ambientes, as edições manuais no rântaim à frente da fonte da verdade.
Uma longa TTL em um cofre config sem um mecanismo para forçar um deficiente.

15) Cenários (esboços)

A. Definição fina de limites de tráfego por região

1. PR com alterações de 'RateLimitPolicy' para 'ring-0' (clientes internos).
2. Roteiros automáticos: esquema/política (limite de ≤ 2k rps).
3. Promoção em 'ring-1' (5% dos usuários), monitoramento p95/erro rate.
4. Extensão para 'ring-N', fixação de fita, encerramento de tarefa.

B. Atualização da malha tarifária

forte semântica e política de negócios: visão dupla, promoção em duas etapas, tempo-janela de entrada, auditoria e possibilidade de reversão instantânea.

C. Pagamento global de foguete de bandeira de config com kill-switch: meta «employees → beta → 10% → 100%», parada automática quando a sucessful payment rate cair abaixo do limite.

16) Integração com Zero-Downtime e entrega progressiva

Os canários Config estão sincronizados com os anéis de lançamento.
Compatibilidade de versões: primeiro campos de extensão, depois código, depois endurecimento.
Shadow-confighi: cálculo paralelo de soluções (por exemplo, limitação) para comparação com o combate.

17) Resumos

A abordagem «configuração como dados» transforma configurações de arquivos frágeis em modelos de domínios confiáveis, com contratos, validações e políticas claras. Esta é a base de agendas previsíveis, experiências seguras e reações rápidas a incidentes. Formalize os circuitos, separe os segredos, implemente GitOps e canários de pelúcia e a configuração vai deixar de ser um risco, tornando-se um ativo controlado da plataforma.