| name | impact-analyzer |
| description | "运行时影响面"分析(区别于 service-dependency-analyzer 的"拓扑影响面")。基于实际 diff + 流量数据估计真实受影响的请求规模。 |
Skill: impact-analyzer
原文 §8.3 服务治理类。运行时而非拓扑视角。
与 service-dependency-analyzer 的区别
| Skill | 维度 | 输出 |
|---|
| service-dependency-analyzer | 静态依赖图 | 哪些服务理论上会受影响 |
| impact-analyzer(本 Skill) | 动态调用 + 流量 | 哪些请求路径实际会被打到 + 量级 |
输入
- 本次 diff(含修改的函数 / 接口)
- 监控/调用链数据源(可选 MCP)
- 服务流量基线(QPS / RT)
工作流
Step 1 — 改动函数提取
从 diff 抽出被改的公共函数 / API endpoint。
Step 2 — 调用方扫描
- 同仓内:
grep 函数名
- 跨服务:对 API endpoint,从
dependencies.yaml depends_on 反查并扫调用方代码
Step 3 — 流量加权
为每个调用点估计 QPS(来自监控数据或历史值),算出"受影响请求量级"。
Step 4 — 输出
=== Impact Analysis ===
被改动函数:couponcenter.GrantByTag
调用方影响:
┌─ 营销后台前端:~50 req/min (工具型流量,可接受短暂抖动)
├─ Marketing CronJob:~5 req/h (定时任务,对延迟不敏感)
└─ 第三方营销 API:~20 req/min (对外契约,必须保证向后兼容)
预计运行时影响:~70 req/min
建议灰度策略:先内部 → 再 CronJob → 最后第三方
协作
- 被
release-coordinator 在阶段 5 前调用
- 被
regression-risk-assessor 用于打分(如果实际影响面 > 1000 req/min,+2 分)