如果您的应用程序提供了糟糕的体验，而您又不在场观察到，您的用户会发出声音吗？

答案是肯定的，而且可能还会有嘟囔和咒骂。可靠的服务体验与用户体验和信任密不可分，是站点可靠性工程 (SRE)的关键目标。但是，如果您看不到正在发生的事情，就无法确保这些服务满足用户的期望。 

这个至关重要的原则称为可观察性。可观察性是指使用正确的工具、流程和程序来测量、收集、组织和分析遥测数据，准确、一致地测量健康指标。没有可观察性，你就无法实现可靠性，因为你实际上是在盲目飞行。

在本文中，我们将深入探讨可观察性和可靠性的概念，以及如何使用这些知识来构建可靠的系统。

可靠性是指服务的特定性能水平，以及我们实现这些目标的程度。在站点可靠性工程中，这些性能目标称为服务水平目标 (SLO)。这些 SLO 必须可使用服务水平指标 (SLI)进行衡量，服务水平指标是用于衡量性能的实际数字。

以下是两个 SLO 示例：

• 连续四周，99% 的请求在 800 毫秒内成功。

• 95％ 的文件每天处理的失败记录少于 25 条。

您能注意到 SLI 吗？在本例中，SLI 是响应时间（延迟在 800 毫秒以内）和失败记录数（少于 25 条）。这些是可衡量的可靠性数字指标。

您的 SLI 应该简单，并且您应该选择正确的指标进行跟踪。跟踪太多无关紧要的指标会使事情变得过于复杂，并隐藏真正重要的指标。

不是。可用性是指服务成功处理请求的时间百分比，而可靠性是指服务在处理请求时运行的良好程度。可用性是构建可靠系统的一部分，但不是唯一因素。例如，即使系统具有高可用性，延迟时间较长的系统也不会非常可靠。 

然而，这并不相反——一个持续不可用的系统不能被视为可靠的。因此，可用性可能是实现可靠性的 SLO 之一。为此，了解如何衡量可用性很有用，如下所示。

您可以使用以下公式轻松计算可用性：

您还可以使用 MTTR（平均修复时间）和 MTTF（平均故障时间）来计算可用性。MTTF 是指系统在发生中断之前正常运行的平均时间。MTTR 是指系统从中断中恢复所需的平均时间。

由于准确计算 MTTF 和 MTTR 可能具有挑战性，因此通常使用更直接的方法（使用正常运行时间和停机时间）来计算可用性。

现在我们已经讨论了可靠性和可用性，让我们回到可观察性。

可服务性是指根据从系统收集的数据确定系统内部状态的能力。在信息技术中，这意味着使用从服务收集的遥测数据来衡量服务运行状况的能力。此服务可以是 Web 应用程序、批处理应用程序、数据库系统或任何提供服务的软件。

如何实现可观察性？

要实现可观察性，我们必须拥有生成、收集和组织遥测数据的方法。我们必须在应用程序开发的初始阶段仔细考虑可观察性的实现。实际上，可观察性是通过使用开源和商业销售形式的专用工具来实现的。

一些可观察产品的示例是Splunk、Dynatrace、  Datadog、ELK（Elastic Search、Logstash、Kibana）和 TIG 堆栈（Telegraph、Influx DB、Grafana）。 

可观察性的支柱：日志、指标和跟踪

可观察性系统提供三种类型的遥测输出，通常称为“可观察性支柱”：日志、指标和跟踪。 

• 日志是随时间发生的离散事件的不可变且带有时间戳的记录。这些记录包括事件、警告和错误。

• 指标是一段时间内测量的数据的数值表示。这些可能是每秒交易量、内存资源消耗或其他有用的数字。

• 跟踪是跟踪应用程序请求在流经应用程序各个部分时的数据。使用跟踪，您可以确定应用程序的哪些部分触发了错误。

示例：典型的可观测系统

1. 系统配备了可以生成遥测数据的代理（例如：Dynatrace oneagent）。或者，系统可以公开可使用遥测数据收集器提取的遥测数据。

2. 遥测收集器接收日志、指标和跟踪等遥测数据。

3. 遥测管道可以选择性地增强或过滤数据并将数据导出到可观测性后端。管道可以采用多种形式，具体取决于所选的可观测性解决方案。

4. 可观察性后端是组织遥测数据以供使用的地方。示例包括Splunk、Dynatrace和Datadog。

如何使用可观察性来增强服务可靠性

1.减少MTTR（平均修复时间） 

当系统发生故障时，无论是完全故障还是部分故障，找出故障原因的速度对于恢复系统正常运行至关重要。这种可观测性直接影响平均修复时间 (MTTR)，而平均修复时间又需要保持高可靠性。使用可观测性系统收集和汇总的遥测信号，团队可以快速分析数据并找出问题的根本原因。 

举个例子。您的用户开始报告他们收到了致命的500 内部服务器或502 错误网关错误。使用您的可观察性系统，您可以快速发现系统中出了什么问题。它可能会报告远程 Web 服务已死、后端数据库服务器没有响应或文件系统可能已满。突然之间，您已经从询问出了什么问题转变为计划如何尽快解决问题。

可观察性还可以帮助您提前发现潜在问题。回到上面的例子，它可以帮助您在文件系统达到容量上限之前就发出信号，避免出现问题。通过主动监控系统运行状况并利用明确定义的警报，我们可以在最终用户受到影响之前开始进行故障排除。

2. 提供代码级诊断以更快地解决问题

当开发人员需要诊断应用程序的问题时，找到有问题的代码就像大海捞针。与此同时，在他们这样做的时候，系统并不像它应该的那样可靠。

通过使用跟踪，您可以显著帮助提供对应用程序的代码级可见性。通过从分布式系统收集跟踪并提供用户界面来可视化它们，可观察性可通过跨服务实现请求范围的可见性（通常是瀑布图）来帮助开发人员。

以下是来自 Dynatrace 的跟踪视图：

来源：dynatrace.com

代码级诊断非常强大，有时开发团队会惊讶地发现应用程序执行路径中存在他们之前不知道的后端调用。

3. 帮助将开发重点转向可靠性改进

开发团队通常努力尽可能频繁地发布，以便他们可以添加新的应用程序功能。相反，SRE 应用程序支持（运营）等支持团队往往采取相反的做法，希望限制对应用程序的更改次数。后者通常是正确的，因为更改会导致 75% 的停机。

通过监控 SLO，我们可以知道何时违反或即将违反。有了这些数据，我们可以将开发重点放在增强可靠性的修复上，而不是开发新功能。此外，我们可以确定是否需要暂停未来版本以保持应用程序的可靠性。

例如，假设一个应用程序的 SLO 可用性为 99.9%，连续四周。99.9% 相当于每月 43.2 分钟。如果停机耗时 35 分钟，则暂停新版本四周是合理的，因为在我们违反 SLO 之前，您只有 7.2 分钟的停机时间。 

4. 确保有足够的服务提供能力

一个重要的可靠性因素是拥有足够的容量（计算、内存、存储和网络资源）来满足应用程序的需求。具有自动扩展功能的公共云平台使容量规划变得更容易一些，因为资源通常可按需提供。但是，如果我们不提前规划容量，成本就是一个重要因素。 

通过利用可观察性，您可以测量应用程序吞吐量、资源利用率、资源饱和度以及这些资源的预期使用情况。这些信息对于确定未来的容量需求非常有价值。此外，可观察性可以显示我们是否过度配置了资源，这是公共云平台的一个主要问题。通过定期监控资源利用率，我们可以避免超支。

5. 使用监控来改进 CI/CD 管道

许多组织使用某种形式的 CI/CD（持续集成/持续部署）来发布其应用程序。但通常，他们不会监控 CI/CD 本身的指标。测量发布频率、发布持续时间、部署错误、回滚持续时间等指标可以提供有价值的见解来改进 CI/CD 管道。这对于识别 CI/CD 管道中的瓶颈很有用。

6. 通过报告生成增强业务能力 

许多开源和商业可观察性平台都具有不错的报告和仪表板功能。报告可以立即生成，但通常需要工作（例如，编写特定查询）才能创建易于理解的报告。当报告可以自动化并轻松与相关消费者共享时，报告是有效的。它对于高管领导推动投资决策特别有用。 

以下是一些有价值的报告：

1. 每周 SLO 报告
2. 每周成本分析报告
3. 每日发布绩效报告

结论

通过实现应用程序的可观察性，您可以减少平均修复时间 (MTTR)，深入了解应用程序的运行方式，监控 CI/CD 管道，规划容量并自动生成有价值的报告。所有这些都可以帮助您实现更高的可靠性，从而提高客户满意度。

实现从用户浏览器到后端系统的端到端可见性似乎很困难。但是，在短时间内实现良好的可观察性生态系统是可能的。一个很好的起点是定义您的 SLO 并实施与它们相关的 SLI 的监控。 

想要了解有关 SRE 最佳实践的更多信息吗？

Pluralsight 提供了站点可靠性工程 (SRE) 基础知识学习路径，可教您有关 SRE 及其实施方法的所有知识。它涵盖了广泛的主题，从 SME 的基础知识以及如何将其纳入您的系统设计开始，到更高级的主题，例如如何管理 SRE 团队以及实施有效的事件响应和变更管理。 

如果您喜欢这篇文章，我强烈建议您查看我的课程“实施站点可靠性工程 (SRE) 可靠性最佳实践”。祝您在实施可观察、可靠的系统的过程中好运！