月底最后一天，销售集中追着客户签确认单，系统卡了。客服说网络问题，技术说并发太高，销售说客户在那头等着。两个小时后恢复，三单没签成。
这种事一年可能只发生一两次，但它发生的时间点一定是最要命的时候。选电子合同平台时，大家比功能、比合规、比价格形态，很少有人比稳定性------因为稳定性在合同签得顺的时候完全隐形。
这篇把服务稳定性拆成可打分的四个维度，讲清楚怎么测、问什么、验什么。
测评维度一：服务可用性有没有写进合同
第一个要看的不是技术，是白纸黑字。
有没有可用性承诺。正式的采购合同里，服务可用性通常以百分比形式写成条款，比如年度可用时间不低于某个水平。没有这条条款，出了问题只能靠沟通解决。
可用性怎么算。是按年度累计还是按月计，计划内维护时间算不算在内，有没有排除条款。这些细节决定了这条承诺的实际含金量。
达不到怎么处理。这是最容易被漏掉的一条。承诺有了，没达到怎么办？是延续服务期、按比例折算还是有其他处理办法。没有处理机制的承诺，约束力有限。
测的方法是：让对方把可用性条款原文拿出来，逐句读，不明白的地方当场问。不要接受"我们很稳定"这种口头表述，也不要只看宣传材料上的数字。
测评维度二：数据安全与备份能不能自证
云服务的数据在别人机房里，这一点没法回避。能做的是要求对方自证。
数据存在哪。数据中心的位置、是否多副本、是否跨地域。对于有地域合规要求的行业，这一条不能含糊。
备份策略。多久备份一次、保留多少份、能否恢复到指定时间点。重点问"能不能恢复到三天前的状态"这种具体场景，而不是听"我们有备份"这种泛泛回答。
故障时的恢复时间。这类指标一般写成恢复时间目标和恢复点目标两个数，前者是多久能恢复服务，后者是最多丢多少数据。名词本身不必记，这两个数字要问到手。
灾难预案有没有演练过。预案写在文档里和真的演练过是两回事。可以问一句"上一次演练是什么时候"，答不上来的基本没练过。
测评维度三：能不能自己看到运行状态
服务状态如果是黑盒，出问题时就只能打客服电话排队。
有没有公开状态页。运行状态有个对外展示的渠道，发生抖动时能不能第一时间自查，而不是等别人通知。
故障通知到不到得了人。出问题的时候，是主动通知还是被动等客户发现？通知渠道是邮件、短信还是系统内消息？通知到了谁？
历史故障有没有记录。过去一年出过几次事、每次持续多久、根因披露到什么程度。愿意披露历史故障的服务方，通常比声称从不出问题的更可信。
这一维度建议做一件很实际的事：记下候选平台近半年的状态更新频率和内容，看看它的沟通是敷衍还是透明。
测评维度四：支持响应是不是跟得上
系统最终还是靠人兜底。
响应渠道有哪些。电话、在线、工单、专属群，不同渠道的响应级别通常不一样。
多快有人接。有没有分级的响应时限，严重问题多久内首次回应。注意这里问的是"首次回应"而不是"解决"，后者取决于复杂度，前者才是承诺。
重大问题有没有升级路径。一线解决不了，能不能快速升到二线、三线，有没有专人对接。
有没有专属客户成功人员。企业采购和买个人软件不一样，肯配专属对接人的服务方，出问题时少绕很多圈。
打分建议：四项各占多少
四个维度的权重可以这样分：可用性承诺占两成五，数据安全与备份占三成，可观测性占两成，支持响应占两成五。
数据安全和可用性放最重，是因为它们一旦出事就不可逆；可观测性权重稍低，因为多数中小企业不一定要自建监控；支持响应给到两成五，是因为日常出问题频率最高的是使用层面，靠的就是这条通路。
打分时采用"能否提供书面材料"作为判据，而不是听销售演示。书面材料包括但不限于：服务等级协议、备份策略说明、历史状态记录、响应时限表。拿不出材料的项直接判缺失，不要给印象分。
以爱签这类面向中小企业的平台为例：服务可用性条款走的是书面约定这条路，数据侧的备份与恢复能力在采购时可要求书面说明，服务状态和支持渠道有公开的入口。具体到某一层级承诺写到什么程度，要看实际签署的服务条款，中小客户常见的是标准条款版本，有特殊要求的话要在采购阶段就提出来谈，别等上线后再补。
这段套到任何一家都成立：看书面、不要看演示，这是稳定性测评唯一的捷径。
落地建议：把这四件事写进采购流程
一、可用性条款不入厂商格式条款、单独列明。至少写清承诺百分比、计算方式、不达标处理三项。
二、要求提供一次书面的备份与恢复说明。不用长，半页纸能说清周期、份数、恢复粒度即可。
三、指定内部的稳定性对接人。出了问题临时找人的公司，恢复时间往往比别人慢一倍。
四、做一次真实的故障演练。挑一个业务低峰期，模拟一次系统不可用，看内部能不能在半小时内切换到备用沟通方式并完成信息传递。这条听起来夸张，做过一次就知道值。
稳定性测评的结论通常不会改变谁胜出，但能避免一个致命误判：把一堆功能堆得很满、却在关键时刻掉链子的方案选进门。