1.7　障碍

如果DevOps解决了开发中长期存在的问题并有如此明显的好处，为什么不是所有的组织都采用DevOps实践呢？本节将探讨采用DevOps时遇到的障碍。

1.7.1　文化及组织类型

在讨论DevOps时，文化很重要。在跨组织以及同一个组织中的不同群体之间，与DevOps相关的文化问题都会影响它的形式与采用。文化不仅取决于你的角色，而且取决于你所在组织的类型。

DevOps的目标之一是缩短新功能或新产品投向市场的时间。在采用DevOps实践时，组织要考虑的一个问题是缩短面市时间所带来的收益与一些事情出现差错之间的权衡。几乎所有的组织都对风险感到担忧。但是，一个特定组织所担忧的风险取决于他们的活动领域。对一些组织来说，出现问题所带来的风险比尽快推向市场更重要。

在监管领域运作的组织（金融、医疗保健、公用事业服务）有他们必须遵守的规则，如果违反了运营规则，就会面临处罚，有可能还是很严重的处罚。即使处于监管领域的组织也可能有不受监管的产品。这样，一个金融组织也可以在某些产品上使用DevOps过程。对于需要更多监管的产品，这些实践可以修改。例如引入更多的看门人。我们将在第8章讨论安全及审计问题。

在成熟、行动缓慢的领域中运作的组织（汽车或建筑行业）有很长的前置时间。并且，虽然他们的截止日期是切切实实的，但他们很早就能预见到。

某些组织的客户在切换到其他供应商（supplier）时成本很高，例如企业资源计划系统，客户因为担心运行的稳定性而不愿意冒险。某些系统宕机时间的成本远远高于更快速引入一个新功能所能得到的竞争优势。

对于其他组织来说，灵活快速的响应比因为快速移动而偶尔产生的错误重要得多。

依赖于业务分析决定产品方向的组织希望在收集数据并根据数据采取行动之间的时间越来越短。因为下一个周期很快到来，出现的错误能够很快纠正。

面临激烈竞争压力的组织需要赶在竞争对手的前面把产品和新功能投向市场。

注意这些例子并不取决于组织的规模，而更取决于他们的业务类型。如果监管者监督你们并且能够强行规定你们的运营规范，或者产品特性的前置时间是好几年，或者你们的资本设备的预期使用期限是40年，那么你们很难灵活起来。

这里讨论的要点是企业有自己的运营环境，并会继承这个环境中的很多文化。第10章将会详细描述。有些DevOps实践是破坏性的，例如允许开发人员直接部署产品。另一些DevOps实践是增值的，它们不会影响产品整体的工作流或监管。把运维人员作为首要干系人的做法应该落入这个非破坏性的分类中。

一个行动缓慢的组织可能变得更加灵活，一个灵活的组织可能面临监管。如果你考虑采用DevOps实践，需要清楚3件事。

1）在你考虑的实践中隐含地包含了其他什么实践？不做持续集成就无法实施持续部署。独立的实践需要优先采用，先于有依赖关系的实践。

2）你考虑的特定实践是什么？它的假定条件、成本和收益是什么？

3）企业文化是什么，采用这个特定的DevOps实践的后果什么？如果这个实践只影响运营与开发，倒还好说。但如果需要修改整个组织结构和监管办法，那可以说是另一回事了。采用一种实践的困难之处是，它影响组织中的其他部分。但即使是一个开发团队和多个运维人员采用DevOps，让所有涉及的人都接受DevOps文化也是很重要的。采用DevOps的一种常见的失败情况是，你雇用了一个DevOps工程师，然后就认为万事大吉了。

1.7.2　部门类型

确定一个组织的文化的方法之一是看它的激励产生什么样的结果。依靠销售额提成的销售人员会很努力地推销。根据季度利润获取报酬的CEO会关注下一个季度的结果。这是人之本性。对开发人员的激励是生产并发布代码。理想情况下，他们受到的激励是生产没有错误的代码。但是有一部Dilbert卡通片显示了这种做法的困难之处。尖脑袋老板对每个发现并修复的缺陷都支付10美元，Wally的回答是：“好哇，今天下午我就可以为自己写出一部小客车来。”不管怎么说，开发人员得到的激励应该是让代码进入生产环境。

另一方面，对运维人员的激励是把宕机时间降至最低。这意味着要去检查并排除宕机的原因。仔细检查是需要花费时间的。而且，避免变更也是减少宕机的一个原因。“没有问题就不要修复”是一个几十年来广为人知的说法。

一般来说，开发人员受到的激励是做出变更（发布新代码），运维人员受到的激励是不要变更。这两种不同的激励机制培育出不同的态度，可能成为文化冲突的原因。

1.7.3　筒仓思维方式（Silo Mentality）

组织中的两个部门有一个共同目标——确保组织取得成功。这句话说起来容易，实际做起来要难得多。一般来说一个人对自己的团队最忠诚，其次才是整个组织。如果开发团队负责制定发布计划，该计划说明将实现哪些功能、以何种优先级实现，那么组织中的其他部门就会感到自己的权力被侵犯了，客户也可能会不满意。如果以前由运维人员完成的工作现在由开发人员完成了，那么运维人员的工作变少了之后会怎么样呢？

这种政治在一个组织中早已司空见惯，但重要性并不因此而降低，也不能因此就视而不见。

1.7.4　工具支持

我们前面描述了自动化过程的优势。这些优势是实实在在的，但也不是没有成本的。

每个工具的安装、配置和使用都必须具备专业技能。工具有新发布、新信息和新特征。使用工具的技能经验必须整合到组织中。

如果一个组织中的很多不同的开发团队使用同一套过程，那就必须有一个方法定义这些共同使用的过程，并确保所有的开发团队都遵守。使用工具意味着需要遵守隐含在工具中的策略。关于如何定义共同使用的过程，可参见第12章中的一个例子。

1.7.5　人员问题

按照Datamation 2012 IT薪水指南，一个软件工程师比一个系统管理员的薪水高50%。把系统管理员（运维）的任务转移给软件工程师（开发），完成任务的人员成本就增加了50%。这样，为了让完成任务的成本保持一致，用于完成任务的时间就必须削减1/3。为了真正赢得时间，还需要进一步削减，而自动化是节省这些时间的最常见方法。为了确定采用哪些DevOps过程以及如何采用，这是一个组织必须仔细研究的一类成本/收益分析。

具备现代技能集的开发人员供不应求，他们的工作量也很重。在他们的工作中增加更多的任务会加剧开发人员的短缺。