作者 |?文振熙、劉文灃

?責編 | 徐威龍

封圖|?CSDN 下載于視覺中國

商米科技成立于 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)歷過與當下大部分創(chuàng)業(yè)公司一樣困境：協(xié)作基本靠吼、發(fā)布基本靠手的階段。然而，業(yè)務(wù)的快速發(fā)展，團隊規(guī)模不斷的擴大，給商米帶來了在「團隊協(xié)作」和「工程效能」上的雙重挑戰(zhàn)。

蒸汽時代

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

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

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

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

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

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

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

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

沒有專業(yè)運維團隊，沒有現(xiàn)成的工具。只能硬著頭皮去網(wǎng)上胡亂找一通，Jenkins太復雜，最后還不容易找到了一個簡易的工具，解決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)變。

電氣時代

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

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

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

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

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

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

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

• SM：評估團隊成員配合過程中的積極性，響應速度；

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

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

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

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

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

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

小結(jié)：

采用以業(yè)務(wù)為導向的跨職能團隊，有效解決職能間協(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è)務(wù)的復雜性和不確定性，體量越來越大。

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

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

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

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

• 人工介入多，容易出錯

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

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

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

2、信息同步不準確不及時

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

• 線上的事情線下做約定

• 發(fā)不發(fā)不清楚，發(fā)到哪不清楚

• 不知道具體應用什么時候有誰做過發(fā)布

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

3、檢查及測試手段匱乏

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

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

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

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

• 代碼評審成為做樣子

• 漏發(fā)、漏測

4、公地危機，環(huán)境問題

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

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

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

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

高鐵時代

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

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

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

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

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

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

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

通過"行云/飛流"工具套件，商米解決了工程效能的問題：

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

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

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

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

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

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

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

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

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

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

2、工程能力建設(shè)作用于協(xié)作方式的轉(zhuǎn)變

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

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

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

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

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

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

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

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

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

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

• 代碼評審通過，自動觸發(fā)發(fā)布流水線

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

從2019年12月20號開始，截止到2020年2月21日，在短短三個月里SUNMI從零開始，做到了從「蒸汽時代」到「高鐵時代」的蛻變，到現(xiàn)在：

• 使用Teambition進行任務(wù)協(xié)作共521名成員，Teambition近期活躍項目49個；

• 使用Codeup管理138個Git項目，3個月來共使用MR合并審核代碼964次；

• 使用Flow管理120條發(fā)布流水線，3個月來共運行過3910次，成功上線771次，平均每天65次構(gòu)建，12次生產(chǎn)發(fā)布。

• 發(fā)布窗口期從周二周四演進到隨時可發(fā)，發(fā)布時間從數(shù)小時到一天半縮短到半小時以內(nèi)；

• 交付速度從兩周一次交付縮短到一天能夠發(fā)布三次，交付三個功能點或修復BUG交付到用戶手中；

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

小結(jié)：

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

三個階段小結(jié)：

從DevOps到SecDevOps

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

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

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

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

寫在后面

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

希望商米的故事，能夠?qū)δ阌幸稽c點啟發(fā)，哪怕只是一點點。

參考：

阿里云智能云研發(fā)團隊：《跨越敏捷，企業(yè)DevOps解決方案》

https://thoughts.teambition.com/sharespace/5e46536cb5d8ea001aa0d8a5/docs/5e4e7907281780001b935245

作者介紹

文振熙，2015年加入SUNMI科技，一直從事云計算研發(fā)管理相應崗位，當前任職「SUNMI-云計算委員會主任」、「SUNMI-SBS業(yè)務(wù)線后端委員會組長」。曾推動SUNMI多次轉(zhuǎn)型：Go語言推廣、全面SOA服務(wù)化、K8S容器化落地、Wayne自助平臺以及《行云/飛流》CI/CD落地等。

劉文灃，2017年加入SUNMI科技，從業(yè)務(wù)開發(fā)至前端研發(fā)管理，現(xiàn)任職「SUNMI-SBS業(yè)務(wù)線前端委員會組長」。先后承擔多次技術(shù)攻堅及推動技術(shù)演進：ng1向react棧的遷移改造、基于webrtc的設(shè)備遠控功能、 前端自動化構(gòu)建及容器化部署、項目微應用化以及「行云/飛流」CI/CD落地等。

聲明：本文為CSDN博主「喵了_個咪」的原創(chuàng)文章，博文鏈接：https://blog.csdn.net/u011142688/article/details/104859720。

推薦閱讀：百萬人學AI：CSDN重磅共建人工智能技術(shù)新生態(tài)突破性能極限——阿里云神龍最新ASPLOS論文解讀漫畫：如何給女朋友解釋什么是熔斷？ 疫情期間天天對你“開槍”的額溫槍，你知道它的工作原理嗎？| 原力計劃 如何更新你的機器學習模型？手把手帶你設(shè)計一個可持續(xù)的預測模型！ 區(qū)塊鏈數(shù)據(jù)分析，讓你看清交易對手 真香，朕在看了！

總結(jié)

以上是生活随笔為你收集整理的DevOps：从「蒸汽时代」到「高铁时代」，SUNMI DevOps转型之路 | 原力计划的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。