很多线上事故，回头看都不是“完全没征兆”。
真实的发布现场往往是：
- 改动文件很多
- 涉及核心模块
- 最近刚出过事故
- 时间点又很危险
但这些信息分散在各个地方，
没人会在上线前把它们合在一起看一眼。
于是发布就变成了：
“感觉应该没问题。”
这篇文章只做一件事：
把“上线风险判断”自动化，
在你点发布之前，直接给出一个风险结论。
🎯 最终效果
上线前运行一次工具，直接得到：
- 本次发布风险评分（0–100）
- 是否命中高风险规则
- 哪些因素在拉高风险
- 一份可保存、可追溯的发布风险报告
不是“上线再看监控”，
而是上线前已经知道这次危险不危险。
🧠 风险评估整体流程
📦 工具结构
release-risk-check/ ├── risk_check.py ├── rules.yaml ├── history.json └── report.md⚙️ 风险规则配置（rules.yaml）
score:max:100rules:large_change:threshold:50score:30core_module:paths:-payment/-order/-account/score:30bad_time:after_hour:18score:20recent_incident:days:7score:20📄 历史事故记录（history.json）
{"incidents":[{"date":"2026-01-05","modules":["payment","order"]}]}🧱 核心脚本（risk_check.py｜完整可运行）
#!/usr/bin/env python3# -*- coding: utf-8 -*-importsubprocessimportyamlimportjsonfromdatetimeimportdatetime,timedeltafrompathlibimportPath RULES=yaml.safe_load(open("rules.yaml"))HISTORY=json.loads(open("history.json").read())REPORT=[]score=0defadd_score(s,reason):globalscore score+=s REPORT.append(f"⚠️{reason}(+{s})")defgit_changed_files():out=subprocess.check_output(["git","diff","--name-only","HEAD~1"],text=True)return[line.strip()forlineinout.splitlines()ifline.strip()]defcheck_large_change(files):iflen(files)>=RULES["rules"]["large_change"]["threshold"]:add_score(RULES["rules"]["large_change"]["score"],f"变更文件数过多（{len(files)}）")defcheck_core_module(files):hit=[]forpinRULES["rules"]["core_module"]["paths"]:ifany(f.startswith(p)forfinfiles):hit.append(p)ifhit:add_score(RULES["rules"]["core_module"]["score"],f"命中核心模块：{', '.join(hit)}")defcheck_bad_time():hour=datetime.now().hourifhour>=RULES["rules"]["bad_time"]["after_hour"]:add_score(RULES["rules"]["bad_time"]["score"],f"发布时间过晚（{hour}点）")defcheck_recent_incident(files):days=RULES["rules"]["recent_incident"]["days"]cutoff=datetime.now()-timedelta(days=days)forincinHISTORY["incidents"]:d=datetime.strptime(inc["date"],"%Y-%m-%d")ifd>=cutoff:formininc["modules"]:ifany(minfforfinfiles):add_score(RULES["rules"]["recent_incident"]["score"],f"{m}模块近期发生过事故")returndefrender_report(files):lines=[]lines.append("# 发布风险评估报告\n")lines.append(f"时间：{datetime.now()}\n")lines.append(f"变更文件数：{len(files)}\n")lines.append("## 风险命中项\n")ifREPORT:lines.extend(REPORT)else:lines.append("未命中任何风险规则")lines.append("\n---\n")lines.append(f"## 总风险评分：**{score}/{RULES['score']['max']}**\n")ifscore>=60:lines.append("🚨 **高风险发布**")elifscore>=30:lines.append("⚠️ **中风险发布**")else:lines.append("✅ **低风险发布**")return"\n".join(lines)defmain():files=git_changed_files()check_large_change(files)check_core_module(files)check_bad_time()check_recent_incident(files)report=render_report(files)Path("report.md").write_text(report,encoding="utf-8")print("发布风险评分：",score)ifscore>=60:print("结果：高风险发布")if__name__=="__main__":main()▶️ 上线前一键运行
pipinstallpyyaml python risk_check.py终端输出：
发布风险评分： 70 结果：高风险发布同时生成report.md。
📄 风险报告示例（可直接存档）
## 风险命中项 ⚠️ 变更文件数过多（72） ⚠️ 命中核心模块：payment/ ⚠️ 发布时间过晚（19 点） ## 总风险评分：70 / 100 🚨 高风险发布这份报告可以：
- 作为发布审批附件
- 留作事故追溯证据
- 直接发到群里
⏱ 发布风险检测时序
🔥 这个工具真正解决的问题
- 把“感觉不太对”变成量化结论
- 把分散的信息集中到一次判断
- 让发布决策有依据、可回溯
上线不是赌运气，
而是：
我已经算过风险了。
📌 一句话总结
高风险发布不是“倒霉”，
而是早就写在变更里的信号。
👉 后续这类「发布安全 / 风险控制 / 自动化兜底工具」
都会持续收录在《程序员自动化工具箱》。
如果你不想
靠运气上线、靠加班兜底，
这个专栏你会用得上。
