臺灣老專家：由蝴蝶效應談運維的系統思考

做者簡介：

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講的話是不一致的，他們的理念不一樣，只要目標不一致，就不該該擺在一個團隊，直到你發現你的兩個團隊目標是一致的時候，把他們擺在一塊兒，這樣子才能急速的提高起來。注意有前提條件，要先克服他。咱們今天大概就會講到這一張就結束。