上期介绍了DevOps的流动原则，是让开发到运维快速的流动。而反馈原则是从运维到开发快速的反馈。这两个原则周而复始运转才能为客户交付最好最快的软件服务。今天我们来聊聊”反馈原则“。

及时发现问题

一个服务/产品的交付历经了很多个过程，从需求分析，原型设计，架构设计，编码，测试，发布，集成测试，验收测试，一直到上线。每个阶段都有工作者参与其中。任何一个问题的产生都是有原因的，如果说我们不能阻止问题的产生，但是我们可以第一时间发现问题，并且让问题立即暴露出来。例如：一个用户需求产品经理没有分析透彻，到了开发阶段程序员在编码的时候就会遇到需求上没有描述到的情况，这个时候程序员就可以提出问题，产品经理就需要对这个需求进行重新分析从而澄清问题。这个是一个好的例子。当然也有一个问题经历了以上几个步骤，每个步骤的参与者都没有发现问题，最后流到客户上手的例子。这个是我们不希望看到的。

解决分析问题

我以前会遇到这种情况，在写代码的时候发现一个潜在的问题，需求和设计上面都没有提到。但是，这个错误如果放到现在的系统中显然是有问题的。如果采取事不关己高高挂起的态度，心想：“反正我按照需求和设计实现代码就好了，出了问题有人背锅！”。那么这个问题是永远无法发现了，以后类似的问题也会经常在系统中出现。那么出现问题我们应该如何处理。

第一，上游环节出现问题，一定不要把问题带到下游环节。在上游环节就把问题解决掉。

第二，暂停上游环节的工作，避免新的问题继续产生。

第三，建立PDCA 环，计划（Plan），实施（Do），检查（Check），改进（Act）避免此类问题不再发生。

源头保证质量

什么是源头，相对下游来说上游就是源头。产品经理是开发的源头，需求质量不过关代码就受影响；程序员是测试人员的源头，程序质量有问题测试就会受影响；测试人员是客户的源头，如果问题都被放过了，那么就不能给客户带来价值。所以，保证源头就是保证交付的质量。对每个过程和阶段做监控是我们要关注的。

需求阶段：需求评审，需求确认，需求宣讲。

开发阶段：代码审核，结对编程，单元测试。

测试阶段：冒烟测试，回归测试，验收测试。

发布阶段：自动配置，自动部署，自动检测。

客户同理心

客户分为两种，内部客户和外部客户。外部客户是通常意义的客户，我们为客户提供软件交付，满足客户的需求，为客户创造价值。内部客户就是我们的下游。产品经理把开发人员作为客户，开发人员把测试人员作为客户。我们在做任何动作，发现任何问题，做任何决定的时候都要想想我们的“客户”，是否对他们有利。我们要把自己放在客户的角度来看问题，好多问题在当下就会被解决。