部署资源评估 ​

把一个项目从“有多少组件”变成“要买几台机器、开哪些网络”的可交付文档。Excel 负责清单，交给运维、采购与网络；Markdown 负责说明，交给实施与开发。

适用场景 ​

• 输出部署清单、部署方案、资源评估、节点规划、机器规格。
• 回答“哪些服务 / 中间件要部署、要几台、什么配置”。
• 梳理入站 / 出站网络策略、防火墙白名单。
• 上线前核对配置项、风险项与待确认事项。

工作流程 ​

1. 生成 profile 骨架：有 K8s Manifest / Dockerfile / 依赖清单时扫描仓库；无 manifest（物理机、只有方案文档）时生成空白模板。
2. 补全 profile：逐项核对 Manifest、依赖清单、配置中心、Git 远程地址与技术方案。
3. 生成部署文件夹：产出资源清单 Excel 与部署说明 Markdown。
4. 按清单自检：核对网络端口、运行时风险与占位内容残留。

Step 1 生成 profile 骨架 ​

A. 有 K8s Manifest / Dockerfile / 依赖清单（推荐）

python3 <skill-dir>/scripts/generate_deploy_pack.py scan --repo <项目根目录> --out ./deploy-work

脚本尽力提取：Manifest 的 namespace / 副本数 / 端口 / 探针 / requests·limits，Dockerfile 的基础镜像与 JVM 参数，pom.xml、package.json、requirements.txt、go.mod 中的中间件依赖，配置中心与前端 .env，以及各模块的 git origin。

B. 无 manifest（物理机 / 虚机部署，或只有需求、方案文档）

python3 <skill-dir>/scripts/generate_deploy_pack.py init \
  --out ./deploy-work --name <系统名> --env prod --namespace <命名空间>

模板已内置通用网络策略骨架（SLB→Service、配置中心、数据库、缓存、日志、NTP）与标准部署步骤，删掉不需要的、补上项目特有的。

两种入口的结果都只是骨架，必须人工补全。

Step 2 补全 profile ​

以 deploy-work/deploy-profile.json 为骨架，逐项核对以下来源：

补全后可单独校验（build 也会自动校验）：

python3 <skill-dir>/scripts/generate_deploy_pack.py check --profile ./deploy-work/deploy-profile.json

Step 3 生成部署文件夹 ​

python3 <skill-dir>/scripts/generate_deploy_pack.py build \
  --profile ./deploy-work/deploy-profile.json \
  --out ./docs/部署包-<系统名>

产物：

部署包-<系统名>/
├── 资源清单与网络策略.xlsx     # 6 个工作表，可直接交运维/采购执行
└── 部署说明.md                 # 结论、拓扑、配置项、上线步骤、风险

两份产物各只管一件事，内容不重复：

清单类内容（服务、中间件、待确认组件、入站/出站明细）只写进 Excel；配置项、风险、待确认事项只写进 Markdown。Markdown 需要指向清单时，用一行说明指向对应 Excel 页即可。

清单排版要求 ​

• 前三列固定为中文名、英文名，第三列按表不同为类型 / 版本 / 描述，便于中英文对照与检索。
• 紧跟 CPU（核）/ 内存（GB）/ 磁盘（GB）/ 数量（个）四个纯数字列，单位只写在表头。
• 解释、建议值、来源、配置项统一放到最后的说明列，不混入服务名与数字单元格。
• 每张表末行给「合计（单规格×数量）」：CPU / 内存 / 磁盘 为 Σ(单行规格 × 该行数量)，数量列为实例数合计，加粗并置底色。
• 「待确认部署组件」同样以中英文名开头，「是否部署」只填是或否，佐证放说明列。
• 不单独出「节点与规格」页，节点总数只在部署说明的结论中给一行。

硬性规则 ​

1. 规格必须可溯源：每项写清来源文件；推算值标注「建议」，未定项标注「待确认」，不得把推算值写成既定值。
2. 待确认部署组件必须给证据：用 grep 命中数、注释掉的配置段作依据，结论写「当前不需要部署」，而非绝对否定。
3. 节点数分两种口径：自建方案总节点数，以及改用云托管 RDS / Redis 后的缩减数，两者都要给。
4. 网络策略必须写方向：入站写“谁访问它”，出站写“它访问谁”；来源与目标用实际承载组件（Nginx / SLB、Pod、kubelet、外部域名）描述，不用 K8s 资源名当访问方。
5. 不写真实密钥：AK/SK 与密码写「需在配置中心填写 / ENC 加密」，禁止落明文。
6. 是/否列只填是或否，数字列只写数字；无法确定写 0 并在说明列注明原因。
7. 只写当前项目的事实：模板占位内容、其他项目的组件与地址必须替换或删除。
8. 生成后打开 Excel 校对列宽与自动换行，避免内容被截断。

自检要点 ​

网络开通逐条确认存在 / 不存在，重点：

• 配置中心 2.x 是否放通 gRPC 端口（8848 + 9848/9849）——缺失通常表现为启动长时间卡住。
• 数据库、每个 Redis 实例、算法 / 模型服务地址、统一网关鉴权域名是否放通；出口 IP 是否已在对端白名单备案。
• APM 采集端口、日志接入点、镜像仓库 443 与 imagePullSecret、NTP 123/UDP。
• 入站：网关 / Nginx → 服务端口（注意 Service 端口 ≠ 容器端口）、kubelet → 探针端口（路径是否与 context-path 拼接一致）。
• 前端为静态资源时，出站放通第三方 SDK CDN；浏览器访问路径（VITE_BASE）需与 Nginx location、try_files 一致。

运行时风险逐条判定：

• 副本数 > 1 时，进程内定时任务是否重复执行（@Scheduled、@EnableScheduling）。
• -Xmx + Metaspace + 直接内存是否超过容器 memory limits。
• CPU limits 是否为 0 或未设置；APM agent 挂载与 -javaagent 启动参数是否一致。
• 免鉴权路径（exclude-path）是否覆盖了内部 / 运维接口。
• 配置开关与实现是否一致（读写分离、同步任务默认关闭等）。
• 技术方案指标（ES 检索、MQ 削峰、RPO）是否有对应代码依赖。

完整清单见技能目录 references/checklist.md。

规格推算口径 ​