台湾老专家：由蝴蝶效应谈运维的系统思考

做者简介：

Ruddy Lee（李智桦）老师，DevOpsDays北京站金牌讲师，台湾著名精益布道师，敏捷专家，著有《精益开发与看板方法 》。

自我介绍：我来自台湾。我是1981年开始写程序的，那时候被叫程序员。经常有年轻不懂的工程师跑过来问我，老师你写这么多年的程序，必定写的很棒，让人好想打他，你想若是我程序写的很棒，我如今还会在这里吗，想也知道。

但是换成是孙子跑过来问我，爷爷爷爷，你程序是否是写的很棒，哈哈!我会说哪有很棒，就是一点点棒。不是很棒，可是一点点棒。

就是由于程式写得一点点棒，因此主管就要求我指导工程师们如何作好测试来改善品质，也就有机会在单元测试跟TDD出来时一睹全貌。慢慢得就变成一个资深的程序员了。

这是个快速变化的时代，需求也不例外，当越来有越多人来请教你许多专案开发上的问题时，被触发的研究精神奖走上敏捷的道途上，而很天然的就变成了一位SCRUM Master，随后我又钻研了精益Kanban，而后就写了《精益开发与看板方法》。

在宣导精益的时候你们都改叫我敏捷教练，因此DevOps出来如日中天，这时候我被称为是顾问(实际上是外表看起来愈来愈不像工程师)，或许是顾问作久了，最近有不少企业找我，要我帮他们诊断一下企业出了什么问题，这颇有趣，企业出问题怎么会找一个软体工程师来解题呢? 这一点正好反应了微软总裁萨提亚纳得拉所说的:「全部的企业都是软件公司。」这表明IT部门将会越来被重视。这是维系着公司生命最重要的一步，这是个人自我介绍。

前言：

---

今天谈由蝴蝶效应谈运维的系统思惟，开发软体就是这个样子，只要有一行错了整个软体就都无法正常运做了，因此企业不是一我的的，是团体共同拥有,因此必定是不能分开来的。

我在这家公司作什么，91APP，整个公司都是工程师，大到300工程师的时候，忽然发现产能不够，老板说要诊断一下怎么解决产能不够的问题，而工程师持续增长，可是产能没有出现，今天会解决这个问题，跟你们谈一下。

1、看见全貌

---

咱们在项目开始之初最重要的一件事要作什么，项目开始的第一件事要作什么呢？(答案在画面上，我不用PPT，是用本身的程式在拨放的)。第一件事是看见全貌，可是世事每每不是这么回事的，当你认为是这就是全貌时，但实际上的全貌又是另外一回事。

咱们来看一下这句话，项目开始之初首重看见全貌，一旦当你把眼光投注在哪个要项的时候，实际上你就只看到那一部分，因此这是必然现象，因此有时候咱们要退两步，再多退两步，看远一点，而后问本身正的问题是什麽? 这正是DevOps 三步工做法的第一步: 系统思惟。

一、价值思考

价值思考，从观看你的看板开始，看板的问题是多仍是少，(赠送学员书:还有你要书仍是鼠标垫。)看板隐藏的内容只有几个问题，若是看Kanban一个上面可能有三四十个内容，反而让你看不到全貌，因此若是你想看到全貌日后退两步，看少一点，可是你看到了全貌，看到全貌不容易，画面上展现的这是微软的XPS功能，你认为这是所有吗，不是，这边还有，因此我把范围加大，你必定尝试著日后退一下，让本身能看到全貌 -这个方法就叫作「抽象化」。

二、观全貌

当你看到全貌之后要怎么办呢？这个问题要先解决，项目开始之初，首重看见全貌，当你看见全貌之后怎么办？(无论学员你回答的对不对，我都要送你东西。这是最终学员的权益，权益很重要)，请记得「要把他画下来」，当你看见全貌的时候马上画下来，由于全貌会变，并且不只仅是要你一我的看见全貌，整个团队都要看见全貌，你的老板要看见全貌，你的下属也要看见全貌，你们才会有一致的方向和看法 – 敏捷就称之为透明化。

三、DevOps三步工做法

今天谈到的第一件事三步工做法，这是DevOps里面的第一个框架，三步工做法，我会提一下，称为三步曲实在是很糟糕的说法，让你们误觉得第一步、第二步，而后才是第三步，这是错的。

但实际上应该长成这个样子，要横切，今天我会提一下。而后横的对照文化层，第二步解决的问题，当你只改了一行代码，请问你要花多少时间来更新、发布呢？接着这张Slide有那两个圆圈，一个是圆圈一个是八字型DevOps，你认为哪个对？

如今全部企业讲DevOps都用无限大，无限大的范围面积比较大吗？没有，这是错误的，化程一个圆圈来表示才是好的，第一步、流，价值流，目标指向怎么样快速的可开发需求，可交付软件，可以使用软件，可以使用的价值。流程的大小决定了开发速度，这是很重要的 - 咱们称之价值流。

2、正确的方向

---

一、科技发展太快

而后我还会再提一下这个，一再的跟我讲，当你在设计看任何Kanban时，千万不要跟Dev跟Ops分开来，为何呢？(由于DevOps之父跟我讲的)最后可能没有机会讲到，我把三步工做法用本身的方式诠释一下，这是图像，世界在改变，从前咱们认为这个世界是属于一群高寒知识就是力量，重视理性分析的特定族群。

曾几什么时候这个世界变了，现在世界将属于具备高感性能力的另外一族群，有创造力，具备同理心，能观察趋势，以及为事物赋予意义的人，我昨天早上才赶来的，我处处飞不多听到有这些人群注重AI，实际上AI应该摆在DevOps上面。这张图只是视觉的改变!

我向图上右边那位女士致敬(Mary Poppendieck)，大家可能常常会问到，精益跟敏捷是不试同样呢?有那裡不同？你若是去请问那位女士的话，她是这两个协会的理事长，是的都是同一我的，因此她说他们是同样的，这是一对让人羡慕的夫妇，这是他去年的一场演讲，所写的一句话，我把上面的那一句英文翻译一下，最下面的图片所讲的是，这些技术到2017年之前有50%会换掉。

二、留住客户才是重点

为何？由于科技来的太快，全部的企业都会变成软件公司，科技来的太快，若是RD改了一行程式码，请问你须要多久才能让它上线。2009年出来的时候DevOps你们都讲，一天要发10次、20次才是大公司，可是***到底要发几回才是对，你试想一下，到底要多久时间，花多少功夫才能换掉，是否是要作一次完整的发布，你是几分钟小时仍是几小时，仍是几小，重点不在那里，重点在这里，留住客户才是重点。

你这个bug会支撑多久，你会挨骂，骂到受不了的时候，客户可能就会要求换厂商了，因此你能够支撑多久，留住你的客户才是重点。正确的release方式是这样的，找到那个组建(component)，而后只针对它进行置换。让你的服务持续不中断才是上策，根本没有(不用)暂停下来，这才是正确的方法，因此没有人再比速度了。

三、DevOps三步工做法推行的文化

解释一下三步工做法，由于你们常常误会要先走第一步，在走第二步，第三步。因此每次DevOps大会都要解释一次，第一步流，Flow就是把商业价值传到客户身上，第二步回馈，回馈是最重要的，若是没有回馈就没有敏捷。客户要回馈给完成需求的人，你这个需求作到仍是没有用到，仍是我根本不在乎，工程师要知道为什么而战，我写的这个功能客户用了之后满意仍是不满意，回馈。

回馈能够减小你的技术成本，例如你作了20个功能，只有10个功能有客户用，另外10个根本没有人用，彻底没有由于这些还要残留这个版本作技术债是不须要的就能够把它拿掉了，你要弄清楚哪些功能客户喜欢或不喜欢，有多喜欢，而后你的Bug改正了之后，在一天内改完客户的满意度，两天改完客户的满意度，仍是及时改完客户很高兴，只要能留住客户就能够了，不要去追逐一天能更新多少回。

大家想三个步骤里面咱们第一个要推行哪个？文化。最顾问的企业，第一件事既然是从文化开始，DevOps最大的影响是什么，是文化。三步工做法第三步是属于文化层的，实验跟学习，请问犯错的工程师学的多，仍是不犯错的工程师学的多。

大家如今能够知道学生有多喜欢我了，但很不幸的是跟个人老师一块儿坐在同一桌吃饭；自从我成了最受欢迎的老师以后，个人老师就再也不跟我一块儿吃饭，损失惨重；要怎么样作实验，很简单，请主管开会的时候离开现场，由团队本身作决策；团队作了决策之后，成败本身负担，就是让客户学到东西之后，主管只要在旁边监视他；这个错误不要太大，在容许的错误范围里面，让你的团队犯错，学到经验。

但是否可以开除犯错的人呢？不行，由于他学到最多，注意在科学实验里面，咱们都知道一个定律，若是我此次实验成功了，我学到的东西不多，5%、10%，若是我失败了，我学到最多，90%、95%，因此犯错的员工，理论上学到的是比较多的，这种员工能随便开除，不要开除，而对DevOps里大胆犯错的员工，他的表现会优于历来不犯错的，可是你犯错必需要公司能够容忍。

真正的动做应该是切割的，逐渐作第一步，逐渐作第二步，逐渐作第三步，第一步是流，第二步是回馈，第三步是改变企业的文化，让他们敢于尝试，敢于错误，敢于改正学到东西。

四、Time to Market

如今咱们来说Time to Market，我不得不抱歉今天的声音品质很糟，从北京飞过来之后太冷，又热下去，声音就消失了，很糟糕。对DevOps而言快是最重要的吗？

系统思惟最重要的是看见全貌，看见全貌最重要不要被你看见表象所迷惑，由于这个世界不是线性，是非线性的世界，1+1不等于2，若是1+1=2那是否是一份耕耘一份收获，那两份耕耘两份收获，完蛋了，那10份耕耘就10份收获，这个世界不是线性，非线性，这是三步工做法凤凰项目一开始写的第一步系统思惟它的目的就是这样。

因此需求跟团队的领导指向正确的方向才是王道，不止要快，快若是快错了方向，一点用都没有，这是很重要的，(放了一段影片，片名是方向)刚刚是新台北，捷运站，距离我家四站，这段影片跑过去只有一条路，怎么可能交错的跑过来，他跑过去呢，可是感受很好，感受比较重要，因此这个世界是感性的世界，世界在变的更有创造力。

而工程师的文化方向，尊重、谦逊跟信任，在你作实验跟学习的过程里面，这三个很重要，工程师不必定在乎金钱，可是在乎的是尊重。你带你的团队最重要，让他本身作决策尊重，工程师要维持谦逊，团队要彼此信任。这是我带团队的时候第一个要提出来的。

五、凤凰项目

咱们来看一下凤凰项目，凤凰项目提出的DevOps的第一个架构，就是三步工做法，这个名称被批评的很严重；为何要用一步、两步、三步，应该改用名称来讲明才是，因此第一次讲的系统思惟放大回馈跟持续学习实验的文化。

实验的文化是容易犯错误的文化，没有问题，犯错知道改就行了；可是曾几什么时候这本书出来的时候，2015到16年对DevOps很大的不一样，三步工做法更新，系统思惟变成流程，其实应该是流程FLOW，这本书的简体版在5月份出来，他坚持把FLOW翻译成流，因此把程字删掉，其余两步是同样的。

这本书就是一块儿设计的，可是为何要更改，实际上是缘由很严重。你们知道系统思惟的主流在哪里？主流是彼得圣吉，所谓系统有没有边界？没有边界，系统的边界是咱们本身放的，由于数据是咱们没法所有监控的，因此咱们就把它区分红须要监控和不须要监控，或者动态的把记录所有记录下来，或者是部分记录下来，或者是根本不记录，只把现象拿来作分析的。

因此系统没有边界，系统的边界是咱们须要边界，若是咱们不设定边界就看不到全貌，这就是我今天要谈的蝴蝶效应就是在这里，想把我划出一块区域，值得看的全貌就在这里。他们一开始对TOC限制理论高德拉特先生致敬，由于他们用一样的收获。

阅读凤凰项目时要知道它是一本小说，因此看它的时候千万不要用技术观点看，一直再找重点这麽作你会很生气的，你还记得第36页第一句话吗，凤凰项目第36页第一句话，若是你看过打开来看，上面写着一句话，「全是废话」。下次从第37页开始看起，TOC的理论就是Kanban的理论。

六、Kanban的理论

Kanban的理论来自于这里，高德拉特先生，咱们Kanban理论也是来自这里，因此不会再这儿解题，这是为何要对他致敬的最大缘由，可是若是你要深刻系统思惟的话，走彼得圣吉麻省理工这套。

请问运维应该提早到哪里？咱们知道测试提早到开发应该是同时的，那运维应该提早到哪儿？咱们应该前移到哪里？用系统思惟的方式来解决这个问题，当咱们提到这个问题的时候，注意没有问题就不要作系统思考，系统思考的前提是有问题，这个问题咱们要解决他，因此咱们作系统思考，这跟思考程序如出一辙，因此我须要这个设计模式来帮我解决这个问题，这是对的。

要先有问题才作系统思考，不然就不要，第一为何要改变，这是分析的阶段，第二个是策略阶段，第三个是战略阶段，这就是限制理论，限制理论的三步骤就是用它来持续改善，咱们一天到晚只听到持续改善，可是怎么持续改善呢？常常问这三个问题来持续改善。

解决从这里出发及影响开发速度的系统图示，回去问业务部门你对开发速度满意不满意，真的开发部门那么差吗？DevOps演进到今天已经走出一条理论来，我分析给你们听，中间那块青色的就是开发的速度，影响最大的就是两块比较大，红色，红色表明是影响开发速度最大的优点，左边影响复杂度是最大的，右边是浪费，浪费多少东西在作其余的东西，就是你的业务太多。

我把他细化一下，咱们看少一点，咱们退后两步看，更明显的看出来开发速度影响最大的是1系统复杂性，2浪费的活动，一般咱们都让最聪明的人升官，任何一个主管就问他，天天作什么，大部分的主管会跟你讲「开会」，因此让最厉害的人升官没有产能，0。开会，电脑工程师只有坐在电脑前面打着键盘才有产能出来，因此你让他开会产能也是0，开完会他会以为好累好累，今天成天都在开会，损失惨重。

而最有趣的是技术，开发速度，但是4是工做/生活平衡，工程师的生活要平衡，效率才能出来，这是颇有趣。因此看你要关注的眼光在那里。这个图看起来已经比较清晰了，可是我还能够再排序一下，你会看到哪些是影响速度最重要的，我想BUG应该是在这里，重工，还有需求模糊。工程师解BUG的时候应该很高兴把它解决了，仍是以为很惭愧，固然是很惭愧。

3、DevOps发展趋势

---

一、裁撤测试人员

DevOps发展到至今两个趋势，一个是趋势是把测试的人裁掉，之后没有测试部门，你开发出来的东西直接去本身的公司马上发布，大家敢这样尝试吗，写完程序之后不要通过测试人员，直接发布，结果会怎么样，有人会自杀吗？结果第一次会很惨，第二次呢？第三次呢？第四次呢？没有问题，工程师天然会把全部的问题都收掉，而目前你们都这么作。

而微软部门没有测试部门的，作完了之后直接三个礼拜发布给3000个工程师来使用，有没有通过测试单位，没有，而后你就会听到，这一桌的人骂隔壁那一桌的。你程序写成这个样子，还敢发布，但是这个骂的声音很快就会结束，工程师会用单元测试TDD把本身的程序守住，没有一个工程师喜欢挨骂的，因此你会怎么样，谨慎再谨慎，学习再学习，你会愈来愈有经验，你会用单元测试来守住你的问题，细看一下测试金字塔，工程师能解决70%到75%的BUG，人工测试5%到10%，因此那个测试单位只能替你解决5%到10%的问题 –称为吃本身的狗食。

这是DevOps的趋势，而作完了之后工程师马上发布，发布之后就开始挨骂，而发布到哪里，发布到那一步，而后挨骂，挨隔壁那桌的骂，挨你们的骂，而后就哪些人搞出多少BUG，最后一名绝对不是一样一我的，他会马上改善，这是迅速的学习方法，能迅速学习到守住本身的BUG，而后急速成长。微软这么作，都这么作，比较前卫的公司都本身这么作。

可是在这麽作以前你必须先教他如何作好测试，因此测试到哪里去？前移了，测试工程师的工做阶段消失了，已经没有测试单位了，在微软里面，我在北京听到最危言耸听的一句话，运维消失；好可怕的一句话，运维融入到开发团队里面去，而在微软里面已经没有运维部门了，消失了，交给开发部门，本身作发布，本身作维护。为何？你一个BUG，最适合改那个BUG的人是谁，固然就是写那个程序的人，所以运维消失了 - Dev + Ops 了。

在微软里面是这个样子。我不晓得推特和Facebook是什么样子的，可是在微软里面是这样的，可是实际上咱们称之为多功能的团队，这个多功能的团队你面，UY、UX运维工程师，开发工程师，测试工程师都在里面，咱们称之为他是多职能的开发团队。

二、引入 Feature lnjection

还有一个解决方法，为何前面+Biz DevOps，他们的回答是这个样子的，前面应该加Biz，可是DevOps这个词你们已经很习惯了，咱们内心就知道这件事就行了，依然叫DevOps就行了，因此我把颜色弄淡一些，这里引入一个Feature lnjection的观念，运用高业务价值的需求来加快项目开发的速度。

我作10个功能。就是让你的需求价值提高，会比你增长开发人员有用的多，而不要想你写的功能多，你用百分之多少他的功能，可能只有10%、20%，因此他们都是过渡使用功能，而握起来为何那么慢，由于他拥有太庞大的功能了，实际上咱们用获得吗，用不到，因此维护他不须要花那么多精神。

实际上就是把业务价值大于等于项目开发时间的时候，没有人会埋怨开发速度太慢。这是一个趋势。这一页我不会讲，就是用影响地图来看它，怎么作，而后作的结果。这一张我不提，迅速到这一张，就是你认为哪个DevOps的图才是对的。哪个要走的路线比较长，咱们不是要求快速吗？为何咱们还要把Dev跟Ops分开来呢？

正确的解读速度的话应该是使用这个，正确的解读见解的话应该是这样的看板，它会比较快，那两层的看板是把Dev跟Ops分开来更复杂，走的速度更慢，可是若是你真的回去要作这个动做的话，注意你的团队要逐步的和谐，并且他们讲的话要一致，一般DevOps讲的话是不一致的，他们的理念不一样，只要目标不一致，就不该该摆在一个团队，直到你发现你的两个团队目标是一致的时候，把他们摆在一块儿，这样子才能急速的提高起来。注意有前提条件，要先克服他。咱们今天大概就会讲到这一张就结束。