AIOps 变更风险评分：发布小，不代表风险小
一、风险不只看代码行数
一次发布只改了几行配置，也可能影响全站；一次代码改动很多，但只在灰度环境生效，风险反而可控。AIOps 做变更风险评分，不能只看提交规模，要结合服务重要性、依赖关系、历史故障、发布窗口和回滚能力。
发布小，不代表风险小。风险来自影响面。
二、评分维度要透明
flowchart TD A[变更] --> B[服务等级] A --> C[依赖拓扑] A --> D[配置类型] A --> E[历史故障] A --> F[回滚难度]核心服务、跨集群配置、数据库结构、权限策略、流量入口，风险权重要更高。文档改动、非核心页面、可快速回滚的配置，风险相对低。
change_risk_score: service_tier: high touches_config: true affects_database: false rollback_ready: true评分要能解释，而不是只给一个红黄绿。
三、历史事故要参与判断
某个服务过去经常因为配置发布出问题，那么同类变更就应该提高风险。AIOps 可以从事故库中提取模式，提醒团队多做检查。
historical_signal: same_service_incidents_30d: 2 same_change_type_incidents_90d: 4 increase_risk: true但历史相似不是定罪。它只是提醒需要额外验证。
四、风险评分要绑定发布策略
评分高的变更，不是一定禁止发布，而是要匹配更严格策略：更小灰度、更长观察、更明确回滚、更多负责人确认。
release_policy: low: normal_pipeline medium: canary_required high: owner_approval_and_rollback_drill还要看发布时间。高风险变更不要压在值班薄弱时段或大促窗口。
最后，评分结果要复盘。高风险变更平稳上线，说明控制措施有效；低风险变更引发事故，说明评分模型漏了维度。
风险评分还要看“同时发生的变更”。单个发布风险不高，但多个相关服务在同一窗口发布，就可能形成组合风险。AIOps 应该识别同一链路、同一数据库、同一集群内的并发变更。
compound_change_risk: same_dependency: true same_release_window: true shared_database: true还要识别配置类变更。配置变更没有代码 diff，看起来很小，但可能改变流量比例、限流阈值、缓存策略和权限边界。配置项必须有风险标签。
最后，评分不能替代负责人判断。它应该让负责人更快看到风险点，而不是用一个分数免掉评审。
风险评分还要检查观测是否就绪。一个变更本身不一定高危，但如果没有对应指标、日志和回滚开关，上线后就很难控制。缺少观测能力应该提高风险。
observability_readiness: dashboard_exists: true alert_exists: true rollback_switch: true owner_oncall: true对高风险变更，可以要求先补齐仪表盘和告警，再允许进入灰度。否则事故发生时只能靠猜。
最后，评分模型要避免只惩罚“改得多”的团队。主动补测试、补回滚、补灰度能力，应降低实际发布风险。
五、总结
AIOps 变更风险评分要结合服务等级、拓扑、配置类型、历史事故、回滚难度和发布窗口。
发布小，不代表风险小。风险评分的价值，是让发布策略更匹配真实影响面。