--- title: 中国云服务走向全球？先把 Status Page 搞定 description: 云服务出海与可用性透明度：为什么需要 Status Page。 canonical: https://yangpan.com/blog/status-page language: zh-Hans section: blog translation_key: status-page date: 2022-12-20 date_type: publication author: 杨攀 / Pan YANG sources: - label: 微信公众号「攀哥四十二」· 原文 url: https://mp.weixin.qq.com/s?__biz=MjM5NzY0NzAwMQ==&mid=2456881916&idx=1&sn=7d62bfe73053c1f0460d318b2b87203e&chksm=b1536d0a8624e41c2e979b9344c2c13d8b84710ac4bf680849f2b09ac237320d57e306bd5c2e&scene=21 --- # 中国云服务走向全球？先把 Status Page 搞定 云服务出海与可用性透明度：为什么需要 Status Page。 本文首发于微信公众号，原文链接见“来源与相关链接”。 近日，国内某某云的一次长时间故障引发了身边技术圈朋友们的激烈讨论。讨论主题极具多样性：有人关心赔偿方案，有人关心机房的物理设施健壮性，有人关心基于多可用区（AZ）下的高可用软件架构，还有人讨论厂商应该如何进行危机公关。但我的一位海外朋友马工（欢迎关注他的公众号），他的关注点却非常独特，他习惯性的搜索并查看了该云的 Status Page 页面，发现在事故发生后，按当时的聊天截图，至少 5 个小时以上的时间，该云的 Status Page 页面没有任何关于事故的信息披露，服务状态也一直显示可用（未发生故障）。 借此机会，让我们聊聊什么是 Status Page？真正有意义的 Status Page 为什么如此重要。 ## 什么是 Status Page？ StatusPage.io 是由美国丹佛的创业公司 Dogwood Labs Inc 于 2012 年开发上线的一个基础设施服务，一句话描述就是：当你的在线业务宕机时，StatusPage 允许你和你的客户进行沟通，告知他们当前服务的状态和问题处理进展。业务正常服务状态下，客户也可以查看当前服务状态是否正常。同时，客户也可以查看这一业务所有历史上的问题发生和处理记录。 2016 年 7 月，开发者服务巨头 Atlassian 在上市后的第一批收购计划中，购入了 StatusPage 并将其改名为 Atlassian Statuspage。 让我们以 GitHub 为例，看看一个典型的 Status Page 页面： ![GitHub Status Page 的当前状态页面](https://assets.yangpan.com/blog/status-page/01.webp) 根据 Statuspage 官方的介绍，Statuspage 服务的主要价值包括： _**“降低互联网服务商在宕机情况下和客户沟通的成本”**_ 如何降低沟通成本呢？ 第一种情况：当互联网服务商因为故障宕机或者被 DDoS 攻击时，客户完全不知道发生了什么，客服电话被打爆，客户不断的轮询询问故障何时恢复，客户经理要一遍一遍的向每一个客户同步服务进展。这时，如果你有一个 Statuspage 服务，客户可以在第一时间，通过 Email / SMS / Slack / Webhook / Twitter / Support Site / RSS 等多种渠道收到通知消息。在故障恢复过程中，客户可以随时自助查看服务恢复的进度和服务商披露的系统修复进展详细信息。 ![GitHub Status Page 的状态更新订阅窗口](https://assets.yangpan.com/blog/status-page/02.webp) 第二种情况：客户调试接口、服务或者使用 SaaS 产品时出错，经常会询问技术支持和客服团队：你们的系统现在可用吗？有故障吗？这时候如果有一个 Statuspage 页面显示系统服务状态，客户/开发者完全可以自助进行排查，如果系统服务一切正常，先从自己一侧入手分析解决。这就大大降低了服务商的支持成本。 虽然 Statuspage 服务可以降低沟通成本，但这只是最表层的价值，Statuspage 的第二个价值，也是最核心价值，是： _**“与客户建立信任关系”**_ 君不见，各家互联网云服务商，无论是 IaaS、PaaS 还是 SaaS 服务商，最常被客户询问的一个问题是：你们服务稳定吗？现在可用吗？出故障了吗？如果服务商回答：没有故障。客户常常是半信半疑的，甚至在很多时候，客户比服务商能够更敏锐，更频繁的感知到故障的发生。这时如果服务商没有一个公开、透明展示自己服务状态信息的地方，给客户留下的印象就会是：不稳定、不透明、有猫腻。 有时候，作为服务商，公开、透明的公布自己遭遇的故障、分析排查过程、恢复步骤，可以大大加深客户对服务商的信任。**从客户角度看，一个能够在发展中快速成长、进步，有能力清楚的分析解决自己问题，不重复掉在同一个坑里的供应商，才是更值得信任的供应商。** ![GitHub Status Page 历史页面中，清晰的记录着历史故障](https://assets.yangpan.com/blog/status-page/03.webp 'GitHub Status Page 历史页面中，清晰的记录着历史故障') ## 国内外云服务 Status Page 现状调研 我选取了一些国内外典型的基础设施服务商，来看看他们是如何提供 Status Page 的： ![国内外云服务 Status Page 现状调研表](https://assets.yangpan.com/blog/status-page/04.webp) 注 1：Stauspage 指 statuspage.io 已经于 2016 年 7 月被 Atlassian 收购。Statuspage 是目前业界事实上的状态服务页标准。这里也不得不赞叹下全球化互联网公司对业内最佳实践的认可和践行。 注 2：全文中 Status Page 泛指服务状态页面服务，StatusPage 指被并购前的 statuspage.io 的商标，Statuspage 指 Atlassian Statuspage 的商标。 可以看到，国内只有阿里云（前文所说故障的主角）提供了 Status Page 服务，但我并没有查到其在显要位置的入口，在故障发布后，经过相当长时间才“手动”更新了故障状态。同时，也没有提供任何公开的沟通方式供大家订阅（国内云服务内置的故障报警服务不在本文讨论范围内）。 再看看腾讯云和华为云，我经过中英文多种关键词组合搜索，均未找到相关页面。 相较之下，GitHub 和 Vercel 各方面都堪称典范，Vercel 甚至在启用不同域名的基础上，vercel-status.com 还使用了与 vercel.com 不同的 DNS Name Server 服务商。 ![vercel-status.com 的 WHOIS 查询结果](https://assets.yangpan.com/blog/status-page/05.webp) 国内目前没有主流的 Status Page 的三方服务商，但是可以用诸如“观测云”（guance.com）这类可观测服务商的产品快速构建一个 Status Page，比如： ![用观测云构建的 Status Page 示例](https://assets.yangpan.com/blog/status-page/06.webp) ## 为什么国内服务商不重视 Status Page？ **理由一：家丑不外扬** 服务出了问题，悄悄地解决，怎么能让全世界知道，而且还能随时追溯历史？ **理由二：留下操作空间** 客户没发现等于没发生，外部可用性指标又提高了。 **理由三：产品不足服务补** 产品质量不好，就多多投入技术支持和客服，这样和客户的沟通增加了，客户关系也提升了。 **理由四：真的还做不到高可靠** 这可能是最无奈也最现实的原因了，由于激烈的竞争，各位服务商的研发工程团队，投入多少资源，有多大能力可以把自己的服务做得坚如磐石呢？如果可以做到，展示一个漂亮的 Status Page 历史记录不也是一种勋章吗？ ## 上价值 Status Page 是一面真实的镜子，它能照出产研团队真实的工程能力，它能照出服务商真实的服务承诺。Status Page 真正上线，才是服务商愿意通过外部监督勇敢面对自身质量问题的开始。 最后，真心希望国内各公司能够不断提升产品的基础质量，更加重视开发者体验，尊重行业最佳实践。 这里有请各位云厂商，为了鞭策自己向前发展，逐步具备国际化竞争力，先上 Status Page 为敬 也只有这样，才能让我们的产品服务真正走向全球。 CC：阿里云行癫、华为云张平安、腾讯云汤道生 **Status Page 很简单，下决心公开 Status Page 很难！** ## 来源与相关链接 - [微信公众号「攀哥四十二」· 原文](https://mp.weixin.qq.com/s?__biz=MjM5NzY0NzAwMQ==&mid=2456881916&idx=1&sn=7d62bfe73053c1f0460d318b2b87203e&chksm=b1536d0a8624e41c2e979b9344c2c13d8b84710ac4bf680849f2b09ac237320d57e306bd5c2e&scene=21)