永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么要让公开状态页面保持诚实
状态页面的存在是为了快速回答一个具体的问题：我所依赖的东西现在是否正常工作，如果不正常，服务商是否已经知道。这是一个狭窄而有用的目的，而且只有当页面足够贴近现实、在真正要紧的那一天（也就是出故障的那一天）值得信任时，它才能发挥作用。一个连续两年都显示全绿的状态页面，要么描述的是一个真正完美无缺的系统（这很罕见），要么描述的是一个按某种与客户实际体验关系不大的时间表来更新的页面。
状态页面的价值几乎完全集中在最不方便如实更新的时刻：在事故进行中，人们的本能是先观望一下，看看问题是否能很快解决，然后再决定是否公开承认。这种本能可以理解，但它也恰恰与让状态页面有用的做法背道而驰。一位在自己这边遇到故障时查看状态页面的开发者，希望尽早知道问题出在自己这边还是服务商那边。一个要等到事故被完全弄清并解决后才确认事故的页面，回答这个问题时已经太晚，没有多大价值。
我们认为，诚实的做法是把状态页面当作一种提供给客户使用的运维工具，而不是营销门面。这意味着在真实事故发生时就发布真实的事故信息，即使还没有掌握所有细节，并随着情况逐渐明朗而更新，而不是一直让页面保持绿色，直到一份整洁、完全解决的总结准备好发布。对于正在实时调试自己系统的人来说，一份粗略但及时的确认，比一份精致却迟到的确认更有用。
这与我们在整个产品中思考的一件事相关联，而不仅仅是事故沟通：尽可能接近实时地为开发者提供他们可以据以行动的信息。每个响应中都带有配额响应头，与状态页面在事故期间应当诚实，出于同样的原因。两者都是为了不让人们等到事后才得知一些本会改变他们当时做法的信息。
一个偶尔出现黄色或红色条目的状态页面，并不是服务商的污点。它证明这个页面确实与真实情况相连。更应该让潜在客户担心的，是那种从来不显示任何瑕疵的页面，因为在一段有意义的时间跨度内真正零事故的系统非常罕见，以至于页面上没有事故记录，通常更多地说明了页面本身的问题，而不是系统的情况。