世界级DevOps专家 : Kris Buytaert带你认识原味的DevOps

作者简介

Kris Buytaert
CoFounder & CTO ，Inuits

个人简介： DevOpsDays 组织方核心成员，世界级 DevOps 专家、布道师，DevOps 运动的大力推动者，长期从事Linux及开源咨询，活跃于各大国际会议，在很多书籍、论文和文章中都发表过相关主题。重点关注高可用、可扩展、虚拟化和大型基础设施项目管理，提出构建可通过 “10楼测试” 的基础设施（现在被广为人知的“云”）。

前言

大家上午好，我会很快介绍一下自己，我的名字叫Kris，我和Patrick一起在很多年之前开始做DevOpsDays。我做这个行业已经有20年了，我最开始是做开发，然后又开始成为了运维人员，所以这两边的工作我都有所了解。

今天我做的工作主要是帮助一些大型的机构运用DevOps，进行更好更快的发布。今天我要谈论的话题将会依据我过去的一些经验和政府的一些合作，还有一些创业的合作来讲，看他们怎么样进行DevOps的实施。

DevOps是什么？

DevOps究竟是什么，大家可能很多人已经听过C(L)AMS，John本来今天要来的，他们之前都说过他们有这个缩写，之前很多人进行过一个交流和采访，最后总结出来了这几点。

• 文化

• 自动化

• 衡量

• 分享

我把文化放在最上面，标成了红色，因为它是最为重要、最为核心的一个DevOps里面的理念。

混乱的墙壁

我们从何而来，过去的一些机构，历史上在这个机构里有很多的部门，比如说开发部门，他们进行新的发布，希望尽可能快的发布新的软件、新的特性。

在这个墙的另外一边我们有运维团队，他们的目标就是要有一个稳定的平台，永远都在工作当中不会出问题，而且他们希望尽可能的让这个平台实现稳定，不希望出现任何的改变。

这两方他们就有完全不同的目标，在这个机构成长的过程当中不仅仅有开发团队，有运维团队，他们中间还夹着一些其他的团队。这个公司就会成为像迷宫一样的，这些人也不知道如何合作起来。

冲突的目标

他们其实目标是相互冲突的，对于开发，他们希望更多的新发布，作为运营来讲，他们更希望是稳定的。

传统的组织

在传统的组织里，官僚机构还有各种条款规定，还有传统，再有是没有自由，每个人必须要听他们的经理要求做什么工作，而缺少自主性。

很多的机构造成很多工程师的流失，有很多其他更小的公司或者机构能给工程师提供更多的自由、足够的空间或者工具，能够做他们更想做的事情。这些是比较老式的机构和组织。

职业技术

再有是在行业里的一些职业，如果说想获得自我成长，从最开始初级的开发员、程序员，升到高级的位置，大家最后也都希望能够成为一个管理者，比如说生产线的经理或者其他更高的职位。

但是有很多时候我们能够看到有很多的人他们是迫于这样的一些希望，他们希望自己能升到很高的位置。

但他们实际上没有这样的能力去完成这样高的职位，而且他们也没有能力去胜任这样的职责，企业会强迫这些人被动成长，为了企业更多的利润。

采用DevOps

在传统的机构或者是公司里，能够看到有很多人他们其实是被强迫的做到高管的位置，但其实没有在业务上或者技术上有更好的发展。有很多的人想产生一些变化，比如他们想接受一些新的思维方式，能更好做一些事情。

Spoiler剧透

再看一下Spoiler，对于企业面对最大的挑战并不是技术方面，而是在于人的因素，在这里工作的人们。

改善管理和阻力

之前我们能够看到，DevOps其实是对人的管理，再有是对管理层进行改变。比如在这里有个比例，20%、60%、20%，20%他们开始说这个想法真的不错，希望能够真正落实，作为这20%的人他们比较欢迎这样新的概念和一些想法、做法的人，就要努力去找到你的同路人。

60%的人会采取观望的态度，他们比较满足现状，不会主动做什么样的改变。还有最后的20%，如果去找他们的时候，他们会直接回答“不”，因为我们已经做了十年了，我们不接受任何的改变，不想看见有任何的变动，这20%的人是比较难以说服的，这20%的人可能我们不需要去说服他们，我们可能会选择其他的办法。

狂热的项目计划

大家看一下传统的企业是什么样的，高层的管理，这些企业他们会做非常大的计划，从2013年的时候就开始做这样的变化，他们对组织结构进行了打乱和重组，他们的意图就是建立新的DevOps团队，我们就需要有新的管理层来进行管理，这样能够让每个人做自己的工作。

他们很多人真的很害怕做错事，如果尝试新的，他们担心丢掉原来的动作。但是另外的人非常有想法非常有勇气，想去尝试新的方式，因为他们已经感受到了新的变化会带来的新的环境。所以20%的人他们最终其实是要被淘汰掉的，因为他们根本没有办法预判未来将会发生什么。

不要称呼它为DevOps流

组建DevOps团队，最开始可能有一些害怕，但并不是一个全新的团队，在Scrum团队里加入了运营，把它称为DevOps团队。DevOps团队在很多情况只是一个团队在研发和运维中间的，我们要做的就是打破这些筒仓。

其实DevOps团队并不是说真正的运营构建的，他有可能有很多以前从功能团队里面分化出来的一些人，把他变成了研究团队，这种简单的重组模式并不能称为是DevOps团队。比如说里面会有质检人员或者DevOps人员。从根本上来讲，他们还在做一直以来的工作。

也不要称他为DevOps工程师

DevOps工程师也并不是一个很好的招聘的名头，很多的企业他们都想招聘DevOps工程师，首先要问的是我先我们需要这些人来做什么，需不需要开发来写代码，或者说我们现在需要的是不是我们运维的工程师。所以我们在招聘的时候一定要问我们自己这些问题。他们其实有很多的时候招来的DevOps工程师，他们其实还是在处理JAVA的工作还有其他运营的工作，给他换了新的名头，并不能改变他的工作内容。

跨职能的团队

我们需要组建一个有不同团队、有不同职能或者专长的团队，把他们组成一个集合型的团队，让他们每个人都有责任来实现最终我们的软件交付。他们必须要有能力为他们所做的开发承担全部的责任。

如何能够让这些人更好的合作在一起，我想最开始就以一个小的团队来进行组建的基础，然后让他们建立一个ChatOps，让他们有更好的沟通，然后让他们知道自己的队友正在面临什么样的问题，大家知道John，他发现了有更好的方法，能够让更多的人合作在一起。

敏捷？

把团队结合在一起，让他们共同的工作，然后再考虑我们的敏捷操作，现在敏捷操作指的是什么，我们有过很多的探讨，到底什么是敏捷操作。如果说牺牲安全，它就不是敏捷。

我听说有团队他们知道自己想做什么，但是有很多的问题还是在用传统的方式来解决。但是开发团队他们采用敏捷操作的方式，这个团队还不能称为整个是在采用我们的敏捷操作。其实取决于我们的团队正在操作什么样的项目。

我们考虑用两种方式结合在一起，还有Scrum，可以用在研发。比如说我们先有Scrum做两周，会有一个比较快的反馈，然后再反复重复来做，在三四个月的时候，大家都能够满意这样的新产品，大家能够看到我们在做持续的改进，我们也缩短我们反馈的流程。

很多人会说我没有办法承诺两周做出来，我们也不知道我们的数据库是否足够强大能够支持这样的功能要求，所以如果说我的团队到明天升级整个的数据库，可能明天就没有办法来做开发。

再有是看板，是另一种方式。我们来通过看板下指令，给大家举个例子，我们有研发团队，他们用Scrum，两周，他们去做代码，运维团队他们使用看板来进行工作布置，运营团队。

把他们放在Sprint的团队里面，让他们与开发人员进行合作，两周开发出新的功能，有更好的表现，让他们与我们的开发人员工作在一起。其他的团队还继续做其他的支持工作，比如说监控或者其他的工作。

第二种Sprint，把第一个Sprint团队放在我们运营的每天工作的团队里，他会知道我们在运营当中每天都有什么样的问题出现，他能够为我们的平台提供更多的支持。所以说开发人员再回去的时候，就会有其他的不同的运营团队分配到不同的开发团队当中，他们会帮助开发出更多的新的功能。

我们可以把一些Sprint开发团队里面的人员放到运维团队里，这样我们能够更好的了解我们的平到底实现什么问题能够帮助我们平台更好的表现，特别是我们的开发人员他们有足够的知识来实现这样一些需求的变化。

在几周之后，每个人都知道这个平台怎么工作的了，这样我们的平台就更加平稳，有很多了解整个情况的人，他们随时待命，这是我们经常做的一种方式，一个团队用不同的方式来组合。比如说通过用看板的方式，再回到Scrum，也能够让不同的部门之间出现互补。

是你的组织敏捷还是一个隔离的简仓？？

所以说敏捷，更大一点的问题是，很多人他们自称为敏捷，但是实际上仅仅只是一个隔离的筒仓，其实整个的结构还没有任何的变化。很多的时候，因为他们业务是没有加入其中的，业务他们不关心我们怎么来运行IT，也不关心怎么样来处理流程，也并不关心如何编软件，大概只有6周时间，他们会回来看一下到底现在做得怎么样。

商业

大概到6个月的时候他们会回来看，他们只关心最终的产品是什么样的。业务需要了解到的是，慢慢的他们意识到如果没有新的发布他们就活不下去，就我刚才讲到的这些情况，现在很多公司已经意识到了，因为我们有不同的部门，而不简单是一家IT公司。

合并

我之前说有两个组，我们想把它组合在一起。其中可能出现的一个错误是，把这两个组的组长都同时保留，他们有两个组长，这个是不可行的。我看到有这样的组，他们将开发和运维组的组长都放在一起。

他们为什么要这么做？因为他们没有办法决定要将哪一个人的经理职位撤下来，所以他们就把两个人都放在这里，但是这个做法是错误的。而且管理团队也需要变得非常的敏捷，你可以用看板的方法，比如你不用这个方法，有人就会跑过来说，你能不能帮我解决这个问题，这样会打乱你一天的工作，就变成了不敏捷的方法。

在一个星期过完以后，有人说你没有解决这个问题、没有解决那个问题，你只能说因为我之前的组长要求我先做另一件事情。在这个团队当中，如果我们知道它的产品周期要在18周之后结束，我们不适合在这样的组里面进行这样的测试。

你的财务部门知道吗？

大家现在都参与进来，你们的财务部门知道吗？你的开发师以及你的运维师现在都加入进来，你们的财务人员是否已经加入了你们的队伍，你们现在在写代码、在进行项目的开发，你们的财务人员是否能够给予你们一些支持的工作。

比如说在你的公司谁来负责购买一些新的软件和工具，通常工程师需要的东西和十年前的需求已经完全不一样了，十年前我可能需要很多的硬件，也需要接下来五年的很多软件支持的东西，现在我们已经有开源的很好的便利服务，我们可以和卖家进行协作，或者说会跟其他的服务提供商来进行协作。

在未来的五年，我们不可能再像过去一样五年跨度当中有同样的需求。现在还有很多大型的机构正在外包他们的工作，我们会将运维进行外包，怎么可能呢，这相当于我们给一个外部的相关方，把我们的安全交到了他的手上，他们怎么可以向我们保证这个平台这些产品正完好的运转。而这些供应商永远不可能向我们保证，因为我们在做的这个平台别人没有办法保证它是否会永远很好的运转下去，他也无法对我们的产品进行负责。

你外包了什么？

外包大量的宏观意味着你有一个雨伞的原则，这其实是打破了我们合作的原则，你进行外包的话，一旦需要外包，要保证你的合作伙伴能够了解到你自己是在怎么工作的，双方才能够进行很好的配合。还有一些次级的项目，有多少人你们是在做开发项目，与此同时还要做数据库的迁移，还爱做网络的生意，还形成了很多类似的这样的次要的项目，而且团队和团队之间并没有沟通，比如说负责存储的团队并没有和管理的团队进行合作和沟通。

边缘项目

如果我们改变了这个基础的平台，我们的行为也会共同来改变。我们所有的团队要有共同的任务分享的清单。

ITIL正确的思想，错误的用法

这也让我想到最初的ITIL，ITIL是一个很好的文件库，但是又有很多人把它作为一个金科玉律，变得非常受限制。这一步一步的按步骤介绍和指引有的时候会给我们造成一定的阻碍。

也有人认为，他会在最后一公里的时候，产品发布之前说这个东西是不可行的，比如说周五的早上10点钟我们开一个会，很多人可能想要推动一个项目的发布，但是突然之间会有人在最后的关键时刻站储量提出反对，这一点是需要改变的。

如果我们打破这些观念，我们忘记这个是不是架构层面的正确，所有的这些功能其实还在原地，我们要将它放到进程的开始而不是结尾，如果你要提反对意见要在一开始提出来。

安全是你的一部分吗？

今天安全是你们工作的一部分吗，如果安全是你们工作一部分，你们可以举手。其实每一个人都应当把安全纳入自己的工作内容之一。

早在这个过程中

就像ITIL当中的进程一样，安全需要和进程打包放在一起，这也就意味着我们不会专门有一个孤立的安全团队，所有的人在做平台都需要有安全意识，有这样的意识就意味着他们需要有相关的知识能够在这个机构的每一个角落都要有安全相关的人员，只有将安全意识放在每个人心中，才能更好的防止基础设施等等更多的架构崩溃。

我们在ITIL当中的最佳实践，安全当中的最佳实践，所有的这些概念我们都要在进程的开始建立起来，是一个前期的工作。有的时候我们的工作就是开始得太晚，等到很晚的时候才开始考虑安全问题、质量问题，这个时候已经太晚了，所以要在这个进程一开始的时候就设立到位，这就需要我们机构重组方面同样有这个的考虑。

开除你的架构师

这个是一个比较有争议性的说法，我看到有很多大型机构，他们有一个架构师的部门，里面有很多的老人，很多年都没有写过代码，他们一直在幻想着有一些工具，但这些工具实际上并不可用，他们从不会对这些工具进行测试。如果我们把这些人重新放到这个团队当中，让他们去写代码，这个时候他们就会有亲身经历，他们就会意识到他们之前有的这些幻想其实并不是最理想的架构。

所以我们需要让我们的架构师在构建的过程当中就参与进来，而不是处在一个封闭的筒仓当中，让他们活跃起来。这就意味着，即便你是处在一个很大的企业当中，我们仍然可能做到这种改变。

DevOps的前景

很多人说大型的机构可能没有办法实施DevOps，但实际上这个回答是肯定的，只是我们需要有更长的时间，要有更多的人力的投入，内部需要有更多的人打乱重组，如果我们给他们这些新的机会，我们就会目睹这个改变的发生，他可能会花上一定的时间，但是发生改变是一个必然的趋势。

高效运维 和 DevOps

DevOps 之父 Patrick 亲自创办的 DevOpsDays 大会，至今已经9年时间，是最资深、最顶级的 DevOps 会议，至今已经在全球举办了150多场。

国内的 DevOpsDays 系列活动，由高效运维社区和国际最佳实践管理联盟联合举办。2017年3月18日举行的 DevOpsDays 北京站，是全世界最大的一次。

2017年8月18日即将举行 DevOpsDays 上海站，也欢迎您的参与。

高效运维社区创始人萧田国和Patrick合影

Patrick先生接受萧田国的专访

END

本文转载自公众号「高效运维」

近期好文：

更多国外大咖即将来华

尽在 DevOpsDays 上海站

8.18日，精彩不容错过

了解更多大会内容及抢票请进官网：

长按二维码 报名参会

购票咨询及团购优惠请联系主办方：

Tel：[phone]

点击阅读原文关注活动官网