改变思考方式

已完成

此模块的所有单元中,这无疑是最重要的内容之一。 在本单元中,我们将思考一些观点,这些观点可能会改变我们对需要监视的重要内容及其原因的理解。 对于某些人而言,这可能会彻底改变他们有关监视的看法,进而提高可靠性。

Diagram with the word reliability in a circle in the middle connected to circles at the end of each spoke, each circle contains a word relating to reliability from a previous unit.

重新思考 #1:从客户的角度来看可靠性

前面讨论过需要监视的一些可靠性的方面,但那似乎只扩展了需要监视的一些内容。 这里有一种观点,可帮助你重点关注为了提升可靠性应该监视的内容:

需要从客户的角度来衡量可靠性,而不是从组件的角度。

这一点非常重要。 建议再次阅读,因为这很重要。 过去人们提倡“监视一切”。如果可以读取计数器、绘制统计信息,或将其放在仪表板上,我们认为应对其进行监视。 “从客户的角度进行衡量”提供更为具体的观点。

我们来看一个简短的方案,阐述并且强调了这点。

方案

你负责运行公司的电子商务网站。 有一个包含 100 个服务器实例的 Web 场。 由于操作系统故障、软件更新、电源不稳定或一些其他意外事件,这 100 个实例中的 14 个突然停止工作。 这 14 个实例现在完全不在状态。

回顾:86 个服务器实例正常运行,14 个服务器实例未正常运行。

这种情况下以下哪一项是正确的?

A:这不是个大问题。 可以等到有时间的时候再处理这个问题。

B:这是个严重的问题。 应停止手上任何工作,尽快让这 14 个服务器示例恢复服务状态。

C:这是企业的生存危机。 应通知 C 级管理人员,并尽快召集所有人来处理这个问题,即使这意味着在半夜将他们从床上叫醒。

回答之前先花点时间仔细考虑下这种情况,然后进一步阅读。 你认为是 A、B 和 C 中的哪个?

正确答案既不是 A,也不是 B 或 C,应该是“视情况而定”。更准确地说,“这取决于客户对于这个故障的体验情况”。

如果设计该站点时就明确甚至没有客户注意到后端故障并且其余 86 个服务器实例承载起负荷而没有任何问题,那么此处不存在任何危机。 它可能是 SEV-3 或 SEV-4 事件,甚至可能只是一个支持票证问题。

如果此故障致使整个业务瘫痪,并且服务器故障每分钟会导致大笔资金损失,这时候可能需要拉起警报、立马集齐员工。 也可能是中间情况,那么答案就选“B”。

再次强调,需要从客户的角度来衡量可靠性,而不是从组件的角度。 这就是为什么从可靠性角度来看,在这种情况下,“100 个计算机中的 14 个(组件计数)故障”(尽管完全正确)不是最重要的信息。

即便对于更为传统的基于组件的监视,这一点也是适用的。 如果发现数据库服务器在 CPU 负载为 50% 的情况下运行,那这是好还是坏呢? 如果负载升至 90%,那是更好还是更糟呢? 如果服务运行正常且用户感到满意,90% 可能是很好的,因为这意味着大大提高了资源利用率。 但如果用户在 CPU 负载为 50% 时抱怨应用程序运行太慢,那 90% 也不见得是一种改善。

重新思考 #2:适当可靠性级别

为了正确树立这个观点,先快速看一下它的起源。 这个观点来自站点可靠性工程 (SRE)。 只需仔细检查下 SRE 的定义,就可以提取几个有用的观点(包括此部分中的观点):

注意

站点可靠性工程是一种工程规范,致力于持续帮助组织实现系统、服务和产品的适当可靠性级别。

此定义中有三个关键字:

  • 可靠性:简介单元详述了可靠性的重要性,此处不再赘述。

  • 持续:在这里,“持续”是指人在所有操作中的角色。 创建可持续的操作实践至关重要。 可靠的系统、服务、产品是由人构建的。 如果我们不采取行动来确保我们的工作是可持续进行的(例如我们每天凌晨 3:00 叫醒员工处理页面,不留给员工与家人相处的时间,他们没有时间照顾自己),那么他们就无法构建可靠的系统。 SRE 认为我们有必要实施一种长期可持续的操作实践,以便我们的员工能够在工作中发挥最大才能。

  • 适当:这对于某些人来说可能是颠覆性的一点。 在操作世界中曾经一度认为,目标就是要确保一周 24 小时一切都正常运行。 我们曾经尝试在全天、整周、整月、全年保证一切都正常运行。 故障是不被接受的。 站点可靠性工程引入操作讨论的其中一点是,我们应该实现适当可靠性级别。

我们来探讨下这点。 关键在于 100% 的可靠性几乎不是正确的目标。 除了医疗设备或飞机制造等某些例外之外,实际上不需要 100% 的可靠性。而且,事实上,100% 可靠性不是经常都可能实现。

下面是“不可能”的例子:现在我们运行的所有系统都与其他系统有依赖关系。 也许你正在运行一个软件,不得不调用付款处理程序或者身份验证系统。 如果付款处理程序并非 100% 可靠,或者身份验证系统不是 100% 可靠,则系统的可靠性也很难达到 100%。

关于 100% 可靠性的另一难点是,这意味着零故障。 这也意味着没有任何机会对认为可能会引起故障的东西进行更改。 不会有任何上升空间,而这可能是你需要的和想要的。

如果尝试进行某一特定操作,从“什么是适当的可靠性级别?”的角度来开始思考是非常有用的。 回到今天主题上来,监视需要支持这一目标。

考虑到这两个观念,让我们在实践中运用,并了解一些有助于实现目标的工具。