本来这是一篇自己写的英语文章（所以吹水的时候更天马行空），想了想还是翻译回来了，顺便补充一些内容。

最近发生了些啥

最近在我的学校，信息服务挺不稳定的。

• 三月的时候，许多人在校内论坛上发帖说，他们用微信给校内网络账号充值，结果系统显示的充值结果比他们付的钱多了好多（大概 100 倍吧）。
• 后来微信的充值服务就被停掉了。因为自从有了微信充网费，很多人都想不起来以前的线下自助充值设备，所以慢慢地很多人都欠费上不了网了。
• 过了几天，校园网的外网计费系统也被停掉了，也就是说可以免费用网。再过了几天，计费系统被恢复了，但是只收月租费（不计流量费）。
• 然后他们发布了一条很隐蔽的说明，说这次故障是外购的计费软件里的 BUG 引起的。
• 在 3 月 20 日早上，拿着校园一卡通（下称校园卡）打开水、买早饭的人们发现自己的卡被刷卡机锁了 （那些没早起的人们应该没有受到影响）。
• 早上的时候没人知道这个问题有没有人在修，直到大概 11 点（该吃午饭了）的时候，学院的辅导员发了条通知说“各食堂有工作人员协助解锁卡片，请学生遵守现场秩序，不要慌乱”。而食堂也贴出了后勤集团的食堂管理部门的通知。解锁卡的过程很快很简单（重新写卡就行了），但是还是有很多人直接到了能用支付宝的食堂吃饭。
• 下午晚些时候，校园卡管理部门的官方说明发布了：这次是系统故障（在联盟上有人说这是个隐藏了 14 年的 BUG)。 联盟上网络中心的老师解释说他们想先把问题的解决方案定好、故障缓解了之后再准备官方说明。
• 在最近几个月校园网络很不稳定：在高峰时间的时候网站访问速度会变得很慢，甚至打都打不开。可能只有 2% 的时间是坏的（按总时间 24 小时计算的话），看起来不多，但用户肯定会有遭殃的感觉。
• 原因看起来很复杂。我个人认为，新的 DNS 服务器、旧的缓存服务器、新的防火墙系统、新的上联带宽和运营商链路问题都可能导致体验差。而且这些新设备上线之后都需要调试，这也是需要时间的。
• 在 5 月 12 日，网络中心发了一篇情况说明，他们认为经过十多天的观察应该没有问题了。其中提到故障点有对核心路由的 DDoS 攻击、新防火墙故障、上联链路调整对应的路由未优化等。
• 然而，近期校学生代表大会即将召开，相信许多学生代表会提出校园网相关的议题。我相信他们大多数可能都搞不懂为什么上个月发生了这些事情。

稍早前的网络简报提到的 DDoS 问题

为什么故障需要及时的透明

突然出了这么多情况，想必也是没人愿意，但它们的发生肯定是有原因的。不管怎么说吧，除了解决问题本身之外，让解决问题的过程透明也很重要。为什么呢？

现今信息技术正在成为生活中不可或缺的一部分，像供水和供电一样，变成了一种基础设施。这时候它已经一点也不“高级”了，人们对其的期望也会很高。另外，信息技术也还在高速发展（发展的速度按年算，而不是十几年），人们的期望也跟着这个速度在涨。这就对所有的信息技术服务者提出了很高的挑战，包括校园的信息部门。

这时候，或许他们在努力，但如果他们不及时说出来，有些人就会觉得“你们服务这么差，我正急着呢，你们还不努力”。两者的认识之间就形成了代沟。即便后来信息服务的问题解决了，别人的气头也过去了，你再怎么解释，效果也没有当时解释来得好。

“你们怎么一个月都修不好个扶梯，XX组走了没”

P.S. 有个好人提醒过我说，有时候体制里会有那种不干活的人。不过我觉得我的校区里的那些人还挺努力的。

如果信息服务的透明不够及时的话，还会有另一个问题：用户不知道他们是该打电话（那时候客服电话总会被打爆）还是该等。实际上大多数人是只会抱怨两句然后静静等修复的，并不会去报障——毕竟大家都很忙嘛，对吧？但是如果服务者就根本不知道这个问题存在呢？我们不知道他们知不知道有问题，而大多数人是不会无限地信任别人，认为“他们肯定在修了”。这样的情况如果持续发生，肯定会导致用户的不满意。

我想不到主动、及时的透明对一个努力工作的公共服务有什么坏处，所以我相信这件事情是应该做的。

对了，我还得强调一下，这里的透明是“及时的透明”。有时候这会带来个问题：当你发现之前你发现的故障并不是那个已经公布的原因的时候，你可能得“打脸”一下。只要每个人都很聪明，知道每个人都会犯错误，这其实并不是太大的问题，你只要把之前说错的话留在那里就好了。

在 Staytus 软件的演示里，有个问题从已解决又回到了故障的状态

工具和平台要有，但并没那么重要

有人可能会说，没有合适的工具来做这个事情。可能现在的工具没那么合适，但当你有想把事情做好的想法的时候，工具和平台并不是个问题。

在我的学校里有个很好的例子。学生资助中心一直在用论坛的方式来回答学生对发钱的疑问。尽管他们选的论坛没那么热门，我还觉得里面一些奖学金发放的进度帖子可以整理在同一个页面里，但是他们首先有了透明的主意，还做得很好。

信息服务跟这个比起来，还是有自己的特点的：

• 更必需，出了问题用户需要得到更及时的回应；
• 范围更广，线下的面对面服务、在每个地方做公告的成本很大；
• 更复杂，硬件、软件、配置、用户自身的设备都可能会出现问题。

要做到透明，用数字的方式可能会更好一些。

不过数字的方式，要做到不故障也需要功夫。我们可以把这个东西放在学校不容易故障的服务器上，而且内外网都要连。更好的解决方案则是：准备一个第三方（公网的 VPS）或者公共的服务（微博微信），然后认为我们故障的时候，他们不故障。听起来不大靠谱，不过要是大家都坏了，那就是中彩票了（估计五十年一遇吧），到那时候你肯定会迫不及待地去做“线下”的通知了。

嗯，只有线下通知可能还不够呢……

一个给信息服务准备的解决方案

搞信息服务的人其实也很忙的，这种时候客服不能只依赖于“我找你，然后你告诉我怎么回事”的模式。这时候可以引入一些自助服务的概念：把故障时的进度更新公开给每个人。当需要帮助的时候，我们自己看一下进度，就知道大概怎么回事，就能放心地等了。

其实我听说在线报修这个东西已经在找厂家做了，不过我觉得现在更有用的还是这个“状态页面”。

提到平台，我们一个一个来看吧。

• 网页，内容呈现时候自定义的范围很大，看起来很不错。不过不管它在浏览器里，还是在微信的内嵌浏览器里，他并没法自己推通知。
• 不过用户在遇到问题的时候，如果事情很严重，足以让他们自己去找故障状态的公布页面。所以推送就没那么重要了。
• 至于说遇到了大范围的故障，事后需要给每个人道个歉啥的，这个需求并不需要那么及时、频繁。这不在我们说的范畴里了。
• 微博看起来不错，可以选的。不过有两个问题：微博太公共了，有时这并不是个好事；而且，现在大家都在用微信，看最新消息谁看微博呢？
• 微信公众号的问题是它没法那么频繁地推送消息。当你有了频率限制，你可能就不想做到那么及时的透明了。而且，用户也不想看到一个频繁推送消息的公众号。
• 微信企业号看起来就没公众号的问题了，它不会限制群发次数。不过呢，选这个方案的时候，要记得几点：一是这个方案可能活不长了（被企业微信替代），而且它也不支持电脑和 Windows 手机。如果你不搞个网页的替代版，就不好叫“透明”了。
• 至于其它的推送途径，没什么人看邮件，短信贵，至于专门的手机应用？这样弄也太复杂了吧。

上面提到说，故障发生的时候，用户是有想法自己去查服务状态的。所以可以搞一个发布频繁、及时更新、没必要“推送”通知给每一个人的服务状态页面。

结论就是，可以搞一个：

• 放在自己服务器上的、单独的服务状态网页，
• 在各个主要的信息平台上设置链接，链接到这个网页（比如微信企业号和网络中心主页），
• 在有需要的时候（校级服务器崩了），可以快速部署到外部的 VPS 上并运行起来，
• 数据可以通过 Webhooks 或者 API 平台提供给其他平台使用，比如微博微信啥的。
  当然这么做也是有技术成本的，所以早期的时候选用现有的公共服务临时应付一下也是可以的。

“怎么发布”也很简单：可以提前制定几条说明的模板（比如用很流行的 investgating/identified/monitoring/resolved 模式），发布的时候再往模板里补充详细信息就好。也可以规定一些信息发布的规则，比如在故障发生时，至少每多少小时发布一次信息。

Google 的服务状态页面上，信息都是预先翻译好的模板，注意那句“我们有附加的英文信息”

我们还得有个人来做发布这件事情（我知道在中国大陆还是挺难的），或许得招个“technical writer”。不过我觉得在学校这个可以靠勤工俭学的学生来解决：他们先签个保密协议之类的东西，然后加到信息部门老师们的工作群里，平时静静不说话，如果出了故障，他就负责看群里的消息，然后套模板发状态更新。的确工作群里有些东西可能不大适合公开，所以说保密还是很重要的嘛。

当然了，如果老师们自己能在保证频率的情况下，自己发状态更新，也挺好的（不过他们也挺忙的）。

Staytus 的发布界面

选一个开源的解决方案

作为一个“没什么钱”的学生，自然会很喜欢折腾开源的东西。在状态页面这个东西上，自然也可以看看能不能用开源来解决。

我研究了一下，国内还是没有这类公共的“状态页面”的服务。比如说 Leancloud 自己做了状态页面。用这类服务的“国际版”也不是很好，毕竟可能会慢。所以我们除了找厂家，就只能自己搭咯。

我觉得吧，校园信息服务的状态页面最重要的东西是“更新”。总体的服务状态的红绿标识倒没那么重要。

对的，苹果这样子不大适合我们

研究了一下之后，我觉得能用的动态的、活跃维护的开源解决方案也没那么多。

• Cachet 是最热门的，不过现在还没那么完美，用的是PHP 和 MySQL/PostgreSQL （顺便要说的是，要用就用开发版，现在的稳定版没有分状态更新的功能）
• Staytus 还挺漂亮的，功能虽然简单但很完美，用的是 Ruby 和 MySQL，演示站点也很漂亮
• statuspage，不怎么热门，我也没仔细研究，这里举出来是因为它的作者说“Cachet 挺好的，我只是不喜欢 PHP，所以做了个 Python 的”

Cachet（开发版）

我知道有些人挺讨厌数据库的，所以也有用静态页面生成的方案。这些方案有是有，但他们还没那么完美，整套工作流程形成起来也不是那么容易。

• Netlify StatusKit 说自己是个"template to deploy your own Status pages on Netlify"，看起来改一下之后在哪部署都行
• 或者我们可以自己用 Jekyll 自定义一下主题和插件，就有了
  希望上面这些方案的介绍有点用吧。不管怎么说，你想做什么还是最重要的。

一点微小的工作

假如有这样一个页面的话，效果是下面这个样子的（注：图中的时间均为根据资料模拟的，不是官方消息，更不是准确时间！）

Staytus 首页示例 Staytus 计费故障示例 Staytus 校园卡故障示例 Staytus 维护示例