feat: add service config templates and extraction script

Former-commit-id: 1de24b7eb79676d1aba9d799a58c5a753290cf52
This commit is contained in:
反编译工作区
2026-05-01 19:38:01 +08:00
parent 3175b7074b
commit 8b15445328
2433 changed files with 8322164 additions and 1604 deletions
@@ -0,0 +1,90 @@
# 访客楼层策略验证执行流程(简化版)
## 1. 目标
按固定顺序完成两组验证,并输出汇总结果:
1. **基线组(广发基金)**:新增“黄平访客 -> 被访人蒙海文(`personId=964454497399468032`)”,再查询该访客楼层权限;
2. **对照组(其他公司多样本)**:从数据库筛选多个公司/多个部门被访人,分别新增“黄志平访客”,再查询各自楼层权限;
3. 最终输出“每个样本是否成功、楼层数量与楼层清单”。
> 说明:本流程强调顺序和可复核性,不再依赖复杂自动推断。
## 2. 统一原则
- 只以 `personId` 作为最终查询键,不以姓名直接判定权限。
- 姓名查询仅用于“定位候选人”,不用于最终业务判定。
- 判定顺序固定:**先写(add/visitor),再读(passRule/image**。
## 3. 执行总流程(必须按顺序)
### 步骤A:准备参数与样本
- 访客固定:黄平/黄志平(按现场实际确认对应 `visitorPersonId`
- 先准备两类样本:
- 样本1(广发基金基线):`businessId=252463...`,被访人 `964454497399468032`
- 样本2(多公司多部门对照):在**与目标验证环境一致**的组织库/MySQL 上筛选多个公司和部门被访人(禁止使用开发库数据去打生产接口)
### 步骤B:执行样本1(广发基金基线)
1.`add/visitor` 新增访客;
2. 紧接着调 `passRule/image` 查询楼层;
3. 记录基线组结果(期望仅 `28F`,若策略开启)。
### 步骤C:执行样本2(多公司多部门)
对每个被访人样本重复:
1.`add/visitor` 新增“黄志平访客”;
2.`passRule/image` 查询该访客楼层;
3. 记录结果到汇总表。
### 步骤D:输出总结果
按样本输出字段:
- 公司
- 部门
- 被访人 `personId`
- 访客 `personId`
- `add/visitor` 结果码
- 楼层数量
- 楼层清单
## 4. 异常分流(必须遵守)
### 4.1 add/visitor 失败(任何样本)
结论:该样本不具备“策略生效验证条件”。
动作:
1. 查同时间窗口服务日志;
2. 定位具体失败点(远程超时、依赖服务不可用、SQL异常等);
3. 修复后仅重跑失败样本。
### 4.2 add/visitor 成功但楼层不符
动作:
1. 查策略读取日志(`policyDecision``allowFloorSize``effectiveFloorSize`);
2. 查策略表配置是否匹配租户;
3.`image_rule_ref` 当前 `person_delete=0` 记录是否包含历史残留。
## 5. 为什么采用该顺序
- 先做广发基金基线,可快速判断策略主路径是否正常;
- 再做多公司多部门对照,可评估是否存在租户间差异或历史规则干扰;
- 最后统一汇总,避免单条日志或单个样本误导结论。
## 6. 推荐命令模板(单样本)
```bash
python3 python/quick_verify_visitor_floor_policy.py \
--mode noauth-probe \
--org-base-url "http://10.0.22.207:8089" \
--elevator-base-url "http://10.0.22.207:16112" \
--business-id "2524639890ba4f2cba9ba1a4eeaa4015" \
--meng-person-id "964454497399468032" \
--visitor-person-id "1102270499947507712" \
--probe-with-businessid
```
> 多样本场景建议外层脚本循环调用本命令,并将结果JSON汇总为一张表。