关于 DevOps，你还应该知道这些

2017-12-11 顾宇 DevOps时代

作者简介：

顾宇
ThoughtWorks 高级咨询师，9年工作经验。加入ThoughtWorks之前曾经参与中国移动，中国联通省级BOSS系统以及呼叫中心系统的研发、实施和割接。担任过售前，项目经理，维护工程师和开发工程师等职务。拥有丰富的大型系统开发及维护的实战经验。

在《关于 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 实践或者外部教练的额外指引，那么使 Dev 和 Ops 的融合将是一个漫长的旅程。

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

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

在上述2的悉尼项目里，我就成为了加入到了产品开发团队中的运维工程师。一方面解决开发团队痛点，一方面和 Enablers 团队沟通。

一方面解决开发团队的痛点，另一方面获得相应的权限和知识，并把开发团队的反馈及时传达给 Enablers 团队。

一个 Dev 和 Ops 合作的团队

这就是 DevOps 所要达到的目标，它不是一个人的属性，而是一个团队的属性。它让利益相关方坐在一起解决问题，而不是相互甩锅。

然而，由于”合作“的定义很简单，也很空泛，导致”合作“难以落地。以下是我认为”关键”的 DevOps 合作方式：

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

此外，还有很多其他的合作方式能够提升 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 之间是相互信任的吗？你信任你的团队成员吗？如果回答是。那么你的团队成员信任你吗？

信任是相互的，而且是高效团队成功的基石。获得信任很难，需要时间去建立。信任同样也很脆弱，很容易就会失去。

你是否明确哪些行为对信任有帮助，而哪些行为会伤害信任？你能说出那些帮助构建信任和伤害信任的行为吗？你的团队都清楚吗？

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

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

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

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

第三点最为重要，我们给出的建议往往不起效的原因就在于你在对别人提要求，而不是提供帮助。而人们对于提要求的感受都不会很好，只有提供自己的帮助，才是真正能解决问题的有效方式。

另外，作为同一个团队的成员，你也必须想办法相信对方，并且让对方相信自己，没有选择。

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

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

沟通

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

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

沟通不仅仅是信息交流的通道，同样也是情绪宣泄的出口。我们在沟通中，有多少是发泄情绪占了很大的比重，但我们往往没有察觉。

人们对表达自己的情绪是难以启齿的，因此用各种各样的“道理”来掩盖真实的意图。

如果团队成员的大脑被不良情绪占据，那么无论如何他在团队中都不会有很好的表现的。人们往往会用其它的方式宣泄自己的情绪，而缺乏正确的发泄渠道则会导致灾难。

你的团队里有没有比较沉默的人或者是不喜欢主动沟通的人？由于信任的逐渐缺失，有些人往往不再沟通。而这类不再沟通的人，往往是项目中的定时炸弹。

而情绪积累到某一个点后，这个炸弹就会爆炸，造成很恶劣的影响。所以，尽早的介入并让每个人能够很顺畅的沟通，对降低情绪风险，尤为重要。

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

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

学习

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

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

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

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

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

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

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

不要指责

很多问题棘手是因为人们不关注如何解决问题，而关注这个问题究竟是谁该负责。如果团队在责任归属的问题上花的时间很多，那么这就是一个指责文化的制度。

在这种情况下，团队成员为了自保，会避免承担责任和解决问题。因此，很多事情没有进展，于是，整个组织沉浸在一种”不求有功，但求无过“的氛围下慢慢凝结，最后僵化。

我们常常听到“零容忍”，然而对问题的”零容忍“往往是很漂亮的口号。但它往往指的是”发现问题掩盖问题“。

以前人们都说，不怕有问题，就怕看不见问题。而现在很多问题的出现并不是“黑天鹅””事件，而是”灰犀牛”事件。恰恰是对问题的选择性失明导致了不可挽回的结果。

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

分享/共担

Share 在英文里有两个意思，一个和别人分享，另一个是和别人共同承担。

在 DevOps 的上下文里二者兼有，一方面是作为学习的结果的产出。另一方面是避免组织陷入不愿承担责任的文化。

对于团队作战来说，一个人犯错，不是他一个人的责任，而是集体的责任。当你用一个指头指着别人的同时，另外四个指头也指着自己。

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

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

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

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

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

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

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