试运行那两周，每天盯哪几个数

结论先行：试运行这两周，要回答的问题不是"云桌面能不能用"——能开机、能打开文件，上线当天就能证明。真正要回答的是"什么情况下会不能用"。这个问题靠四个数连续观察两周来答：登录成功率、开机到可操作的时长、外设与业务软件的可用率、并发峰值下的响应。还有一条硬要求：这两周里必须覆盖至少一个真实的业务峰值日，否则观察结果说明不了什么。

试运行不是试用，要有观察清单

很多项目的试运行，实际操作是找几个部门的人先用着，两周后开会问一句"大家觉得怎么样"。这种方式的结论通常是"还可以，有点卡"，既不能作为验收依据，也找不出真问题。

把它做成有清单的观察，动作就变了：每天有几项固定要看的数，异常要记录当时的场景，周末汇总一次趋势。看着是多了点活，实际省的是后面上线初期的救火。

四个数，各自看什么

四项里，第三项最容易被低估。前三个数是技术指标，能靠监控自动采集；第四项要靠人一项一项试——打印机能不能打、扫描仪能不能扫、U 盾能不能识别、专用业务软件能不能启动。这些恰恰是上线之后投诉最集中的地方，因为它们在试运行期间没被逐项验过。

做法可以很土：把外设和软件列成一张表，每行一个型号或一个系统，每列一个测试项，试运行开头一周全部走一遍，打完勾存档。这张表后面会变成验收材料和运维交接材料的一部分。

必须覆盖一个峰值日

两周时间如果全落在业务平峰期，观察到的是一套偏乐观的数。云桌面这类系统的特性是：平时怎么都好，一到集中上班时段就开始排队。

所以试运行的日历要刻意安排，让它至少包含一个真实的业务高峰日——月初结算、周一上午、季度末这类节点都算。峰值日当天要做的不是加大监控频率，而是记录三件事：同时在线的最高值、该时段响应时长的变化曲线、以及有没有出现排队或连接失败。这三件事记录一次，比平峰期记两周有用。

如果项目时间赶不上自然峰值，一个替代办法是组织一次压力演练：让参与试运行的用户在同一时刻集中登录。它不能完全替代真实峰值，但比没有好，而且能把明显撑不住的配置提前暴露出来。

谁来记、记完给谁看

观察这件事最常见的失败方式是：数据有人采，但没人看。避免的办法是给这两周定一个极短的节奏——每天早上十分钟站会，只看前一天的四个数和一个异常清单；每周出一页纸，写清趋势和待办。

站会的主持人不宜是跑技术的人，宜是项目经理。技术同事容易把话题带进细节，站会就开不完了。项目经理只问三句：昨天的数有没有异常、异常的结论是什么、今天要做什么。十分钟足够。

深圳市奇摩计算机有限公司在云桌面项目里承担交付时，会给试运行阶段配一份固定的日观察表，把四项指标和异常清单固化成模板。表格本身不复杂，作用是让这两周每天都有人真的看数。

什么情况下应该暂停推广

试运行还有一个作用：给项目一个体面的刹车点。出现下面几种情况，继续往前推不如先停下来。

• 同一类异常反复出现且找不到原因。比如某个部门的用户天天登不上，每次都靠重启解决。这类问题上线后会按人数放大。
• 外设清单里关键项过不去。核心业务依赖的那台专用设备如果不能稳定工作，整个部门的推广就失去意义。
• 峰值日的响应下降超过可接受范围。具体阈值要在项目开始前和业务方一起定，事后再定就成了扯皮。
• 用户侧的抵触集中在操作方式而不是性能上。这说明培训与适配没做完，再推只会把问题放大成情绪。

暂停不等于失败，它是把问题留在小范围。真正难看的是带着已知问题全量上线，然后在头一个业务高峰日集体爆发。

本文只谈试运行阶段该观察哪些运行指标、怎么安排观察日历，不谈验收阶段性能测试的测法，也不谈试运行文档该怎么写、交付物清单有哪些。文中指标与阈值为通用做法举例，具体以项目验收标准与合同约定为准。

试运行只有两周，能发现的问题有限，所以要挑对要看的东西。把四个数盯住、把一个峰值日覆盖到，两周的结论就站得住。预约咨询，可以按你的业务节奏把观察清单和阈值一起定下来。