职业成长-06-从业务测试转向平台工程时最容易卡住的5类工程问题
从业务测试转向平台工程，最容易被误判的地方，是把卡点理解成语言、框架或工具不熟。真正让转型停住的，往往不是不会写代码，而是不会把零散动作收成长期可运行的系统。
平台工程关注的是对象、状态、边界、执行链路和长期治理。业务测试更擅长识别风险、构造场景和判断结果，但一旦进入平台建设，问题会从“单次任务怎么做”转成“系统如何长期稳定地做”。如果这个视角切不过来，越往后越容易出现脚本能跑、页面能点、系统却不可靠的情况。
一、第一类工程问题：对象建模卡住
业务测试习惯围绕需求、页面、接口、流程去看对象，但平台工程需要先回答系统里真正长期存在的核心对象是什么，以及这些对象之间是什么关系。
常见卡点有三种：
1. 把操作对象当成系统对象
例如把“执行一次回归”直接理解成一个按钮动作，却没有拆清：
- 任务定义
- 任务实例
- 执行节点
- 环境
- 资源占用
- 结果与证据
这样做的后果是系统一开始还能跑，后面一旦要支持补跑、重试、回收、并发和审计，就会发现没有对象能挂这些能力。
2. 把页面结构误当对象结构
控制台上有任务页、报告页、环境页，不代表后端对象就该按页面拆。页面只是展示入口，对象才是系统长期演进的基础。
3. 把临时字段越补越多
对象没拆清时，最常见的补救动作就是加字段。字段越加越多，含义却越来越模糊，最后演变成谁都不敢动的“平台黑盒表”。
二、识别信号：怎么判断自己卡在对象建模
出现下面这些信号时，通常不是功能实现慢，而是对象没建好：
1. 一提到扩展需求就要改很多表和很多接口
例如新增“失败补跑”时，不只是补一个按钮，而是执行表、报告表、任务表、告警表都要联动改。
2. 同一个概念在不同模块里名字不一致
例如有的地方叫任务，有的地方叫计划，有的地方叫执行单，有的地方又叫批次，但实际指的都是相近概念。
3. 状态无法解释清楚
如果一个对象从创建到结束经历了哪些状态，说不清、画不出、表里也对不上，说明对象没有建稳。
三、补齐动作：先把 4 张关系图画出来
对象建模不靠灵感，先做这 4 件事：
1. 画对象清单
至少列出：
- 主对象
- 从属对象
- 外部依赖对象
- 证据对象
2. 画对象关系
明确：
- 一对一
- 一对多
- 是否允许复用
- 是否允许跨环境共享
3. 画对象生命周期
每个核心对象至少要有：
- 创建入口
- 状态流转
- 终止条件
- 回收动作
4. 画对象归属边界
明确哪些字段属于任务定义，哪些属于任务实例，哪些属于执行现场，哪些属于结果产物。
四、常见误区
误区 1：先做页面，后补对象
页面先行会让对象长期被展示结构绑架。
误区 2：对象名字可以后面再统一
对象名字如果一开始不统一，后面接口、表结构、日志、告警都会被污染。
五、第二类工程问题：执行链路卡住
业务测试更熟悉单次操作和单条用例，平台工程必须把一次执行拆成完整链路：
- 任务入队
- 资源分配
- 执行启动
- 步骤推进
- 状态回传
- 证据落盘
- 结果汇总
- 回收释放
如果执行链路没有被拆开，系统就会停留在“点一下跑一下”的阶段，没法真正长期运行。
六、识别信号：怎么判断自己卡在执行链路
1. 本地能跑，放到平台就不稳定
这通常不是脚本问题，而是平台缺失调度、租约、超时、回收和状态同步。
2. 任务失败后无法知道停在哪一步
只有“失败”两个字，没有步骤位置、资源上下文和最后动作记录，说明执行链路没有收完整。
3. 同一个任务偶发重复执行或假完成
这通常是状态写入点不统一、回调和轮询并存却没有对账、超时终止和实际执行脱节。
七、补齐动作：先补最小执行主线
1. 给每次执行分配唯一实例标识
任务定义和任务实例必须分开。平台里真正跑起来的，是实例，不是定义。
2. 固定状态推进点
至少要有：
- 已创建
- 已分配
- 执行中
- 已完成
- 已失败
- 已终止
- 已回收
3. 固定证据落点
日志、截图、录屏、环境信息、错误信息要落到统一位置，不能散在多个目录里。
4. 固定失败收口动作
失败后要明确：
- 是否回收资源
- 是否允许重试
- 是否触发告警
- 是否保留现场
八、常见误区
误区 1：先把脚本跑通，再考虑平台编排
脚本能跑只是起点，不是平台链路成立。
误区 2：执行链路可以靠日志补
日志是证据，不是状态机。状态和证据必须分别设计。
九、第三类工程问题：状态与数据结构卡住
从业务测试转向平台工程时，最容易低估的是状态设计。只要状态设计不稳，任务调度、报告生成、补跑恢复、趋势分析都会跟着失真。
十、识别信号：怎么判断自己卡在状态和数据结构
1. 数据表里大量 nullable 字段和魔法值
这说明对象阶段和状态边界没有拆清，只能靠空值和约定俗成撑住。
2. 同一个状态被多个模块各自维护
如果调度器、执行器、报告系统都在维护“完成/失败”，最后一定会出现互相打架。
3. 报告和现场对不上
页面显示成功，但现场日志显示失败；页面显示失败，实际资源却没回收。这类问题本质上都是状态源不唯一。
十一、补齐动作：先定状态源和状态写入原则
1. 找到单一状态源
主状态只能有一个主写入来源，其他模块只能消费，不要多头更新。
2. 状态推进必须带条件
例如只有资源分配成功后，实例才能进入执行中；只有证据收口完成后，任务才能真正结束。
3. 数据结构按职责拆层
至少分成：
- 定义层数据
- 执行层数据
- 证据层数据
- 汇总层数据
4. 给关键状态留审计信息
至少记录：
- 谁写入
- 何时写入
- 基于什么事件写入
- 写入前后值是什么
十二、常见误区
误区 1：先把表建出来，状态后面慢慢补
状态是平台主线，不是附加字段。
误区 2：为了开发快，多个服务都能改状态
开发阶段看似方便，长期运行时最容易出现不可追踪的错乱。
十三、第四类工程问题：边界与分层卡住
业务测试常常围绕功能流做事，平台工程必须明确哪一层负责什么，不能让页面、接口、调度器、执行器、报告系统互相越界。
十四、识别信号：怎么判断自己卡在边界和分层
1. 后端接口里直接拼接执行命令
说明控制层越界到了执行层。
2. 页面要知道大量底层细节
例如前端要传入执行器细粒度参数、环境路径和设备选择规则，这说明边界没立住。
3. 同样的逻辑在多个地方重复实现
资源探活、失败归因、重试策略如果前后端各写一套，后面必然分叉。
十五、补齐动作：先按 4 层拆开
1. 控制层
负责接收请求、校验参数、组织视图，不直接承担执行细节。
2. 编排层
负责任务调度、状态推进、资源分配、失败恢复。
3. 执行层
负责真正调用脚本、驱动、设备和外部能力。
4. 证据与结果层
负责日志、截图、录屏、报告、趋势和审计。
十六、常见误区
误区 1：分层会拖慢开发，所以先写在一起
平台前期最怕快写成一团，后期再拆通常代价更高。
误区 2：只有做微服务才需要分层
分层和部署方式无关，单体系统同样需要明确边界。
十七、第五类工程问题：长期运行与治理卡住
业务测试更熟悉一次性任务，而平台工程必须面对长期运行。系统能不能跑一周、一个月、一个季度，比能不能在演示环境里成功一次更重要。
十八、识别信号：怎么判断自己卡在长期治理
1. 一换环境就出问题
说明环境依赖、配置注入和探活机制没有收稳。
2. 任务量一上来就大量堆积
说明并发槽位、资源租约、超时机制、回收机制没有建立。
3. 线上出问题只能靠人工翻日志
说明监控、告警、审计和证据聚合没有形成固定链路。
十九、补齐动作：先把长期运行的底线能力补齐
1. 补环境治理
明确配置来源、探活动作、资源池状态和回收时机。
2. 补稳定性治理
至少要有超时、重试、熔断、降级和人工接管入口。
3. 补监控与告警
监控执行量、失败率、卡死数、回收失败数、资源泄漏数。
4. 补证据与审计
让每次异常都能快速回答：
- 发生在哪一步
- 用了哪些资源
- 最后一个有效动作是什么
- 系统做过哪些恢复动作
二十、常见误区
误区 1：先把功能做全，再补治理
功能越多，治理债务越大。
误区 2：演示环境稳定，就代表系统可用
长期运行能力只能在真实节奏下暴露。
二十一、5 类工程问题的最小识别表
| 工程问题 | 最明显信号 | 最先补的动作 |
|---|---|---|
| 对象建模卡住 | 概念混乱、扩展困难 | 画对象清单、关系图、生命周期 |
| 执行链路卡住 | 平台不稳定、失败无定位 | 固定实例、状态、证据和失败收口 |
| 状态与数据结构卡住 | 页面、日志、结果对不上 | 建单一状态源和分层数据结构 |
| 边界与分层卡住 | 逻辑重复、模块互相越界 | 按控制、编排、执行、证据拆层 |
| 长期运行与治理卡住 | 量一上来就失控 | 补环境、稳定性、监控、审计 |
二十二、真实案例：回归平台频繁卡死，问题不在脚本
场景
一个回归平台最初是从接口回归脚本扩出来的。单次执行时能跑通，接入定时任务和多环境之后，平台开始频繁出现任务卡死、资源占用不释放、报告迟迟不出的问题。
执行
现场先做了三个动作：
- 拉取最近 3 天的失败任务和卡死任务。
- 对比任务表、执行日志、资源占用记录和报告生成记录。
- 抽取 5 个典型任务做完整时间线还原。
现象
还原后出现了 4 个明显异常：
- 任务页面显示“执行中”，但脚本进程已经退出。
- 资源池显示设备仍被占用，实际设备已经空闲。
- 报告系统一直等不到“完成”事件，导致页面无结果。
- 失败任务里有一部分并非脚本失败，而是回调丢失后状态没有收口。
排查
继续往下拆，发现根因不是单点 bug，而是 3 类工程问题叠在一起：
- 没有真正区分任务定义和任务实例，导致同一条记录既想表示配置，又想表示现场。
- 执行状态由调度器、执行器和报告模块分别更新，出现多头写入。
- 资源回收依赖“完成回调”触发，一旦回调缺失，系统就不会自动兜底。
这说明问题表面上像脚本不稳定，实质上卡在对象建模、状态源设计和长期治理能力三个层面。
修复
修复动作没有直接从脚本层入手，而是按工程主线重构：
- 新增任务实例表，把定义层和执行层拆开。
- 把主状态写入收口到编排层，执行器只上报事件，不直接改最终状态。
- 增加状态对账任务，对超时未收口的实例做补偿判断。
- 增加资源租约超时和兜底回收机制，避免回调丢失后长期占用。
- 把报告生成改成消费执行终态和证据目录，不再依赖单一回调。
调整后，平台的核心变化不是“脚本更快了”，而是任务实例、资源状态和报告结果终于能对齐，卡死和假运行都明显下降。
二十三、收尾
从业务测试转向平台工程，真正卡住人的通常不是语法，而是工程视角没切过来。对象建模、执行链路、状态设计、分层边界和长期治理，这 5 类问题只要有一类没有补齐，平台就会表现出“能演示、难长期运行”的典型症状。
更有效的做法，是把每个卡点都收成可识别、可补齐、可验证的工程问题。这样转型过程就不会停留在“会不会写代码”的层面，而会真正走到“能不能设计和维护一个长期可运行的平台系统”。