(1)客戶介紹

商米科技成立于 2013 年，總部位于上海市楊浦區(qū)創(chuàng)智天地，是一家極具產(chǎn)品創(chuàng)新基因和互聯(lián)網(wǎng)基因的公司。商米在短時間內(nèi)迅速成長為一家近1000人的企業(yè)，產(chǎn)品研發(fā)人數(shù)占比一度超過70%。

 

做為一家初創(chuàng)企業(yè)，商米研發(fā)團隊早期也經(jīng)歷過與當(dāng)下大部分創(chuàng)業(yè)公司一樣困境：協(xié)作基本靠吼、發(fā)布基本靠手的階段。然而，業(yè)務(wù)的快速發(fā)展，團隊規(guī)模不斷的擴大，給商米帶來了在「團隊協(xié)作」和「工程效能」上的雙重挑戰(zhàn)。

 

(2)項目背景

 

為了能快速讓團隊進入步入正軌，商米研發(fā)團隊早期采取和大多數(shù)企業(yè)類似的組織方式，以職能為單位的進行團隊劃分，分為前端、后端、Android端、測試、產(chǎn)品等職能團隊，并采用傳統(tǒng)瀑布研發(fā)模式組織團隊協(xié)作。當(dāng)時，我們稱之為正規(guī)的研發(fā)模式。

 

每個團隊由組長負責(zé)制，具體負責(zé)團隊任務(wù)的分配、技術(shù)決策和人員培養(yǎng)，組員負責(zé)具體的研發(fā)任務(wù)。根據(jù)這樣的職能協(xié)作的方式，商米建立了早期的研發(fā)流程：

 

 

產(chǎn)品經(jīng)理進行原型圖設(shè)計；

 

然后產(chǎn)品經(jīng)理，分別找各個組長請求人員支持；

 

組長根據(jù)自己團隊人員工作現(xiàn)狀，將工作安排給相應(yīng)的同學(xué)，接手產(chǎn)品開發(fā)任務(wù)，完成工作量評估、給出截止時間等；

 

最后再各自團隊的同學(xué)，完成相應(yīng)的工作之后，大家約好一個時間，集中聯(lián)調(diào)一下，再交付給測試團隊。

 

優(yōu)勢	劣勢
資源不易空閑，需求排著隊任何一個組員都能隨時頂上	延續(xù)性差：分配任務(wù)時可能熟悉需求的成員在另一個需求研發(fā)中，其他成員不熟悉此業(yè)務(wù)
組長參與需求把關(guān)，設(shè)計方案得到保障	歸屬感差：團隊成員不對業(yè)務(wù)成果負責(zé)，有任務(wù)就做思考業(yè)務(wù)不深入，潛能發(fā)揮不出來
組長分配任務(wù)，技術(shù)演進容易推動	研發(fā)過程難以保證：研發(fā)過程中沒有監(jiān)管，驗收階段常常出問題
相同專業(yè)成員坐在一塊技術(shù)交流方便	組長被高度依賴：組長要參與評審、分配任務(wù)、解決難題、審核代碼、推動演進技術(shù)、成為最大瓶頸

職能團隊的組織方式，幫助商米走出了第一步。但是彼時，工程能力方面，卻是一窮二白，別說CI/CD了，連部署工作都還是手工FTP上傳文件，來進行服務(wù)器的發(fā)布。

 

沒有專門的運維團隊，服務(wù)器運維工作一直是后端團隊承擔(dān)，發(fā)布又是一個很重要的動作，出不的半點差錯，只能讓后端組組長進行發(fā)布，當(dāng)業(yè)務(wù)不斷發(fā)展，項目數(shù)量不斷增多，負責(zé)發(fā)布的那個同學(xué)苦不堪言。

 

沒有專業(yè)運維團隊，沒有現(xiàn)成的工具。只能硬著頭皮去網(wǎng)上胡亂找一通，Jenkins太復(fù)雜，最后還不容易找到了一個簡易的工具，解決FTP上傳的問題，但最后的發(fā)布還是人工進行。

 

小結(jié)：通過建立職能團隊，產(chǎn)品經(jīng)理對接職能團隊，尋找開發(fā)資源，以瀑布方式組織交付；工程能力方面，采用FTP純手工上傳方式進行發(fā)布，無專業(yè)運維團隊。

 

團隊的不斷增長和快速發(fā)展的業(yè)務(wù)，又帶來了新的挑戰(zhàn)。團隊間協(xié)作依賴，團隊成員業(yè)務(wù)歸屬感差；同時，因為手工為主發(fā)布軟件，通宵發(fā)布不是一件稀罕事。

 

無論是協(xié)作效率，還是工程能力上，這種老牛拉破車的狀態(tài)，逼著商米團隊進行轉(zhuǎn)變。

 

(3)解決方案

 

在尋找解決辦法過程中，商米引入Scrum研發(fā)模式，嘗試將職能團隊改造基于業(yè)務(wù)線的跨職能團隊：

 

資源獨享，組建獨立業(yè)務(wù)交付團隊，每個團隊都包含產(chǎn)品、測試、后端、前端、Android端，跨職能；

 

采用Scrum工作模式，引入Scrum Master 和四次Scrum會議（計劃會、每日站會、評審會議、回顧會議）

 

跨職能團隊恰好能解決當(dāng)時商米遇到的團隊協(xié)作上的問題，但卻無法兼顧職能團隊的優(yōu)勢，于是增加技術(shù)委員會團隊來支持業(yè)務(wù)交付團隊：

 

遇到的問題	技術(shù)委員會的作用
敏捷組成員空閑	委員會分配公共任務(wù)或借調(diào)其他團隊
設(shè)計質(zhì)量難于保障	委員會參與評估避免成員單方面敲定實現(xiàn)設(shè)計
技術(shù)演進難以推動	委員會與SM協(xié)商排期增加重構(gòu)或改進計劃
技術(shù)交流減少	委員會定期進行技術(shù)分享，每周收集成員工作情況

通過敏捷化演進，在團隊協(xié)作上"虛線"和"實線"發(fā)生了變化：

 

 

 

這種方式同時給SUNMI帶來了另外一個改善，在成員評估上可以綜合成果產(chǎn)出、工作狀態(tài)以及技術(shù)能力多方面做出較全面的判斷：

 

PO：評估團隊成員的業(yè)務(wù)成果的貢獻；

 

SM：評估團隊成員配合過程中的積極性，響應(yīng)速度；

 

委員會：評估團隊成員的技術(shù)能力和技術(shù)水平。

 

如組員張三的轉(zhuǎn)正評估：

 

 

為了更好的進行跨地域協(xié)同，數(shù)字化研發(fā)活動，在協(xié)作工具上，商米引入敏捷模板，能夠?qū)print進行規(guī)劃，并且能夠?qū)Φ鷶?shù)據(jù)燃盡圖進行分析。

 

 

 

 

在缺陷管理方面也從Mantis切換到云效缺陷管理，和任務(wù)無縫關(guān)聯(lián)。

 

 

 

 

同時，在文檔協(xié)作上引入Thoughts工具，建立了完善的知識庫體系；

 

 

 

 

研發(fā)協(xié)作模式的改變，給團隊在協(xié)作效率和節(jié)奏上帶來了真正的好處。團隊再也不覺得自己是草臺班子了，而是真正具備一家科技公司該有的樣子。這是技術(shù)團隊，在管理模式上的一次重大升級。

 

 

小結(jié)：采用以業(yè)務(wù)為導(dǎo)向的跨職能團隊，有效解決職能間協(xié)作的依賴問題，同時增加團隊的業(yè)務(wù)歸屬感；以技術(shù)委員會，從職能角度組織人員培養(yǎng)和技術(shù)決策；落地Scrum研發(fā)模式，讓團隊形成節(jié)奏感。

 

 

商米經(jīng)過敏捷轉(zhuǎn)型，解決了部分問題，支撐了團隊規(guī)模和業(yè)務(wù)體量的進一步擴大，進入了新一輪增長期。除了支持企業(yè)內(nèi)部的研發(fā)發(fā)布，同樣商米也在構(gòu)建自己的研發(fā)生態(tài)圈，按部就班的研發(fā)方式，顯然難于應(yīng)對當(dāng)前業(yè)務(wù)的復(fù)雜性和不確定性，體量越來越大。

 

 

同時，隨著產(chǎn)品服務(wù)化之后，服務(wù)的數(shù)量持續(xù)增加。業(yè)務(wù)復(fù)雜性，團隊規(guī)模，還是技術(shù)的復(fù)雜性和耦合性，都給整個協(xié)作和發(fā)布效率帶來了巨大的麻煩。

 

 

看似繁華的背后，卻有著道不盡的心酸：

 

1.發(fā)布流程不規(guī)范

 

2.發(fā)布頻次低，流程長，時間久

 

3.人工介入多，容易出錯

 

4.漏測、搭車現(xiàn)像頻繁

 

5.沒有驗證完，還不愿發(fā)的被發(fā)布了

 

6.每兩個月就有由于流程原因?qū)е碌墓收?/p>

 

7.信息同步不準(zhǔn)確不及時

 

8.任務(wù)的工作狀態(tài)與發(fā)布流程割裂

 

9.線上的事情線下做約定

 

10.發(fā)不發(fā)不清楚，發(fā)到哪不清楚

 

11.不知道具體應(yīng)用什么時候有誰做過發(fā)布

 

12.各角色、各系統(tǒng)之間的信息分離

 

13.檢查及測試手段匱乏

 

14.無檢查無驗證卡點，測試后置

 

15.檢查驗證手段有限，測試手工兜底

 

16.每次發(fā)布，驗證周期時間很長

 

17.代碼評審集中在少數(shù)人，有瓶頸

 

18.代碼評審成為做樣子

 

19.漏發(fā)、漏測

 

20.公地危機，環(huán)境問題

 

21.環(huán)境被長期占用，總是不夠用

 

22.環(huán)境有臟東西，不清楚是什么

 

23.每次發(fā)布，對業(yè)務(wù)有影響，停機發(fā)布

 

 

 

 

如何破？成了商米技術(shù)管理者面前的一道難題。

加速：交付加速的基礎(chǔ)發(fā)布方式的提升

一個偶然的機會，接觸到阿里巴巴云智能的云效團隊，我們決定聯(lián)手解決商米當(dāng)前面臨的難題，經(jīng)過分析，發(fā)現(xiàn)問題主要集中在以下幾個方面：

 

1.返工：批量的集成，容易造成整個版本的失敗，每次失敗，所有的變更都跟著發(fā)不了。所謂，一粒老鼠屎，壞了一鍋湯

 

2.阻塞：手工工序過多，形成等待、阻塞；依賴過多，等待其他的部署

 

3.落后的技術(shù)：手工測試，流水線手工串接及觸發(fā)，信息同步靠口口相傳，純手工維護所有文檔

 

4.債務(wù)：無測試自動化，無有效的代碼掃描手段，無單元測試，應(yīng)用間耦合高

 

5.分析完這些問題，在云效團隊的幫助下，我們分別從整個流程和每道工序上進行了優(yōu)化。

 

 

 

 

通過云效商米解決了工程效能的問題：

 

 

第一步：自動化部署流水線，釋放運維人力。一是對部署能力上，進行自動化改造，不再讓發(fā)布成為瓶頸，團隊想發(fā)就發(fā)，發(fā)失敗了也有相應(yīng)的自動化應(yīng)急措施。另一方面，在整個流水線上，通過流水線模板，快速創(chuàng)建了自己的流水線，并同時進行了改造，保存為企業(yè)自定義的流水線模板，這樣，當(dāng)有團隊需要用到流水線時，自動從模板上復(fù)用下來，減少了配置和推廣的成本，默認(rèn)從同一個模板上生成的流水線，在規(guī)范上是一致的。

 

 

 

 

第二步：建立質(zhì)量保障機制，建立質(zhì)量卡點，防止低級錯誤漏出；完善代碼掃描、單元測試，從源頭控制質(zhì)量；同時，通過流水線的Jenkins插件，把我們之前基于Jenkins job的測試任務(wù)對接進來，完善掉測試屏障。

 

 

 

 

同時，靈活卡點設(shè)置，根據(jù)團隊業(yè)務(wù)情況動態(tài)配置研發(fā)流程。

 

 

 

 

與此同時，我們直接采用代碼平臺提供內(nèi)建的代碼規(guī)約掃描和安全敏感信息掃描，從實際上的效果來看，直接在配置上打開就可以了，還不錯。如果采用非主流的開發(fā)語言，可以把掃描做為流水線當(dāng)中的一個階段任務(wù)，對接進行來就可以了。

 

 

Code Review的能力同樣采用了代碼平臺內(nèi)置的功能，代碼的瀏覽和主流的云上編輯器差不多，可以單行給comments，并且可以將code review設(shè)置為強制卡點。團隊code review的實踐很容易在這個工具下進行。

 

 

我們早期維護了一些自動化的測試用例，一直都是通過Jenkins Job進行運行的，采用流水線之后，通過流水線的Jenkins插件，也把之前的測試用例給跑起來了。

 

 

第三步：通過流水線的編排能力，為業(yè)務(wù)交付團隊提供發(fā)布部署順序上的編排，由業(yè)務(wù)交付團隊自行控制發(fā)布的時間、順序。團隊不再依賴專職的運維同學(xué)幫助發(fā)布軟件。運維團隊也逐漸從發(fā)布工程師，慢慢往SRE的路上發(fā)展。而之前，都是需要開發(fā)工程師反復(fù)寫好發(fā)布的說明，由運維去執(zhí)行。

 

 

 

 

第四步：整個流程可視化，發(fā)布狀態(tài)實時感知，日志完善方便研發(fā)排查問題；

 

 

 

 

我們聽過很多的方法，接觸過許許多多的實踐，但畫在PPT上的流程難于落地，寫在書上的方法離我們太遠。技術(shù)人在意的是實實在在解決問題，將流程和方法，內(nèi)建在工具上，是這次轉(zhuǎn)變的最大收益。

 

 

真正做到流程工具化、過程自動化、反饋數(shù)字化。工程能力的巨大的提升，同時進一步促進了協(xié)作方式的轉(zhuǎn)化。

 

 

(4)價值體現(xiàn)

 

 

由于開發(fā)和運維在工作流程上割裂的原因，在團隊協(xié)作看板上，也是割裂的，彼此完全基于不同的單元在組織工作。

 

 

兩周的迭代，第一周，需要主要集中在團隊開發(fā)看板上，第二周，發(fā)布請求主要集中在運維發(fā) 布看板上 。

 

 

Scrum Master在開發(fā)團隊的看板上剛組織完需求協(xié)作：

 

 

 

 

又得到運維看板上去協(xié)調(diào)發(fā)布請求，并且建立發(fā)布請求與需求之間的關(guān)系：

 

 

 

 

當(dāng)發(fā)布工作完全由團隊自行決定后，團隊可以自行控制發(fā)布節(jié)奏，很自然地融合了開發(fā)看板及運維看板，形成完整的需求交付生命周期，基于需求組織交付協(xié)作。

 

 

 

 

引入云效DevOps工具，工程師可以直接從需求/任務(wù)卡片上創(chuàng)建變更分支，自動就將代碼變更與需求/任務(wù)卡片進行關(guān)聯(lián)，代碼變更的提交，同時自動地觸發(fā)的流水線，流水線的狀態(tài)也同樣會顯示到開發(fā)看板中，大大減少了信息同步過程花費的時間。

 

 

 

 

 

 

真正做到基于一個團隊開發(fā)看板，就能可視化代碼變更、發(fā)布流程所有信息，將隱性的工作顯性化，進一步簡化了信息同步，促進了協(xié)作。

 

 

 

 

每日站會，開發(fā)者基于云效進行需求或任務(wù)指派

 

 

開發(fā)者基于需求/任務(wù)，自動創(chuàng)建變更分支

 

 

將需求的代碼變更提交到變更分支，采用內(nèi)置的代碼規(guī)約和安全掃描，完成代碼檢查，并發(fā)起代碼評審

 

 

代碼評審?fù)ㄟ^，自動觸發(fā)發(fā)布流水線

 

 

中間所有的代碼變更、發(fā)布流水線狀態(tài)，全都自動同步到需求/任務(wù)卡片上，保證需求上匯集協(xié)同所需要的全部信息。同時釘釘機器人將發(fā)布過程中的任何問題，自動推送給開發(fā)者，完全精確反饋。

 

 

商米引入云效工具再加上協(xié)作方式的改變，為整個商米軟件研發(fā)效能帶來了巨大的提升，真正意義上的進入了“高鐵時代”。從過去每周兩次的發(fā)布窗口期改善為隨時可交付，部分團隊甚至一天可以進行三次交付，大幅節(jié)省了運維發(fā)布時間，不再依賴人工操作和當(dāng)面溝通，團隊內(nèi)部可以在一個TB看板內(nèi)關(guān)注到需求交付的全過程。

 

 

小結(jié)：優(yōu)化部署流水線，按工序持續(xù)完善質(zhì)量保障，為持續(xù)交付建立工程能力基礎(chǔ)；同時，工程能力的提升，也促進協(xié)作方式的改進。

 

 

 

 

 

三個階段小結(jié)：

 

 

階段	協(xié)作方式	工程能力
蒸汽時代	職能團隊，傳統(tǒng)瀑布方式	純手工，借助FTP工具發(fā)布
電氣時代	跨職能團隊，Scrum方式	開源工具，手工，專職運維發(fā)布
高鐵時代	全職能，精益開發(fā)，云效	阿里云效、自動化，開發(fā)自運維

 

 

 

 

 

不光要快，還要安全。無論是真正的高鐵，還是DevOps。對于中小企業(yè)來說，安全就是生命線，誰也不敢在資產(chǎn)安全問題上掉以輕心。

 

 

針對中小企業(yè)來說，要完整地構(gòu)建安全編碼的能力，缺少這樣的實踐，同時，也缺少比較好的規(guī)則引擎。我們采用代碼平臺內(nèi)置的代碼規(guī)約掃描把一般的編程中容易導(dǎo)致安全漏洞的代碼給識別出來，同時，我們也通過一些敏感信息掃描，來識別是否有把安全相應(yīng)的信息給明文化出來。

 

 

 

 

同時，針對工具平臺本身的安全，同樣采用代碼平臺提供的白名單設(shè)置，權(quán)限管理等，來提前做好安全的防控，做到事前預(yù)防；同時，在過程，工具平臺，還可以對一些異常行為（如批量的代碼轉(zhuǎn)移或刪除動作）進行監(jiān)控，提前提出預(yù)警，做到事中監(jiān)控；如果一旦發(fā)現(xiàn)有問題，我們也可以利用平臺的日志功能，來做到事后追溯的目的。

 

 

整體上來說，這些安全的能力已經(jīng)完全夠用，如果不想用到這些能力，想用自己的話，也可以，disable掉，接入自己的就可以了。不過，我還是建議那些沒有太多安全防控能力的企業(yè)，直接采用平臺內(nèi)置的功能，省得重復(fù)制造輪子。

 

 

問題永遠是創(chuàng)新發(fā)展的發(fā)動機。在商米走向DevOps的路上，正是這樣一個個的問題，促使著我們?nèi)ヌ剿靼l(fā)現(xiàn)，也正是這樣每一次的探索發(fā)現(xiàn)，在解決問題路上的那點小糾結(jié)、小成就、小雀喜，讓我們在解決問題的路上走得更堅定，更有信心。

 

 

感謝在我們成長路上幫助過的人們，正是你們的毫無保留地幫助，才讓我們走得越來越有信心。我們依舊在路上。

 

 

希望我們的故事，能夠?qū)δ阌幸稽c點啟發(fā)，那怕只是一點點，我們也會很開心。