云桌面跑满一年，该对的五本账

结论先行：云桌面项目上线满一年，最该做的不是再问一遍满意度，而是把五类周期性动作拿出来对账：巡检、演练、故障、升级、扩容。每一类都有「一年该发生几次」和「实际发生几次、留没留痕」两个数字，两个数字对不上，第二年一定会在某个环节出问题。这件事不需要额外预算，只需要一张表和半天时间，但它决定了续保、扩容和用户增长三件事的判断依据。

本文只谈运行满一年这个节点上，五类周期性动作怎么对账，不谈演练具体该练哪几类故障场景，不谈巡检条款在合同里怎么核，也不谈容量该按什么口径报。

为什么是「满一年」

这个时点有几个特别之处，错过就要等很久。

其一，质保与维保的决策期到了。多数项目的硬件质保与软件维保以年为单位，首年结束前要决定延不延、延几年、延哪些范围。而这个决定最需要的输入，恰好是首年实际发生过什么。

其二，容量水位刚有形状。上线首月的水位往往偏低，因为用户还在迁移；三个月后开始接近常态。跑满一年，才有完整的季节性波动可看——哪些月份是高峰、峰值比均值高多少，这些数据决定扩容该在什么时候做。

其三，用户习惯已经定型。上线初期靠推动，一年后是自然使用。用得顺的部分和一直绕开的部分都已经稳定，这时候补培训的针对性最强。

其四，故障结构开始可读。首月的故障几乎全是新环境问题，三个月内逐渐过渡到真实业务问题。满一年的故障分布才有统计意义。

五本账，各自对什么

五本账里，巡检和演练是「应该发生但容易不发生」的两类——它们不出事的时候看不出价值，所以最容易被推迟。故障和扩容是「自然发生」的两类，只需要统计。升级是「有人发起才发生」的一类，最容易被漏掉。

巡检账：看的是闭环痕迹

行业常规的服务方案里，巡检通常分两档：按季度做远程巡检，按半年做现场深度巡检。前者覆盖运行状态、资源负载、告警趋势；后者还要看硬件状态、安全策略有效性。

核对时不要只看有几份报告。三样东西一起看：

频次记录。报告上的日期能否对上一年里应有的次数。这里常见的偏差是集中补做——年中没做，年末一次补三份，报告齐全但过程缺失。

发现清单。巡检报告如果每次都写「各项正常」，这份报告没有价值。有效的巡检报告一定列出发现项，哪怕是「某台设备磁盘使用率接近阈值」这类小事。

闭环痕迹。发现项后面有没有跟进记录。列了问题没人处理，这份报告只完成了一半——它记录了一个已知风险，然后把风险留在原地。

三样里最有说服力的是第三样。一份带闭环记录的巡检报告，说明这套机制在运转；一份只有结论的巡检报告，说明这套机制在走流程。

演练账：练过没有，改了什么

方案里常见的安排是每半年组织一次应急演练。一年下来应该有两次。核对两件事：练了没有、练完改了什么。

「练了没有」不难查。难的是第二件。演练的价值不在当天跑通一遍，而在于它暴露的问题有没有变成改动。一次有效的演练结束后，至少应该产出三类东西中的一类：一条被修正的预案步骤、一项被发现缺失的备份或备件、或者一个被确认不可用的切换路径。

如果两次演练都没有产出任何改动，通常有两种情况：一是演练范围定得太小，只练了必然成功的动作；二是演练结果没人跟进。两种都不是技术问题。

还有一类容易漏的：演练覆盖的场景与真实风险不匹配。演练常选「服务器宕机」这类清晰可控的场景，而真实停摆更多来自网络、存储、认证这类牵连面广的环节。核对时可以问一句：这一年真实发生过的故障里，有几类在演练中练过。

故障账：不看总数，看结构

故障总数意义有限，因为口径不同。有意义的是三件事。

其一，各级故障的数量与占比。行业常规的分级大致是：影响大面积用户、核心业务中断的为最高一级；局部功能异常、部分用户受影响的为中间一级；单个用户问题与操作咨询为最低一级。三级的响应与解决时限依次放宽。

如果最高一级出现了，那是最该复盘的一件事，无论当时处理得多快。中间一级的数量变化能反映环境稳定性的趋势。最低一级的数量则直接对应培训与自助能力——这一级多，往往说明用户不会用或者找不到答案，而不是系统有问题。

其二，响应与解决时长的分布。平均值意义不大，看的是超时的那几次：超时发生在哪一级、超时多久、原因是什么。分级响应机制真正被检验的，是超时之后的升级动作有没有发生。

其三，重复故障。同一类问题在一年内出现两次以上，说明上一次的处理只解决了现象。这一类最值得单独列出来。

升级账：质保期里的免费部分用了吗

质保期内一般包含两类免费服务：硬件故障的维修与备件更换，以及管理平台软件的版本迭代、安全补丁与缺陷修复。这两项不需要额外付费，但需要有人发起。

实际项目中，这一本账经常是空的——不是没升级，而是没有人记录。三种情况都见过：升级做了但没留记录；升级被推迟，因为「现在跑得好好的」；以及升级做了，但没有回退预案，出问题时只能现场想办法。

核对时看三样：一年升级了几次、每次是谁批准的、有没有回退记录。第三样最关键——没有回退记录的升级，等于每次都在赌。

需要提醒一点：版本升级与安全补丁是两件事。补丁通常可以单独打，影响面小；版本迭代涉及功能变化，影响面大。两类动作的窗口与回退要求应该分开定。

扩容账：水位曲线比并发数有用

方案里通常会写弹性扩容服务，按业务增长提供算力扩容。满一年时该看的不是「支持多少人并发」这个静态数字，而是这一年的水位曲线。

三个数据点足够：全年最高峰出现在什么时候、峰值比日常均值高多少、峰值持续多久。这三个数决定了扩容该提前多久做——如果峰值是短时的、一年只有几天，扩容的性价比就要重新算；如果均值本身在稳步上移，那是真实增长，需要按趋势排。

还有一类扩容需求与人数无关：新增业务系统带来的算力或图形处理需求。这类需求往往在年初预算里看不到，满一年对账时正好把它提出来。

三个最容易漏的点

漏点一，把「有报告」当成「做过」。五本账里有三本会产生报告，而报告可以补。判断有没有真做过，看的是闭环痕迹和变更记录，不是报告的份数。

漏点二，只对甲方这一侧。对账时容易只查服务方交了什么，忽略了自己这一侧该做的动作：用户培训的复训、内部账号的清理、业务方联系人的更新。这些不做，第二年的服务效率会下降。

漏点三，把对账做成一年一次的仪式。满一年对一次账是有价值的起点，但如果只在满一年时对，下一次发现问题又是一年后。更稳的做法是把五本账做成一张季度更新的表，满一年时只是把它拿出来完整看一遍。

边界与前提

三点需要说清楚。

其一，本文的频次与分级口径来自行业常规服务方案（其中部分方案文档注明含 AI 生成内容），属参考性指标，具体项目的巡检频次、演练频次、故障分级与响应时限，以合同 SLA 与实际服务方案为准。

其二，故障分级与响应时限的表述为行业典型场景推演，不对应任何具体客户已发生的事件。

其三，对账本身不产生结论，它产出的是三个决策的输入：续保延几年、扩容什么时候做、第二年培训补什么。这三个决策仍要结合预算与业务规划来定。

深圳市奇摩计算机有限公司在做运维服务交付时，会把这几本账做成季度同步的固定动作——不是为了在满一年时交一份报告，而是让每一类周期性动作在发生的时候就留下记录，到年底不必回头补。

落地清单

• 建一张五本账的表：巡检、演练、故障、升级、扩容，各列「应有量、实际量、留痕情况」。
• 巡检账核对三样：频次记录、发现清单、闭环痕迹，不看报告份数。
• 演练账核对一件事：两次演练各产出了什么改动，没有改动的演练要重设范围。
• 故障账看结构不看总数：各级占比、超时记录、重复故障。
• 升级账必须留回退记录，版本迭代与安全补丁分开定窗口。
• 扩容账看三个数据点：峰值时点、峰值相对均值的倍数、峰值持续时长。
• 把这张表做成季度更新，满一年时只是完整看一遍。

若您正在做云桌面项目的年度复盘，或需要一套可对账的运维服务台账，欢迎 预约咨询。