802 lines
42 KiB
Markdown
802 lines
42 KiB
Markdown
STORAGE LABOS
|
||
固件回归测试值守机器人
|
||
产品定义、开发方案、竞争策略与未来规划
|
||
核心命题
|
||
不重新发明测试工具，先把工程师从刷版本、守机器、重启、收日志、填报告等机械劳动中解放出来。
|
||
产品代号
|
||
Storage LabOS · Regression Worker
|
||
版本
|
||
V1.0
|
||
日期
|
||
2026年7月27日
|
||
适用对象
|
||
联合创始人、产品负责人、研发团队、首批试点客户
|
||
首个落地场景
|
||
固件 A/B 版本的无人值守循环回归
|
||
北极星指标
|
||
无人值守完成率 + 每工位释放的工程师工时
|
||
一句话定位：固件提交后，系统自动刷版本、运行回归、处理卡死、收集证据、复现失败，并生成版本结论和缺陷单。
|
||
# 文档摘要
|
||
最终建议
|
||
先做“单工位固件回归值守机器人”，证明它能在一块 SSD、两个固件版本和一套真实 SOP 下，无人值守完成循环测试；测试主机卡死后自动恢复；失败时保存完整证据；结束后自动形成 A/B 对比报告。不要从协议合规、EDA、PCIe 高速背板或自研主控起步。
|
||
本项目的本质不是“AI 会不会判断 SSD”，而是建立一个存储实验室数字执行员：专家负责定义测试和决策，系统负责反复执行、值守、恢复、留证和整理。
|
||
公开市场中的 ULINK、OakGate、SANBlaze、Quarch 与 PyNVMe3 已经证明存储验证、供电控制、故障注入和自动化测试存在稳定需求；同时也说明新团队不应在底层测试覆盖和最新 PCIe 代际上正面竞争。你们的切口是这些能力之上的统一控制平面。
|
||
问题
|
||
方案
|
||
可量化结果
|
||
工程师夜间值守、失败后人工重启
|
||
带外控制器监测主机，分级执行软恢复、Reset、整机断电恢复
|
||
人工介入次数、自动恢复成功率
|
||
工具和脚本分散，失败现场不完整
|
||
统一连接器和 Evidence Bundle，将日志、设备状态、画面、温度和恢复过程对齐
|
||
证据完整率、从失败到可提单时间
|
||
回归结果靠 Excel 和人工对比
|
||
固件 A/B 自动对比、失败指纹聚类、自动生成报告与缺陷单
|
||
报告生成时间、重复问题合并率
|
||
企业已有工具难以推倒重来
|
||
以插件方式接入 DriveMaster、SANBlaze、Quarch、PyNVMe、fio 及私有工具
|
||
接入周期、适配器数量
|
||
## 目录
|
||
上半部分
|
||
下半部分
|
||
1. 项目判断与战略边界
|
||
7. 硬件方案与演进路径
|
||
2. 行业痛点、用户与价值模型
|
||
8. 竞品分析与竞争策略
|
||
3. 产品定位与主打卖点
|
||
9. 差异化、护城河与品牌表达
|
||
4. MVP 产品定义
|
||
10. 产品路线与未来规划
|
||
5-6. 产品功能、技术架构与开发方向
|
||
11-12. 商业化、团队分工与附录 A-D
|
||
# 1. 项目判断与战略边界
|
||
## 1.1 核心判断
|
||
战略公式
|
||
已有测试能力 × 无人值守执行 × 带外自救 × 证据闭环 × 失败复现 = 第一款可卖的产品。
|
||
你们最适合的起点不是存储芯片设计、EDA、主控固件本身，也不是再造一套协议测试仪，而是替代存储公司中高频、固定、耗时但决策含量低的执行劳动。
|
||
测试与验证并非“无脑工作”本身。真正应该被替代的是其中的机械执行层：准备环境、刷固件、反复启动、等待、检测卡死、收集日志、截图、对比版本、整理报告。测试设计、根因确认和发布决策继续由工程师负责。
|
||
## 1.2 产品要解决的任务
|
||
把一份固定 SOP 转换成可审计、可恢复、可重复执行的结构化工作流。
|
||
在无人值守状态下完成固件刷写、I/O、重启、休眠、恢复和数据校验循环。
|
||
测试主机失联或崩溃后，由独立带外控制器恢复环境并从安全检查点继续。
|
||
失败发生时自动保存完整现场，而不是只留下“第 67 轮失败”。
|
||
将固件 A/B 的结果自动对比，并输出研发可直接使用的报告和缺陷草稿。
|
||
兼容客户已有测试工具和私有脚本，降低替换阻力。
|
||
## 1.3 明确不做什么
|
||
非目标
|
||
原因
|
||
何时再考虑
|
||
重新开发完整 NVMe 协议合规套件
|
||
成熟厂商与开源框架已经积累大量用例；首版投入大、差异化弱
|
||
客户明确需要且已有稳定收入后，以连接器或合作方式补齐
|
||
PCIe Gen5/Gen6 高速背板与协议分析仪
|
||
涉及高速信号完整性、时序、电源和认证，容易拖慢产品验证
|
||
在单工位软件闭环和客户付费成立后，由专门硬件团队推进
|
||
让大模型直接控制破坏性命令
|
||
误操作代价高，不能把安全交给概率模型
|
||
大模型只生成草稿；确定性规则和人工审批执行
|
||
自动批准固件发布
|
||
发布是工程责任与组织流程，不应由系统越权
|
||
系统提供门禁证据和风险提示
|
||
EDA 或芯片设计自动化
|
||
进入核心设计签核，专业、信任、数据和销售门槛均过高
|
||
长期若有明确行业伙伴再单独评估
|
||
## 1.4 产品切入点
|
||
图 1｜本产品不与底层测试平台争夺协议覆盖，而是作为统一执行与闭环层。
|
||
# 2. 行业痛点、用户与价值模型
|
||
## 2.1 目标用户
|
||
用户角色
|
||
日常痛点
|
||
本产品交付
|
||
固件工程师
|
||
新固件出来后要等回归结果；失败信息不完整，复现成本高
|
||
版本差异、失败证据、最短复现建议
|
||
验证 / QA 工程师
|
||
大量时间花在刷版本、守机器、重跑和填表
|
||
无人值守执行、自动恢复、自动报告
|
||
实验室负责人
|
||
机器利用率低，夜间失败无人处理，资源状态不透明
|
||
工位在线率、任务队列、人工介入统计
|
||
FAE / 客户支持
|
||
现场问题难复现，日志来源分散
|
||
统一证据包、复现工作流、环境指纹
|
||
研发经理
|
||
无法准确知道版本风险和回归进度
|
||
版本门禁看板、阻断问题、历史趋势
|
||
## 2.2 当前人工流程
|
||
领取测试盘 → 核对序列号 → 刷入固件 → 重启并确认版本→ 配置测试环境 → 跑现有脚本 → 等待 / 观察→ 卡死后人工重启 → 重跑失败段 → 收集多处日志→ 截图 / 复制数据 → 与上一版对比 → 填 Excel→ 写测试报告 → 建缺陷单 → 工程师再次复现
|
||
这里面真正需要专业判断的环节有限，但每一次执行都需要工程师保持在线。夜间失败、主机蓝屏、网络断开和脚本挂起会让“已经自动化的测试”重新变成人工值守。
|
||
## 2.3 目标流程
|
||
工程师选择 DUT + 固件 A/B + 已审核工作流→ 系统完成安全预检和环境指纹记录→ 自动刷写、运行、重启、休眠、恢复、校验→ 失联时带外控制器分级自救并留痕→ 失败时自动收集 Evidence Bundle 并重现→ 自动聚类同类失败、对比 A/B、生成报告和缺陷草稿→ 工程师只处理需要判断的异常与发布决策
|
||
## 2.4 价值模型
|
||
北极星指标
|
||
每个测试工位每周释放的工程师工时。辅助指标包括无人值守完成率、人工介入次数、自动恢复成功率、证据完整率和从失败到可提单的时间。
|
||
指标
|
||
定义
|
||
产品阶段目标
|
||
无人值守完成率 UCR
|
||
无人工触碰完成的计划任务数 ÷ 总计划任务数
|
||
POC 先达到可用；产品化后持续逼近 98%+
|
||
人工介入密度
|
||
每 100 小时测试需要人工处理的次数
|
||
持续下降，且分类记录介入原因
|
||
自动恢复成功率
|
||
主机/Agent 失联后由带外控制恢复的成功比例
|
||
区分软恢复、Reset、整机断电三层
|
||
证据完整率
|
||
失败任务是否包含规定的环境、日志、状态和恢复记录
|
||
关键字段不得因主机崩溃而丢失
|
||
报告交付时间
|
||
任务结束到可审阅报告生成的时间
|
||
分钟级，而不是人工半天整理
|
||
基础设施误报率
|
||
被错误归因到 DUT 的脚本、主机或网络故障比例
|
||
必须单独监控，否则自动化会制造噪声
|
||
# 3. 产品定位与主打卖点
|
||
## 3.1 一句话定位
|
||
产品定义
|
||
固件提交后，系统自动刷版本、运行回归、处理卡死、收集证据、复现失败，并生成版本结论和缺陷单。
|
||
产品名可以暂定为 Storage LabOS，第一款模块叫 Regression Worker。品牌不必强调“AI SSD”，应强调“固件回归不再靠人熬夜”。
|
||
## 3.2 三个主打点
|
||
主打点
|
||
用户能感知到的结果
|
||
为什么重要
|
||
一、自动完成，而不只是自动启动
|
||
工程师配置一次，系统整夜运行；主机卡死后能够继续，而不是停在那里等人
|
||
多数“自动化脚本”在异常后仍需要值守，这是实际人工成本来源
|
||
二、失败自动留证
|
||
每个失败形成统一时间线和 Evidence Bundle，包含环境、命令、日志、设备状态、画面、温度和恢复过程
|
||
减少“无法复现”和跨团队来回索取材料
|
||
三、不推翻现有工具
|
||
DriveMaster、SANBlaze、Quarch、PyNVMe、fio、私有刷写工具和脚本均以连接器方式接入
|
||
降低客户迁移成本，也避免与成熟平台在底层能力上正面竞争
|
||
## 3.3 支撑卖点
|
||
基础设施故障与 DUT 故障分开：网络、脚本、系统、Agent、供电和设备异常使用不同状态码。
|
||
失败自动复现与缩小范围：固定环境重跑、局部步骤重跑、单变量验证和版本二分。
|
||
A/B 版本结论直接可用：不仅给 Pass/Fail，还给新增、消失、加重和偶发问题。
|
||
安全优先：绑定 DUT 序列号、破坏性动作白名单、工作流签名、权限和全量审计。
|
||
私有化部署：客户日志、固件和工具默认不离开内网；AI 可选本地模型。
|
||
报告在测试结束时已完成：工程师从执行者变成审阅者。
|
||
## 3.4 对外表达
|
||
场景
|
||
推荐表述
|
||
官网主标题
|
||
固件回归不再需要工程师通宵值守。
|
||
副标题
|
||
机器卡死能自救，失败自动留证，第二天直接看版本结论。
|
||
对研发负责人
|
||
把初级工程师从刷版本、重启、收日志和填报告中释放出来。
|
||
对实验室负责人
|
||
提升工位利用率，量化每周节省的人工介入和停机时间。
|
||
不建议使用
|
||
“AI 精准判断所有 SSD 根因”“替代验证工程师”“一套工具取代所有测试平台”。
|
||
# 4. MVP 产品定义
|
||
## 4.1 首个场景：固件 A/B 的 100 次循环回归
|
||
MVP 只支持一个 SSD 型号、两个固件版本、一台 Windows 或 Linux 测试主机和一套真实 SOP。测试组合可包含 I/O、重启、冷启动、休眠恢复和数据校验。目标不是覆盖所有测试，而是证明全流程能无人值守闭环。
|
||
## 4.2 用户操作流程
|
||
1. 选择已登记的测试主机与 DUT，系统校验序列号、容量、当前固件和允许动作。
|
||
2. 选择固件 A、固件 B 以及一套已审核工作流模板。
|
||
3. 设置循环次数、重试策略、报告接收人和是否允许破坏性写入。
|
||
4. 系统执行环境预检：磁盘空间、网络、带外控制器、工具版本、日志目录和时间同步。
|
||
5. 任务开始后实时显示当前步骤、轮次、主机状态、设备枚举和关键指标。
|
||
6. 异常时自动收证、恢复、重试或中止，并明确区分基础设施故障与 DUT 故障。
|
||
7. 任务结束后输出固件 A/B 对比、失败簇、证据包和缺陷草稿。
|
||
## 4.3 MVP 范围
|
||
包含
|
||
暂不包含
|
||
单工位、单 DUT；Windows 或 Linux 二选一先做
|
||
多租户云平台与复杂计费
|
||
Python / Shell / PowerShell / fio / nvme-cli / 私有 CLI 连接器
|
||
完整 NVMe 合规套件
|
||
重启、休眠、冷启动、主机掉电恢复
|
||
精准 M.2 3.3V 微秒级掉电
|
||
树莓派带外 Power / Reset / 心跳 / 温度
|
||
PCIe Gen5/Gen6 自研高速背板
|
||
设备、主机、固件和环境指纹
|
||
自动 BIOS 版本刷写与视觉操作
|
||
统一日志、截图、状态和 Evidence Bundle
|
||
大规模预测性故障模型
|
||
规则判定 + AI 摘要 / 报告 / 复现建议
|
||
由 AI 直接执行危险命令或批准发布
|
||
## 4.4 MVP 功能模块
|
||
模块
|
||
MVP 功能
|
||
验收重点
|
||
资产中心
|
||
测试主机、DUT、固件、工具版本、序列号与标签
|
||
任何破坏性任务必须绑定允许的 DUT
|
||
工作流引擎
|
||
步骤、循环、条件、超时、重试、检查点、失败处理
|
||
任务重启后能从安全状态继续
|
||
Host Agent
|
||
执行命令、采集日志、心跳、设备枚举、上传证据
|
||
Agent 崩溃不应导致全部证据丢失
|
||
带外控制
|
||
软重启、Reset、整机电源循环、在线状态监测
|
||
测试主机完全失联时仍可操作
|
||
Evidence Bus
|
||
统一事件时间戳、原始日志、截图、摘要、哈希
|
||
失败材料可追溯且不被覆盖
|
||
比较与报告
|
||
A/B 通过率、失败类型、恢复次数、性能与温度差异
|
||
报告结论能回链到证据
|
||
AI 助手
|
||
SOP 草拟、日志摘要、失败归类建议、缺陷草稿
|
||
所有结论必须引用证据，不直接控制危险动作
|
||
## 4.5 POC 验收门槛
|
||
门槛
|
||
最低验收标准
|
||
完整执行
|
||
对固件 A、B 分别完成规定循环，支持中断恢复和任务审计
|
||
零误盘
|
||
所有破坏性动作均经过序列号和系统盘保护校验，误操作次数必须为 0
|
||
自救能力
|
||
模拟 Agent 停止、系统卡死或网络失联时，能够触发至少两级恢复策略
|
||
证据闭环
|
||
每个失败均可打开一条时间线，并下载统一证据包
|
||
版本比较
|
||
能够明确显示新增失败、已修复失败、重复失败与基础设施失败
|
||
人工减少
|
||
与原人工 SOP 对比，显著减少夜间值守、重启、收日志和整理报告时间
|
||
# 5. 产品功能与交互方案
|
||
## 5.1 页面结构
|
||
页面
|
||
核心内容
|
||
用户动作
|
||
总览 Dashboard
|
||
运行中任务、工位在线率、异常、人工介入、版本风险
|
||
快速判断实验室是否需要人处理
|
||
资产中心
|
||
主机、DUT、固件、工具、带外控制器、标签与状态
|
||
登记、绑定、禁用和审计
|
||
工作流模板
|
||
SOP 转换后的步骤、参数、权限、版本和审批状态
|
||
复制、编辑、审核、发布
|
||
任务创建
|
||
选择资产、固件、模板、循环、报告和安全策略
|
||
启动或预约任务
|
||
实时运行
|
||
当前轮次、步骤、心跳、设备状态、日志和恢复动作
|
||
只在必须时人工接管
|
||
证据浏览器
|
||
失败时间线、原始日志、截图、环境和哈希
|
||
定位证据、下载包、生成缺陷
|
||
版本比较
|
||
A/B 成功率、失败簇、性能、温度和恢复差异
|
||
作出版本判断
|
||
失败中心
|
||
跨任务聚类、指纹、首次/最近出现、关联版本
|
||
去重、标记、复现和分派
|
||
## 5.2 失败状态模型
|
||
INFRA_NETWORK_FAILURE 网络 / 交换机 / SSH / RPCINFRA_AGENT_FAILURE Agent 或插件运行器异常INFRA_HOST_OS_FAILURE 蓝屏、Kernel Panic、系统无法启动TEST_SCRIPT_FAILURE 脚本异常、参数错误、依赖缺失DUT_ENUMERATION_FAILURE SSD 未识别、掉盘、链路异常DUT_DATA_FAILURE 校验失败、介质错误、不可恢复数据错误DUT_PERFORMANCE_REGRESSION 超出已审核阈值的性能 / 长尾退化DUT_FIRMWARE_FAILURE 刷写、提交、激活或回退异常UNKNOWN 证据不足，等待工程师分类
|
||
状态模型必须在大模型之前建立。AI 可以解释和推荐，但真正的状态码应由规则、工具返回值和硬件信号生成。
|
||
## 5.3 Evidence Bundle
|
||
类别
|
||
内容
|
||
身份与环境
|
||
Run ID、DUT 序列号、型号、固件、主板、BIOS、操作系统、内核/驱动、工具版本
|
||
流程上下文
|
||
工作流版本、步骤、循环轮次、输入参数、超时、重试和检查点
|
||
设备证据
|
||
Identify、SMART/Health、Error Log、Self-test、Telemetry/厂商私有日志（可用时）
|
||
主机证据
|
||
系统日志、事件查看器、dmesg/journal、进程、资源、设备枚举和链路状态
|
||
现场证据
|
||
HDMI 截图/录像、串口、温度、供电控制动作、主机心跳和网络状态
|
||
数据证据
|
||
测试文件哈希、校验结果、失败 LBA/范围、fio/PyNVMe/私有工具输出
|
||
恢复证据
|
||
软恢复、Reset、断电、重新上线、重新枚举和恢复耗时
|
||
完整性
|
||
所有文件清单、时间戳、大小、哈希和生成组件版本
|
||
NVMe 标准已经定义 SMART/Health、Error Information、Device Self-test、Persistent Event 和 Telemetry 等可供诊断的日志或能力；厂商私有日志可通过专用工具或 nvme-cli 插件扩展读取。[11][12]
|
||
## 5.4 A/B 报告结构
|
||
执行摘要：版本是否建议进入下一阶段、阻断问题数量、关键风险。
|
||
环境锁定：两次测试的主机、BIOS、OS、驱动、工具和配置是否一致。
|
||
通过率与稳定性：总循环、完整完成、失败、自动恢复、人工介入。
|
||
问题变化：新增、已修复、仍存在、出现频率变化和严重性变化。
|
||
证据链接：每一个结论回链到原始任务、事件时间线和 Evidence Bundle。
|
||
下一步建议：复现工作流、需要固定/变化的变量、建议责任团队。
|
||
# 6. 技术架构与开发方向
|
||
图 2｜MVP 总体架构。带外恢复面独立于测试主机，证据面独立保存失败现场。
|
||
## 6.1 核心组件
|
||
组件
|
||
职责
|
||
MVP 建议
|
||
Web 控制台
|
||
资产、模板、任务、运行状态、证据、比较和权限
|
||
Next.js + TypeScript + ECharts
|
||
API / Orchestrator
|
||
领域模型、权限、安全门禁、任务编排和报告
|
||
FastAPI + PostgreSQL
|
||
Durable Workflow
|
||
长时间任务、重试、等待主机上线、检查点与补偿动作
|
||
POC 用数据库状态机；产品化再评估 Temporal 等持久工作流
|
||
Host Agent
|
||
命令执行、心跳、设备/系统采集、插件隔离与上传
|
||
MVP 用 Python 服务；稳定后将核心守护进程迁移到 Go
|
||
Plugin Runner
|
||
接入 CLI、脚本、DriveMaster、SANBlaze、Quarch 等
|
||
清单化插件 + JSON 输入输出 + 超时/权限声明
|
||
OOB Controller
|
||
Power、Reset、AC、电源状态、HDMI/串口/温度
|
||
树莓派 / CM4 / 工业控制器 + 独立 Agent
|
||
Evidence Store
|
||
原始日志、截图、证据包和不可变清单
|
||
MinIO / S3 兼容对象存储；元数据进 PostgreSQL
|
||
AI Service
|
||
SOP 草拟、摘要、聚类标签、复现建议和报告
|
||
可配置本地或客户批准的模型；所有输出引用证据
|
||
## 6.2 工作流状态机
|
||
DRAFT → APPROVED → QUEUED → PRECHECK → RUNNING ↘ WAITING_FOR_HOST ↘ COLLECTING_EVIDENCE ↘ RECOVERING → RESUME / RETRY ↘ PASSED ↘ FAILED_DUT ↘ FAILED_INFRA ↘ ABORTED / EMERGENCY_STOP
|
||
持久状态机比普通脚本循环重要。测试可能持续数小时或数天，控制服务、Agent、主机或网络都可能重启；任务状态必须可恢复，且每一步需要幂等、超时和补偿逻辑。
|
||
## 6.3 工作流定义示例
|
||
workflow_version: 1name: fw_ab_powerstate_regressionsafety: allowed_dut_serials: ["SAMPLE-001"] destructive_write: true require_approval: truevariables: cycles: 100 firmware: "FW_B.bin"steps: - id: precheck action: lab.precheck - id: flash action: vendor.flash_firmware args: {image: "${firmware}"} - id: reboot action: host.reboot wait_for: {agent_online: true, timeout_sec: 600} - id: loop repeat: "${cycles}" steps: - action: nvme.collect_baseline - action: io.run_profile args: {profile: "4k_mixed", duration_sec: 300} - action: host.hibernate - action: host.wait_resume - action: dut.verify_enumeration - action: data.verify_hashon_failure: - action: evidence.capture_all - action: recovery.escalate - action: failure.classify
|
||
## 6.4 插件规范
|
||
字段
|
||
作用
|
||
name / version / platform
|
||
标识连接器、版本兼容和运行环境
|
||
capabilities
|
||
声明刷固件、采日志、I/O、供电、Reset 等能力
|
||
risk_level
|
||
只读、写入、格式化、Sanitize、固件更新等风险级别
|
||
inputs / outputs
|
||
使用 JSON Schema 约束参数和结构化结果
|
||
timeout / retry / idempotent
|
||
定义超时、重试和能否安全重复执行
|
||
evidence
|
||
声明必须产生的日志、快照和状态字段
|
||
healthcheck
|
||
任务前验证工具、许可证、设备和依赖是否可用
|
||
cleanup / compensation
|
||
失败或取消后恢复环境的动作
|
||
## 6.5 数据模型
|
||
实体
|
||
关键字段
|
||
Host
|
||
主机 ID、硬件、BIOS、OS、驱动、Agent、带外控制器、状态
|
||
DUT
|
||
序列号、型号、容量、形态、固件、标签、允许动作、生命周期
|
||
Firmware
|
||
文件哈希、版本、来源、兼容型号、审批、刷写工具
|
||
Workflow
|
||
版本、步骤、参数、风险、审批、签名、关联 SOP
|
||
Run / Step Run
|
||
状态、时间、主机、DUT、固件、输入、输出、重试、检查点
|
||
Evidence
|
||
类型、URI、哈希、时间范围、来源组件、关联步骤
|
||
Failure Signature
|
||
状态码、日志特征、步骤、环境、DUT 状态、聚类 ID
|
||
Intervention
|
||
人工介入原因、动作、耗时、结果，用于量化真实节省
|
||
## 6.6 AI 与确定性系统的边界
|
||
由确定性系统负责
|
||
由 AI 辅助
|
||
设备序列号与系统盘保护
|
||
把自然语言 SOP 草拟成工作流
|
||
命令白名单、权限、审批、超时和紧急停止
|
||
解释日志和生成工程摘要
|
||
真正执行刷写、格式化、Sanitize、供电和 Reset
|
||
给失败簇命名、提取相似特征
|
||
Pass/Fail 阈值、发布门禁和状态码
|
||
提出下一轮单变量验证或复现建议
|
||
原始证据采集、哈希和审计
|
||
生成 A/B 报告与缺陷草稿
|
||
AI 原则
|
||
任何 AI 结论都必须包含证据引用、置信度和“尚不能排除”的替代解释。AI 不直接执行危险动作，也不替代工程师作最终根因和发布判断。
|
||
## 6.7 安全与私有化
|
||
默认部署在客户内网；固件、私有工具、日志和客户数据不上传公共云。
|
||
工作流模板需要版本化、审批和签名；运行时禁止临时拼接未审核的危险命令。
|
||
系统盘、非白名单序列号和生产盘默认禁止写入；破坏性动作需要双重确认或审批。
|
||
Secrets 与日志分离；刷写工具凭据、许可证和 API Token 使用专门密钥存储。
|
||
所有自动恢复和人工接管动作写入不可变审计日志。
|
||
模型调用可配置脱敏；客户要求时使用本地推理。
|
||
# 7. 硬件方案与演进路径
|
||
## 7.1 MVP：树莓派作为带外控制器，不作为高性能测试主机
|
||
树莓派的价值不是跑满高端 SSD，而是在测试主机完全失联时仍能独立判断在线状态、操作 Power/Reset、记录温度和恢复过程。I/O 与固件测试应优先在真实 x86 Windows/Linux 主机的原生 M.2/U.2 接口上运行。
|
||
组件
|
||
首版选择
|
||
作用
|
||
测试主机
|
||
普通 x86 台式机或服务器，系统盘与 DUT 分离
|
||
运行客户原有工具、驱动和真实负载
|
||
带外控制器
|
||
Raspberry Pi 5、CM4 或工业 Linux 控制器
|
||
心跳、Power、Reset、AC、传感和画面
|
||
ATX 控制
|
||
光耦隔离的 Power/Reset 控制板
|
||
模拟按键，避免直接操作高风险供电轨
|
||
供电控制
|
||
首版先控制整机 AC；需要 DUT 精确掉电时接入成熟工具
|
||
避免首版陷入 M.2 供电时序和信号完整性
|
||
画面采集
|
||
USB HDMI 采集，可选串口
|
||
OS 未启动或蓝屏时仍能留证
|
||
传感器
|
||
温度为主，后续增加电流/电压
|
||
辅助判断热相关和供电相关异常
|
||
网络
|
||
控制面与带外控制器独立心跳
|
||
区分主机崩溃与网络故障
|
||
## 7.2 分级恢复策略
|
||
1. Agent 仍在线：终止异常进程、清理资源、重新执行安全步骤。
|
||
2. Agent 失联但操作系统可达：远程软重启或服务恢复。
|
||
3. 主机无响应：带外控制器短按 Reset，并监测重新上线。
|
||
4. Reset 无效：执行整机 AC 电源循环，保存断电和恢复时间。
|
||
5. 多次恢复失败：进入安全停止，保留现场，禁止无限重启。
|
||
## 7.3 硬件演进
|
||
阶段
|
||
硬件投入
|
||
进入条件
|
||
H0 现成硬件 POC
|
||
测试主机 + 树莓派 + ATX 控制 + 温度 + 可选 HDMI
|
||
先证明完整闭环和人工减少
|
||
H1 工程样机
|
||
工业控制器、隔离 I/O、机箱、状态灯、看门狗、可靠供电
|
||
已有试点客户，需要长期无人值守
|
||
H2 第三方仪器集成
|
||
PSPA、Quarch、智能 PDU、温箱等适配器
|
||
客户确实需要 DUT 独立掉电和故障注入
|
||
H3 自研带外控制板
|
||
多路 Power/Reset、传感、串口、硬件看门狗、远程升级
|
||
多个客户有一致需求，外购成本或集成复杂度成为瓶颈
|
||
H4 专业 DUT 电源 / 夹层板
|
||
精确掉电、测量、旁带信号和保护
|
||
由硬件团队完成 SI/PI、电气安全和长期可靠性验证
|
||
硬件边界
|
||
第一版不要直接切断 M.2 3.3V，也不要自研 Gen5/Gen6 高速转接背板。专业厂商已经提供可软件控制的 DUT 供电、功耗测量、Reset、HotPlug 和故障注入能力；先适配，后自研。[3][5][6][8]
|
||
# 8. 竞品分析与竞争策略
|
||
## 8.1 市场现状
|
||
截至 2026 年 7 月，主流存储验证厂商继续向更高 PCIe 代际、更多 DUT、协议合规、功耗测量、供电控制和故障注入扩展。OakGate 与 SANBlaze 已公开面向 PCIe 6.0 的产品路线，说明新团队若从高速验证硬件正面进入，将面对成熟技术积累与持续代际升级。[13][14]
|
||
另一方面，ULINK、SANBlaze、Quarch 和 PyNVMe3 都提供不同程度的自动化或 API 能力，不能把差异化建立在“竞品不会自动化”上。真正可建立的新定位是：跨工具编排、测试主机自救、证据闭环、失败去重与复现，以及对企业真实 SOP 的快速适配。
|
||
## 8.2 主要竞品画像
|
||
竞品
|
||
公开定位与能力
|
||
强项
|
||
本项目的策略
|
||
ULINK DriveMaster + NVMe Suites + PSPA
|
||
Windows 上的 NVMe 命令、协议、回归与数据完整性测试；回归套件覆盖多种电源循环、数据比较和 JEDEC 工作负载；PSPA 支持软件控制 DUT 供电与测量。[1][2][3]
|
||
测试内容成熟，协议/命令控制和电源循环结合紧密
|
||
不重写套件；做上层版本流转、任务调度、主机恢复、跨工具证据和缺陷闭环
|
||
Teledyne LeCroy OakGate
|
||
专有 SVF 软件与桌面/机架设备组合，支持主流存储协议，可扩展多个 DUT，面向中大型测试团队。[4]
|
||
成熟、稳定、规模化、底层验证能力强
|
||
把 OakGate 视为高价值执行器；产品在其上方统一编排实验室流程
|
||
SANBlaze SBExpress
|
||
Turnkey NVMe 验证系统；RM5 为 16 盘位 Gen5 机架设备，支持供电、功耗和错误注入；桌面系统提供 Python、REST、CLI/XML，公开资料称有 900+ 内置测试。[5][6]
|
||
协议、合规、硬件控制、API 和多盘位一体化
|
||
不比测试数量；比人工介入、异常自救、证据完整性和跨平台复现
|
||
Quarch
|
||
聚焦功耗、供电循环、HotPlug、旁带和物理层故障注入，提供 Python/REST 等自动化接口，并可与 PyNVMe 等集成。[7][8]
|
||
电源与物理故障注入专业、模块化
|
||
作为硬件连接器；不先自研精密供电与信号故障注入
|
||
PyNVMe3
|
||
Python + 专用用户态 NVMe 驱动，可在通用 x86/Ubuntu 平台运行，适合脚本化与 CI，降低专用硬件门槛。[9][10]
|
||
灵活、低成本、开发者友好、易于定制
|
||
作为首批默认执行器之一；补齐带外自救、资产、安全、证据和报告
|
||
企业自研脚本 / Jenkins 类流水线
|
||
自由组合 Python、Shell、PowerShell、fio 和私有工具
|
||
最贴合内部需求，已有沉没成本
|
||
真正的隐形竞品；必须做到接入而非替换，并明显降低维护和值守成本
|
||
## 8.3 能力重心对比
|
||
能力维度
|
||
专业测试平台
|
||
自研脚本 / CI
|
||
Regression Worker
|
||
协议与底层测试覆盖
|
||
强，通常是核心卖点
|
||
取决于团队积累
|
||
不作为首版核心；调用外部能力
|
||
供电 / Reset / 故障注入
|
||
成熟平台可很强
|
||
需要自接硬件
|
||
统一适配，并提供带外恢复策略
|
||
企业私有 SOP 适配
|
||
可定制，但取决于平台
|
||
强，但维护分散
|
||
以工作流与插件为核心
|
||
主机完全卡死后的自救
|
||
部分平台具备设备级控制；跨主机流程各异
|
||
常需人工处理
|
||
产品级主打能力
|
||
跨工具证据时间线
|
||
通常围绕自身工具
|
||
多目录、多格式
|
||
统一 Evidence Bundle
|
||
基础设施与 DUT 故障区分
|
||
依赖具体平台和脚本
|
||
容易混杂
|
||
统一状态模型和分类
|
||
失败去重与最短复现
|
||
通常需工程师完成
|
||
依赖内部开发
|
||
核心增值能力
|
||
报告 / 缺陷闭环
|
||
有报告，但跨工具整合有限
|
||
人工拼接常见
|
||
测试结束即生成可提单结果
|
||
采购与替换阻力
|
||
可能较高
|
||
最低
|
||
叠加在现有资产上，降低迁移阻力
|
||
## 8.4 如何真正脱颖而出
|
||
1. 指标不同：竞品常用协议覆盖、测试数量、带宽、盘位和测量精度证明能力；你们用“每周节省多少人工介入、多少失败能够自动形成证据”证明价值。
|
||
2. 中立连接层：支持竞品和客户自研工具，把已有投入变成插件。客户无需在迁移前先否定过去的系统。
|
||
3. 主机级自救：很多存储工具能控制 DUT，但客户真正痛苦的是测试主机、操作系统、Agent 和网络异常后没人处理。
|
||
4. Evidence First：把“失败结果”变成可转交、可复现、可审计的工程资产。
|
||
5. Failure Intelligence：基于结构化状态和真实证据做去重、版本关联、单变量复现和历史问题检索。
|
||
6. SOP 产品化：每接入一套真实 SOP，就形成可复用模板、连接器和行业知识，而不是一次性外包脚本。
|
||
## 8.5 竞争风险
|
||
风险
|
||
判断
|
||
应对
|
||
成熟厂商增加 AI、报告或调度
|
||
很可能发生，不能依赖单一功能领先
|
||
保持跨厂商中立、做连接器广度和真实 SOP 数据
|
||
客户选择自研
|
||
这是最常见替代方案
|
||
以更快上线、带外硬件、证据标准和长期维护降低自研吸引力
|
||
被认为只是“套壳 Jenkins”
|
||
如果只做任务调度，确实会发生
|
||
必须把 OOB 自救、DUT 安全、证据包、失败指纹和复现做深
|
||
客户不愿开放私有工具和日志
|
||
存储行业数据敏感
|
||
内网部署、最小权限、适配器边界、脱敏和可审计
|
||
不同客户 SOP 差异过大
|
||
可能沦为项目制外包
|
||
核心模型标准化，连接器和模板参数化，严格控制定制边界
|
||
# 9. 差异化、护城河与品牌表达
|
||
## 9.1 可持续护城河
|
||
护城河
|
||
形成方式
|
||
为什么不容易复制
|
||
连接器网络
|
||
对专业平台、私有 CLI、操作系统和硬件控制器持续适配
|
||
单个连接器不难，但长期兼容和组合测试成本高
|
||
标准证据模型
|
||
把主机、DUT、工具、画面、供电和恢复放入统一时间线
|
||
需要深刻理解真实故障流程和客户材料要求
|
||
失败指纹库
|
||
跨固件、环境、步骤和日志生成稳定签名与聚类
|
||
数据来自长期真实回归，不能靠一次模型训练获得
|
||
SOP 模板资产
|
||
将客户流程抽象为可复用工作流、参数和门禁
|
||
越贴近行业，交付越快，客户切换成本越高
|
||
带外控制经验
|
||
主机状态识别、分级恢复、避免死循环和安全停止
|
||
软硬件结合，需要大量异常场景验证
|
||
可信度与审计
|
||
零误盘、证据完整、可回溯、私有化
|
||
存储验证的信任来自长期稳定运行，不只是界面和模型
|
||
## 9.2 数据飞轮
|
||
更多真实工作流→ 更多结构化运行与失败证据→ 更稳定的失败指纹和恢复策略→ 更快的 SOP 接入与更少误报→ 更高无人值守完成率→ 客户愿意接入更多工位和工具
|
||
数据飞轮不能依赖上传客户原始敏感数据。产品应支持在客户本地训练/统计，中心仅同步脱敏的规则、连接器版本和通用失败模式；是否共享由客户明确授权。
|
||
## 9.3 品牌与销售语言
|
||
建议强调
|
||
避免强调
|
||
存储实验室数字执行员
|
||
万能 AI 存储专家
|
||
无人值守完成率和释放工时
|
||
测试脚本数量
|
||
异常自救和证据闭环
|
||
简单任务调度
|
||
不替换现有工具，快速叠加
|
||
颠覆所有测试平台
|
||
工程师保留最终判断
|
||
替代验证工程师
|
||
私有化、安全、可审计
|
||
把所有日志上传云端训练
|
||
# 10. 产品路线与未来规划
|
||
图 3｜路线以里程碑和验收门槛推进，而不是先搭建“大而全”平台。
|
||
## 10.1 阶段 A：单工位 POC
|
||
交付
|
||
进入下一阶段的门槛
|
||
一台测试主机、一块允许破坏性测试的 SSD、两个固件版本、一套 SOP
|
||
完整跑通 A/B 工作流，所有动作可追溯
|
||
Agent、基础工作流、树莓派 Power/Reset、日志和报告
|
||
模拟主机失联后能自动恢复
|
||
设备身份、安全白名单、Evidence Bundle
|
||
误盘为 0；失败证据不因主机崩溃丢失
|
||
人工流程对照测量
|
||
明确减少了哪些步骤和工时
|
||
## 10.2 阶段 B：试点版 Regression Worker
|
||
接入客户真实刷写工具、私有日志工具和一到两套回归 SOP。
|
||
增加角色权限、模板审批、审计、报告版本和缺陷系统接口。
|
||
完善 Windows / Linux 主机故障识别与分级恢复。
|
||
建立基础失败指纹、任务对比和工位利用率指标。
|
||
形成可重复安装、升级和远程诊断的私有化部署包。
|
||
## 10.3 阶段 C：多工位 Storage LabOS
|
||
统一资源预约、任务队列、优先级、并发和维护窗口。
|
||
主机、DUT、固件、工具和许可证资产管理。
|
||
跨工位失败聚类、历史版本关联和实验室健康看板。
|
||
连接器 SDK 与客户自助适配框架。
|
||
支持接入 OakGate、SANBlaze、Quarch、DriveMaster 等现有资产。
|
||
## 10.4 阶段 D：兼容性循环测试柜（方向 4）
|
||
在单工位工作流、自救、证据和调度成熟后，增加多主板、多 BIOS、OS、驱动和电源状态矩阵。此时方向 4 不再是一个新项目，而是同一 LabOS 的新资源类型与测试模板。
|
||
独立测试节点与带外控制，避免首版设计高速 PCIe 共享背板。
|
||
系统镜像恢复、驱动安装、启动前画面采集和兼容性环境指纹。
|
||
Pairwise / 风险加权等组合缩减，避免矩阵全排列。
|
||
输出固件与主板/BIOS/驱动的兼容性图谱、白名单和最小复现组合。
|
||
## 10.5 阶段 E：相邻产品
|
||
产品模块
|
||
复用能力
|
||
新增能力
|
||
RMA 返修盘初检
|
||
资产、工作流、日志、证据、报告
|
||
返修登记、标准复现、初步分流
|
||
来料质检工位
|
||
多工位调度、设备身份、报告
|
||
批量扫码、批次基线、标签/系统接口
|
||
工业存储黑匣子
|
||
Agent、事件时间线、异常模型
|
||
现场长期采集、边缘缓存、远程回传
|
||
精确掉电与故障注入
|
||
带外控制、工作流、证据
|
||
自研电源/信号板或深度仪器集成
|
||
实验室运营分析
|
||
任务、工位、介入、失败数据
|
||
容量规划、利用率和质量趋势
|
||
## 10.6 关键决策门
|
||
决策门
|
||
继续投入的必要证据
|
||
从 POC 到试点
|
||
真实 SOP 下显著减少人工介入；至少一次异常被自动恢复并形成可用证据
|
||
从试点到产品化
|
||
客户愿意持续使用并提供第二套 SOP；部署、升级和安全问题可控
|
||
从单工位到多工位
|
||
客户有明确工位规模和调度痛点，而非为了平台化而平台化
|
||
从外购硬件到自研控制板
|
||
三个以上客户出现重复硬件需求，且外购成本/集成限制影响销售
|
||
进入兼容性测试柜
|
||
单工位底座稳定，且有主板/BIOS/OS 矩阵的真实付费需求
|
||
# 11. 商业化与首批客户策略
|
||
## 11.1 最适合的首批客户
|
||
客户特征
|
||
为什么适合
|
||
中型 SSD、主控、模组或工业存储团队
|
||
有真实测试压力，但未必已有完整内部 LabOS
|
||
拥有 5-50 个测试工位或大量零散脚本
|
||
人工值守和维护成本明显，能量化 ROI
|
||
至少有一套固定且高频的固件回归 SOP
|
||
容易形成第一条闭环，而不是开放式咨询
|
||
愿意提供脱敏报告、正常/异常样品和工程师接口
|
||
能验证产品是否真正解决问题
|
||
需要私有化部署和现有工具接入
|
||
恰好匹配中立控制层定位
|
||
首批客户选择
|
||
暂不优先挑战已经拥有成熟自研 SLT / LabOS 的头部厂商。先找“已有测试能力，但流程碎片化、夜间仍要人守”的团队。
|
||
## 11.2 POC 交付包
|
||
一份真实 SOP 的结构化工作流和风险清单。
|
||
一台测试主机 Agent 与一套树莓派带外控制。
|
||
客户私有刷写工具、I/O 工具和日志工具连接器。
|
||
固件 A/B 循环任务、异常自救和 Evidence Bundle。
|
||
版本对比报告、人工步骤对照和 ROI 结果。
|
||
下一阶段产品化边界与报价依据。
|
||
## 11.3 商业模式
|
||
收入项
|
||
说明
|
||
POC / 集成服务
|
||
围绕一套 SOP 和一个工位完成连接器、流程和现场验证
|
||
软件许可 / 订阅
|
||
按工位、并发任务或实验室规模授权，私有化部署
|
||
带外控制硬件
|
||
标准控制盒、机箱、传感和可选画面采集
|
||
高级连接器
|
||
专业测试平台、仪器、缺陷系统和私有工具适配
|
||
维护与升级
|
||
连接器兼容、系统升级、安全补丁和远程支持
|
||
后续模块
|
||
兼容性柜、RMA、来料质检、运营分析
|
||
## 11.4 ROI 计算方式
|
||
每月可节省成本 ≈（原每次人工操作分钟 × 每月任务次数 × 工程师综合小时成本）+ 夜间 / 周末值守成本+ 因失败证据不足导致的重复复现时间+ 测试机空转和等待人工恢复的机会成本- 软件与硬件的月度摊销成本
|
||
销售时不要只展示“技术很强”，而要对照客户原 SOP 逐步标注哪些动作被删除、哪些异常不再需要人到场、报告提前了多久。
|
||
## 11.5 POC 访谈问题
|
||
哪一套测试每周重复最多，步骤最固定，最需要人守？
|
||
测试主机最常见的中断原因是什么：蓝屏、掉盘、脚本、网络、供电还是环境？
|
||
失败后工程师必须收集哪些证据才能建缺陷单？
|
||
现有工具有哪些 CLI、API 或可调用入口？哪些只能操作 GUI？
|
||
哪些动作可能破坏数据或刷错盘？现有审批与白名单是什么？
|
||
一名工程师每周花多少时间在执行、值守、重跑和整理报告上？
|
||
哪些问题由于证据不足经常被标记为“未复现”？
|
||
# 12. 团队分工、风险与立项动作
|
||
## 12.1 初始团队
|
||
角色
|
||
主要职责
|
||
你：产品 / 全栈 / AI
|
||
产品定义、控制台、工作流、数据模型、AI 报告、交付体验和项目推进
|
||
同学：存储领域 / 客户 / 资金
|
||
真实 SOP、测试样品、固件/日志解释、行业关系、首批客户和资源投入
|
||
验证工程师（必须）
|
||
把真实流程拆成可执行步骤、定义门禁、验收状态和异常分类
|
||
嵌入式 / 硬件工程师
|
||
带外控制、隔离、可靠供电、看门狗、机箱与后续自研板
|
||
后续平台工程师
|
||
Agent 稳定性、部署、升级、对象存储、权限和多工位调度
|
||
## 12.2 主要风险清单
|
||
风险
|
||
影响
|
||
缓解措施
|
||
没有真实 SOP，只按想象开发
|
||
做出漂亮但没人使用的通用平台
|
||
第一条工作流必须来自同学公司或真实客户
|
||
试图一次支持所有工具和接口
|
||
项目失控、无法验收
|
||
先锁定一个 OS、一个 SSD 类型、一套工具链
|
||
只做网页调度，没有异常自救
|
||
容易被视为脚本平台或 Jenkins 套壳
|
||
带外控制、状态机和证据闭环必须进入 MVP
|
||
AI 结论过度承诺
|
||
降低工程师信任并带来错误决策
|
||
证据引用、置信度、规则优先、人工确认
|
||
硬件故障导致误判或损坏 DUT
|
||
安全和品牌风险
|
||
隔离、保险、白名单、紧急停止和硬件评审
|
||
客户定制过多
|
||
变成低毛利项目制
|
||
插件 SDK、标准模型、可配置模板、定制边界
|
||
无法证明节省人工
|
||
购买理由不充分
|
||
从第一天记录人工介入和原流程基线
|
||
## 12.3 立项后的第一批动作
|
||
1. 向同学获取一份最耗人的固件回归 SOP、一份脱敏测试报告和两个固件版本。
|
||
2. 选定一台独立测试主机和一块允许反复写入/刷写的测试 SSD。
|
||
3. 用人工完整执行一次 SOP，逐步记录动作、等待、判断、异常和最终报告。
|
||
4. 将流程拆成“专家判断”和“机械执行”，只自动化后者。
|
||
5. 先实现设备身份、安全预检、任务状态机和原始证据采集，再做 AI。
|
||
6. 接入第一个刷固件工具与第一个 I/O/日志工具。
|
||
7. 接入树莓派 Power/Reset，模拟 Agent 失联和主机卡死。
|
||
8. 完成固件 A/B 的 100 次循环 Demo，统计人工介入和失败证据。
|
||
9. 让真实验证工程师审阅报告，修改 Evidence Bundle 和状态码。
|
||
10. 用 Demo 向第二个潜在客户验证是否存在同类 SOP，而不是立即扩功能。
|
||
## 12.4 最终立项结论
|
||
建议立项
|
||
以“固件回归测试值守机器人”为第一产品，底层定位为 Storage LabOS 的单工位执行节点。第一阶段只证明三件事：测试能自动完成、主机异常能自救、失败能自动形成可用证据。完成后再扩展多工位和兼容性测试柜。
|
||
# 附录 A｜工作流与证据目录示例
|
||
## A.1 Evidence Bundle 目录
|
||
run-20260727-0001/├── manifest.json├── environment/│ ├── host.json│ ├── dut.json│ ├── firmware.json│ └── tool_versions.json├── timeline/events.ndjson├── device/│ ├── identify.json│ ├── smart-health.json│ ├── error-log.json│ └── telemetry.bin├── host/│ ├── system.log│ ├── kernel.log│ └── device-enumeration.json├── test/│ ├── stdout.log│ ├── stderr.log│ ├── metrics.json│ └── hashes.json├── oob/│ ├── heartbeat.ndjson│ ├── power-actions.ndjson│ ├── temperature.csv│ └── screenshots/├── recovery/recovery.json└── summary/ ├── failure-signature.json ├── ai-summary.md └── issue-draft.md
|
||
# 附录 B｜失败指纹建议
|
||
失败指纹应由稳定、可解释的字段组成，而不是直接使用大模型生成的文本。建议包含：
|
||
失败状态码与工作流步骤。
|
||
DUT 是否枚举、控制器/命名空间状态和链路信息。
|
||
关键错误码、内核事件、工具返回值和日志模板。
|
||
固件、主板、BIOS、OS、驱动和电源状态。
|
||
失败前后时间窗口内的温度、供电动作和恢复结果。
|
||
数据校验是否失败以及失败范围。
|
||
将结构化字段归一化后计算签名，再使用聚类或语义模型辅助合并相似问题。工程师可以手动拆分、合并和给簇命名，结果反哺后续规则。
|
||
# 附录 C｜参考资料与竞品官方来源
|
||
以下资料用于核对竞品公开定位与 NVMe 日志能力，访问日期均为 2026 年 7 月 27 日。竞品“缺口”属于基于公开产品定位的战略判断，不代表其不存在非公开或定制功能。
|
||
[1] ULINK DriveMaster 10 NVMe
|
||
[2] ULINK NVMe Test Suites
|
||
[3] ULINK PCIe-SSD Power Adapter Plus Gen4
|
||
[4] Teledyne LeCroy OakGate SSD Test and Validation Solutions
|
||
[5] SANBlaze SBExpress-RM5
|
||
[6] SANBlaze SBExpress-DT5CD
|
||
[7] Quarch Data Center & AI Solutions
|
||
[8] Quarch PyNVMe / PyNVMe3 Integration
|
||
[9] PyNVMe3 User Guide
|
||
[10] PyNVMe3 Developer’s Guide
|
||
[11] NVM Express: Error Reporting, SMART, Log Pages and Management
|
||
[12] NVM Express: Open Source NVMe CLI
|
||
[13] Teledyne LeCroy: OakGate PCIe 6.0 / NVMe Validation Announcement
|
||
[14] SANBlaze: Gen6 SSD Testing Announcement
|
||
# 附录 D｜术语
|
||
术语
|
||
说明
|
||
DUT
|
||
Device Under Test，被测设备，本项目主要指 SSD。
|
||
OOB / 带外控制
|
||
独立于测试主机操作系统的控制路径，用于 Power、Reset、画面、串口和传感。
|
||
Evidence Bundle
|
||
一次失败或任务的标准化证据包。
|
||
UCR
|
||
Unattended Completion Rate，无人值守完成率。
|
||
Failure Signature
|
||
由状态、步骤、日志、环境和设备特征组成的失败指纹。
|
||
Regression Worker
|
||
Storage LabOS 的第一款单工位固件回归执行模块。
|
||
LabOS
|
||
面向存储实验室的统一控制平面，管理任务、工位、证据、恢复和智能分析。
|
||
SOP
|
||
Standard Operating Procedure，企业既有标准操作流程。
|
||
— 文档结束 — |