把您的DevOps思维从工具转移到文化

DevOps建立在不断完善和发展基础之上，而员工是迭代过程的积极参与者。该技术的中心思想是促进员工自我学习和自我提高。

实时、数据驱动的IT决策非常具有挑战性，而且直到最近还是不可行。IT管理人员是在所谓 “泰勒式”工作模式下成长起来的——其中，运营、安全、开发等都是按照任务、目标和技能进行细分，导致相互孤立的工作风格，对成功的理解也不尽相同。此外，传统的管理结构不允许有创造性的思维，也不支持自我主动工作。要做出能够推动业务向前发展的决策，必须进行跨部门协作，并相互理解。我们正在进入数字化的新时代，协作方式的转变将决定能否成功。这种协作背后的推动力量不仅是工作流程的转变，更重要的是文化和思维方式的转变。

有了这一新理念后，所有部门都会合作参与那些影响整个企业的活动，因为他们理解每个部门和各种活动都会从整体上影响推动企业发展的系统和服务。这是关于处理相同数据集、共享任务和换位思考的一般原则。这也的确需要在文化上有所转变：各部门一起工作，提供客户所需的服务，促进早日取得业务成果。

传统的IT工作模式

与“泰勒式”工作模式同名，机械工程师Frederick Winslow Taylor想最终能够改变人们的工作方式，使之更加高效。Taylor在他的《科学管理原理》一书中敦促企业把工程原理应用到工厂工作中。他认为，通过一种“工程镜头”来检查员工的表现，管理层能够确定员工是以最有效的方式去完成任务。他认为，通过分析工作，能够发现“一种最佳方式”。然而，他并没有解释是否有多种“最佳方式”的可能性，尤其是跨部门、工作流程和技术的最佳方式。

相似的，传统的IT是把流程应用于运营，从而提高日常工作的效率。考虑到IT所关注的流程，就容易理解为什么当事情没有按计划进行时，管理人员把责任归到个人是很好的做法；而创造一种环境，让员工置身其中去尝试新方法——变得几乎不可能。最近我访问了一家企业，有人告诉我，如果问题出现在你的收件箱中，而且问题升级到了管理层时，就会有人专门找你，问题会更加严重，找不到解决办法。这种“谴责游戏”文化非常盛行，以至于没有人愿意承担生产问题。毫不奇怪的是，如果出了任何事情，支持部门的最终目的并不是去寻找解决方案，而是把问题归给个人，这样解决不了问题。

这种谴责文化很快会抹杀掉在培养开放、协作、创新和问责文化方面取得的所有进步。我看到越来越多的企业正在放弃这种自上而下的执行模式，因为他们看到了在以部门为中心的工作环境中工作有明显的好处。在我曾经工作过的一家公司——位于美国的一家有25年历史的传统的软件公司，他们改变了角色、部门结构，甚至是物理空间，以鼓励营造更为投入和协作的环境。

当出现问题时，他们并不是找替罪羊，而是使用共享数据和工具来进行“不指责的事后分析”，目的是解决现在的问题，防止以后再发生。结果，除了更快的发布，更少的错误以及更短的解决时间之外，他们发现还有很多切实的好处；部门内部和部门之间能够更好的协作，从而提高了工作满意度和员工保留率。

IT作为变革的代言人变得越来越复杂

数字化转型悄然而来。随之而来的是复杂的细分IT创新。另一家我曾工作过的公司——位于纽约的一家大型金融机构，也是纠结于此。它面临的压力是缩短新解决方案的交付时间，以便与创新金融企业相竞争——也称之为“FinTech（金融技术）”，但却受制于产品交付涉及到太多的孤立部门。在新兴的金融技术企业中，协调一致的各个部门能够在数小时内完成新功能的规划、开发和发布，而在传统企业中，不能相互协调的各个部门没有四周的时间根本无法批准已完成项目的发布。如果他们保留传统的部门结构，他们就没有机会跟上，更不用说赶上了。

这些根本性的改变要求IT和DevOps建立一种新的工作模式，以保持联系，相互关联，相互引导，而不是去努力跟上。ITOps、DevOps和其他的业务部门应协调一致的提供关键服务、系统和信息，以实现并维持关键业务成果。在与客户的交流中，他们认为敏捷、速度和质量是数字化转型的迫切需要。但要做到这一点，就需要文化上的转变——员工应通过领导感受到授权和激励，而不是被繁琐的流程所压制。我们怎样改变IT运营模式，实现这种文化上的转变，带来数字化转型？

理论上，DevOps工作流程打破了“泰勒式”壁垒，为更精简的方法开辟了道路。无论您是员工还是管理人员，由于每个人都会对业务怎样运营有不同的看法，因此，每个人都要与部门一起工作，这对于影响业务的活动是至关重要的。一家传统的欧洲银行现在便是这样运营的，该银行调整了部门结构——按照独立功能（开发、质保、运营）横向对齐的部门结构替代了按照业务服务（在线银行、贷款服务等）纵向对齐的部门结构。这有利于软件的“连续交付”模型，因为每个部门都拥有计划、构建、验证、部署和操作新技术所需的所有专家。每个人在履行个人职责时都有共同的目标。

借助于这种思想，每个人都能深入了解所有部门，被授权做出必要的改变，在同一页面上工作，同时朝着同一目标努力。但这并不是不受约束的授权，因为工作流程是开放的，结果是共享的，每个部门和个人都要对彼此负责，对管理负责，对业务负责。DevOps建立在不断完善和发展基础之上，而员工是迭代过程的积极参与者。该技术的中心思想是促进员工的自我学习和自我完善。过程在确保质量一致性和消除冗余方面起着核心作用，但文化思维转变的中心思想无疑是集中在换位思考上。

DevOps是以人为中心的，所以我们必须找到方法来衡量文化的变化。您可以针对客观指标来挖掘各种应用程序，例如部门和个人工作效率的差异，每周加班次数和员工时间表，但是衡量指标总是有主观的解释。通用数据架构支持所有相关者共享DevOps流程的可视化功能，这样，他们可以更轻松地进行协作和交流，获取客观数据，以便更快的做出决策，交付代码。然而，数据并非包揽一切。部门的思维方式从纵向转为横向，为部门成功创造了前所未有的机会——不仅是在数字世界里，而且在他们的日常生活中。

【本文作者系Andi MannSplunk首席技术推广官】

未经允许不得转载：DOIT » 把您的DevOps思维从工具转移到文化