DevOps反馈技术实践：创建遥测以解决问题

### DevOps 反馈技术实践：创建遥测以解决问题 在软件开发和运维过程中，快速发现并解决问题至关重要。通过创建有效的反馈机制和遥测系统，我们可以实现从运维到开发的快速反馈，从而在软件开发生命周期的早期发现并解决问题，提高软件质量和组织的适应能力。 #### 1. 为何需要遥测 在运维工作中，小的变更可能会导致许多意外结果，包括停机和全局故障，影响所有客户。然而，当生产故障和其他问题发生时，我们往往缺乏解决问题所需的信息。例如，在停机期间，我们可能无法确定问题是由于应用程序故障（如代码缺陷）、环境问题（如网络问题、服务器配置问题），还是完全外部的因素（如大规模拒绝服务攻击）。 传统的运维方式可能只是简单地重启服务器，而高绩效组织则采用了“因果文化”，使用生产遥测来理解可能的影响因素，从而更有针对性地解决问题。研究表明，服务水平最高的组织重启服务器的频率比平均水平低 20 倍，“蓝屏死机”的情况也少 5 倍。 #### 2. Etsy 的 DevOps 转型案例 Etsy 在 2009 年开始的 DevOps 转型中，生产监控是关键的一部分。他们将整个技术栈标准化为 LAMP 栈，为了确保在进行重大变更时不影响服务，需要更多的指标来提供信心。 他们使用 Ganglia 收集服务器信息，并将其显示在 Graphite 中。通过在 Graphite 中添加“无与伦比的垂直线技术”，可以更快速地看到部署的意外副作用。到 2011 年，Etsy 已经在应用程序栈的各个层面跟踪了超过 20 万个生产指标，到 2014 年，这一数字超过了 80 万。 高绩效者解决生产事件的速度比同行快得多。在 2015 年的 DevOps 状态报告中，高绩效者解决生产事件的速度比同行快 168 倍；在 2019 年的报告中，精英绩效者解决生产事件的速度比低绩效者快 2604 倍。 #### 3. 创建集中式遥测基础设施 传统的运维监控和日志记录已经存在了多代，但往往存在信息孤岛的问题。开发人员只创建对他们有意义的日志事件，而运维人员只监控环境的上下线状态。当问题发生时，没有人能确定整个系统为何不能按设计运行，或者哪个特定组件出现了故障。 为了能够看到所有问题，我们需要设计和开发应用程序及环境，使其生成足够的遥测数据。现代监控架构通常由以下组件组成： - **数据收集**：在业务逻辑、应用程序和环境层收集事件、日志和指标。日志可以存储在每个服务器上的特定文件中，但最好发送到一个通用服务进行集中管理。在操作系统层面，可以使用工具收集 CPU、内存、磁盘或网络使用情况等指标。云原生计算基金会创建了一个名为 OpenTelemetry 的开放标准，许多开源和商业工具都支持该标准。 - **事件路由器**：负责存储事件和指标，支持可视化、趋势分析、警报和异常检测等功能。通过收集、存储和聚合所有遥测数据，我们可以更好地进行进一步分析和健康检查。常见的工具包括 Prometheus、Honeycomb、DataDog 和 Sensu 等。 将日志转换为指标后，我们可以对其进行统计操作，例如使用异常检测来更早地发现异常和偏差。此外，我们还应该收集部署管道中的遥测数据，以便在问题进入生产环境之前发现并修复错误。 #### 4. 创建有助于生产的应用程序日志遥测 在拥有集中式遥测基础设施后，我们需要确保开发和运维工程师在日常工作中为新的和现有的服务创建足够的生产遥测。每个功能都应该进行检测，以确认其按设计运行并实现预期结果。 不同的团队成员会以不同的方式使用遥测数据。例如，开发人员可能会临时创建更多的遥测数据来诊断工作站上的问题，而运维人员则使用遥测数据来诊断生产问题。为了支持这些不同的使用模式，我们有不同的日志级别： | 日志级别 | 描述 | | ---- | ---- | | DEBUG | 用于调试，通常在生产环境中禁用，但在故障排除时临时启用 | | INFO | 用户驱动或系统特定的操作信息 | | WARN | 可能成为错误的条件信息，可能会触发警报和故障排除 | | ERROR | 错误条件信息，如 API 调用失败、内部错误条件 | | FATAL | 必须终止的情况信息，如网络守护进程无法绑定网络套接字 | 选择正确的日志级别很重要。为了确保服务的可靠和安全运行，我们应该确保所有可能的重要应用程序事件都生成日志条目，并创建日志层次结构类别，以便更轻松地解释和赋予这些日志条目意义。 #### 5. 使用遥测指导问题解决 高绩效者使用科学的方法来解决问题，而不是依赖谣言和传闻。当存在指责文化时，团队可能会避免记录变更和展示遥测数据，从而导致无法创建关于事件发生原因的机构知识，以及无法吸取教训以防止未来再次出现这些错误。 遥测使我们能够使用科学方法来制定关于问题原因和解决方案的假设。在解决问题时，我们可以回答以下问题： - 我们从监控中得到了哪些证据表明问题确实发生了？ - 我们的应用程序和环境中哪些相关事件和变更