DevOps 文字培训

如何建立监控（遥测）来管理 DevOps 软件生命周期？

你的 IT 行业经验已经告诉你，出问题时往往难以找出根本原因。问题可能出在软件应用、运行环境，或与应用及环境集成的其他组件中。

回顾过去 50 年间相对复杂的客户端和服务器平台的发展，有一件事经常发生：服务器开始表现不佳、不断报错、无法提供服务时，你就把它重启，希望这样能解决问题。重启有时确实能暂时消除一个你从未弄清楚的问题。然而，如果这样没用，你接下来就会找开发和测试人员，指责他们交付不当或未能在测试软件时发现问题。这种混乱不仅会影响客户对服务的满意度，也会破坏组织的工作氛围。

领先的 DevOps 组织在解决问题的过程中很少重启服务器。他们采用系统化方法识别和解决问题，依靠生产遥测了解根本原因和影响因素，避免盲目重启服务器。他们的平均恢复时间（MTTR）仅为其他组织的 1/96。换句话说，他们解决生产问题的速度是一般企业的 96 倍。领先 DevOps 组织最重要的技术做法，是在软件和应用中部署遥测。

什么是遥测？

简单来说，遥测是记录系统行为的过程。

为此，软件、生产和预生产环境以及部署流水线都需要在设计上能持续生成遥测记录。目标是部署足够多的遥测功能，让你能确认服务在生产环境中正常运行。出问题时，查看遥测记录就能迅速了解问题所在，并依据这些信息作出修复决定。

遥测还能让你核对自己对生产系统运行情况的理解与实际情况是否一致。

构建遥测基础设施

要实现遥测，需要具备两个主要组成部分：

1. 记录遥测指标： 所有高绩效 DevOps 组织都会在应用、环境和部署流水线的各层持续记录数十万项指标。例如业务逻辑中的事件，如销售笔数，以及服务器平台健康检查，如监控操作系统、数据库、磁盘 I/O、网络 I/O、RAM、CPU 和安全性。
2. 管理遥测指标的集中平台： 这个平台存储指标与事件，支持可视化、趋势分析、采样、告警和异常检测。它将日志转化为指标，例如某个软件应用中的致命异常数量。此外，部署流水线中的事件，比如生产及预生产环境中的提交、回滚、安装、卸载和自动化测试结果，也应保存在同一遥测基础设施中。

你、DevOps 团队以及与团队协作的其他利益相关方，都应该可以通过自助 API 和图形界面获取遥测平台的信息，无须提交工单请求访问。

除了可能侵犯客户隐私或危及客户安全的指标，所有遥测信息都必须百分之百向整个组织开放。

遥测指标的类型

1. 业务层指标： 例如 A/B 测试结果、利润、收入、新用户数量、平均会话时长、已完成订单数及放弃结账的次数。
2. 应用层指标： 例如应用响应时间、事务耗时、核心转储数量及致命异常数量。
3. 基础设施层指标： 例如服务器流量、磁盘 I/O 操作、网络 I/O 操作，以及 RAM、CPU 和磁盘使用情况。
4. 客户端层指标： 例如 Web、移动端、JavaScript 及其他客户端应用的响应时间和错误。
5. 部署流水线层指标： 例如代码提交、部署前置时间、频率、环境状态，以及运行自动化测试后的绿、黄、红状态。

把指标按不同类别和嵌套子类别组织成层级至关重要，这样你和 DevOps 团队就能轻松理解各项指标。

确保应用日志条目易于理解，因为它们之后会被转换为遥测指标。就像按不同事件类别对日志分组一样，也应对遥测指标进行类似分组。例如，可以使用 Debug、Info、Warn、Error 和 Fatal 等遥测指标级别。

利用遥测信息指导解决问题

如果组织习惯于指责，谁也不愿让生产系统中的变更完全可见，谁也不愿公开遥测数据。在这种氛围下，很少能正确找出问题的根本原因，更糟的是，组织也学不到新东西。

为确保可以利用遥测来指导问题解决，应让编写遥测成为整个 DevOps 团队的日常工作。建立易用的库，让一行代码就能轻松创建一条遥测记录。

此外，要为版本控制系统和运行环境的写入事件创建遥测记录。这样，从遥测监控中就能清楚、直观地看出系统变更与其对客户产生的影响之间的关系。

例如，下图清楚显示，周四晚上最后几次部署中的某一次，很可能是结账流程中购买失败事件增多的根本原因。

对比一段时间内的部署成功、部署失败与业务活动。

查看原始示意图 ↗

两次部署之间，购买事件的失败率上升，成功率下降
（来源：Measure Anything, Measure Everything、DevOps Handbook）

遥测能帮助你详细沟通问题。你和 DevOps 团队对自己和利益相关方没有什么需要隐瞒。因此，要持续监控，并向利益相关方实时展示上图这类图表，便于快速识别问题，并观察部署与关键业务事件之间可能存在的因果关系。业务人员能够更加透明、深入地了解你和团队所做的工作，DevOps 开发人员和运维工程师也能看出事件与部署之间的关联。

遥测让你趁问题还容易修复、成本较低时发现它们，这样你就能在问题蔓延并引发其他问题之前解决它们。

通过遥测，你和 DevOps 团队可以识别关键业务和技术指标的规律，并在异常发生时发出告警。最初设定的告警阈值可能不准确，并产生误报，这很正常。别慌，也不要让任何人削弱你在建设遥测基础设施方面的努力与投入。与复杂系统中的其他工作一样，你会逐步弄清楚并调整可接受的告警阈值，让它们服务于你、客户和业务。

总结

领先的 DevOps 组织用流失客户数、损失收入等可量化的业务指标衡量问题的影响。因此，组织中每个人都更加重视生产和预生产环境的遥测。他们投入时间与资源构建和使用遥测，并依靠它快速识别和消除错误。