评估口径：这篇文章面向准备进入POC或正在制定验收用例的企业团队，重点讨论如何把“生产场景验证”写成可执行脚本、证据表和复验判定，不把演示环境跑通等同于上线通过。
容器平台POC最容易出偏差的地方，是把“能安装、能创建应用、控制台好看”当成通过标准。对企业平台负责人来说，POC真正要回答的是：这个K8s容器平台在生产发布、多环境治理、权限审计和问题定位上，是否能留下足够证据支撑采购判断。
因此，POC不应只是一场产品演示，而应是一组可执行脚本。每个脚本都要说明前置条件、测试动作、预期结果、证据截图或日志、责任人和复验规则。这样即使某个场景失败，团队也能判断是环境问题、用例问题、能力缺口，还是需要进入采购评审的风险项。
POC前置条件先写清楚
在设计容器平台POC脚本之前，先确认本轮验证的边界。边界不清，后续结论就容易变成“供应商说可以、业务觉得不够、采购无法判断”。
POC启动前至少确认：
- 参与角色：平台团队、应用团队、运维团队、安全团队和采购评审人员分别负责哪些验证项。
- 验证环境：本轮使用哪个集群、哪些命名空间、哪些网络入口、哪些镜像仓库和账号权限。
- 样例应用：选择一个接近生产流程的应用，而不是只使用完全无业务语义的演示样例。
- 通过标准：每个动作的预期结果、失败判断和证据要求要提前写入脚本。
- 范围排除：哪些能力本轮不验证，哪些问题只记录为后续项目交付项。
这一步不是流程负担，而是为了让POC结果可比较、可复验、可进入采购评审。如果团队还在梳理容器平台能力边界，可以先阅读 容器与Kubernetes分类 下的选型、K8s生产治理和多集群相关文章，再把关注点转化为POC脚本。
测试脚本要覆盖生产关键动作
POC脚本不需要把平台所有菜单都点一遍，更重要的是覆盖生产使用中最容易影响决策的动作。建议把原本分散的“发布、多环境、权限、可观测、交付边界”压缩成一套脚本组，每组都能独立得出通过、不通过或需复验结论。
| 脚本组 | 测试动作 | 预期结果 | 证据截图 / 日志 | 责任人 |
| 应用发布 | 使用指定镜像部署样例应用，完成访问验证和版本变更 | 应用可访问，版本、环境和操作人可追踪 | 部署记录、访问截图、版本变更记录 | 应用负责人 |
| 失败回退 | 使用错误镜像或健康检查失败版本触发异常，再执行回退 | 平台能提示异常原因，回退后服务恢复 | 事件日志、回退记录、恢复截图 | 平台团队 |
| 多环境策略 | 将同一应用按测试和生产两套策略部署到不同环境 | 权限、资源配额和发布要求可区分 | 环境配置截图、策略命中记录 | 平台团队 |
| 权限审计 | 使用平台管理员、应用负责人、安全审计三类角色分别操作 | 角色能完成必要动作，不能越权访问其他范围 | 权限配置、拒绝访问提示、审计记录 | 安全团队 |
| 问题定位 | 触发一次可控异常，查看事件、日志、指标和最近变更 | 团队能从现象定位到可能原因，并保留处理记录 | 告警、日志、事件和处理记录 | 运维团队 |
表格中的“责任人”不是追责标签，而是为了明确谁来执行、谁来确认、谁来补证。POC现场经常出现“动作做了，但没人保存证据”的情况，最后很难支撑采购评审。
测试动作要包含失败路径
只验证成功发布，无法说明平台能不能应对生产问题。建议至少保留一个可控失败动作，例如错误镜像、资源不足、健康检查失败、权限不足或发布策略不符合要求。
失败路径的目标不是制造障碍，而是确认平台是否能提示原因、阻断风险、保留审计记录并支持恢复。对采购评审来说，一次有证据的失败复验，往往比一场顺利演示更能说明平台是否适合进入下一阶段。
证据采集表比功能清单更重要
POC验收不能只保存会议纪要或演示截图。更稳妥的做法，是把每个脚本动作都落到证据采集表中，确保结论能被复盘。
证据采集表建议包含：
| 字段 | 填写要求 | 常见问题 |
| 脚本编号 | 对应具体测试动作，便于追踪 | 只写“发布测试”，无法定位动作 |
| 前置条件 | 环境、账号、镜像、网络和样例应用状态 | 未说明前置条件，失败原因无法判断 |
| 预期结果 | 提前定义通过标准和失败判定 | 事后按演示结果反推标准 |
| 实际结果 | 写清成功、失败、部分成功或未执行 | 只写“已验证”，没有细节 |
| 证据位置 | 截图、日志、事件、审计记录或会议附件 | 证据散落在聊天工具里 |
| 责任人 | 执行人、确认人和补证人 | 复验时没人负责 |
| 复验结论 | 通过、需复验、不通过或转入项目风险 | 失败项没有后续处理 |
如果POC周期较短，也应至少保留关键脚本的截图、日志和审计记录。尤其是权限、发布回退、异常定位和多环境策略这类容易在正式上线后引发争议的内容，不能只靠口头说明。
复验判定要区分失败类型
POC出现失败并不等于产品或路线一定不可用。关键是要判断失败类型，并给出复验口径。
常见失败项可以分为四类：
- 环境或准备问题：例如账号权限未开、镜像不可拉取、网络策略未放通。修正前置条件后可复验。
- 用例设计问题：例如脚本动作与本轮范围不一致，或预期结果写得过宽。需要改脚本后重新执行。
- 能力缺口问题：例如权限隔离、审计证据、回滚链路或多环境策略无法满足核心要求。应进入采购评审风险项。
- 范围外问题：例如本轮POC不覆盖的深度集成、二次开发或后续项目实施内容。应记录但不直接作为本轮不通过依据。
这种分级能避免两个极端：一是因为单个非核心问题全盘否定；二是把核心能力缺口包装成“后续再说”。复验必须回到脚本和证据，而不是回到口头解释。
POC结论分级要服务采购判断
POC最后不应只有“通过”或“不通过”。更有用的结论，是能进入采购评审、项目计划和后续谈判的分级结果。
| 结论分级 | 判断口径 | 后续动作 |
| 通过 | 核心脚本完成，证据齐全，失败项不影响本轮判断 | 可进入采购评审或项目实施准备 |
| 条件通过 | 核心场景基本满足，但存在需补证或限期整改项 | 明确复验时间、责任人和采购附加条件 |
| 需复验 | 关键脚本未执行完整，或失败原因无法归类 | 补齐前置条件后重新执行指定脚本 |
| 不通过 | 关键生产场景长期无法满足，且影响采购目标 | 调整选型、范围或技术路线 |
| 范围外记录 | 与本轮POC目标不直接相关，但影响后续交付 | 写入项目计划或合同交付边界 |
这类分级可以帮助采购、技术和业务团队在同一张表上讨论问题。对于还处于选型前期的团队，也可以阅读 容器平台选型相关文章 ，把能力判断先转化为POC脚本，再决定是否进入正式项目。
下一步建议
容器平台POC的价值在于把采购判断从“看演示”推进到“看证据”。建议企业先选择一个典型应用、两类环境、三类角色和若干关键脚本，形成可执行、可截图、可复验的POC记录。
进入评审前，重点检查脚本是否覆盖生产发布、失败回退、权限审计、多环境策略和问题定位；证据是否包括截图、日志、事件、审计记录和责任人；失败项是否已经分级并写明复验动作。只有这些内容清楚，POC结论才真正能支撑采购判断。
常见问题
容器平台POC脚本怎么写？
建议按“前置条件、测试动作、预期结果、实际结果、证据位置、责任人、复验判定”来写。脚本不必覆盖所有功能菜单，但要覆盖生产发布、失败回退、权限审计、多环境策略和问题定位等关键动作。
容器平台POC哪些证据必须留存？
至少应留存部署记录、访问截图、版本变更记录、异常事件、回退结果、权限配置、越权阻断提示、审计记录和问题处理记录。证据要能对应具体脚本编号，避免只保存零散截图。
POC失败项如何复验？
先判断失败属于前置条件、用例设计、能力缺口还是范围外事项。前两类可以修正后复验；能力缺口要进入采购评审风险项；范围外事项应记录到后续项目计划，不能混入本轮通过标准。
POC结论如何进入采购评审？
把结论分为通过、条件通过、需复验、不通过和范围外记录，并附上脚本编号、证据位置、责任人和整改期限。采购评审不只看演示感受，而应看核心场景是否有证据支撑、失败项是否可控。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/122/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
