3. 监控

引言

在技术快速发展的世界中，系统日益复杂，用户期望同步提高，有效的监控是站点可靠性工程（SRE）不可或缺的组成部分。你将理解监控在构建和维护高弹性、高性能系统中的重要性。监控系统地实时观察和测量系统性能、可靠性和安全的各个方面。它使SRE能够快速识别问题、诊断根本原因，并采取纠正措施，确保系统达到或超过其服务等级目标（SLO）。在本章中，我们将探讨监控的核心原则、实施的最佳实践，以及如何利用监控工具和技术为你所用。通过理论概念和实践示例的结合，你将理解监控的关键方面，例如数据收集、可视化和告警。我们还将讨论监控在事件管理、容量规划和事后复盘中的关键作用。

结构

在本章中，我们将讨论以下主题：

• 监控的必要性
• 监控的支柱
  • 延迟
  • 流量
  • 错误
  • 饱和度
• 阈值监控
• 监控与可观测性
• 应用监控
• 监控最佳实践

目标

学完本单元后，你应该能够理解SRE工程师对可观测性的核心重要性。可观测性是SRE工作角色的关键方面之一。从可观测性的含义开始，如果以正确的方式实施，业务也能获得成果。监控是SRE的关键组成部分，使团队能够快速主动地识别、诊断和解决问题，确保软件系统的可靠性和可用性。到本章结束时，你将拥有必要的知识，能够为你的系统设计和实施有效的监控策略，从而提高可靠性、减少停机时间并改善用户体验。

监控的必要性

软件行业呈指数级增长，行业间的竞争也同样如此。科技公司正在竞争并参与一场竞赛，旨在拥有最佳的基础设施和平台来维持业务运行，并尽可能降低应用程序故障的风险。现代应用程序的要求与十年或更久以前不同。系统是分布式的，复杂得多，包含多个服务组件。要保持应用程序正常运行，每个服务的健康非常重要。所有服务的健康状况共同决定了应用程序的健康结果，直接影响客户满意度和公司收入。

更复杂 = 更多故障空间

现代IT基础设施由于多种广泛连接的技术而变得非常复杂。说复杂性给故障提供了更多空间，并不为过。每天我们都在探索新事物，并向已有架构添加更多技术，这也为中断提供了空间。不难说，如果我们管理不善，就可能遇到动荡。根据Splunk分享的一份调查报告，我们看到2017年至2022年间中断事件有所增加，这直接或间接导致了重大财务损失、声誉损害和合规问题。

最近的一些相关例子包括Google中断和Atlassian中断。我们将在本章后面将这些中断作为案例进行讨论。

在下图中，你将看到任何基本计算系统的主要组件，以及在出现任何告警状态时将如何表现，请参考下图：

图 3.1：IT基础设施

（原图展示了IT基础设施的主要组件及其在告警状态下的行为，包括但不限于服务器、网络设备、存储等组件及其相互连接和响应。由于原描述较简略，此处保留文字说明。）

假设你是一个应用程序的拥有者，收到一个告警，提示存在延迟问题。你的应用程序对业务至关重要，因此你需要快速找到根本原因。然而，由于你处于复杂的微服务拓扑中，可能很难确定根本原因来自哪里。更复杂的是，你所有的依赖项可能基于不同的技术。例如，一个基于Node.js构建，一个是DB2数据库，另一个用Java编写，等等。请参考下图：

图 3.2：示例服务概览

（原图展示了多个服务，每个服务基于不同技术栈（如Node.js、DB2、Java等），它们相互连接，共同构成一个应用。）

现在，所有这些技术都有各自通常监控的不同指标，而你可能不是这些不同技术中任何一种的专家，因此可能很难找出问题所在。所以，你可能需要为每种技术请一位专家。可想而知，每个人检查自己的服务、找出是否存在问题或是否需要继续向下游排查，这很耗时。同时，你的用户仍在经历这个延迟问题。我们需要更好的方法来解决这个问题。SRE学科告诉我们，只需要监控四个关键性能指标，而不是每种技术的所有不同指标。

我们将这些性能指标称为 黄金信号。具体如下：

• 延迟
• 流量
• 错误
• 饱和度

描述黄金信号的延迟，即相对于最大容量的利用率；饱和度，即请求错误率流量以及服务请求所花费的时间的视图。

现在，让我们回到最初的例子，看看如何应用黄金信号。在某个服务中，我们称之为服务A，我们知道存在延迟问题。我们知道延迟基本上是一个症状，检查服务A时不会看到任何原因。我们知道必须继续向下游排查；但我们不想回到复杂的微服务拓扑中试图找出所有问题。一些APM工具可以通过识别仅与我的问题服务相差一跳（one hop）的服务来帮助我们。假设有服务B、C、D连接到服务A（存在问题的那个）。无论这些服务基于什么技术，我们只需要查看黄金信号。遍历所有服务，我们首先检查服务B的黄金信号，即延迟，但没有发现问题。这让我们认为不需要在检查服务B上花费更多时间。下一个直接连接到服务A的服务是服务C。检查黄金信号，我们在服务C上也没有发现问题。接下来是服务D，我们检查了所有黄金信号，发现服务D的饱和度呈上升趋势。请参考下图：

图 3.3：错误追踪

（原图展示了从服务A开始，依次检查服务B、C、D的黄金信号，最终在服务D发现饱和度的上升趋势，从而定位根因。）

只用了几分钟，我们就确定了服务D很可能是根本原因。现在，不需要为每个服务都请专家，我们可以直接找到服务D，让专家知道我们已确定的根本原因，以便他们修复。这也为整个问题和解决方案提供了另一个视角。如果上述服务是为可调试性设计的，即每一行代码执行时都在某处记录，那么它就是完全可调试的。将来出现任何问题时，你可以直接找到那一行并检查问题。这也使得回溯到阻塞系统的瓶颈变得容易。当我们检查服务B时，确认所有日志都存在，没有发现任何异常、超时消息和错误，那么我们就完全确信服务B运行正常。服务C也是如此。我们将在本章后面讨论发出日志的问题。现在，回到监控。

根据上述用例，使用监控的原因有：

• 缩短解决问题的时间
• 更好的业务规划
• 容量规划
• 改进的性能指标

监控什么

IT基础设施监控涉及跟踪与支持应用或服务的底层硬件、软件和网络组件的性能、可用性和可靠性相关的各种指标。以下是SRE团队通常在IT基础设施中监控的一些关键领域：

• 健康状态（设备在线/离线）
• 性能（RAM和CPU利用率）
• 容量（监控资源使用情况）

监控一直是通往可靠系统的道路。不了解系统的健康状况，就无法提高可靠性。系统会产生大量数据，但我们需要理解哪些数据是相关的，以及应该采取什么行动。你可能遇到的一些用例示例包括：

• 系统是否对命令有响应？
• 系统是否没有意外和异常行为？
• 响应时间是否在时限内且没有延迟？
• 系统是否能在高峰时段承受压力？
• 如果某个服务发生故障，系统是否能够自我修复？

监控的支柱

监控的四大支柱是一个框架，帮助企业谨慎地跟踪和评估其基础设施、应用程序和系统的各个元素。虽然没有一套公认的四大支柱，但一个常用的框架包括以下支柱：

• 指标：指标是用于监控系统或应用程序的功能、健康状态和行为的定量测量。它们揭示了关键绩效指标（KPI），如资源使用率、延迟、吞吐量、错误率等。指标经常被收集，并可用于实时监控、历史分析和预测。
• 日志：日志是系统、程序和基础设施组件执行的操作、通信或事务的记录。它们提供了组件内部运作和交互的详细、带时间戳的信息，对于调试、识别问题和理解问题的根本原因不可或缺。日志可以存储和分析，以辅助故障排除、合规和安全。
• 追踪：追踪提供了每个请求或事务在分布式系统中移动的完整视图。它们让组织深入了解请求如何在不同服务、部分或节点之间被处理，从而能够识别瓶颈、延迟问题和其他与性能相关的问题。在现代微服务架构中，请求经常跨越多个服务，追踪尤其重要。
• 事件：事件是系统内值得跟踪的显著事件或调整。它们可能由多种因素产生，包括用户操作、系统状态变化或告警。事件帮助组织更好地理解其应用程序和系统的状态，发现趋势，并处理事件。

这四大支柱提供了一种全面的监控策略，使企业能够定位和修复问题，提升性能，并保证其系统和应用的可靠性和安全性。通过从这四个领域收集数据，组织可以全面了解其基础设施，并做出明智的决策以提升性能。

根据公司提供的服务和应用程序（无论是电商商店还是金融科技服务），我们要监控以了解服务健康状况的指标对不同用户会有所不同。我们需要检查并关注与客户相关的指标。

黄金信号应与所有类型公司（例如电商、教育科技、金融科技等）的日志监控相关。这四个黄金信号不仅是需要测量的相关指标，而且在资源是否正确或需要追溯到问题时，它们正是我们需要开始寻找的东西。

正如Google所述，还有两个与黄金信号密切相关的支持指标：

• RED方法：

3. 监控

---

黄金信号与相关方法

[CONTEXT_OVERLAP] 黄金信号不仅是衡量相关指标的依据，而且在资源正常或需要追溯问题时，也正是我们开始查找的起点。

正如 Google 所述，还有两个与黄金信号密切相关的支持指标：

• RED 方法：速率（Rate）、错误（Errors）、持续时间（Duration）（性能监控）
• USE 方法：利用率（Utilization）、饱和度（Saturation）、错误（Errors）（服务监控）

让我们详细了解这些指标以及它们如何与黄金信号相关联。

---

延迟（Latency）

延迟是处理一个请求所花费的时间。需要为合理的延迟率设定一个阈值。目标阈值的选择因应用程序类型而异。接下来，我们必须监控与成功请求相关的延迟，并将其与失败请求的延迟进行比较。失败请求的延迟率通常低于成功请求，因为失败请求通常无需额外处理而快速失败。按照之前章节中定义的方式并参考图 2.3，逐一追踪整个网络中的延迟有助于识别哪些服务没有阻塞性能并拖慢流程。一旦找到受影响的微服务，我们就有了下一步的聚焦区域。

流量（Traffic）

流量是衡量流过网络的请求数量的指标。这些可以是 Web 服务器上的 HTTP 请求，也可以是使用 Kafka 或 Maas 发送到消息队列的消息。流量会因时间、季节和其他因素而变化。为了详细说明，我们以 Flipkart（在线电商商店）的“Big Billion Sale”大促为例。在这些日子里，公司会预期服务器承受更大的压力，可能需要扩展服务器。我们将在后续章节讨论服务器自动扩缩容以及它们如何通过监控来避免宕机。

错误（Errors）

错误表示请求失败或返回不正确结果的比率。这个比率不仅反映了应用程序的真实健康状态，还可以在系统级别或微服务级别通过正确的监控手段识别。错误率的飙升可能表明数据库或网络发生故障。错误还可能表明代码中存在某种在测试中幸存下来、仅在生产环境中暴露的缺陷，这些缺陷会影响其他指标，例如降低延迟或增加饱和度。

饱和度（Saturation）

饱和度定义了网络和服务器资源的负载。每个资源都有一个极限，超过该极限后性能会下降或不可用。它描述了你的服务被占用的程度。这适用于内存使用率、CPU 利用率、磁盘容量以及每秒操作数。结果，用户对你服务可靠性的信任度会下降。通过监控分析应用程序后，我们可以获得正确的指标，并在性能下降之前调整容量。以下是一些例子：

• 你的服务利用了多少
• 数据库和流媒体应用的磁盘 I/O 速率

注意

许多系统在达到 100% 利用率之前性能就会下降，因此设定一个利用率目标至关重要。建议根据系统的利用率设置告警，用户可以根据自身用例定义阈值。

---

阈值监控（Threshold Monitoring）

阈值监控是一种跟踪系统和应用程序的方法，它为某些性能指标设定限制或阈值。当这些限制被突破时，会向相关人员发送警报或通知，让他们了解可能的问题。这使他们能够找出问题并修复它，以保持系统的稳定和良好运行。

在 SRE 中，阈值监控尤其有用，其目标是使系统或服务保持在所需的可靠性和性能水平。在 SRE 方面，阈值监控的一些示例如下：

• 错误率阈值：在 SRE 中，可以使用服务等级目标（SLO）来决定可接受的错误率。如果错误率超过此预定阈值，可能意味着存在需要调查的问题。可以触发警报，通知 SRE 团队解决问题并防止服务质量下降。

• 延迟阈值：可以根据期望的服务响应速度设置延迟阈值。如果平均响应时间或百分位（例如第 95 或第 99 百分位）延迟超过此阈值，可以发送警报。SRE 团队随后可以找出延迟增加的原因，并采取措施来改善性能。

• CPU 使用率阈值：可以为服务或服务器的 CPU 使用率设置限制阈值。如果 CPU 使用率超过此限制，可能表明资源不足、应用程序运行不佳或可能存在瓶颈。警报可以通知 SRE 团队调查情况并优化应用程序运行或增加更多资源。

• 饱和度阈值：可以为资源（如内存、磁盘空间或网络带宽）的使用程度设置饱和度阈值。如果这些资源中的任何一个超过预定的阈值，可能意味着服务可能会降级或停止工作。警报可以通知 SRE 团队调查问题并修复它，例如通过释放资源或扩展基础设施。

---

监控与可观测性（Monitoring and Observability）

根据麦肯锡的报告，十二月是零售商一年中最忙碌的月份，节假日期间人们会蜂拥而至。为了证明这一说法，我们可以考虑涵盖圣诞节、新年以及更多地理边界内的节日。根据麦肯锡在 2021 年提供的报告，人们在节假日期间的购买意愿比 2020 年高出 7%，比 2019 年高出 9%。那么，回到业务层面，我们如何让客户获得高质量的购物体验，并确保系统不会崩溃？因为一旦崩溃，将导致收入损失、品牌形象受损和 SEO 排名下降。我们将通过覆盖每个 SRE 工程师在职业生涯中可能遇到的一些例子，来解释业务收入与我们系统技术方面的联系。

假设有两个 8GB RAM 的服务器，每个服务器均已使用 55%，服务器 A 和服务器 B，其中服务器 A 是主服务器，服务器 B 是备份服务器，这也意味着当前流量由服务器 B 处理。请参考下图：

图 3.4：负载均衡

现在让我们分析一下，服务器 A 运行良好，有一半的空间可用，服务器 B 也有足够的空间。因此，如果出现问题，它们有足够的空间来应对灾难。现在，假设服务器 A 发生故障，我们的灾难恢复被激活，服务器 B 成为新的主服务器。服务器 A 必须将其 55%（4.4 GB）的负载转移到服务器 B，但服务器 B 已经占用了 55% 的空间。通过简单的计算，我们知道 4.4GB + 4.4GB > 8GB。通过这个简单的观察，我们可以说问题陈述中给出的系统是不可靠的，只是在等待故障发生。请参考下图：

图 3.5：负载均衡 2

让我们考虑另一个场景来简化这个概念。假设有三台服务器，每台当前提供 60% 的负载。请参考下图：

图 3.6：故障排除服务器崩溃

所有三台服务器都在处理流量，突然服务器 C 崩溃，我们需要服务器 A 和服务器 B 平稳地接管负载，且不报告任何故障。对于服务器 A、B 和 C，我们知道 60 < 100。

现在服务器 C 崩溃了，我们需要检查如果我们将服务器 C 的负载平均分配给服务器 A 和 B，它们是否能够承受。

服务器 A = (60 + 30) < 100 || 服务器 B = (60 + 30) < 100

每台服务器上的负载仍然小于 100，因此我们可以得出结论，我们需要恐慌的临界点大约在初始负载的 60% 到 66% 之间。如果初始负载超过 66%，那么就会有问题，系统将不再被认为是可靠的。这是一个非常小的例子，说明了设计复杂系统时所需的基本可观测性。在讨论监控之后，我们将再次回到可观测性，然后在这两者之间建立联系。

本章前面部分，我们讨论了监控的核心含义、为何需要监控以及不同的监控方法。在这里，我们将讨论监控与可观测性为何不是同一回事。我们经常听到 SRE 是 DevOps 2.0，可观测性是监控 2.0，为什么我觉得不是这样，反而可观测性是监控的超集。我想带您稍微回顾一下，再次提出一个问题：我们对监控的理解是什么？如今市场上有多种工具，例如用于监控的 Prometheus 和 Datadog，但我们需要理解它们究竟在监控什么、如何监控以及背后的过程。我们将在本章后面讨论这些工具，以及借助这些工具可以做的仪表盘和钻取分析。现在，让我们专注于监控的核心概念。我们正在监控一个系统，我们知道某个特定场景会在 6:00 发生故障。有些条件是我们已知的，我们不希望系统达到饱和以防止任何故障。但是那些未知的故障呢？由于我们没有任何阈值、X 百分比，而且目前我们不知道未知项。我们需要找出那些未知项。这就是可观测性发挥作用的地方。只有对系统进行清晰的观察，我们才能设置相关的监控和告警。你一定听说过银行系统声称他们的系统并非 100% 可用，而是 99.9999%。这意味着我们仍然给了系统在 0.001% 的时间里发生故障的机会，在这个时间窗口内可能发生某些未知故障。这个缓冲是必要的，以便改进随时可能发生的未知故障。最好的解决方案是适当的测试以及相关的监控和告警。

可观测性是在寻找未知的未知（unknown unknowns）

— Chaos Genius

监控侧重于一组预定义的系统健康指标以及它们随时间的变化。日志提供独立的数据，但通常孤立查看。监控有助于理解“什么”正在变化。当系统故障点被充分理解且未知项较少时，这很有帮助。

可观测性是通过分析系统生成的数据（如日志、指标和追踪）来理解系统内部状态的能力。可观测性将监控提升到下一个层次，它不仅突出“什么”在变化，而且分析相关数据集以回答“为什么”某些指标会变化，并识别根本原因。可观测性在分布式系统中尤为重要，因为分布式系统中可能存在许多故障，并且无法提前预知故障点。请参考下图：

图 3.7：监控与可观测性

让我们将监控和可观测性的过程分解，并检查它们如何可以被预测。既然我们现在知道监控是可观测性的一个子集。系统的可观测性是通过可观测性的传统三大支柱来观察系统性能和基础设施：日志、指标和追踪。

• 日志：日志条目包括应用程序针对代码中发生的某些事件发出的结构化和非结构化数据。日志是对指标的补充，因为它们提供了捕获指标时应用程序事件的上下文。这完全取决于应用程序团队需要哪些日志。某些应用程序由于存在信息性日志而在故障期间被认为具有高度可调试性。

• 指标：指标是一组通常随时间捕获的测量值，用于指示系统的健康状况。指标由一组属性（例如名称、值、标签和时间戳）组成，这些属性传达了关于指标的信息。指标支持更简单的查询和更长的数据保留时间。最常见的基础设施指标包括延迟、流量、查询时间、错误、利用率等。

3. 监控

追踪

追踪（Traces）帮助你理解请求在分布式系统中经过多个节点的完整生命周期。通过正确使用追踪，可以极大地帮助发现系统中的瓶颈，并理解哪个服务影响了系统的整体性能。我们在图3.3中看到一个示例，并追踪到应用程序D是系统中的故障所在，这让我们立即意识到相关服务是服务D，而其余服务运行正常。

监控工具格局

监控与可观测性领域的格局相当丰富且信息量大，详见Gartner于2022年6月发布的《可观测性报告》中的以下图表：

图3.8：应用监控与可观测性的魔力象限

为了更好地理解这些术语：

• 利基市场参与者（Niche players）：在小细分市场或特定ISN领域相对成功，但创新不足或表现不如其他厂商。
• 远见者（Visionaries）：理解市场发展方向，或拥有改变市场规则的愿景。
• 挑战者（Challengers）：在当前市场执行相对良好，或在大型细分市场中占据主导地位，但其路线图与Gartner对市场演变的看法不一致。
• 领导者（Leaders）：在当前市场执行相对良好，且为未来做好了充分准备。

NOTE

此处不推广任何特定工具；结果严格基于国际公认的Gartner报告。

应用监控中的SRE角色

SRE在应用监控中扮演着重要角色，因为这与其核心职责——确保数字服务和应用的可靠性与可用性——密切相关。以下是他们在应用监控中的主要参与内容：

• 设计监控系统：SRE负责创建和执行监控系统及应用监控策略。他们指定必须监控的应用程序特征，如性能指标、错误率和延迟。他们确保监控的全面性，并与服务等级目标（SLO）保持一致。
• 实施监控工具：SRE识别并部署相关的监控工具和框架。他们配置这些工具以从多种来源（如服务器、容器、数据库、网络设备和应用程序日志）收集并分析数据。
• 设置告警阈值：基于SLO和错误预算，SRE设置告警阈值。他们指定何时触发告警，并确保告警有用、可操作且无虚假误报。
• 实时监控：SRE持续实时监控应用程序的健康状况和性能。他们密切关注偏离正常行为的情况，并快速响应异常或事件。该方法通常包括自动告警和值班轮换。
• 事件响应：当通过监控检测到问题时，SRE负责事件响应。他们调查事件的根本原因，减轻服务中断，并努力防止类似问题再次发生。
• 容量规划：SRE使用监控数据进行容量需求规划。他们分析趋势和使用模式，确保资源适当扩展以满足需求，同时避免过度配置。
• 性能优化：监控帮助SRE识别应用程序中的性能瓶颈和低效之处。他们利用这些信息优化代码、配置和基础设施，以提升应用性能。
• 安全监控：SRE也在安全监控中发挥作用，确保应用程序受到保护，免受安全威胁。他们监控未经授权的访问、漏洞和可疑活动，并响应安全事件。
• 文档和报告：SRE记录监控安装、配置和流程。他们生成报告和仪表板，提供关于应用程序健康性和可靠性的洞察，并将这些信息提供给团队其他成员。
• 持续改进：SRE通过分析监控数据来识别可以提升可靠性的领域，推动持续改进的文化。他们利用事后审查和复盘会议从过去的事件中学习，并完善监控策略。

监控最佳实践

日志记录和监控的概念并不新鲜，但组织在制定和实施以安全为重点的日志记录和监控策略时仍然面临困难。主动收集和分析信息的方法可以帮助多个利益相关者（如开发人员、系统管理员）以多种方式解决问题，例如通过应用程序级日志检测代码中的问题，通过基础设施日志（如AWS/Azure）识别网络流量中的异常。通过采用以下日志记录和监控最佳实践，可以应对这些挑战：

• 明确日志记录和监控的需求。
• 列出需要记录的内容。
• 为你的问题找到合适的监控工具。
• 不要过度告警。（否则你会被告警淹没并错过最重要的告警）
• 根据告警建立事件响应计划（Runbook）。

监控和可观测性工具示例

有许多监控和可观测性工具可用，每种工具都有其特性和功能。以下是一些示例：

• Prometheus：Prometheus是一个流行的开源监控和告警系统，用于收集和存储时间序列数据。Prometheus以其可扩展性和支持复杂部署的能力而闻名。它还拥有强大的查询语言，允许用户查看指标并观察其随时间的变化。

• Grafana：Grafana是一个开源的数据可视化和监控平台，支持多种数据源，如Prometheus、Graphite、Elasticsearch等。Grafana允许用户创建自定义仪表板和告警，并提供多种数据可视化工具。

• Nagios：Nagios是一个广泛使用的开源监控工具，提供主机和服务状态的实时告警和信息。Nagios非常灵活，可以通过大量的插件和扩展进一步增强功能。

• 命令行工具：如今的多数Linux发行版都附带一组用于监控系统性能的工具。这些工具帮助你测量和理解各种子系统统计数据（CPU、内存、网络等）。我们将各举一个示例：

  • top命令：top命令是一个Linux实用程序，提供Linux系统上运行进程的实时动态信息，包括系统资源使用情况和CPU活动。这是一个强大的工具，允许用户监控系统性能并识别性能瓶颈或问题。参考下图：

    图3.9：top命令输出示例

  • netstat命令：显示活动的TCP连接、计算机正在监听的端口、以太网统计信息、IP路由表、IPv4统计信息（针对IP、ICMP、TCP和UDP协议）以及IPv6统计信息（针对IPv6、ICMPv6、TCP over IPv6和UDP over IPv6协议）。如果不带参数使用，netstat显示活动的TCP连接。参考下图：

    图3.10：netstat命令输出示例

  • df命令：要查看磁盘空间使用情况，不带参数运行df命令。它将以表格形式显示磁盘空间使用情况。df命令可用于确定机器或文件系统上的可用空间量。参考下图：

    图3.11：df命令输出示例

  此命令可与多个标志一起使用，如-h、-T等。请将此部分视为更好理解监控形式的示例。

结论

SRE高度依赖监控和告警。通过密切监控，SRE团队可以在性能问题影响客户之前发现它们。当问题出现时，SRE团队需要尽快收到告警，以便及时响应和修复问题。选择合适的监控工具和指标对于SRE团队实施有效的监控和告警至关重要。为了确保告警有意义且可操作，他们还必须建立清晰的阈值和告警策略。最后，SRE团队需要定期审查和改进其监控和告警流程，以确保它们随着业务需求的变化而发展。

在下一章中，读者将学习这些流程的基础知识、目标及其在维护系统可靠性中的重要性。关键主题包括事件管理生命周期、角色与职责、沟通、响应规划、风险评估、缓解策略、监控和持续改进。通过理解这些概念，读者将能够更好地制定和实施有效策略，以增强组织的IT韧性，培养主动文化，并保障业务连续性和运营效率。

通过主动的事件管理来维护服务可靠性和可用性，需要一套独特的技能，包括技术知识、出色的沟通能力和主动性。利用本章中的指导原则，SRE团队可以构建一个有效的事件管理流程，保护用户免受不必要的服务中断，并减少未来停机的可能性。

选择题

1. 应处理哪种类型的故障？ a. 逻辑性 b. 操作性 c. 程序性 d. 功能性

2. 应调试哪种类型的故障？ a. 逻辑性 b. 操作性 c. 程序性 d. 功能性

3. 监控允许用户做什么？ a. SLO测量 b. 报告停机原因 c. 系统健康状态 d. 安全

4. Google建议使用4个黄金信号做什么？ a. 自动化特性 b. 提升安全性 c. 减少MTR d. 监控系统

答案：

1. c.
2. a.
3. c.
4. d.

加入本书的Discord空间

加入本书的Discord工作区，获取最新更新、优惠、全球技术动态、新版本以及与作者的交流： https://discord.bpbonline.com

3. 监控

图片引用

• [Image 1699 on Page 84]
• [Image 1703 on Page 85]
• [Image 1705 on Page 86]
• [Image 1722 on Page 94]
• [Image 1724 on Page 95]
• [Image 1725 on Page 95]
• [Image 1730 on Page 98]
• [Image 1734 on Page 100]
• [Image 1744 on Page 105]
• [Image 1747 on Page 106]
• [Image 1750 on Page 107]
• [Image 600 on Page 109]