從「蒸汽時代」到「高鐵時代」，SUNMI DevOps 轉型之路財經頭條網

2020-03-18 08:56:02 CSDN

作者 | 文振熙、劉文灃

出品 | CSDN博客

封圖| CSDN 下載於視覺中國

商米科技成立於 2013 年，總部位於上海市楊浦區創智天地，是一傢俱有產品創新基因和互聯網基因的公司。商米在短時間內迅速成長為一家近1000人的企業，產品研發人數佔比一度超過70%。做為一家初創企業，商米研發團隊早期也經歷過與當下大部分創業公司一樣困境：協作基本靠吼、發佈基本靠手的階段。然而，業務的快速發展，團隊規模不斷的擴大，給商米帶來了在「團隊協作」和「工程效能」上的雙重挑戰。

蒸汽時代

為了能快速讓團隊進入步入正軌，商米研發團隊早期採取和大多數企業類似的組織方式，以職能為單位的進行團隊劃分，分為前端、後端、Android端、測試、產品等職能團隊，並採用傳統瀑布研發模式組織團隊協作。當時，我們稱之為正規的研發模式。

每個團隊由組長負責制，具體負責團隊任務的分配、技術決策和人員培養，組員負責具體的研發任務。根據這樣的職能協作的方式，商米建立了早期的研發流程：

產品經理進行原型圖設計；
然後產品經理，分別找各個組長請求人員支持；
組長根據自己團隊人員工作現狀，將工作安排給相應的同學，接手產品開發任務，完成工作量評估、給出截止時間等；
最後再各自團隊的同學，完成相應的工作之後，大家約好一個時間，集中聯調一下，再交付給測試團隊。

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

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

沒有專業運維團隊，沒有現成的工具。只能硬著頭皮去網上胡亂找一通，Jenkins太複雜，最後還不容易找到了一個簡易的工具，解決FTP上傳的問題，但最後的發佈還是人工進行。

小結：

通過建立職能團隊，產品經理對接職能團隊，尋找開發資源，以瀑布方式組織交付；工程能力方面，採用FTP純手工上傳方式進行發佈，無專業運維團隊。

團隊的不斷增長和快速發展的業務，又帶來了新的挑戰。團隊間協作依賴，團隊成員業務歸屬感差；同時，因為手工為主發佈軟件，通宵發佈不是一件稀罕事。

無論是協作效率，還是工程能力上，這種老牛拉破車的狀態，逼著商米團隊進行轉變。

電氣時代

在尋找解決辦法過程中，商米向Teambition學習，並引入Scrum研發模式，嘗試將職能團隊改造基於業務線的跨職能團隊：

資源獨享，組建獨立業務交付團隊，每個團隊都包含產品、測試、後端、前端、Android端，跨職能；
採用Scrum工作模式，引入Scrum Master 和四次Scrum會議（計劃會、每日站會、評審會議、回顧會議）

跨職能團隊恰好能解決當時商米遇到的團隊協作上的問題，但卻無法兼顧職能團隊的優勢，於是增加技術委員會團隊來支持業務交付團隊：

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

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

PO：評估團隊成員的業務成果的貢獻；
SM：評估團隊成員配合過程中的積極性，響應速度；
委員會：評估團隊成員的技術能力和技術水平。

如組員張三的轉正評估：

為了更好的進行跨地域協同，數字化研發活動，在協作工具上，商米引入Teambition推出的敏捷模板，能夠對Sprint進行規劃，並且能夠對迭代數據燃盡圖進行分析。

在缺陷管理方面也從Mantis切換到Teambition的缺陷管理，和任務無縫關聯。

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

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

小結：

採用以業務為導向的跨職能團隊，有效解決職能間協作的依賴問題，同時增加團隊的業務歸屬感；

以技術委員會，從職能角度組織人員培養和技術決策；落地Scrum研發模式，讓團隊形成節奏感。

商米經過敏捷轉型，解決了部分問題，支撐了團隊規模和業務體量的進一步擴大，進入了新一輪增長期。除了支持企業內部的研發發佈，同樣商米也在構建自己的研發生態圈，按部就班的研發方式，顯然難於應對當前業務的複雜性和不確定性，體量越來越大。

同時，隨著產品服務化之後，服務的數量持續增加。業務複雜性，團隊規模，還是技術的複雜性和耦合性，都給整個協作和發佈效率帶來了巨大的麻煩。

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

1、發佈流程不規範

發佈頻次低，流程長，時間久
人工介入多，容易出錯

漏測、搭車現像頻繁
沒有驗證完，還不願發的被髮布了
每兩個月就有由於流程原因導致的故障

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

任務的工作狀態與發佈流程割裂
線上的事情線下做約定
發不發不清楚，發到哪不清楚
不知道具體應用什麼時候有誰做過發佈
各角色、各系統之間的信息分離

3、檢查及測試手段匱乏

無檢查無驗證卡點，測試後置
檢查驗證手段有限，測試手工兜底
每次發佈，驗證週期時間很長
代碼評審集中在少數人，有瓶頸
代碼評審成為做樣子
漏發、漏測

4、公地危機，環境問題

環境被長期佔用，總是不夠用

環境有髒東西，不清楚是什麼
每次發佈，對業務有影響，停機發布

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

高鐵時代

1、加速：交付加速的基礎發佈方式的提升

一個偶然的機會，接觸到阿里巴巴雲智能的雲效團隊，我們決定聯手解決商米當前面臨的難題，經過分析，發現問題主要集中在以下幾個方面：

返工：批量的集成，容易造成整個版本的失敗，每次失敗，所有的變更都跟著發不了。所謂，一粒老鼠屎，壞了一鍋湯
阻塞：手工工序過多，形成等待、阻塞；依賴過多，等待其他的部署
落後的技術：手工測試，流水線手工串接及觸發，信息同步靠口口相傳，純手工維護所有文檔
債務：無測試自動化，無有效的代碼掃描手段，無單元測試，應用間耦合高

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

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

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

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

同時，靈活卡點設置，根據團隊業務情況動態配置研發流程。

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

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

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

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

第四步：整個流程可視化，發佈狀態實時感知，日誌完善方便研發排查問題；

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

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

2、工程能力建設作用於協作方式的轉變

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

兩週的迭代，第一週，需要主要集中在團隊開發看板上，第二週，發佈請求主要集中在運維發佈看板上。

Scrum Master在開發團隊的看板上剛組織完需求協作：

又得到運維看板上去協調發布請求，並且建立發佈請求與需求之間的關係：

當發佈工作完全由團隊自行決定後，團隊可以自行控制發佈節奏，很自然地融合了開發看板及運維看板，形成完整的需求交付生命週期，基於需求組織交付協作。

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

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

每日站會，開發者基於teambition進行需求或任務指派
開發者基於需求/任務，自動創建變更分支
將需求的代碼變更提交到變更分支，在行雲上，採用內置的代碼規約和安全掃描，完成代碼檢查，併發起代碼評審
代碼評審通過，自動觸發發佈流水線
中間所有的代碼變更、發佈流水線狀態，全都自動同步到需求/任務卡片上，保證需求上彙集協同所需要的全部信息。同時釘釘機器人將發佈過程中的任何問題，自動推送給開發者，完全精確反饋。

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

使用Teambition進行任務協作共521名成員，Teambition近期活躍項目49個；
使用Codeup管理138個Git項目，3個月來共使用MR合併審核代碼964次；
使用Flow管理120條發佈流水線，3個月來共運行過3910次，成功上線771次，平均每天65次構建，12次生產發佈。
發佈窗口期從週二週四演進到隨時可發，發佈時間從數小時到一天半縮短到半小時以內；
交付速度從兩週一次交付縮短到一天能夠發佈三次，交付三個功能點或修復BUG交付到用戶手中；

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

小結：

優化部署流水線，按工序持續完善質量保障，為持續交付建立工程能力基礎；同時，工程能力的提升，也促進協作方式的改進。

三個階段小結：

從DevOps到SecDevOps

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

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

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

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