3.4 常见的理解误区

本节将介绍常见的理解误区，分别如下。

1.DevOps强调交付时间，天下武功，唯快不破

在软件开发等科技领域，价值流同样存在，而且制造业的原则和经验在这些领域同样适用：同样是由业务部门提供明确的需求定义，将开发、测试、部署交付给运维团队，最终价值流向客户。区别于传统制造业的产品，科技领域的价值流更多是以服务的形式进行交付的。

只有将我们开发、测试完成的软件运行在面向最终客户的生产环境之上时，I T领域的价值流动才算完成，在那之前都只是“工作制品”（WIP）而已。

在DevOps中，交付时间也不是全部。“快”很重要，可靠性、稳定性、扩展性、安全性同样重要。DevOps追逐的快速价值流动，是建立在不会因此而带来服务中断、安全事件等混乱事件的基础之上的，所以也需要“稳”。

2.DevOps适合小型团队，大型团队难以开展

当开发人员的数目增加的时候，由规模效应带来的沟通、协作等额外作业不可避免地会对个体开发者产生比较明显的影响。就像《人月神话》一书中所解释的那样，当项目延迟时，增加开发者不但会降低个体开发者的效率，也会降低整体的效率。

而 DevOps 则从另外一个角度告诉我们，当我们有合适的架构、合适的技术实践、合适的文化氛围之时，小的团队也能高效地完成作业。同时，大规模的团队也同样适合DevOps。Google等公司已经证明即使对于数千人的团队，架构和实践依然能使得团队像初创公司那样产生很好的效率。

同时，DORA调查结果也表明，当人数增加时，由践行DevOps的高效能人员所组成的团队依然能够保证与小团队同样的线性增长效率。

3.给予开发团队较多权责，容易产生更多问题

在20世纪制造业变革的浪潮中，很多高绩效的制造企业的做法让人眼前一亮。这些制造企业不再将工人视作工具，而是给予工人一定的权责，使得工人能够在他们的日常工作中进行试验和改进。区别于传统企业的做法（限定的流程，出现错误进行惩罚），这种企业认为不断地改进才应该是常态，甚至已经将其变成了例行的工作内容。

同样的情况，在企业的 DevOps 实践中也得到了验证，给予开发团队一定权责会给企业带来更好的活力。很多号称敏捷开发的团队在实际作业时遵从其他团队所做的需求，而没有提出自己意见的权利，这个限制可能会带来很多实际的问题，而最终的结果则可能是产品不会取悦客户，也无法交付所期待的业务结果。敏捷开发的一个重要目标是在整个开发过程中都去寻求客户的真正需求，这使得开发团队能够得到重要的信息，但是如果不管开发团队发现了什么，他们都没有任何权利对需求进行改变，创新能力将会被极大地阉割掉。

4.反馈的信息过于繁杂，只重视主要信息即可

复杂系统反馈的信息的确非常多，但这并不意味着只重视主要信息即可。前提是我们能分辨出主要信息和次要信息，但是在现实的世界中，这个往往很难。而微弱的征兆如果得不到足够的重视，灾难性的后果迟早会发生。

2003 年，在完成了 16 天的研究任务后，美国的哥伦比亚航天飞机在返回大气层的时候发生爆炸，原因是起飞时燃料罐隔热泡沫发生脱落。而这个问题在航天飞机返回大气层之前，已被工程师发现并上报，但是没有得到重视，他们被告知泡沫问题不是什么新问题，以前也出现过，从来没有出过事。这个问题一直没有得到重视直到灾难发生。2006年，有关人员对美国国家航空航天局（NASA）的文化进行了剖析，他们将组织模型分为标准模型和试验模型两种，组织模型分类及说明如表3-4所示。

表3-4 组织模型分类及说明

NASA的模型则为标准模型，对模型的错误选择导致本来应该得到重视的新的信息被忽视。这一惨痛的教训告诉我们，应当对每次试验的结果进行认真的审视，通过放大反馈予以重视，以保证微弱的征兆也不会被忽视。