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 变更风险评分要结合服务等级、拓扑、配置类型、历史事故、回滚难度和发布窗口。发布小不代表风险小。风险评分的价值是让发布策略更匹配真实影响面。