刻度云上线快一周，累计下载四百八十六次。

付费账户十八个。

十八张订单，一百七十八元两角，加上按单结算的一百一十元五角二分奖励，一共两百八十八元七角二分。

周衡将这笔收入单独记了一行，随后打开大家反馈最多的通知设置。

十八名付费用户里，有七个人关闭了夜间提醒，三个人把邮件通知全部停掉。免费用户的数据更差，真正连续接入超过二十四小时的实例不到下载量的一成。

“河堤上的猫”昨天说，页面好用，就是手机夜里响得太勤。

第一批客人已经掏了钱，周衡想让他们用得更舒服。

周衡把这几天收到的反馈放进表格。短暂网络抖动、定时任务启动、机器正常重启、测试环境停机，都会被当前版本当成需要处理的事件。每一条判断单独看都有依据，叠在一起，却像一个遇到任何声音都拉响警报的人。

真正的故障夹在中间，反而更容易被忽略。

他没有先加一个总开关让用户自己解决。

第一步，是把告警持续时间与恢复情况放回事件里。接口慢两秒后立即恢复，先进入观察状态；持续超过用户设置的时间，或者在短时间内反复出现，才升级为需要确认的事件。

第二步，是给计划内变更留窗口。用户登记发布或维护时间以后，相关告警仍然保存，但不在第一时间发出红色通知。

第三步，是把测试、预发布和生产环境分开。测试环境默认不在深夜给人发短信，除非用户明确要求。

这些调整让页面安静下来，也带来另一种风险。

如果阈值设得太宽，真正的问题会被延后发现。

周衡没有替所有人选择一个所谓最佳数字。他在默认值旁边写清代价，被压住的原始记录仍可展开查看。

0.1.2版本发布后，“河堤上的猫”跑了一个晚上。

原来十几条红色事件变成两条观察记录，没有发夜间通知。凌晨三点一次持续六分钟的接口异常仍然升级成事件，并在恢复后保留完整时间线。

对方早上回复：“终于不像消防车停我家楼下了。”

另一位用户提醒，维护结束以后也该及时恢复监控。周衡给维护窗口补上了结束按钮，再用测试数据跑过一遍。

“这个版本我留着用了。”对方回复，“之前那套收费几十块，还得我自己配一堆东西，你这个打开就能看。”

周衡把这句话看了两次。

周衡把这句反馈标成已解决，继续联系其他付费用户。

有人只回“还行”，有人根本不回。一个做内部工具的开发者说，他买付费版只是为了支持独立产品，尚未真正接入生产。另一个用户连续用了五天，却从未点过“接手”按钮，所有事件最后都由系统自动恢复。

周衡问：“你们没人值班？”

“就我一个人。告警发到邮箱，看到就看，看不到第二天再说。”

“那你为什么还保存时间线？”

“老板偶尔会问昨晚是不是出过问题。我得找个东西证明，不是我早上才把服务打开。”

这不是周衡最初设想的用法，却是真实需求。

他在反馈表里新增一列：谁需要结果。

开发者本人、合伙人、老板、客户、值班团队。相同的一条告警，对不同的人意味着不同的事。有人要立刻处理，有人只需要第二天看到报告，还有人最在意故障发生时到底谁接过手。

下午，一个新用户在问题区上传了一份表格。

文件名很普通：《刻度云体验问题》。打开后共有十七项，每项都写了复现步骤、影响对象和建议优先级，没有一句“体验不好”之类的空话。

第一项不是误报，而是首次接入失败后，页面只显示一串技术错误，使用者不知道该找网络、权限还是脚本。

第四项指出，事件显示“已恢复”，但没有区分系统指标恢复和人工确认恢复。

第九项问，如果两个人同时点了接手，最后谁负责跟进。

第十四项更直接：报告可以导出，却没有接手人、处理时长和未完成事项，拿给管理者也看不出这次事故有没有人负责。

周衡从头看到尾，又看了一遍用户资料。

账户实名是孟冉，付费时间在两天前，也是九块九，没有使用任何优惠码。她接入的是一套个人测试环境，事件量不大，却几乎点过每一个功能。

周衡在问题区回复：“方便沟通半小时吗？只讨论你主动提供的测试环境，不需要业务数据。”

十分钟后，孟冉发来一个会议链接。

视频接通时，她身后是一面空白墙，桌边放着一只已经凉掉的咖啡杯。

“十七项都能复现？”周衡先问。

“前十五项可以。后两项是我按企业使用场景推出来的。”

“你做技术？”

“做B端产品。”孟冉说，“写过几年需求，也替销售收拾过几年承诺。你这个版本看得出来是工程师做的。”

她说着，点开了报告页：“底子挺利落，我才愿意给你列这张表。”

周衡把表格共享到屏幕：“先看第四项。指标恢复和人工确认，我准备拆成两个状态。”

“拆状态没问题。但谁会去点人工确认？”

“值班人。”