《DevOps实践指南》- 读书笔记（五）

Part 4 第二步 ：反馈的技术实践

在第三部分中，我们描述了如何建立从开发到运维的快速流动的工作流，以及它所需要的架构及技术实践。在第四部分中，我们将描述如何实现第二步工作法的技术实践，创建从运维到开发的快速且持续的反馈。

这个实践能加快并增强反馈回路，让我们识别出发生的问题，并把这些信息反馈给价值流中的所有人。这样就可以在软件开发生命周期的早期快速地识别并修复问题 ；在理想情况下，早在导致灾难性事故发生以前，问题就被处理掉了。

我们还将阐述在构建、测试和部署的流程中，如何对用户行为、生产故障、服务中断、合规问题和安全漏洞进行全面监控。需要探索和落实如下工作 ：

• 建立能定位和解决故障的遥测系统 ；
• 使用监控更好地预测故障，感知业务目标的达成情况 ；
• 将用户研究和反馈融入到研发团队的工作中 ；
• 为开发和运维提供反馈，让他们能安全地部署应用 ；
• 用同行评审和结对编程的反馈方式，提高工作质量

14. 建立能发现并解决问题的遥测系统

运维团队无法规避的一个问题是发生故障——一个小小的变更也会导致很多意外后果，包括服务中断，甚至是对所有客户造成影响的全球性故障。事实就是：运维团队面对的是复杂系统，没有哪个人能了解整个系统，能说清楚系统的每个部分是如何配合的。

为了能训练有素地解决问题，我们需要设计出能够持续遥测的系统。遥测被广泛定义为“一个自动化的通信过程，先在远程采集点上收集度量数据，然后传输给与之对应的接收端用于监控”。目标是在应用及其环境中建立遥测，包括生产环境、预生产环境和部署流水线。

本章的目标是通过建立全面的监控系统，确保服务在生产环境中正常运行。在出现问题时，能快速地定位，并做出正确的决策解决问题，而且最好是早在客户受到影响之前就解决。此外，监控让我们能够汇集对现实最好的理解，并在理解不正确时及时发现。

应急响应指标：

• MTTR：平均响应事件时间（Mean-Time-To-Resolution），表示某一问题从被首次报告到最终被技术人员解决所持续的时间。在网络安全领域，MTTR被用来表示网络安全事故从被首次发现到最终被安全运营人员解决之间的时间跨度。
• MTTD：平均故障检测时间（Mean Time to Detect），表示攻击者使用战术和技术在目标网络上首次获得立足到最终被网络或终端安全设备检测出来所持续的时间。
• MTTA：平均确认时间（Mean time to acknowledge）。MTTA是指从系统产生告警到人员开始注意并处理的平均时间。
• MTTI：平均调查时间（Mean time to investigate）。MTTI是指从确认一个安全事件到开始调查其原因和解决方案的平均时间。
• MTTC：平均遏制时间（Mean Time to contain）。MTTC是指安全团队找到威胁者并阻止他们进一步进入你的系统和网络所需的时间
• MTTF：平均故障时间（Mean Time to fail）。MTTF是指故障持续时间

14.1 建设集中式监控架构

运维监控和日志管理绝对不是新鲜事物，多年以来运维工程师已使用和定制监控框架（例如，HP OpenView、IBM Tivoli 和 BMC Patrol/BladeLogic）来确保生产系统的正常运行。监控数据通常使用在服务器端运行的代理或通过无代理监控（如 SNMP Trap 或基于轮询的监控）方式来采集。前端通常会使用图形用户界面展示，而后端经常使用诸如 Crystal Reports 等工具来补充。

现代的监测体系架构具有以下组成部分

• 在业务逻辑、应用程序和环境层收集数据： 在每一层中，建立以事件、日志和指标为对象的监控。日志可以在所有服务器上使用特定文件（如/var/log/httpd-error.log）来存储，但是最好将所有日志发送到公共日志服务中，这样更利于集中、轮换和清除。大多数操作系统都提供了这个功能，如 Linux 的 syslog、Windows 的事件日志等。此外，在应用程序栈的所有层次中收集指标，能更好地了解系统的活动状态。在操作系统级别，可以使用 collectd、Ganglia 等工具采集状态指标，如 CPU、内存、磁盘或网络的使用率等。使用其他工具来采集性能指标，这些工具包括 AppDynamics、New Relic 和 Pingdom 等。
• 负责存储和转发事件和指标的事件路由器： 此功能支持监控可视化、趋势分析、告警、异常检测等。通过采集、存储和聚合所有监控信息，能实现更深入的分析和健康检查。这里也是存储与服务（和它们支持的应用程序与环境）有关的配置信息的地方，可以实现基于阈值的告警和健康检查。

“监控是如此重要，所以监控系统需要比被监控的系统更具可用性和可扩展性。”

从此，术语遥测可以和度量互换使用，它涵盖了应用程序栈的各层级服务所产生的事件日志和度量指标，也包括来自所有生产环境、预生产环境和部署流水线的事件日志记录和度量指标。

14.2 建立生产环境的应用程序日志遥测

有了集中的遥测基础架构，我们必须确保对所有正在构建和运维的应用都建立充分的遥测。要实现这一点，开发和运维工程师必须把建设生产遥测作为日常工作的一部分，不仅仅是对新服务，对已有的服务也要建立充分的遥测

“NASA 每次发射火箭时，都用数百万的自动传感器来报告这一宝贵资产每个组成部分的状态。然而，我们通常不会对软件做同样的事。我
们发现，建设应用和基础设施的遥测是投资回报最高的事情之一。”

日志要具有不同的级别，其中的一些可能也会触发告警，举例如下

• 调试级别：此级别的信息是相关应用程序中发生的所有事件，最常用于调试的时候。通常，调试日志在生产中是禁用的，但在故障诊断期间要暂时启用。
• 信息级别：此级别的信息包括用户触发的或系统特定的操作（例如“开始信用卡交易”）。
• 警告级别：此级别的信息告诉我们可能的出错情况（例如，调用数据库花费的时间超过某个特定时长）。可能会因此而触发报警和故障诊断过程，而其他日志消息会有助于更好地理解事件的原因。
• 错误级别：此级别的信息侧重于错误状况（例如，API 调用失败，内部出错）。
• 致命级别：此级别的信息告诉我们何时发生了中断情况（例如，网络守护进程无法绑定网络套接字）

为了帮助确保拥有与服务可靠性和安全操作相关的信息，我们应该保证所有潜在的重大应用事件都生成日志记录条目

• 认证/授权的结果（包括退出）；
• 系统和数据的访问；
• 系统和应用程序的变更（特别是特权变更）；
• 数据的变更，例如增加、修改或删除数据；
• 无效输入（可能的恶意注入、威胁等）；
• 资源（内存、磁盘、中央处理器、带宽或其他任何具有硬/软限制的资源）；
• 健康度和可用性；
• 启动和关闭；
• 故障和错误；
• 断路器跳闸；
• 延迟；
• 备份成功/失败。

为了更容易地解释和给出所有日志条目的意义，（理想情况下）我们应该对日志记录进行分级和分类，比如对非功能属性（如性能、安全性）和功能属性（如搜索、排行）

14.3 使用遥测指导问题的解决

如本章开头所述，高绩效者在解决问题方面是训练有素的，这与依靠道听途说的常见做法形成鲜明对比，后者的平均清白证明时间（即花多长时间说服其他人，不是我们造成了中断）指标是非常糟糕的。

遥测技术赋予了我们一种科学的方法，让我们能够对具体问题的原因和解决方案作出假设。在解决问题的过程中，我们可以回答以下问题

• 监控系统中有什么证据表明了问题实际上正在发生？
• 在应用程序和环境中，导致问题的可能的相关事件和变更是什么？
• 可以做出什么假设，来证实提出的原因和结果之间的联系？
• 如何验证哪些假设是正确的，能成功地解决问题？

14.4 将建立生产遥测融入日常工作

为了让所有人都能在日常工作中发现并解决问题，我们需要让他们在日常工作中可以轻松地创建、展示和分析度量指标。因此，必须建立必要的基础设施和库，让任何开发或运维人员都能很容易地针对任何功能创建遥测。理想情况下，创建一个新的指标，通过仪表板显示出来，让价值流中的所有人都可以看到它，应该像编写一行代码那样简单。

图 14-3 显示了用一行代码创建的用户登录事件（在这个例子中，那一行 PHP 代码是：StatsD::increment("login.successes")）。图中显示了每分钟登录成功和失败的次数，图上的垂直竖线表示一次生产部署。

通过将创建生产环境度量指标作为日常工作的一部分，不但可以及时地捕获问题，而且还可以在设计和运维过程中不断暴露问题，从而能跟踪越来越多的指标

14.5 建立自助访问的遥测和信息辐射器

我们希望生产监控指标具有高度的可见性，这意味着要将其放置在开发和运维人员工作区域的中心，从而使所有感兴趣的人都能看到服务的现状。这至少要包括价值流中的每一个人，比如开发、运维、产品管理和信息安全。

这通常称为信息辐射器（information radiator），它是由敏捷联盟定义的：“这个通用术语指的是，团队放置在一个非常显眼位置上的手写、绘制、印刷或电子信息展示，让所有团队成员以及路过的人都可以快速浏览最新信息：自动化测试次数、速率、事故报告、持续集成状态等。这个想法起源于丰田生产系统。

通过将信息辐射器放置在非常显眼的地方，我们在团队成员中传播着责任感，同时也积极地展示出以下价值观：

• 团队对观察者（客户、利益相关者等）毫无隐藏；
• 团队对自己无所隐藏，他们承认并直面问题。

现在，我们可以将基础架构生成的生产环境遥测信息辐射到整个组织，还可以将此信息传播给内部客户，甚至外部客户。例如，创建可以公开浏览的服务状态页面，方便客户了解他们所依赖的服务的状态

14.6 发现和填补遥测的盲区

我们需要在所有环境中，在应用程序栈的每个层级中，以及支持它们的部署流水线中，建立充分而完整的遥测。我们需要以下层级的度量指标

• 业务级别：示例包括交易订单的数量、产生的营业额、用户注册数、流失率、A/B 测试的结果等。
• 应用程序级别：示例包括事务处理时间、用户响应时间、应用程序故障等。
• 基础架构级别（如数据库、操作系统、网络、存储）：示例包括 Web 服务器吞吐量、CPU负载、磁盘使用率等。
• 客户端软件级别（如客户端浏览器上的 JavaScript、移动应用程序）：示例包括应用程序的出错和崩溃、用户端的事务处理时间等。
• 部署流水线级别：示例包括构建流水线状态（例如：各种自动化测试套件的红色或绿色状态）、变更部署前置时间、部署频率、测试环境上线状态和环境状态。

通过利用遥测完整地覆盖以上领域，我们能够看到服务依赖的所有事物的健康状况，用数据和事实说明问题，而不是听信传言、指指点点、互相责备

通过尽早发现并修复问题，我们可以在问题还小、容易修复的时候就修复它们，进而减少对客户的影响。此外，在每次生产故障之后，我们应该识别是否存在遥测盲区，弥补它们就能更快地发现故障和恢复服务。更好的做法是，在功能开发阶段，在同行评审的过程中就能识别出这些盲区。

14.6.1 应用程序和业务度量指标

在应用程序层面，我们的目标是：不仅要确保产生的遥测能够反映应用程序的健康状况（例如内存使用、事务计数等），还要度量目前组织的业务目标的实现情况（例如用户增长数、用户登录次数、用户会话时长、活跃用户比例、某些特性的使用频率，等等）。

业务指标将是客户获取渠道的一部分，它是潜在客户购买商品的理论步骤。例如，在电子商务网站中，可度量的事件包括：用户在线时长、产品链接点击次数、购物车中的商品数量，以及完成的订单。

“通常情况下，功能团队会在获取渠道上定义目标，包括每个客户在一天中使用该功能的次数。有时候，在监控的不同阶段，对用户的非正式称呼分别是‘踢轮胎者’‘活跃用户’‘成员用户’和‘骨灰级用户’等。”

14.6.2 基础架构度量指标

与为应用程序度量指标所做的类似，对于生产环境和非生产环境的基础架构，我们的目标是确保建立全面的遥测指标，以便在任何环境中出现问题时，能够快速定位问题是不是由基础架构引起的。此外，还必须能够定位到究竟是基础架构的哪个组件引发了问题（例如，数据库、操作系统、存储、网络等）

我们希望尽可能多地向所有技术利益干系人展示基础架构的监控信息，而且在理想的情况下是按照服务或应用程序的逻辑来组织的。换句话说，当环境出现问题时，我们需要准确地知道应用程序和服务可能会或正在受到什么影响。

不管服务多么简单或者多么复杂，将业务指标与应用程序和基础架构指标聚合在一起显示，会有助于发现故障。例如，可能会看到新客户注册数下降到日平均值的 20%，然后还立即发现所有数据库查询花费的时间是正常情况的 5 倍，这使我们能够把精力集中在解决问题上。

“我们不是根据停机时间来衡量运维，更好的做法是根据停机所造成的实际业务后果来衡量开发和运维团队：我们应该获得却没有获得的业务收益是多少。”

14.6.3 显示叠加的指标组合

为了提高变更的可视化程度，可以在监控图形上叠加显示所有生产环境的部署活动。例如，对于处理大量入站事务的服务，生产环境变更可能会导致明显的下跌周期，在此期间，应用的性能由于所有高速缓存查询失效而骤降。

为了更好地理解和保持服务质量，我们要了解性能何时能恢复，并且如果有必要，还要实施性能提升方案。同样，我们还想叠加其他有意义的运维活动，例如当服务正在维护或备份时，有可能需要在某些地方显示告警或者暂停告警

14.7 小结

在问题发生时就能发现问题是多么地重要，这样才能及时地找出原因，并迅速补救。无论是在应用程序、数据库还是生产环境中，通过使服务的所有组成部分都发送遥测信息以便进行分析，可以早在故障导致灾难之前，甚至是早在客户注意到问题之前，就发现并解决问题。这样不仅能使客户更加满意，而且通过减少救火和危机次数，工作压力也会减轻，倦怠程度也会降低，工作也会更加愉快、更富有成效。

15. 分析遥测数据以更好地预测故障和实现目标

本章，我们将创建工具来识别隐藏在生产环境遥测中的差异和微弱的故障信号，从而避免灾难性故障的发生。本章会介绍大量统计技术，并通过案例研究来讲解它们的用途

本章会探讨很多统计和可视化技术（包括异常检测），我们可使用它们来分析遥测数据，从而更好地预测问题。这样，我们就能够以更快的速度、更低的成本，早在客户或组织中的任何人受到影响之前就解决问题。此外，我们还将创造更多的数据使用场景，帮助我们做出更好的决策，实现组织的目标。

15.1 用均值和标准差识别潜在问题

分析生产环境度量指标最简单的一种统计技术是计算均值（或平均数）和标准差。通过这种方式，我们可以创建一个过滤器，用来检测度量指标与正常值显著不同的情况，甚至配置告警，以便触发修复动作（例如，当数据库查询速度明显低于平均值时，在凌晨 2 点通知生产环境的值班员进行排查）。

标准差的常见用途是，定期检查数据集的某个度量，如果与均值有显著差异就告警。例如，当每天未经授权的登录次数比均值大三个标准差时就告警。只要这个数据集呈高斯分布，我们就预计只有 0.3%的数据点会触发告警。

即使只是一种简单的统计分析，它也是有价值的，因为再也不必设置静态阈值——如果跟踪的是几千或几十万个生产指标，这样是不可行的。

在本书的后续内容里，我们将交换使用术语遥测、度量和数据集。换句话说，度量（例如“页面加载时间”）将映射到一个数据集（例如，2 毫秒、8 毫秒、11 毫秒等），统计学家用后者来描述一个数据点矩阵，其中每一列代表对其执行统计操作的一个变量。

15.2 异常状态的处理和告警

在当前这个阶段，我们将复制以上实践成果。其中一个最简单的方法是：分析在近期（例如30 天内）遇到的最严重的事故，并建立一个遥测列表，用来更早、更快地检测和诊断问题，以及更方便、更快捷地确认已经实施了有效的修复措施。

例如，如果 NGINX Web 服务器停止对请求做出响应，我们会查看主要指标，它们可能已提前警告我们，我们已开始偏离标准操作。例如：

• 应用级别——网页加载时间正在增加等；
• 操作系统级别——服务器闲置内存不足、磁盘空间不足等；
• 数据库级别——数据库事务处理时间超出正常值等；
• 网络级别——负载均衡器背后运行的服务器数量下降等。

上述所有指标都是生产环境事故的潜在征兆。对于每一个这样的指标，我们将设置告警。当它们偏离均值足够多时，就发出告警，通知相关人员采取纠正措施

通过对所有更弱的故障信号重复以上过程，我们就可以在软件的生命周期中更早地发现问题，从而减少影响客户的事件的发生次数。换句话说，我们不但要主动地预防问题，而且要进行更快速的探测和修复。

15.3 非高斯分布遥测数据的问题

使用均值和标准差来检测异常是非常实用的。然而，在运维中我们会用到许多个遥测数据集，对它们都使用这些技术，并不一定会产生预期的结果。

换而言之，当数据集里的数据没有呈上述的高斯分布（钟形曲线）时，使用与标准差相关的属性就不合适了。例如，我们正在监控网站每分钟的文件下载量，需要检测的是下载量异常大的时段。例如，当下载率比均值大三个标准差时，我们就可能要主动地增加更多的带宽。

Nicole Forsgren 博士解释说：“运维中的很多数据集呈我们所谓的‘卡方’分布。对这样的数据使用标准差，不仅会导致告警过度或告警不足，还会产生荒谬的结果。当并发下载量比均值低三个标准差时，结果会是负数，这显然是讲不通的。”

Netflix 利用了这样一个事实：其消费者的浏览模式有着惊人的一致性和可预测性，尽管未呈高斯分布。图 15-4 反映的是在整个工作周内每秒的客户请求数，展示了从周一到周五客户浏览模式是规律和一致的

15.4 应用异常检测技术

在监控数据并不呈高斯分布的情况下，我们仍然可以使用各种方法来找到值得关注的差异。这些技术广泛地分类为异常检测，其通常的定义是“搜索不符合预期模式的数据条目或事件”。其中的一些功能可以在监控工具里找到，而其他功能可能需要统计专家的帮助。

我们采用了称为平滑的统计技术，它对于时间序列数据特别适用，这意味着每个数据点都有一个时间戳（例如，下载事件、已完成的事务处理事件等）。平滑技术通常涉及使用移动平均数（或滚动平均数），它利用每个点与滑动窗口中的所有其他数据的平均值，来转换数据。这样做有助于抑制短期波动，突出长期趋势和周期。

图 15-6 中展示了这种平滑技术的效果。黑线表示原始数据，而灰线表示 30 天的移动平均数（即 30 天的平均值轨迹）。

我们可以预期，与用户有关的大量遥测数据将具有周期性/季节性的相似性——网络流量、零售交易、电影观看以及许多其他用户行为，其每日、每周和每年的模式都是惊人地规律和可预测。这让我们可以检测出与历史规律有差异的情况，例如，周二下午的订单交易率降至周平均数的 50%

图 15-7 显示了某电子商务网站每分钟的交易次数。注意在这幅图中，每周的交易量是在周末下降的。目测第四周发生了特殊的状况，因为周一的交易量并没有恢复到正常水平。这表明我们应该对这个事件进行调查。

15.5 小结

本章探讨了几种用于分析生产环境遥测数据的统计技术，通过它们能更早地发现和解决问题，并且能在问题较小的时间予以解决，从而避免造成灾难性后果。这些技术使我们能识别出那些微弱的故障信号，并及时采取行动，从而建立一个更安全的工作系统，同时提高实现目标的能力。

16. 应用反馈实现安全部署

我们必须要将生产遥测的监控融入到部署工作中，同时还要建立文化规范，那就是每个人都对整个价值流的健康承担着相同的责任

本章将建立反馈机制，让我们在服务生命周期的每个阶段（从产品设计到开发和部署，再到运维和最终下线），都能够持续地改善价值流的健康状况。这样，就可以保证服务始终处于“就绪”的状态，即使是在项目的初始阶段，同时还可以从每次发布和生产问题中总结和学习，并将经验用于未来的工作中，从而提高安全性和每个人的生产力。

16.1 通过遥测使部署更安全

在这个阶段，我们确保在任何人执行生产部署时，都积极主动地监控生产环境的度量指标，这可以让部署人员（无论是开发人员还是运维人员）在新版本在生产环境中运行以后，快速地确认功能是不是按预期正常运行。毕竟，在这个新版本按预期在生产环境中运行以前，我们都不应该认为代码部署或生产环境变更已经完成

如第三部分所述，我们的目标是在软件进入生产环境之前，在部署流水线中就发现错误。然而，还是存在着检测不到的错误，这就要依靠生产环境的遥测来快速恢复服务了。我们可以使用特性开关关闭出错的功能（这通常是最简单且风险最小的选择，因为它不涉及生产部署），或者前向修复这个错误（即为了修复缺陷而修改代码，然后通过部署流水线将代码变更部署到生产环境），或者回退（例如，使用特性开关切换回之前的旧版本，或通过蓝绿部署、金丝雀发布等模式，将出错的服务器做离线处理）

虽然前向修复通常是危险的，但是当拥有了自动化测试、快速部署流水线以及全面的遥测之后，我们就可以快速地确认生产环境中的一切是否正常运行，这样其实是非常安全的。

• 前向恢复：指系统进行可靠性设计时，在可能发生故障的进程上设置一系列检测点，要求检测点提供尽可能多的故障信息，并在进程前方预先设置一个或若干个恢复点，系统可以在这些点上从预定的状态开始恢复工作，最终能够得到一个可以接受的输出序列。前向恢复适用于时空资源比较苛刻，但实时性要求又比较强的系统。由于它没有进行完整的运算，所提供的服务往往是功能降级的。在存在多个恢复点时，根据故障检测得到的信息，可以选择服务损失最小的恢复点开始恢复。因此，前向恢复需要对故障可能的影响进行估计，选择究竟从哪一点开始继续运行，并对最终结果可能带来的偏差以及因丢失了一部分服务使得服务的降格进行估计。
  

• 后向恢复：指在系统进行可靠性设计时，在可能发生故障的进程上设置一系列检测点，要求检测点提供尽可能多的故障信息。并在检测点进程后方设置一系列一个或若干个恢复点，当检测点检测到一个故障时，系统就复位到故障前进程经由的一个恢复点。恢复点能够保持先前进程经由时的状态（数据），以便故障排除后，可以从这个状态重新开始进行从该恢复点到到检测点之间的运算，得到正确的结果。这种恢复策略的优点是系统恢复不造成功能的降级；缺点是增加了执行时间和空间。
  

16.2 开发和运维共同承担值班工作

每一项产品功能都标记为“完成”并不代表业务目标已经实现。相反，所有功能都在生产环境中按照设计正常地运行，没有引起重大的故障，也没有引发计划外的运维或开发工作，才是真的“完成”。

ITIL 将“保证”定义为服务能在生产环境中可靠地运行一段预定时间（例如两周）而无需干预。理想情况下，这个“保证”的定义应该纳入到“完成”的定义中。

这种做法对各种团队都适用，包括面向市场的团队、负责开发和运行功能的团队，以及以职能为导向的团队。

不管团队的组织结构怎样，基本原则是不变的：当开发人员获得应用程序在生产环境中运行的反馈时，包括故障的修复状况，他们与客户之间的距离就更近了，这会使价值流中的所有人都受益。

16.3 让开发人员跟踪工作对下游的影响

交互和用户体验设计中最强大的技术之一是情境访谈。产品开发团队观察客户在他们的自然环境中（通常是在他们的办公桌前）使用应用程序，这就是情境访谈。通过情境访谈，通常会发现客户在使用产品的过程中所遇到的困难，例如，在日常工作中执行一项简单的任务也需要很多次点击操作，需要在多个屏幕之间复制和粘贴文本，或者需要在纸上记录信息。其实这些都是补偿性行为，是由应用程序的可用性不足造成的。

我们的目标是运用这种技术观察我们的工作对内部客户产生的影响。开发人员应该跟踪他们的工作，这样可以看到下游工作中心在生产环境中是如何与他们开发的产品交互的。通过这种方式，我们获得了对代码的非功能方面（包括所有与面向客户的功能无关的元素）的反馈，并能找到提高应用程序的可部署性、可管理性、可维护性等的方式。

通过进行用户体验观察，能够在源头保证质量，并对价值流中的其他团队成员产生同理心。理想情况下，用户体验观察有助于我们创建应用的非功能需求，并将其放入共享的待办工作中去，最终我们可以主动地将它们落实到构建的所有服务中，这是 DevOps 文化建设工作的一个重要组成部分。

16.4 让开发人员自行管理生产服务

即使开发人员平时在类生产环境中编写和运行代码，运维团队仍有可能遇到导致灾难性事故的产品发布，因为这其实是我们第一次看到代码在真实生产条件下的表现。出现这种结果的原因是，在软件生命周期中运维学习往往进行得太晚了。

为了解决这一问题，谷歌的一项实践是值得参考的。他们先让开发团队自己在生产环境中管理他们开发的服务，然后才能交由集中的运维团队管理。通过让开发人员自己负责部署工作并且在生产环境中提供支持，他们所开发的产品更有可能顺利地过渡给运维团队去管理。

为了防止有问题的自管理服务进入生产环境，带来组织性风险，我们可以定义服务的发布要求。只有满足这些要求，服务才能与真实客户交互，并暴露给生产环境流量。此外，为了帮助产品团队，运维工程师应该担当顾问，帮助他们做好将服务部署到生产环境的准备。

通过建立服务发布指南，有助于确保用整个组织的集体智慧，特别是运维团队所累积的经验，去帮助每一个产品开发团队。服务发布指南和要求可能包括以下内容。

• 缺陷计数和严重性：应用程序是按设计运行的吗？
• 告警的类型/频率：在生产环境中应用程序所产生的告警数量是否太多，无法得到支持？
• 监控覆盖率：监控覆盖的范围是否够大，能够为恢复故障服务提供足够的信息？
• 系统架构：服务松耦合的程度是否足以支持生产环境中高频率的变更和部署？
• 部署过程：在生产环境中代码部署的过程是不是可预测的、确定性的和足够自动化的？
• 生产环境的整洁：是否有迹象表明生产习惯已经足够好，可以让其他任何人提供生产支持？

目前，我们还可能想了解，现在或者未来，这项服务是否要遵从任何监管目标。

• 服务是否产生了大量的收益？（例如，如果其收入是美国一家上市公司总收入的 5%以上，那么它就是一个“重要账户”，必须遵守 2002 年《萨班斯奥克斯利法案》第 404 条。）
• 服务的用户流量或停机/损害成本是否很高？（即运维问题是否会导致可用性或声誉风险？）
• 服务是否存储付款卡持有者信息（如信用卡号）或个人身份信息（如社会安全号码或病人护理记录）？是否存在可能产生监管、合同义务、隐私或声誉风险的其他安全问题？
• 服务是否有任何其他监管或合同要求，如美国出口监管、PCI-DSS、HIPAA 等？

以上信息将确保我们有效地管理与服务相关的技术风险，以及潜在的安全和合规风险。它还为生产环境的控制和设计提供了重要的输入

1. 通过在开发过程的最初阶段融入可运维性需求，并让开发人员先自行管理自己的应用程序和服务，可使新服务发布到生产环境的过程变得更加顺畅、容易和可预测。然而，对于生产环境中的现有服务而言，我们需要另外一种机制来保证运维不会陷在无法支持的服务中无法自拔。这对于功能导向的运维组织尤其重要。
2. 在这个阶段，我们可以建立服务回传机制。换句话说，当生产环境中的一个服务变得非常脆弱时，运维部门能把支持这个服务的责任交回给开发部门
3. 在服务变为由开发人员管理时，运维部门的角色就从提供生产支持变为开发部门的顾问，帮助开发团队再次将服务变成生产环境就绪状态。
4. 这种机制对于运维人员来说就像是减压阀，它确保运维团队不会陷入这种境地：不得不管理脆弱的服务，同时技术债务不断累积，局部问题扩大为全局问题。这一机制还有助于保障运维部门拥有足够的能力去开展改进工作和预防性项目。

案例
谷歌为发布新服务的两个关键阶段建立了两套安全检查，分别是交接就绪审核（LRR）和上线就绪审核（HRR）。

谷歌在将任何新服务公开给客户并且接收生产流量之前，必须进行 LRR，而且要签字验收，而当将服务转换到运维管理状态后（通常是在 LRR 几个月之后）执行 HRR。LRR 和 HRR 审核清单其实是相似的，但是 HRR 更加严格，并且验收标准更高，而 LRR是由产品团队自行执行并上报的。

LRR 和HRR 审核清单是建立组织记忆的一种方式。

16.5 小结

本章讨论了反馈机制，它使得我们可以在日常工作的每个阶段改进服务，不管是将变更部署到生产环境，在出现问题时请求工程师修复代码，让开发人员跟踪下游工作，建立非功能性需求来帮助开发团队编写更优的生产就绪代码，还是将有问题的服务交回给开发团队自己管理。

通过创建这些反馈回路，可以使生产环境的部署更安全，提高所开发代码的生产就绪程度，并且通过强化共同的目标、责任和同理心，在开发和运维团队之间建立更好的工作关系。