丨持續(xù)改進pdca體系和的意義

公司的DevOps全過程。在交流時，我問了他一個問題，他的回答讓我印象特別深刻我問他：“你覺得，公司是在什么時候實現(xiàn)DevOps的呢？”他想了想說：“現(xiàn)在，我們公司已經(jīng)沒有專職的測試和專職的運維了，基礎架構也早就容器化了。這些事情，都是業(yè)務發(fā)展到一定階段之后自然而然發(fā)生的，只不過，DevOps來以后，我們才發(fā)現(xiàn)，原來在做的就是DevOs。所以，很難說在哪個時間點完成了DevOps。對我們來說，最重要的就是團隊具備了一種能力，就是始終能夠找到新的突破，持續(xù)追求更好的狀態(tài)?！?，這段話應該非常能夠代表一個團隊實施DevOps時期望達到的狀態(tài)吧。其實，如果你有機會去跟谷歌、Netflix的工程師交流一下，你就會發(fā)現(xiàn)，這些業(yè)界DevOps做得特別牛的公司，內部都不怎么提DevOps的概念。因為，他們早就對DevOps比如，像Gerrit這種非常流行的代碼評審和管理工具，最開始就是為了解決谷歌內部缺少一種基于Git并且具備權限管控的代碼評審工具的問題，才被開發(fā)出來的，你可以了解下這段 你看，遇到一個釘子，從而造個錘子，和拿著一把錘子，滿世界找釘子就是兩種截然不同的做法。但很多時候，我們采用的都是后一種做法，手里拿著一堆錘子，卻找不到釘子在哪里。所以，如果一定要讓我來回答，DevOps做到什么程度，就算是實現(xiàn)落地了？那么，我的回答是，就是團隊已經(jīng)具備了持續(xù)改進的能力，而不只是簡簡單單地引入了幾個工具，說到這兒，你可能會說，這個所謂的持續(xù)改進，怎么感覺無處不在呢？似乎很多工程實踐的落地方法中，最后一步都是持續(xù)改進。那么，持續(xù)改進的意義到底是什么呢？為什么一切活動的終極目標都是持續(xù)改進呢？這是因為，每家公司的問題都不一樣，從0到1的過程相對比較簡單，可以對照著工程實踐，快速地引入工具，建立流程，補齊能力短板。但是，從1到N的過程，就需要團還以最開始那個問題為例，基于Gitlab和Jenkins搭建了自動化構建和發(fā)布的能力之后，談到持續(xù)改進，有一個非常著名的方法體系，叫作PDCA，也稱為戴明環(huán)。沒錯，你從名稱就能看出，這套方法體系同樣來自于大師戴明博士。PDCA是四個英文單詞的縮寫，也就是n（計劃）、Do（實施）、Check（檢查）和Action（行動）。PDCA提供了一套結構化的實施框架，任何一項改進類工作，都可以劃分為這四個實施階段。通過PDCA循環(huán)的不斷迭代，驅動組織進入一種良性循環(huán)，不斷識別出新的待改進問題。針對這些問題，首先要進行根因分析，制定具體的實施計劃。然后，不定期地檢查實施的結果和預期目標是否一致。最后，要對改進結果進行復盤，把做得好的地方保留下來，把做得不好的地方納入下一階段的循環(huán)中，繼續(xù)改進。大概兩年前，我參與到一家中型企業(yè)的DevOps工作當中。這家企業(yè)剛開始接觸DevOps時的狀態(tài)呢，我就不細說了，反正就是基本啥都沒有。代碼庫使用的是SVN，構當然，這并不是重點，重點是，我上個月又碰到了這個項目的。她跟我說，他們現(xiàn)在的發(fā)布節(jié)奏已經(jīng)實現(xiàn)了兩周一次，甚至不定期還有臨時版本發(fā)布。我很好奇，他們究竟是怎么做到的。原來，最開始導入改進方案的時候，我給項目組提到過容器化的思路，但是因為當時客觀條件不具備，就沒有繼續(xù)推進下去。沒想到，在短短不到一年的時間里，他們已經(jīng)實現(xiàn)了容器化部署，自建的PaaS平臺也有模有樣，即便是跟很多大公司相比，也毫不遜色。她說：“這段DevOps的過程，帶給我們的不僅僅是一些常見的工程實踐和工具平的確，很多工程實踐和工具平臺，在公司內部其實只是一小步，之后遇到的問題和還會有很多。這時候，我們能夠依靠的終極奧義就是持續(xù)改進的思想，而構建持續(xù)改進的，從失敗中學習是我們從小就懂的道理。一個團隊對待故障的態(tài)度，很大程度上就反映了他們對于持續(xù)改進的態(tài)度。系統(tǒng)出現(xiàn)故障是誰都不愿意遇到的事情，但在真實世界中，這是沒法避免的。與這些做法相比，更好的方法是建立一種正向回溯和總結的機制。也就是說，當問題發(fā)生之后，事先準備一份詳盡的故障分析報告，并拉上相關方一起徹底分析問題的根因，并給出改進任務的具體時間點。這就需要有團隊來負責收集和總結這些常見的錯誤，并提取關鍵錯誤信息和常見解決方法，形成一個案例庫。同時，在構建系統(tǒng)中嵌入一個自動化服務，下次再有人遇到編譯錯誤的時候，就可以自動匹配案例庫，并給他推送一個問題分析報告和解決建議，幫助團隊成員快速解決問題。這樣，隨著團隊智慧的不斷積累，越來越多的問題會被識別出來，從而實現(xiàn)組織知識共享和研發(fā)輔助的能力，這在很多大公司里面都是一個重點建設方向。仔細想想，這本身就是一個PDCA的過程。不過，這里要補充一點，團隊實施持續(xù)改進的過程，不應該是一次大而全的，而應該是一系列小而高頻的改進動作。因為大的往往影響眾多，很容易半途而廢，而小的改進更DevOps重要性要高于DevOps建設的重要性?？蓡栴}是，業(yè)務的需求是沒有止境的。有時候，我去問一線員工：“你覺得有什么地方，是DevOps可以幫你的嗎？”要么大家會說“沒什么特別的，現(xiàn)在挺好”，要么就是一些非?，嵥榈狞c。實際上，這只能說明，要么是沒想過這個事情，要么就是不知道還有更好的做法。所以，正確的做法是，在團隊的日常迭代中，事先給改進類工作預留一部分時間，或者是在業(yè)務相對不那么繁忙的時候（比如大促剛剛結束，團隊在調整狀態(tài)的時候），在改進工作上多花些時間。這些工作量主要用于解決非功能需求、技術改進類問題，比如修復技術、單元測試用例補充、度量識別出來的改進事項等。通過將這部分改進時間固定下來，可以培養(yǎng)團隊持續(xù)改進的文化。我比較推薦的做法是，在團隊的Backlg中新增一類任務，專門用于記錄和這類持續(xù)改進的內容。在迭代計劃會議上，對這類問題進行分析，并預估工作量，保證團隊有固定的時間來應對這些問題。另外，很多公司也開始流行舉辦HackathonDay（），是說在有限的時間里通內部效率提升的“難”問題，還能提升團隊成員的積極性，在更大的舞臺上展現(xiàn)DevOps的價值，一舉兩得。在一個新功能開發(fā)完成上線之后，要能實時查看這個需求的上線狀態(tài)。如果需求分析時已經(jīng)關聯(lián)了業(yè)務考核指標，那么，同樣可以將該業(yè)務關聯(lián)的指標數(shù)據(jù)進行展示。這樣，研發(fā)就會知道自己交付的內容有多少問題，用戶的真實反饋是怎樣的，從而促使團隊地站在用戶的視角思考問題。除了業(yè)務指標，DevOps。大家可以查看自己所在團隊比如，之前，我們團隊的一個測試人員發(fā)現(xiàn)，日常埋點測試費時費力，而且沒有數(shù)據(jù)統(tǒng)計。于是，她就自己利用業(yè)余時間開發(fā)了一個小工具，用工具來承載這部分工作，效率大幅提升。比較好的做法是，在團隊成員的績效目標中，增加對團隊貢獻和技術創(chuàng)新的要求，在團隊內部鼓勵創(chuàng)新類工作。另外，在團隊內部建立對應的選拔和激勵機制，為好的想法投入資源，把它們變成可以解決類似問題的工具。很多公司也開始注意到這種內部知識復用的重要性，所以，無論是代碼庫開源，還是公共基礎組件的市的建設，甚至是公司級的平臺治理系統(tǒng)，都可以幫助你快速地復用已有的能力，避免一直重復造。就像每個工程實踐的終點都是持續(xù)改進一樣，我們專欄的“工程實踐篇”同樣以持續(xù)改進的我始終認為，團隊是否建立了持續(xù)改進的文化，是評估團隊的DevOps實踐效果的重要參考。在這一講中，我給你介紹了PDCA的持續(xù)改進方法體系，也就是通過計劃、實施、檢這些方法的就是想打造一個學習型的組織