前面几篇总结了DevOps的基本概念和流动的技术实践，这篇总结下反馈的技术实践。
目录
1 建立能发现并解决问题的遥测系统
在应用及其环境中建立遥测，包括生产环境、预生产环境和部署流水线，通过遥测系统，先在远程采集点上收集度量数据，然后传输给接收端用于监控，分析造成故障的可能因素。测量一切，并且让工程师轻松地测量一切。
开发人员只创建它们感兴趣的日志事件，而运维人员只监控运行环境是否正常运行。当每一层都处在监控和日志记录中时，我们才可以使用其他的重要功能，如绘制喝可视化监控指标、异常事件探测、主动报警和升级等。
一种现代监控体系架构：在业务逻辑、应用程序和环境层收集数据，在每一层中，建立以事件、日志和指标为对象的监控。负责存储和转发事件和指标的事件路由器，此功能支持监控可视化、趋势分析、告警、异常检测等，通过采集、存储和聚合所有监控信息，能实现更深入的分析和健康检查，这里也是存储与服务有关的配置信息的地方，可以实现基于阀值的告警和健康检查。
将日志集中后，就可以在事件路由器中对事件计数来转换成度量指标，通过将日志转换为指标，就可以执行统计操作，比如使用异常检测，在问题周期的早期发现异常值和方差。理想情况下，我们所建立的遥测会确切地告诉我们感兴趣的事情发生在什么时候，发生在哪里，情况怎么样，监控数据还要适用于手动和自动分析，即使手里没有生成日志的应用，也应该能够分析。
从术语上来说遥测可以和度量互换使用，它涵盖了应用程序栈的各层级服务所产生的事件日志和度量指标，包括来自所有生产环境、预生产环境和部署流水线的事件日志记录和度量指标。
建立生产环境的应用程序日志遥测：建立应用程序和基础设施的遥测是投资回报最高的事情之一，价值流中的所有成员都将以各种方式使用遥测。日志要具有不同的级别：调试级别、信息级别、告警级别、错误级别、致命级别，在确定一条信息应该是错误还是警告时，设想一下在凌晨4点被叫起来处理错误吧。为了更容易地解释和给出所有日志条目的意义，我们应该对日志记录进行分级和分类，比如对非功能属性（如性能、安全性）和功能属性（如搜索、排序）。
使用遥测指导问题的解决：遥测技术赋予我们一种科学的方法，让我们能够对具体问题的原因和解决方案做出假设。
将建立生产遥测融入日常工作：通过将创建生产环境度量指标作为日常工作的一部分，不但可以及时地捕获问题，而且还可以在设计和运维过程中国呢不断暴露问题，从而能跟踪越来越多的指标。
建立自主访问的俄遥测和信息辐射器：生产监控指标具有高度的可见性，将信息辐射器放置在非常显眼的地方，在团队成员中传播着责任感，同时积极地展示出以下价值观：团队对观察者（客户、利益相关者等）毫无隐藏；团队对自己无所隐藏，他们承认并直面问题。
发现和填补遥测的盲区：在应用程序栈的每个层级中，需要以下度量指标：
业务级别，包括交易订单的数量、产生的营业额、用户注册数、流失率、A/B测试的结果等；
应用程序级别：示例包括事物处理时间、用户响应时间、应用程序故障等。
基础架构级别（如数据库、操作系统、网络、存储）：示例包括web服务器吞吐量、cpu负载、磁盘使用率等。
客户端软件级别：示例包括应用程序的出错和崩溃、用户端的事务处理时间等。
部署流水线级别：示例包括构建流水线状态、变更部署前置时间、部署频率、测试环境上线状态和环境状态。
通过利用遥测完整地覆盖以上领域，能够看到服务依赖的所有事物的健康状况，用数据和事实说明问题，而不是听信传言、指指点点、互相责备。
2 分析遥测数据以更好地预测故障和实现目标
用均值和标准差识别潜在问题：分析生产度量指标最简单的一种统计技术是计算均值和标准差。标准差的常见用途是，定期检查数据集的某个度量，如果与均值有显著差异就告警。
异常状态的处理和告警：在理想的情况下，我们会删除目前监控系统里所有的告警，然后，在每一个用户业务中断以后，我们会问什么指标能预测这个中断，然后在把这些指标加入到监控系统他中，并更加需要告警，再不断重复这一过程，这样，我们就只会收到预防中断的告警，而不是在故障发生以后遭到报警信息的轰炸。
3 应用反馈实现安全部署
在部署代码的时候，通过提供更快和更频繁的反馈，以及减少部署工作的批量大小，可以让它们获得代码部署的安全感，进而重拾信心。实现工作稳定和持续流动的诀窍就在于频繁地进行小规模的变更。仅仅实现部署流程的自动化是不够的，我们必须要将生产遥测的监控融入到部署工作中，同时还要建立文化规范，那就是每个人都对整个价值流的健康承担着相同的责任。
通过遥测使部署更安全：在部署过程中积极地监控软件功能相关的度量指标，以确保没有无意中破坏自己的服务，或者破坏了另一项服务。如果变更破坏或影响了其他功能，就会召集相关人员来诊断和解决问题，迅速恢复服务。我们的目标是在软件进入生产环境之前，在部署流水线中就发现错误，然而，还是存在着检测不到的错误，这就要依靠生产环境的遥测来快速恢复服务了，我们可以使用特性开关关闭出错的功能，或者向前修复这个错误，或者回退。
开发和运维共同承担值班工作：运维人员不再独自、孤立地解决生产环境中的代码缺陷，相反，所有人都会帮忙在修复生产环境缺陷和开发新功能之间实现平衡。
让开发人员跟踪工作对下游的影响：交互和用户体验设计中最强大的技术之一是情境访谈，产品开发团队观察客户在它们的自然环境中使用应用程序，这就是情景访谈。我们的目标是运用这种技术观察我们的工作对内部客户产生的影响，开发人员应用跟踪它们的工作，这样就可以看到下游工作中心在生产环境中是如何与它们开发的产品交互的。
让开发人员自行管理生产服务：让开发团队自己在生产环境中管理他们开发的服务，然后才能交由集中的运维团队管理，通过让开发人员自己负责部署工作并且在生产环境中提供支持，他们所开发的产品更有可能顺利地过渡给运维团队去管理，为了防止有问题的自管理服务进入生产环境，带来组织性风险，我们可以定义服务的发布要求，只有满足这些要求，服务才能与真实客户交互，并暴露给生产环境流量。为了帮助产品团队，运维工程师应该担任顾问，帮助他们做好服务部署到生产环境的准备。
当生产环境中的一个服务变得非常脆弱时，运维部门能把支持这个服务的责任交回开发部门。
4 将假设驱动开发和A/B测试融入日常工作
在构建一项功能之前，我们应该严肃地问自己：“应该构建它吗？理由是什么”，然后开展最廉价，最快速的实验，通过用户研究来验证设想的功能能否产生预想的业务成果，我们可以使用假设驱动的开发，客户获取渠道和A/B测试等技术。越快地实验、迭代并将反馈集成到产品服务中，我们就可以越快学习和超越竞争对手。
一项及其强大的用户研究技术是定义客户获取渠道并执行A/B测试，A/B测试技术是在直效营销中率先使用的，另一类称为大众营销和品牌营销。在这些营销活动中，通过实验来确定哪些形式的转化率最高。
在功能测试中集成A/B测试：在现代用户体验实践中，最常用的A/B测试技术是，在一个网站上，给访问者随机地展示一个页面的两个版本之一，即控制组A或实验组B，基于对这两组用户后续行为的统计分析，可以判断这两者的结果是否存在显著差异，从而找出实验组和结果之间的因果联系。有时，A/B测试也城为在线控制实验和拆分测试，在实验的过程中还支持多个变量，从而观察变量之间的相互作用，这种技术称为多变量测试。
在发布中集成A/B测试：通过在生产环境中快速轻松地按需部署，利用特性开关将软件的多个版本同时交付给多个用户群，可以进行快速、迭代的A/B测试，要实现这一点，需要在应用程序栈的各个层次上进行全面的生产环境遥测，通过勾选特性开关中的选项，可以控制能看到实验组版本的用户比例。
在功能规划中集成A/B测试：采用实验的方法进行产品开发，不但需要将工作分解成更小的单元，而且还要验证每个工作单元是否能够实现预期的结果，如果没有达到预期，就用替代方案修改工作路线图，并最终实现业务成果。
5 建立评审和协作流程以提升当前工作的质量
用不间断的同行评审取代定期检查，目标是确保开发人员、运维人员和信息安全人员始终紧密协作，从而使系统所做的变更可靠、安全、符合设计。
“过度控制变更”的潜在危险：传统的变更控制可能会导致意想不到的后果，例如延长交付时间，降低部署过程中反馈的强度和即时性。丰田生产系统的核心理念之一是“最了解问题的人通常是离问题最近的人”，随着工作和工作系统变得越来越复杂和动态，这在DevOps的价值流中是很典型的，在这种情况下，让距离工作越来越远的人来做相关审批的步骤，这实际上可能会降低工作成功的概率，就像之前就已经证明过的一样，开展工作的人和决定做这项工作的人之间的距离越远，审批流程的结果就越差。
一项研究发现高绩效组织更多地依赖同行评审，更少地依赖外部变更批准，组织越依赖变更审批，它在稳定性（平均服务恢复时间和更改失败率）和吞吐量（部署前置时间，部署频率）方面的表现就越差。
变更的协调和排程：每当多个团队在共享依赖关系的系统上工作时，就可能需要协调变更，以确保它们不会相互干扰，一般来说，组织的架构越是松耦合，组件团队之间需要沟通和协调的事情就越少，当系统架构真正做到了以服务为导向时，每个团队就可以进行高度自主的变更了，因为局部的变更不太可能造成全局的中断。松耦合团队里，为了降低风险，我们可能会使用聊天室的方式，发布变更通告，并主动地搜索可能存在的冲突；对于复杂的组织，以及系统架构耦合程度高的组织来说，我们可能需要更加小心地来安排变更。
变更的同行评审：同行评审的目标是通过工程师同事的仔细核查来减少变更错误。进行同行评审的合理时机，是将代码向版本控制系统中的主干提交时，这个时候变更可能会影响到整个团队，或者造成全局影响，至少工程师同事应该审核我们的变更，但是对于风险更高的领域，例如数据库变更，或者在自动化测试覆盖率不高的情况下对业务的关键组件进行变更，可能就需要领域专家做进一步的审查，或者做多重评审，保持小批量尺寸的原则也适用于代码评审，变更的批量越大，评审工程师理解这些工作需要花费的时间越长，他们的负担也越大。
代码评审的指导原则如下：每个人在将代码提交到主干以前，必须要有同行来评审他们的变更；每个人都应该持续关注其他成员的提交活动，以便识别和审查出潜在的冲突；定义哪些变更属于高风险的变更，从而决定是否需要请领域专家来进行审查；如果提交的变更尺寸太大了，以至于让人很难理解，换句话说，阅读了好几遍代码还是无法理解，或者需要提交者进行解释，那么这个变更就需要分解成多个较小的变更提交，使之一目了然。
利用结对编程改进代码变更：在常见的结对模式中，一名工程师扮演驾驶者角色，他是实际上编写代码的人，而另一名工程师则作为导航员、观察者或督导者。结对编程还能有益于知识在组织内的传播，以及信息在团队内部的流动。让经验丰富的工程师在经验不足的工程师实现代码的同步评审，这也是一种有效的教学和学习的方式。
评估pull request的有效性：被要求描述一个好的、表面评审过程有效的pull request时，必须足够详细地说明变更的原因、如何做的变更，以及任何已识别的风险和应对措施。
参考书《DevOps实践指南》，《持续交付发布可靠软件系统方法》
508
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
