控制配置版本

1）为什么要验证配置

配置是可执行的策略：它定义路由、限制、幻灯片、访问、数据模式。版本控制使更改可重复，可预见和可逆性：减少MTTR和更改失败率，消除"销售中的魔力"，并进行安全性和合规性审核。

2）配置分类

基础设施（IaC）：集群，网络，LB，DB，队列。
服务：应用参数、资源、限制、时间表、转发。
产品/业务逻辑：关税，AB实验，内容规则。
数据/DataOps：电路合同,SLA新鲜,转型。
安全：访问策略、角色、密钥/证书（秘密本身-回购之外）。
可观察性：SLI/SLO，Alerts，dashbords。

规则：任何影响系统行为的都是配置，必须生活在转换下。

3）版本控制原则

1.GitOps：真理的唯一来源是存储库；通过公关和自动管道进行更改。
2.声明性：描述目标状态，而不是步骤脚本。
3.文物的不可移动性：config →唯一可实现的狙击手。
4.方案和验证：JSON/YAML方案，严格的类型引导，强制性字段。
5.环境作为代码："env"-文件夹/覆盖物（dev/stage/prod），差异最小且显而易见。
6.等效性和回滚：任何配置版本都是可逆的（revert/rollback）。
7.审核和可跟踪性：作者，原因，滴答声/RFC，更改签名。

4）考试策略

SemVer用于configs包（'MAJOR.MINOR.PATCH`):

MAJOR-不兼容的电路/策略更改。
MINOR-新字段/规则,向后兼容性。
PATCH-在不更改模式的情况下修复值。
标签发行版和发行注释：更改了什么，如何回滚，检查点。
Pinning/lock文件：捕获相关性版本（模块、图表）。
Matrix版本：Application X工件与config Y（服务目录中的矩阵）兼容。

5）存储库的组织

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

分支：基于trunk（主要）+短功能分支。Merge仅通过具有强制性CI的PR。

6）验证和测试

方案：每个更改都经过方案验证（required, enum, ranges）。
静态林特：格式，键，双打，禁区。
兼容性测试：config+版本的服务/图表在沙箱中上升。
控制运行：dry-run应用，目标状态的"what-if" diff。
策略即代码：接纳规则（Rego/CEL）-谁可以更改以及可以更改什么。

7）部署和回滚配置

渐进式交付：带有SLO Gardreils的金丝雀1%→5%→25％。
登机口：没有活跃的SEV-1，Alerta绿色，签名真实，回滚准备就绪。
回滚：'revert tag vX。Y.Z'或切换到以前的狙击手；回滚命令记录在运行簿中。
发布注释：config版本以度量/逻辑发布,以便与事件快速相关。

8）动态和远程配置

Remote config/feature flags：更改参数而不重启；所有标志都在GitOps下。
边界：允许动态更改哪些参数（白名单列表）。
缓存和一致性：TTL，版本，原子替换集（双相发布）。
安全栏杆：runtime更改的极限和范围，在SLO后面时自动滚回。

9）秘密和敏感数据

永远不要在回购中存储秘密。在配置中-仅参考/播放器。
在需要时加密config文件：与秘密/密钥管理器集成。
轮换和JIT：在运营期间提供可用性；行动的足迹不变。
现场伪装：验证禁止PII/秘密进入 config。

10）环境管理

Base+overlays： dev/stage/prod之间的差异最小且透明。
通过人工制品的宣传：通过舞台的相同狙击手在舞会上前进。
时间窗口：值班时不会发生变动；对于风险高-RFC和服务窗口。

11）检测和消除漂移

控制器将目标状态与实际状态进行比较，然后进行报告。
漂移变量：仅在严重差异时才使用页面；其余的是门票。
自动还原：在分辨率下-返回目标状态。
手动编辑审核：任何"kubectl 编辑/ssh" →过程和CAPA事件。

12）配置目录和所有权

服务目录：所有者,SLO,相关策略,方桉,版本,兼容性。
RACI：谁建议，谁是嫉妒，谁赞成；高风险的CAB。
透明度：每个条目都有版本历史记录，并链接到PR/tiketa/AAR。

13）成熟度量

Coverage： GitOps之下的服务/策略百分比（目标≥ 95%）。
领导时间变化：中位数从PR到prod。
Change failure rate：回滚/事件的config发行比例。
漂移率：差异数/周数和消除时间。
滚回时间：恢复到先前版本的中位数。
审核完整性：完全验证的更改比例（验证器,dry-run,评论）。

14）支票单

在更改配置之前

• 有tiket/RFC和更改所有者。
• 已经通过了电路和linter的验证。
• 有一个回滚计划和运行手册中的团队。
• Gate：测试是绿色的，签名是有效的，没有主动SEV-1。
• 对于高风险-已分配服务窗口。

在分手期间

• 金丝雀和SLO Gardrails活跃。
• 发布版本注释。
• 通道中有回声消息；根据MW规则，警报噪音被抑制。

之后

• 观察窗口已通过，SLO绿色。
• 结果和事件（之前/之后的图形，dry-run报告）附在柚木上。
• 已根据需要更新图表/文档。

15）迷你模板

15.1配置方案（YAML方案，片段）

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15.2 Basic config+overles prod

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15.3入场政策（想法）

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15.4 Config发行卡

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16）反模式

在GitOps（"快速分类"）上进行编辑。
Config 存储库中的秘密/PII。
没有电路和静态检查。
周围环境的强烈差异（base≠prod）。
没有版本和故事的"现场"幻灯片标志。
忽略服务器上的漂移和手动编辑。
没有发布注释和回滚计划的标签。

17）实施路线图（4-6周）

1.奈德。1：核对清单；分开的目录，前10名服务的模式。
2.奈德。2：在CI中包括林特/验证和干跑；禁止禁止使用绿色支票。
3.奈德。3：GitOps分开+金丝雀；遥测中的版本注释。
4.奈德。4：输入公差策略（策略即代码）和滚回模式；漂移。
5.奈德。5-6：覆盖90%的服务；将env的差异减少为过量；添加成熟度指标和每周config更改审查。

18）结果

配置版本控制是系统，而不仅仅是Git。方案和验证，GitOps和访问策略，金丝雀和回滚，漂移检测和全面审核将config变成了受控的人工制品。结果是快速而安全的更改，SLO的可预测性以及团队对每个版本的信心。