我们能停止使用正常运行时间百分比吗？
内容提要
文章批评了用“正常运行时间百分比”来展示服务可靠性的做法，认为这种数字（如99.9%和99.99%）看似相近，实际差异巨大，对普通用户不直观。作者建议在状态页面上改用更易懂的表述，如“过去30天受影响12小时”，并附上百分比，以便用户直接理解服务中断的实际时长。
延伸解读
百分比背后的非线性差异
文章指出，正常运行时间百分比看似相近，实则差异巨大。例如，99.9%与99.99%的差距并非0.09%，而是故障时间相差10倍。这种非线性关系对非专业人士极不直观，容易让人低估服务中断的严重性。作者类比地震震级，强调微小数字变化可能代表数量级的差异，提醒读者在查看状态页时需警惕这种误导性。
状态页面的受众已变
过去，状态页面主要面向基础设施工程师，他们熟悉“几个九”的行话，能快速解读百分比。如今，随着云服务普及，普通用户也频繁查看状态页面，但他们缺乏相关背景知识。作者认为，状态页面作为服务的公共界面，应适应更广泛的受众，而非仅服务专业人士。这反映了技术沟通中需考虑用户认知水平的普遍问题。
更直观的可靠性表达方式
作者建议在状态页面上同时提供“过去30天受影响小时数”和百分比，例如“12小时受影响（98.31% uptime）”。这种方式将抽象数字转化为具体时间，降低理解门槛，使用户能直接感知服务中断的实际影响。这一建议强调以用户为中心的设计，而非仅追求技术指标的精确性。
Q&A
为什么说正常运行时间百分比（如99.9%和99.99%）对普通用户不直观？
因为99.9%和99.99%看起来非常接近，但实际停机时间相差10倍。普通用户很难直观理解这种非线性差异，而基础设施人员因为常用“几个九”的简写，所以能快速把握。
作者建议如何在状态页面上展示服务可靠性？
作者建议在状态页面上同时展示受影响的实际时长和百分比，例如“过去30天受影响12小时（98.31%正常运行时间）”，这样用户可以直接理解停机时长，而不需要解读接近100%的数字。
文章中提到从90%到99%再到99.9%的可靠性提升难度如何？
文章引用Jason Gorman的观点，认为从90%到99%的可靠性提升难度与从0到90%一样大，而从99%到99.9%的难度又和之前一样大，说明越往后提升越困难。
为什么说正常运行时间百分比是“糟糕的界面”？
因为正常运行时间百分比是面向基础设施人员的标准化指标，但状态页面的受众已经扩展到普通用户，他们只想知道服务最近中断了多少，而百分比需要专业知识才能解读，因此对普通用户不友好。
文章中提到哪些服务经常出现停机？
文章提到GitHub、CI（持续集成）、AI、Slack等服务经常出现停机，作者因此频繁访问状态页面。
作者认为状态页面的主要受众是谁？
作者认为状态页面的受众不再仅仅是基础设施人员，而是越来越广泛的普通用户，因为停机影响到了所有人的日常工作。
