由蝴蝶效应谈运维的系统思考

彭小阳

作者简介：

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

自我介绍：我来自台湾。我是1981年开始写程序的，那时候叫程序员，年轻不懂的工程师会跑过来问我，老师你写这么多年的程序，一定写的很棒，我好想打他，如果我程序写的很棒，我现在还会在这里吗，想也知道;可是我孙子跑过来问我，爷爷爷爷，你程序是不是写的很棒，我说一点点棒。不是很棒，但是一点点棒。就是因为写了一点点棒，所以有机会在单元测试跟TDD出来，我变成一个资深的程序员，结果在需求改变的时候，就变成了SCRUM Master，我就写了精益Kanban，我自己就写了《精益开发与看板方法》，精益的时候大家都叫我敏捷教练，所以DevOps出来如日中天，这时候我被称为是顾问，或者是顾问，最近有很多企业找我，要我帮他们诊断一下企业出了什么问题，这很有趣，企业出问题怎么会找一个软体工程师来，所以所有的企业都是软件公司。这代表IT部门被重视。是维系着公司生命最重要的一部，这是自我介绍。

前言：

今天谈由蝴蝶效应谈运维的系统思维，一行错整个软体就都错，所以企业不是一个人的，是团体共同拥有,所以一定是不能分开来的。我在这家公司做什么，91APP，整个公司都是工程师，大到300工程师的时候，突然发现产能不够，老板说要诊断一下怎么解决产能不够的问题，而工程师持续增加，但是产能没有出现，今天会解决这个问题，跟大家谈一下。

一、观全貌

在我们开始之前第一件事要做什么，项目今天开始第一件事要做什么？答案在画面上，我不用PPT。第一件事是看见全貌，但是往往不是这么回事，你认为是全貌，但实际上不是全貌，我们来看一下这句话，项目开始之初首重看见全貌，一旦当你把眼光投注在哪一个要项的时候，实际上你就只看到那一部分，所以这是必然现象，所以有时候我们要退两步，再多退两步，看远一点，然后咨询少还是多。

1、价值思考

价值思考，你看你的看板，看板的咨询是多还是多，还有你要书还是鼠标垫。看板隐藏的咨询只有几个咨询，如果看Kanban一个上面可能有三四十个咨询，反而让你看不到全貌，所以如果你想看到全貌往后退两步，看少一点，但是你看到了全貌，看到全貌不容易，这是微软的XPS，你认为这是全部吗，不是，这边还有，所以我把范围加大，你要往后退一下，看到全貌。

2、观全貌

当你看到全貌以后怎么办？这个问题要先解决，项目开始之初，首重看见全貌，当你看见全貌以后怎么办？不管你们讲的对不对，我都要送你东西。我是最终使成员的权益，权益很重要，你要把他画下来，当你看见全貌的时候立刻画下来，因为全貌会变，而且不要是你一个人看见全貌，整个团队都要看见全貌，你的老板要看见全貌，你的下属也要看见全貌，大家才会有一致的方向和见解。

3、DevOps三步工作法

今天谈到的第一件事三步工作法，这是DevOps里面的第一个框架，三步工作法，我会提一下，三部曲很糟糕，让人家以为第一步第二步，然后才是第三步，这是错的。

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

现在所有企业讲DevOps都用无限大，无限大的范围面积比较大吗？没有，这是错误的，那个源泉才是好，第一步流，价值流，怎么样快速的可开发需求，可交付软件，可使用软件，可使用价值。可的大小决定了开发速度，可很重要.

二、正确的方向

1、科技发展太快

然后我还会再提一下这个，一再的跟我讲，你看任何Kanban，千万不要跟Dev跟Ops分开来，为什么会听到呢？因为191分高，你还是要小心一点，最后可能没有机会讲到，我把三步工作法用自己的方式诠释一下，这是图像，世界在改变，从前我们认为这个世界是属于一群高寒知识就是力量，重视理性分析的特定族群。

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

我向右边那位女士致敬，你们可能经常会问到，精益跟敏捷一样不一样？你如果问问那位女士的话，他是这两个协会的理事长，是同一个人，所以他说他们是一样的，那是一对夫妇，这是他去年的一场演讲，所写的一句话，我把上面的那一句英文翻译一下，最下面的是下午讲的，技术到2017年以前有50%会换掉。

2、留住客户才是重点

为什么？因为科技来的太快，所有的企业都会变成软件公司，科技来的太快，如果RD改了一行程式码，请问你需要多久才能让它上线。2009年出来的时候DevOps大家都讲，一天要发10次、20次才是大公司，但是VPN到底要发几次才是对，你试想一下，到底要多久时间，花多少功夫才能换掉，是不是要做一次完整的发布，你是几分钟小时还是几小时，还是几小，重点不在那里，重点在这里，留住客户才是重点。

你这个bug会支撑多久，会骂你，骂到受不了的时候，可能会换厂商，所以你可以支撑多久，留住你的客户才是重点。正确的release方式是这样的，找到那个组建，然后只针对它进行置换。继续服务，根本没有暂停，这才是正确的方法，所以没有人再比速度。

3、DevOps三步工作法推行的文化

解释一下三步工作法，因为大家经常误会要走第一步，第二步，第三步。所以每次DevOps大会都要解释一次，第一步流，Flow就是把商业价值传到客户身上，第二步回馈，回馈是最重要的，如果没有回馈就没有敏捷。客户要回馈给需求的人，你这个需求做到还是没有用，我根本不在意，工程师要知道为何而战，我写的这个功能客户用了以后满意还是不满意，回馈。

回馈可以减少你的技术，例如你做了20个功能，只有10个功能有客户用，另外10个根本没有人用，完全没有因为这些还要残留这个版本做技术是不需要把它拿掉，你要弄清楚哪些功能客户喜欢不喜欢，多喜欢，然后你的Bug改正了以后，一天改完客户的满意度，两天改完客户的满意度，还是及时改完客户很高兴，只要留住客户就可以了。
你们想三个步骤里面我们第一个要推行哪一个？文化。最近我到企业去做顾问，第一件事既然是从文化开始，DevOps最大的影响是什么，是文化。三步工作法第三步是属于文化层的，实验跟学习，请问犯错的工程师学的多，还是不犯错的工程师学的多。
你们现在可以知道学生有多喜欢我了，我不幸的是跟我的老师一起坐在同一桌吃饭；自从我成了最受欢迎的老师之后，我的老师不再跟我一起吃饭，损失惨重；怎么样做实验，很简单，请主管开会的时候离开现场，由团队自己做决策；团队做了决策以后，成败自己负担，就是让客户学到东西以后，主管只要在旁边监视他；这个错误不要太大，在允许的错误范围里面，让你的团队犯错，学到经验。
可是否能够开除犯错的人呢？不行，因为他学到最多，注意在科学实验里面，我们都知道一个定律，如果我这次实验成功了，我学到的东西很少，5%、10%，如果我失败了，我学到最多，90%、95%，所以犯错的员工，理论上学到的是比较多的，这种员工能不能开除，不要开除，而对DevOps里大胆犯错的员工，他的犯错率会优于从来不犯错的，但是你犯错必须要公司可以容忍。
真正的动作应该是切割的，逐渐做第一步，逐渐做第二步，逐渐做第三步，第一步是流，第二步是回馈，第三步是改变企业的文化，让他们勇于尝试，勇于错误，勇于改正学到东西。

4、Time to Market

现在我们来讲Time to Market，我不得不抱歉声音品质很糟，从北京飞过来以后太冷，又热下去，声音就消失了，很糟糕。快是最重要的吗？

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

所以需求跟团队的领导指向正确的方向才是王道，不止要快，快如果快错了方向，一点用都没有，这是很重要的，刚刚是新台北，捷运站，距离我家四站，这个影片跑过去只有一条路，怎么可能跑过来，他跑过去呢，忽悠，但是感觉很好，感觉比较重要，所以这个世界是感性的世界，世界在变的有创造力。

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

5、凤凰项目

我们来看一下凤凰项目，凤凰项目提出的DevOps的第一个架构，就是三步工作法，被批评的很严重；为什么要用一步、两步、三步，应该用名称来，所以第一次讲的系统思维放大回馈跟持续学习实验的文化。

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

这本书就是一起设计的，但是为什么要更改，其实是原因很严重。大家知道系统思维的主流在哪里？是在彼得圣吉，系统有没有边界？没有边界，系统的边界是我们自己放的，因为数据我们无法全部监控，所以我们就把它区分成需要监控和不需要监控，或者把记录全部记录下来，或者是部分记录下来，或者是根本不记录，只把现象拿来做分析的。

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

凤凰项目是一本小说，所以看它的时候千万不要用技术观点看，你会很生气，你还记得第36页第一句话吗，凤凰项目第36页第一句话，如果你看过打开来看，上面写着一句话，全是废话。下次从第37页开始看起，TOC的理论就是Kanban的理论。

6、Kanban的理论

Kanban的理论来自于这里，高德拉特先生，我们Kanban理论也是来自这里，所以不会再这儿解题，这是为什么要对他致敬的最大原因，但是如果你要深入系统思维的话，走彼得圣吉麻省理工这套。

请问运维应该提前到哪里？我们知道测试提前到开放是同时的，那运维应该提前到哪儿？我们应该前移到哪里？用系统思维的方式来解决这个问题，当我们提到这个问题的时候，注意没有问题就不要做系统思考，系统思考的前提是有问题，这个问题我们要解决他，所以我们做系统思考，这跟思考程序一模一样，所以我需要这个设计模式来帮我解决这个问题，这是对的。

要先有问题才做系统思考，否则就不要，第一为什么要改变，这是分析的阶段，第二个是策略阶段，第三个是战略阶段，这就是限制理论，限制理论的三步骤就是用它来持续改善，我们一天到晚只听到持续改善，但是怎么持续改善呢？经常问这三个问题来持续改善。
解决从这里出发及影响开发速度的系统图示，回去问业务部门你对开发速度满意不满意，真的开发部门那么差吗？DevOps演进到今天已经走出一条理论来，我分析给大家听，中间那块青色的就是开发的速度，影响最大的就是两块比较大，红色，红色代表是影响开发速度最大的优势，左边影响复杂度是最大的，右边是浪费，浪费多少东西在做其他的东西，就是你的业务太多。

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

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

三、DevOps发展趋势

1、裁撤测试人员

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

而微软部门没有测试部门的，做完了以后直接三个礼拜发布给3000个工程师来使用，有没有经过测试单位，没有，然后你就会听到，这一桌的人骂隔壁那一桌的。你程序写成这个样子，还敢发布，可是这个骂的声音很快就会结束，工程师会用单元测试TDD把自己的程序守住，没有一个工程师写成是挨骂的，所以你会怎么样，谨慎再谨慎，学习再学习，你会越来越有经验，你会用单元测试来守住你的问题，能解决70%到75%的BUG，人工测试5%到10%，所以那个测试单位只能替你解决5%到10%。

这是DevOps的趋势，而做完了以后工程师立刻发布，发布以后就开始挨骂，而发布到哪里，发布到那一步，然后挨骂，挨隔壁那桌的骂，挨大家的骂，然后就哪些人搞出多少BUG，最后一名绝对不是同样一个人，他会立刻改善，这是迅速的学习方法，能迅速学习到守住自己的BUG，然后急速成长。微软这么做，都这么做，比较前卫的公司都自己这么做。

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

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

2、引入Feature lnjection

还有一个解决方法，为什么前面+Biz DevOps，他们的回答是这个样子的，前面应该加Biz，但是DevOps这个词大家已经很习惯了，我们心里就知道这件事就好了，依然叫DevOps就好了，所以我把颜色弄淡一点，这里引入一个Feature lnjection，运用高业务价值的需求来加快项目开发的速度。

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

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

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