如果你在路上遇见了DevOps，干掉它！
本次的分享不谈技术只谈谈想法。我从事 IT 行业 41 年了，这 40 年的经验并不是说我就是权威、专家，但在洞察这方面做得更好些。
1980 年代，当时 IT 除了被发展出来，很多的是一些项目的管理，实际上我们也做了很多的项目，有很强的能力掌握项目。
1990 年的时候我们开发了很多的系统，如开发一个专业的管理系统。2000 年的时候，就有敏捷这一概念，从 2000 年开始我们就说 DevOps。
可以看到这上面有四大转变，从传统转变到现代，凭借 40 年的经验，我是非常认真的在思量，DevOps 对于我之前所看到的所有的变革，是一个颠覆性的变革，而且前景非常好。
大家都是 DevOps，实际上我想关注 IT 这个事情到底发生了什么？我希望我的洞察和一些看法能够激发大家相关的灵感。比如说上图你可以看到是只鸟，你还可以从另外一个角度来看。
下面的内容我会给到大家一些不同的视角去看干掉 DevOps 的要点：
DevOps 没啥用，除非你能够在一个全局性的视野下，将其与业务建立创造性的合作。
这个要点是非常重要的，我再强调一下，就是和业务共同创造价值的情况下才有用。这是非常重要的观点，这样的话 DevOps 才会有用。
下面将以四块内容来阐述：
探讨 DevOps。
向业务执行层 ”兜售” DevOps。
发现最薄弱的环节。
采用正确的态度。
探讨 DevOps
盲人摸象的故事大家都知道的，对于 DevOps 来讲，他们所摸到的都是一样就是 DevOps。
如果大家在谈论 DevOps 的时候需要谨慎，他们说的真的是一个 DevOps，还是只是一个市场行为？
我们要真正知道 DevOps 的价值，如果说不是盲人而是六个业务盲人和 IT 来摸这个大象时，他们所关注的是什么呢？
是投资回报率（ROI）。我的想法是希望将我们的 DevOps 和 ROI 能够紧密地结合，这其实也是一个目标。
我们来用一个简单的框架来阐述，比如说 IT 行业有行业的指引，做得更快、更便宜，然后提供更好的 IT 服务，这是 IT 人员所做的事情，他们通过这个方式来提供 IT 的服务。
同时我们给商人提供更好的信息系统信息服务，帮助他们达成商业的目标，这个模型是比较简单的。商人认为是一种投资，所以他们想要投资的回报。
让我们把它分解一下，如果我们只看 IT 的话，它包括开发和运维，并且是非常高的精度。
如果说我们看一下商业，就是需求和使用，这是一个非常高的简单的系统，能够具体化 IT 的要求，同时它能够使用系统，这一点是非常高层的模式，还需要继续更详细的探讨。
接下来看一下价值链，看从一个商业的角度或者是一个信息的角度，因为商业需要业务、信息、应用和基础设施。在最开始的时候做投资的话，需要在信息科技上和解决问题上做投资。
为了做投资他们需要具体化需求，知道要去做什么，要去研发体系等，开发需要基础，设施需要平台，需要工具来做项目。运维也需要平台也需要基础设施，也需要工具来提供更好的信息系统，也包括应用。
如果我们想一想敏捷的话，在价值流中敏捷在哪儿呢？它其实是在信息应用和商业之间搭起了一座桥梁，这些是可以实现的目标。
关键词是潜在的可实现的，它不是已经部署过的实现的而是潜在的，需要你去部署。
现在是在生产当中的，你看一下信息体系，它其实就是运作，这一点非常好，我们的信息体系也是在运作当中，那坏消息是我们不能产生任何价值。
因为一直到现在为止，没有人应用这些信息体系，没有人创造价值，这个领域是我们称之为 IT 信息服务流程。
使用者使用这样一个系统，希望生成价值。他们希望价值和商业的价值是一样的，所以我们有一个圈，就是价值圈。
非常感兴趣的一点是使用者如何使用你的信息体系，你认为他们能够有效地使用信息体系吗？
经常我们的使用者并不是有效地使用信息体系，所以不会产生足够的价值。如果我们能够想到限制理论，最薄弱的点在哪里呢？你就可以去想想，投资是不是够好？是不是正确地把握了需求？能不能正常使用？
我们遇到了一个非常有趣的观点，那就是 DevOps 的定位。一般提到 DevOps 都不太知道所指的是什么？它怎么把研发和运维联系在一起呢？
我们应该是 DevOps If，那就是基础设施的运维或者是业务的运维，我认为这是狭义的定义，只是聚焦在需求、开发、基础设施、持续交付、持续部署。
但是 DevOps 可以应用在更宽广的概念上，去包括商业与 DevOps 的范围。
因为 DevOps 的原则是能够让你更好更多创造更多合作，这是 DevOps 更宽广意义上的概念。
当大家谈到 DevOps 的时候，他们到底谈的狭义的 DevOps，还是广义的 DevOps 都是正确的。
我推荐两本书，《凤凰项目》和《Devops Handbook》，《凤凰项目》已经翻译成中文了，《Devops Handbook》会在今年年底翻译成中文。
《Devops Handbook》这本书与凤凰项目一脉相承，他们有一些原则有一些技术实践，能够帮助你快速部署工作流，进行测试，进行部署。
同时还能帮助你实现世界级的可靠性、可用性和安全，有敏捷、信息系统的稳定性，这个其实就是 DevOps 的全部内容，不仅仅是开发还有运维。
《Devops Handbook》这三位作者 John Willis、Patrick Debois、Gene Kim。
我认为三位作者能够写出《Devops Handbook》，是能够让你非常信任他们，因为他们知道自己在写什么，让你言之有悟的。下面列举一些：
DevOps Handbook 原则和技术实践：
DevOps 的 3 种途径。
快速工作流。
快速、频繁、良好的反馈。
持续学习和实验。
将信息安全、变更管理和合规集成到日常工作中。
DevOps Handbook 技术实践：
开发。
运维。
基础设施。
平台
管道(pipeline)
工具
DevOps Handbook 原则：
工作可视化，进行中的工作(WIP)， 批量大小，转移(handoffs)，限制，困难，浪费。
问题，知识，质量，下游优化。
关于改进、扩散、弹性、安全、学习、文化的制度化。
从而我们可以进行持续的程序的开发、程序的运维，然后持续的交付和持续的集成等。
这个是用于持续集成、持续交付部署当中的一些实践。
这个是广义的应用，可以看到这当中所涉及到的业务是很多的。在 IT 这个部门当中你可以采用更多的价值并且提高你的速度、可靠性，还有个人的可靠度和提高业务的功能性。
DevOps 是有经济效益约束理论，还有敏捷的延伸。当时是有这些原则和技术实践，这上面有三种途径，同样的也是一个耦合的架构。
它可以利用在小的团队当中，也可以用于狭义和广义上面。同样的有自动化、精益、衡量和分享。还有文化，这也是非常重要的一部分。
向业务执行层“兜售”DevOps
这是典型的高层的对话。怎么说服 CEO？你必须要说商业上的话，必须说 MBA 听得懂的话。
接下来说说商业上可用的话，我们要了解 DevOps 的收益，一个是 DevOps 的报告，一个是 Dora 的有关于转型的报告。
我还是强调一下，就是快速交付更可靠、更便宜的信息服务，这是关键点。
首先我们看看 IT 系统，如何利用 DevOps 来提升这些相关点。来看看这当中关键点，如有用的功能性。
从 DevOps 的特点来说，比如说好用点是什么？好用性、可靠性和安全性，这是我们的业务目标。
也可以从速度上来看，排个优先级，哪个工作先做，哪个先产生价值，这是我们需要考量的问题。最后是成本，包括开发和运维的成本。
与商业相比我们在 IT 上面应该花多少？我们需要缩减成本，缩减成本的途径呢？
这只是一个内部的 IT 行为，不能提供信息的功能性，但是可以提高支付保障性以及降低成本。降低 IT 成本在一定程度上可以降低企业的成本。
如果我们能够继续提高快速交付和新功能研发的话我们就能快速进入市场，将产品和服务打入市场，通过内部行为来加速企业内部的变化，来降低运营的成本。这就是 MBA 语言，CEO 所说的话。
如果想要提到保障性使用的效率的话，提高了稳定性，信息系统的稳定性就提高了，从公司的层面来看能够减少生意的干扰，无形中减少了生意的开支。
如果顾客也参与其中的话，我们也会提高客户的满意度。客户的满意度对 CEO 来说是非常重要的，这也是 MBA 的语言。
如果我们能够把企业放一起的话，其实就能提高信息系统的功能性，取决于不同的功能你可以去建立更多提高销量的可能，保持高的价格。
通过在客户忠诚度上进行投资，可以保持高价，提高客户的满意度。同时也给你的产品和服务提供更好的反馈，减少运营的成本，降低风险。
现在我们学了一点 MBA 的语言，那为什么要在 DevOps 上投资，而不是投资在别的领域呢？
以 MBA 的行话来说，我们可以避免崩溃，更好地面向市场，更少的业务中断。
向业务高管“兜售”DevOps 有用并且好用、快速交付，别跟业务高管提 IT 收益、成本、风险。
发现最薄弱的环节
在开始 DevOps 时，文化阻力将导致重大失败。 —- Gartner
组织变革问题远比新技术投资更具挑战性。—- CIO.com
边”做”边”学”边”改”，在业务沙盘游戏中团队：
通过”工作可视化”减少混乱。
通过”识别和减少限制”提升工作流。
通过”小的迭代和快速反馈”避免宕机和返工。
通过”持续实践和学习”改进。
最薄弱环节，到底是商业上还是 IT 还是之间的协作？
如果是在 IT 上，是交互的速度不够吗？还是有一些有疑惑的地方，大家不能好好合作？
DevOps 能够帮助你们解决这些问题，但是改变并非一时，尤其是文化的改变。
我们如何做能够帮助自己改变、革新工作方式呢？凤凰项目有一个游戏可以借鉴下，可以用商业模拟的方法，来帮助大家优化工作方式。
如果你的业务部是最薄弱的环节呢？如果做投资？如何细化需求？如何保护信息？
我们就需要找到他们进行解决，我们有一个 BISL 模型能够帮助商人提高和改进自己的工作方式。
如果最薄弱的环节是到合作呢？合作是很简单的以及人与人合作的流程。因为人不是机器，业务与 IT 需要得到协作的建议，这样双方才能获得好的合作。
发现你最薄弱的环节，在最薄弱的环节上工作，组织文化很重要，变革不容易，边做边学边改。
采用正确的态度
当我说干掉 DevOps 的时候，有很多人都会把烂西红柿扔向我，他会非常生气说我不喜欢 DevOps，要干掉 DevOps。
当我说干掉 DevOps，我想的是禅语、佛陀。一个年轻的僧侣一直想要找到佛陀，但是他认为他找到佛的时候，大师却说你其实没有找到，杀死佛继续找。我认为这与 DevOps 的观念是一样的。
如果你在路上遇见了 DevOps，干掉它。因为你不会找到真正的 DevOps，你需要继续实习、继续实践，这才是 DevOps 的真意。
作者：Mark Smalley
编辑：陶家龙、孙淑娟
来源：转载自DevOps时代微信公众号
Mark Smalley，ASL BiSL 基金会大使。当下的兴趣爱好： 数字化企业、IT 运作模式、IT 价值、IT 与业务关系、共同创造价值、多学科协作、处理复杂问题。
精彩文章推荐：