关于 DevOps ，咱们聊的可能不是一回事

在过去的三年中，我作为 DevOps 的咨询师参与了很多企业的 DevOps 转型咨询以及技术实施，也在不同的社区活动中分享了自己在 DevOps 上的实践、理解和观点。

随着 DevOps 的盛行，我在很多场合和越来越多的人聊起 DevOps。也在不同的渠道听到了很多人在讲 DevOps。然而，讨论的背后，我发现每个人对 DevOps 所指并不是同一件事情，也由于各执一词导致不欢而散。

于是我通过 DevOpsDays 的官方网站整理所有 DevOps 的有关材料，随着学习和了解的不断增多，我也渐渐的对 DevOps 有了更进一步的认识。我把学到的材料经过整理后把陆续放在了简书上，形成了" DevOps 前世今生" 这个系列，这个系列还在不断补充新的材料。

含义越来越丰富的 DevOps

DevOps 至今都缺乏一个清晰和统一的认识。对于一场运动来说，这是一件好事，也同样是一件坏事。虽然 Patrick 曾经在自己的博客里一再提到自己对 DevOps 的"正确认识''，但社区似乎不以为然。

缺乏“官方定义”好处是人人都可以定义，因此没有一个人或者组织可以垄断 DevOps 定义权。所以每个人都自己可以参与到这一运动中去，不断为其增加新的概念、新的实践和新的工具。这会使 DevOps 社区不断的繁荣。

而坏处也很明显，对于 DevOps 的后来者 —— 那些没有参与进来的人，需要学习和理解的 DevOps 知识的广度和深度也越来越大。

以至于后来出现了这幅众所周知的“盲人摸象图”：

image.png

这幅图中包含了很多概念，但主要表现的意义 DevOps 是一系列概念的总和，任何一个单方面的定义只是 DevOps 的一个部分，而不是 DevOps 的整体，随着 DevOps 这个概念的不断膨胀，人们就更难理解 DevOps 了。

那么，你理解的 DevOps 是指的什么？

在接触了各类客户和社区之后，我开始尝试理解每个人谈到 DevOps 的时候，他们分别指的是什么，以及所指内容背后的目标和动机。渐渐的，我把我所听到的 DevOps 概念分成如下四类，分别是：

• DevOps 是一组技术/实践
• DevOps 是一个角色
• DevOps 是一种工作方式
• DevOps 是一种组织结构

那么，我们分别来谈谈这四类 DevOps。

当 DevOps 是一组技术/实践

在工程师文化的组织里，对先进技术的渴望是最常见的学习动机。可以促进工程师用更有效率，更优雅的方式解决问题。而对于非工程师文化的组织，新的技术往往是提升其 KPI 的工具。以下是我听到 DevOps 的时候，经常触及的话题：

• 高频部署
• 持续交付
• 云计算/虚拟化技术
• 基础设施即代码
• Docker
• 自动化运维

高频部署

曾经和某跨国著名银行的外汇交易产品的 IT 产品负责人交流 DevOps。对方很自豪的告诉我，他们产品每天的部署频率超过500次，我听了不以为然。因为，部署频率高不见得是件好事。于是我问了以下几个问题：

1. 为什么你们需要这么频繁的部署？有这么频繁变动的业务需求吗？
2. 在这么多次部署里，是发布业务价值的部署更多，还是修复问题的部署更多？
3. 这些生产环境的变更难道完全是不可规划的吗？

由于对方的金融业务有相应的法律法规，理论上没有这么频繁的变更需求，除非清理技术债，否则没有很强烈的变更动机。但对方并没有直接回答我的问题，而是换到了其它问题上，因此我最终也不清楚对方这么频繁变更的驱动力。

这对我有一个重要的：指标导向的 DevOps 往往是一种 DevOps 的反模式，它会忽略和掩盖真正的问题。

指标的背后是某种度量，如果部署频率一直很高，一定反应了某种现象。而这些现象不一定是个好现象：不是业务的变动很频繁，就是技术的变动很频繁。但如果二者都频繁，我们应该衡量变更带来的价值和风险（当然，DevOps 可以降低变更的风险），并优先变更价值较高的请求。有可能新的业务尝试让我们从市场上获得了更多的关注，也有可能新的技术提升了生产率。但无论是哪一种，部署频率应该是一个有多到少不断循环的过程。这表明系统在走向成熟和稳定的同时，能够及时响应变化，无论是对技术还是对业务，对变更产生的影响都需要一段时间去积累和总结数据。

此外，DevOps 绝不是为了提升部署频率而牺牲了软件质量和业务价值，甚至是安全措施。换句话说，DevOps 不是一种对质量的平衡和妥协，它是一种全局改进。全局的改进就意味着以价值为最高原则所度量的相关指标是不能有所下降的。

持续交付

持续交付是 DevOps 中非常重要的实践，持续交付的思想远早于 DevOps 。但直到第二届欧洲的 DevOpsDays 才有了持续交付这个重量级话题。因为持续交付本身也通过技术手段和实践解决了 DevOps 最初所面临的 Dev 和 Ops 的合作问题。

不夸张的说，如果 Patrick Debois 早一点读到持续交付中运维相关的话题，说不定就没有 DevOps 了。

然而，随着 DevOps 的理念的发展比持续交付融汇了更多的概念（这就是没有一个人能垄断定义的好处），使得 DevOps 更加广泛和盛行。因此， DevOps 所涵盖的范围已经超出了持续交付本身。

我把 持续交付 列为 DevOps 的核心实践之一，因为如果你没有实践 持续交付。那么根本不能称之为 DevOps，但是如果你完整实践了持续交付，那么你离完整的 DevOps 也不远了。

云计算/虚拟化技术

随着分布式应用的井喷式发展。基础设施的管理成为了分布式应用的新瓶颈。在集中式管理的时代，大型应用只能运行在昂贵的小型机上，只有微软，SAP， IBM ，Oracle 和 EMC 这样的企业才有能力提供相应的产品完成这样复杂度很高的架构。因此企业需要单独的运维部门（Ops）来管理这些软件和设备。

而随着虚拟技术和云计算的兴起，企业的基础设施管理工作往往变得很简单。VMWare 这样的虚拟技术企业和 AWS 这样的云计算供应商提供了更加成熟和稳定的产品。大大的节约了企业机房管理的开支。

而 Ops 也不再需要进出机房，只需要通过远程桌面的方式就可以使用各种 SDK 开发工具去完成过去很多只有在机房才能做到的操作。

然而，即使云计算和虚拟化技术提升了 Ops 的生产率，减轻了 Ops 的痛苦。但仍没有解决 Dev 和 Ops 之间的矛盾 —— 开发团队和维护团队仍然各自为政，仍然通过制度谈判而不是合作共赢来工作，毕竟目标是相对立的。

基础设施即代码

随着设备和网络的持续增多，加之更加复杂的应用部署和初始化。基础设施的管理成为了一个十分尖锐的问题。当复杂度上升一个量级，就需要专业的管理工具来管理这类问题。于是 Puppet 这样的框架顺势而出。以至于在 《DevOps Handbook》中，合著者之一的 John Willis 在理解了 PuppetLab 的创始人 Luke Kanies 的想法之后，才有了 DevOps 的最初理解。

基础设施即代码利用了编程语言和虚拟化工具 API 的无缝连接达到这一目的。它在很大程度上把基础设施的管理当做其问题域，采用正确的面向对象方式，让开发人员和运维人员能够理解并设计出更加稳定和灵活的基础设施。大大降低基础设施变更的风险：提升了运维知识的透明度并使基础设施变更具备幂等性。

此外，它在一定程度上解决了不同环境（开发，测试，生产）之间的不一致问题，也让开发人员能够学习到 Ops 领域的知识并用软件开发的优秀思想解决运维领域的问题。

因此，基础设施即代码除了工具以外，更是一种 Dev 和 Ops 之间相互沟通的媒介，能够让开发人员和运维人员相互理解。所以，基础设施即代码毫无疑问的是 DevOps 的核心实践之一。

Docker

Docker 是含着 DevOps 的金钥匙出生的，它诞生的第一天就带着 DevOps 的基因：更简单的解决了基础设施即代码和虚拟化在实践中的问题，进一步提升了自动化能力以提升效率，并且对开发人员和运维人员都十分友好。

甚至很多地方都会以是否采用 docker 来评判是否采用了 DevOps 的相关技术。

Docker 一定程度上简化了基础设施的初始化和状态管理问题。通过镜像和运行时容器封装了应用运行时的复杂度。并通过容器的编排实现轻量级的分布式架构，也更加经济快捷。

但是，Docker 和任何一种工具一样，都不是”黄金锤“。当用错了场景，使用 docker 可能是一场灾难。我曾经参与并帮客户完成了一个数据中心迁移的项目，就是采用的 docker 作为统一的运行时容器。最初是因为 docker 镜像的移植性好，在各种异构 Linux 系统上可以正确执行，且镜像构建过程透明。但是客户为了能让这个业务场景更加通用，又分别采用了另外两种工具对其部署场景进行封装，并写出了第三个工具。由于这个工具并没有很好的分离其业务关注点和技术关注点，导致这个工具使用异常繁琐，需要增加更多额外的配置去定制化容器运行环境。原本为了提升生产效率的手段反而成为了阻碍效率的绊脚石。

自动化运维

看了以上那么多的工具和技术，很多对 DevOps 望文生义�或有些技术了解的运维工程师认为提高了自动化运维的水平，就是 DevOps。虽然 DevOps 里的一个重要特征是“自动化”，但拥有自动化运维，并不代表你就正在实践 DevOps，很可能你仅仅提升了运维部门的效率，但并没有从全局的角度提升开发和运维之间的效率和端到端价值的流动。因此，仅仅有自动化运维，还不足以称之为 DevOps。

关于 “ DevOps 技术”

以上列举了很多所谓 “DevOps 技术”，是从技术的角度来认识 DevOps。然而，不探索 DevOps 真正的问题，以及技术背后的目的和最佳实践。往往会使导致对 DevOps 的片面了解而适得其反。

从 DevOps 运动发展的历史上来看，DevOps 相关技术是解决 DevOps 相关问题的结果，而非起因。因此，对于 DevOps 的理解如果本末倒置，则很有可能起到东施效颦的结果。你会发现你拿着一堆 DevOps 的锤子，看见了可能并不存在的钉子。

此外，我相信掌握工具对于工程师群体来说不是一件难事，并且随着技术的发展，工具和平台的使用会越来越容易。但是，能够跳出自己的舒适区和思维习惯，从全局的角度观察并解决问题的能力则是很多工程师所欠缺的。

当 DevOps 是一个岗位角色

当 DevOps 传播开来，大家都会倾向于去找叫做 “DevOps” 的人，希望通过招聘和培训来提升自己的 DevOps 能力。 于是设置了一些称之为 "DevOps 工程师" 的岗位和角色。通过对这些招聘需求以及客户对 DevOps 的需求，我发现了四个不同但是相关的 " DevOps 工程师 " ：

• 作为 Dev 的 Ops（会开发技能的运维工程师）
• 作为 Ops 的 Dev（会运维技能的开发工程师）
• 基础设施开发工程师
• 全栈工程师

作为 Dev 的 Ops

有很多人也会认为，只要让开发工程师掌握运维技能，运维工程师掌握开发技能，就做到了 DevOps。这招来了很多运维工程师的反感。我采访过一些运维工程师，当初他们就是不喜欢也不想写代码，才选择了运维方向。

这种想法的其中一个动机是在于架构的逐渐稳定带来的运维工作减少，特别是使用了云计算技术和虚拟化技术的企业。这会让管理层有一种错觉，认为运维团队的空闲状态，一定程度上是浪费。因此，为了达到“人尽其用”，让运维工程师进入开发团队去写业务代码。并用“DevOps"作为对这种措施这一合理化的幌子。

这种想法的天真在于忽视了开发和运维的专业性和差异性。这让我想起一个段子：

老板：“我怎么觉得在公司的运营中你们部门没起多大作用？” 运维经理：“你走过大桥吗？” 老板：“走过。“ 运维经理：“桥上有栏杆吗？” 老板：“有。” 运维经理：“您过桥的时候扶栏杆吗？” 老板：“不扶。” 运维经理：“那么，栏杆对您来说就没用了？” 老板：“那当然有用了，没用栏杆护着，掉下去怎么办？” 运维经理：“可是您没有扶栏杆啊！？” 老板：“…… 可是 …… 可是没有栏杆，我会害怕！“ 运维经理：“那么，运维就是桥上的栏杆。“

虽然我不否认技术的发展对二者来说难度和门槛在不断降低。而且掌握一定开发技能的运维工程师前景更加光明。但是强人所难并不会让事情变好。此外，这类人才可遇不可求，也不要因为招不到这样的人而阻止了 DevOps 实践。

作为 Ops 的 Dev

同样的误解也会发生在开发工程师身上。对于开发工程师来说，其实难度并没有增加。无非是把 Ops 的工作当做需要通过别的工具完成的开发需求而已，甚至很多开发工程师自己也这么认为。

运维除了知识以外，很大一部分的不可替代性来源于生产环境的维护经验。然而这些经验不可复制，因为有些问题作为开发人员来说你很难碰到。我曾打趣的说，当你听到有人说“这不可能啊”，他一定是个运维新手。

就像我在上文强调的，软件开发和软件维护是相互关联但是各自独立的专业领域。DevOps 并不是要消除任何一方，而是要通过更加深入的合作成为彼此工作的润滑剂而非绊脚石。

对于开发工程师来说，掌握更多的技能绝对是一件好事。但也不要低估运维的专业性和经验性。

基础设施开发工程师

由于有了虚拟化和基础设施即代码这样的技术，“通过 Dev 的方式完成 Ops 的工作，就是 DevOps “ 也很自然的成为了很多 Ops 对 DevOps 的认识。指的是通过 SDK，相关工具和配置文件，利用现有的平台资源，为应用程序构建基础设施。而他们往往有一个新的称谓：基础设施开发者 （Infrastructure Developer）或这 云计算工程师 （Cloud Engineer）。

有一次到马来西亚出差，我称自己是 Infrastructure Developer 被 Uber 司机当做政府基建项目开发商�问了一堆稀奇古怪的问题，当然我并没有澄清，而是继续逗他 ;-D

在一些企业里，基础设施开发工程师都会肩负着推行企业 DevOps 的责任。但很少有企业能够明确 DevOps 是要做什么（这就是 DevOps 缺乏基准定义的坏处），而这些基础设施开发工程师会慢慢变成一个孤立的“平台团队”，这对 DevOps 是不利的。

全栈工程师

当然绝对不排除有些工程师是既懂开发也懂运维的"复合型人才"。但这样的人才的成本也十分高昂：一方面是寻找这样的人所花费的时间。另一方面是雇用这样的人所花费的资金。此外，对于某些企业来说还有培养这样人才的成本。

但是，仅仅认为有了这样的人才就具备 DevOps 的能力也并不现实。首先，DevOps 是一个团队属性，而不是一个人属性。一个人的力量相较于一个团队来说，还是很有限。其次，招聘这样的人主要还是为了胜任纷繁多变的工作，创业公司尤其如此。因此，我有时候会戏称全栈工程师为“全干工程师”，听起来很厉害，但工作境遇并不见的很好。

你可能只需要一个 “DevOps 晃动器”

软件开发和软件运维，是两类不同但联系很密切的事务，在过去很长的时间里。由于专业性和责任的不同从甲乙双方的矛盾变成了企业内部的矛盾。这是企业在互联网转型过程中的必经阶段，因为运维的开发不密切合作带来的问题日渐突出。而如何平滑的过渡，则是 DevOps 成败关键所在。你所需要不光是工程人才，你还需要新型的管理人才或者外部顾问来推动这项改进。

一般来说，DevOps 的变革一定会调整组织的制度和做事方式。而制度层面的改变从企业内部是很难做到的。企业越大，“不求有功，但求无过”的鸵鸟心态普遍存在，因此越是大型的组织，所面临的组织僵化会越严重。组织僵化不见得是一件坏事，这意味着你的企业组织形态更加的问题和高效，这是长时间积累的结果。但由于过于高效，组织僵化的负面效应就是缺乏创新。

所以，要推动企业的 DevOps 转型，特别是制度方面的创新，往往需要从组织外部引入“晃动器”（无论是聘用新的管理人才，还是外部顾问）来松动一下过于高效的组织，这都是能够帮助组织解除僵化的方式。

DevOps 是一种工作方式

这算是最贴近 DevOps 的目标的定义。但是在理解和时间上也是问题百出，片面的理解和机械的模仿都会造成 DevOps 之痛。对于 DevOps 的工作方式，有以下四个常见的理解：

• 用 Dev 的方法做 Ops 的事
• 换了名字的 Ops 团队
• 一个有 Ops 的 Dev 团队
• 一个 Dev 和 Ops 合作的团队

用 Dev 的方式做 Ops 的事

当你采用了上文中的 “基础设施即代码”，或者你有了“基础设施开发工程师”的时候。很自然的会想“我已经做到 DevOps 了”。然而，如果你并没有注意我在上述概念中特别提到的情况，那么你可能得到的只是下面所述的”换了名字的 Ops 团队“。

换了名字的 Ops 团队

这其实是很多公司的做法，认为 DevOps 所做的事情只是技术的更新，并无其它。

在 2016 年底我在悉尼的一个 DevOps 项目上做转型咨询，客户的应用系统是基于 AWS 构建的。并且客户始终认为 DevOps 工程师就是上文所述的基础设施开发团队，只是工作的内容全都在 AWS 上面，并没有什么变化。而且给这个团队一个很高大上的名字：Enablers。然而，这个团队仅仅用新工具是清偿了之前运维工程师留下的技术债，并没有帮助开发团队、测试团队甚至是业务团队从自己的角度提供帮助来提升价值的流动速度和工作效率。

不光如此，因为这个团队掌握了关键的基础设施资源，成为了所有团队前进的阻力，导致其它部门有更多积压的工作并需要更多人的人来处理。由于出现了这样的结果，“DevOps doesn't work in my orgnization”（DevOps 在我的组织里不好使）的批评也不绝于耳。

在 DevOps 转型的初期，我们需要一个这样的团队从运维的角度提出统一的方案并提供统一的服务支持。但随着 DevOps 能力和成熟度的提升，这样一个实体团队而不是虚拟团队的存在则会成为 DevOps 继续发展的阻力。

一个有 Ops 的 Dev 团队

最天真的想法莫不如把两类工程师放在一个团队里，在同一个负责人的范围内消化 Dev 和 Ops 的问题。这样，Dev 和 Ops 就能统一目标，平衡矛盾和冲突，共同解决问题。

但实际上很少有企业能够走出这一步，一方面是 IT 部门的岗位设置和预算归属，另一方面是团队变更后的 KPI 考核。一件很小的举动就会牵扯更多的问题，使 DevOps 难以进行下去。此外，如果缺乏有效的 DevOps 实践或者外部教练d 额指引，那么使 Dev 和 Ops 的融合将是一个漫长的旅程。

在这种情况下，我建议采用 DevOps 项目制的方式来进行 DevOps 的体验：

1. 首先根据项目汇聚资源，在项目中预留 Ops 角色。
2. 从运维部门借调运维工程师到项目中。运维部门要提前安排好运维工作的交接，或者至少把日常性的运维任务的80%剥离出来，分配给现有团队。保证进入项目团队的运维工程师的工作不被打扰
3. Ops 所在的部门绩效分为两块：一块为常规运维绩效（保证系统稳定性），另一块为 DevOps 项目绩效（保证开发顺利性），可以根据具体工作状况来设置这样的工作比率。
4. 保证运维团队人员能够有机会进入项目实践 DevOps ，同时要把项目开发中的运维痛点带回给运维团队处理。

在上述 2的悉尼项目里，我就成为了加入到了产品开发团队中的运维工程师。一方面解决开发团队痛点，一方面和 Enablers 团队沟通。一方面解决 开发团队的痛点，另一方面获得相应的权限和知识，并把 开发团队的反馈及时传达给 Enablers 团队。

一个 Dev 和 Ops 合作的团队

这就是 DevOps 所要达到的目标，它不是一个人的属性，而是一个团队的属性。它让利益相关方坐在一起解决问题，而不是相互甩锅。然而，由于”合作“的定义很简单，也很空泛，导致”合作“难以落地。以下是我认为”关键”的 DevOps 合作方式：

1. 共同进行架构设计
2. 共同进行技术决策
3. 持续交付流水线的建立
4. 共同 Pair 和 Review 代码和环境的配置
5. 共同参与回顾会议
6. 通过定期的内部 Session 增加相互的理解
7. 共同处理运维的问题

此外，还有很多其他的合作方式能够提升 DevOps 的效果，在此不一一列举，这里仅做参考。如果你是一个敏捷的团队，只需要把 Ops 作为团队的一份子，参加所有的活动就可以了。

DevOps 是一种组织文化

在著名在 Velocity 09 大会上，来自 Flicker 的著名演讲”10+ Deploys Per Day: Dev and Ops Cooperation“ 明确的指出工具和文化是他们成功的原因。这也第一届 DevOpsDays 也将工具和文化这两个话题进一步细化。在会后 Patrick Debois 把 DevOps 定义为“管理改进”和技术提升“。

John Willis 和 Damon Edwards 也在 2010 年 MoutainView 举办的 DevOpsDays 中重新强调了文化的重要性。

相对于可以看得见的工具，文化显得华而不实，也有人认为 DevOps 文化是一种“空谈陷阱”。

有一篇关于企业文化的文章写的非常好，这篇文章叫做”Culture is the Behavior You Reward and Punish“。翻译过来就是：文化就是你奖励和惩罚的行为。就是说对行为的惩罚和奖励构成了你的文化，对 DevOps 也一样。奖励符合 DevOps 的行为（而不仅仅是鼓励），惩罚不符合 DevOps 的行为。就形成了 DevOps 的文化。

而我所说的“建立 DevOps 的文化“则是建立一种规则约束，这种约束不但包含了 DevOps 的行为准则，而且包含了奖励和惩罚的机制。而这种规则约束不能变成一纸空文，更要切实执行下去，形成一种行为习惯。

习惯的力量则能够保证一种好的制度和实践顺利的延续下去。当然这种规则约束不是一成不变的，这些约束和规则也需要根据团队的发展不断的变化以适应新的状况。

然而，就如上文所说的，由于企业并不存在产生 DevOps 的基因（否则你早就有 DevOps 了）。这些制度很难从内部产生，必须要的话，请引入外部资源，例如 DevOps 顾问或者 DevOps 教练。

我经常看到一些 ”KTV式转型”，这种转型就像是唱 KTV：当人们在 KTV 里面对歌词字幕你总能唱出来，也能唱对。但如果没有歌词，人们往往就唱不出来了。这里的歌词字幕就相当于是转型教练，当教练在的时候，每个人都知道怎么做。当教练不在，什么都没有了。

很多情况下，顾问和教练在短期内起到从”0到1“的转变，然而从”1-100“则不是一朝一夕就能实现的。文化的形成是一个长期的塑造过程，不是能够买来的。你需要有足够的耐心来不断的评估和反馈当前的状况。

以下是 DevOps 所鼓励的行为。尽管每个人都鼓励以下的行为，但实际效果则千差万别，往往抓住了形式而不是本质。

• 信任
• 沟通
• 学习
• 分享/共担
• 不要指责

信任

你的团队里的 Dev 和 Ops 之间是相互信任的吗？你信任你的团队成员吗？如果回答是。那么你的团队成员信任你吗？信任是相互的，而且是高效团队成功的基石。获得信任很难，需要时间去建立。信任同样也很脆弱，很容易就会失去。你是否明确哪些行为对信任有帮助，而哪些行为会伤害信任？你能说出那些帮助构建信任和伤害信任的行为吗？你的团队都清楚吗？

当想到以上这些问题，你还信任你自己和你的团队吗？

这里有一个很重要的原理：没有无条件的信任，信任是需要建立的。

除了《凤凰项目》中所介绍的构建信任的方式——把自己最脆弱的一面告诉大家——以外，这里我推荐一种构建信任的方式：

1. 回顾团队中的每一个人。
2. 把你不信任的人说出来，并且说出你不信任的点。
3. 为了消除这种不信任，你自己愿意做什么事情（而不是让对方做什么事情）
4. 其它人为了消除团队中的不信任，也可以轮流发言。
5. 如果消除了这种不信任，也请说出来。并为之前你不信任的人和整个团队故障欢呼。

第三点最为重要，我们给出的建议往往不起效的原因就在于你在对别人提要求，而不是提供帮助。而人们对于提要求的感受都不会很好，只有提供自己的帮助，才是真正能解决问题的有效方式。另外，作为同一个团队的成员，你也必须想办法相信对方，并且让对方相信自己，没有选择。

很多人都觉得难以启齿，难以启齿的原因就是因为人们不愿意相信对方能够接纳这些不信任。而这么做恰恰能表明你对对方的信任，相信经历过一系列的措施之后，能改善当前的状况。

如果你觉得信任很难达成，那么这就是一个风险点，他会影响团队成员的行为和判断，造成不利的影响。所以，请多检查团队内部的信任情况，及时排除风险。

沟通

沟通是一个泛滥的话题，各种打着“高效沟通”的方法也层出不穷，但人们虽然都懂各种道理，也知道沟通的重要性，可沟通仍然被用作为”命令“的幌子，或用来实施语言暴力。

沟通的主要目的在于对齐交换意见和看法，达成理解。

沟通不仅仅是信息交流的通道，同样也是情绪宣泄的出口。我们在沟通中，有多少是发泄情绪占了很大的比重，但我们往往没有察觉。人们对表达自己的情绪是难以启齿的，因此用各种各样的“道理”来掩盖真实的意图。如果团队成员的大脑被不良情绪占据，那么无论如何他在团队中都不会有很好的表现的。人们往往会用其它的方式宣泄自己的情绪，而缺乏正确的发泄渠道则会导致灾难。

你的团队里有没有比较沉默的人或者是不喜欢主动沟通的人？由于信任的逐渐缺失，有些人往往不再沟通。而这类不再沟通的人，往往是项目中的定时炸弹。而情绪积累到某一个点后，这个炸弹就会爆炸，造成很恶劣的影响。所以，尽早的介入并让每个人能够很顺畅的沟通，对降低情绪风险，尤为重要。

此外，在沟通里，你是听的多？还是说的多？如果作为听者，你真正明白对方讲的是什么吗？如果作为说者，你在沟通之前，你是否有计划，是否明确沟通的目的，沟通后如何确认达到了沟通的目的？

如果不确认这些问题，那么沟通往往就是没有意义的闲聊。

学习

在英文里， 学习是一个词——Learn 。而在中文里“学习”是两个词，对应的英文分别是 Learn （学）和 Practice（习）。比如：learnt 就可以因为上下文的不同表示两种意思。一种是”经历过学习的过程，但不一定掌握”，另一种则是真正学会了。

当说到学习，往往想到的都是“输入”：看书（虽然买了也未必会看），看博客，看代码，看视频…… 然后练习，直到掌握。

然而，仅有输入是不够的，学习还应当有”输出“：形成博客、开源软件、演讲甚至是培训工作坊。有一句很著名的话叫做：“教是检验学习成果的唯一标准。”是不是真的掌握了，教一下别人，你会意识到“学习的错觉”。

在这里，我要强调一种重要的输入途径：从过往的经验教训中反思，总结，并形成团队的经验。很多事情过去了，无论成败，往往缺乏总结。这无法让团队成长，因为成败全凭”运气“。

学习的目的在于指导今后的实践，无论成败，都会降低未来失败的概率，多做“正确的事”，少做“错误的事”。

而只有学，没有习。只有输入，没有输出，或者只向外看，不向内看，都是片面的学习方式。我推荐的学习方式则是以输出作为学习目标，对知识和信息进行加工，思考，实践，提炼的过程。

毕竟，判断一个人的知识不再于他的输入，而在于他的输出。因为讲出来，才是自己的。

不要指责

很多问题棘手是因为人们不关注如何解决问题，而关注这个问题究竟是谁该负责。如果团队在责任归属的问题上花的时间很多，那么这就是一个指责文化的制度。在这种情况下，团队成员为了自保，会避免承担责任和解决问题。因此，很多事情没有进展，于是，整个组织沉浸在一种”不求有功，但求无过“的氛围下慢慢凝结，最后僵化。

我们常常听到“零容忍”，然而对问题的”零容忍“往往是很漂亮的口号。但它往往指的是”发现问题掩盖问题“。以前人们都说，不怕有问题，就怕看不见问题。而现在很多问题的出现并不是“黑天鹅""事件，而是"灰犀牛"事件。恰恰是对问题的选择性失明导致了不可挽回的结果。

在实践 DevOps 的时候，需要先测试一下有多少装睡的人。因为没有解决不了的问题，只有不愿承担的责任。

分享/共担

Share 在英文里有两个意思，一个和别人分享，另一个是和别人共同承担。在 DevOps 的上下文里二者兼有，一方面是作为学习的结果的产出。另一方面是避免组织陷入不愿承担责任的文化。对于团队作战来说，一个人犯错，不是他一个人的责任，而是集体的责任。”当你用一个指头指着别人的同时，另外四个指头也指着自己。

我们要相信没有不良的人，只有不良的制度。当出现了问题，从制度上而不是从个人的角度分析问题出现的原因。而且要能总结原因，形成新的制度。如果一个问题不在制度上去避免，那么还会发成下一次。

如果什么都是 DevOps ，那么 DevOps 实际上什么也不是

如果把所有 DevOps 相关的内容加总就能得到 DevOps，那和没有定义 DevOps 一样。如果我们没办法确定”什么不是 DevOps“，那同理我们也很难定义 DevOps 是什么。

我试图从上文中的认识里，提取出一些 DevOps 的必要元素来构成 DevOps 的概念。这些元素缺一不可，但单独拿出来又不能构成完整 DevOps 的概念。这样既可以保证对 DevOps 的完整理解，又避免 DevOps 概念过大难以下手。

根据我自己的实践，我认为 DevOps 包括以下几点原则：

1. DevOps 有一个明确的目标：通过充分的合作解决由于责任模糊而相互推诿的问题。（没有 DevOps 痛点的团队自然也没有 DevOps 的动力）
2. DevOps 是一个团队属性而不是个人属性，这个团队需要处理开发和维护任务。（有单一任务都不算是 DevOps 团队，因为没有合作解决 DevOps 痛点的动机）
3. DevOps 是一种团队改进，对于团队的表现有明确目标和度量。（没有度量的改进就是耍流氓）
4. DevOps 是一种团队工作方式和文化，它包括了一系列促进 Dev 和 Ops 合作的具体技术和实践以达到上述目标。（ DevOps 也不是缺乏技术的理论空谈 ）

因此，以下的描述都不是 DevOps：

1. DevOps 不是一个职务或者角色，因为 DevOps 是团队属性。
2. 不存在” DevOps 团队“，只存在”以 DevOps 方式工作的团队“。

以上是我过去三年的 DevOps 实践和咨询经历，希望能给正在做 DevOps 的你一些参考和提示，并祝愿你在 DevOps 的实践过程中更加顺利。