9 月 19 日，CODING 和中國 DevOps 社群聯合舉辦的深圳第九屆 Meetup 在騰訊大廈 2 樓多功能圓滿結束。本次沙龍以 「DevOps 轉型與實踐」 為主題，4 位來自網際網路、金融、零售行業的知名世界 500 強企業技術大咖，在現場分享了他們對於 DevOps 轉型實踐的見解和經驗。80 多位觀眾與講師們也進行了深入的技術探討，共同探討在 DevOps 潮流下，企業可能面臨的新機遇和挑戰。
CODING 一直致力於讓所有開發者都能有機會傾聽最具前沿的 DevOps 技術分享，之後還會在全國各地舉辦一系列 DevOps 技術沙龍。在不同城市的小夥伴也無需擔心，我們屆時會提供線上直播平臺，讓異地的同學也能與導師無障礙交流，敬請期待！話不多說，本期為大家分享的是《DevOps 在 SEE 小電鋪的落地與實踐》——
背景介紹
SEE 小電鋪是微信生態內最大的小程式電商服務平臺，目前累計與 10000+ 自媒體合作開店，是微博、鬥魚等平臺的官方電商 SaaS 服務商，以及抖音頭部渠道電商平臺。
SEE 小電鋪技術負責人馬志雄講述了在競爭激烈的電商行業背景下，SEE 小電鋪是如何引入業界優秀的 DevOps 實踐，打造了高效穩定的應用交付體系，幫助公司邁向雲原生時代的。他主要圍繞落地的法則，分享了 SEE 小電鋪內 DevOps 實踐的目標、落地的原則和具體實踐。
引入 DevOps 實踐
在疫情期間， SEE 小電鋪的工作人員採取了遠端辦公模式，這對所有人的協作和效率提出了更高的要求。研發流程中出現的各種問題促使 SEE 小電鋪反思技術架構、研發流程、度量工具以及團隊文化如何能夠高質量地順暢交付使用者價值。
持續改革的第一步是識別問題。經過調研和討論，SEE 小電鋪首先引入了 DevOps 能力成熟度模型，對當前團隊裡面存在的問題以及需要補齊的能力進行梳理。
SEE 小電鋪在組織支撐方面設立了 DevOps 工作小組，由工程效能團隊專項推進，把DevOps 具體事項納入 OKR 裡進行目標管理，並拆解到相關的一線同事裡面去。藉此機會，團隊文化被重新塑造，工作小組不斷和一線同事講未來的技術方向是什麼，為什麼要去做這件事情，和所有人同步推進 DevOps 目標、方法和策略。在具體落地路徑上，灰度思維幫助優先主導推進那些對 DevOps 認同度比較高的同事，從比較容易改造並且能夠迅速看到成效的專案著手。
隨後，SEE 小電鋪制定了一期改進目標：
- 統一工具平臺
過去 SEE 小電鋪使用了繁多的工具，不僅有維護成本高等問題，在實際研發過程中的使用也不太順暢。舉個例子，部署還是依賴於人工 + 指令碼的方式手動進行。在調研了市面上各種 DevOps 工具，最終 SEE 小電鋪選擇了 CODING DevOps 作為一站式研發平臺。主要的優勢體現在不需要跳轉多個產品，整個資料是打通互聯的，而且部署在國內，訪問速度好，中文支援度高，團隊成員上手也比較快。另外，持續部署是基於 Spinnaker，功能比較強大，和目前使用的騰訊雲整合較好。測試管理也無需單獨付費，整個維護無需自建維護，價效比高。
- 統一分支策略
在工具切換之後，SEE 小電鋪面臨的一個困境是分支策略不統一。GitLab Flow 和 Git Flow 混合使用，整個流程非常複雜，容易出錯，合併也非常費時。多個版本並行時，GitLab Flow 需要配套多個環境，與持續整合的理念相違背。為了把研發效能提升到比較極致的狀態，SEE 小電鋪結合團隊自身的情況，決定採用有功能分支的主幹開發策略，然後在團隊內部不斷地去講怎麼用，包括怎麼去更好地拆使用者故事和任務，怎麼去做 git cherry-pick 和 rebase ，怎麼去把 commit 設計得更加原子性等。
- 統一製品管理
SEE 小電鋪之前面臨的製品管理困境是應用的分發包是多種多樣的：整個系統在經過微服務進行改造以後，累計有四五十個服務需要進行維護，面臨著多應用集合管理和配置困難的問題；另外製品庫也是不統一的，缺乏統一的管控以及許可權控制。在這種情況下，SEE 小店鋪使用了 Docker 和 Helm 來解決製品的統一性問題。Docker 映象能夠標準化交付元件， Helm 能夠幫助簡化 K8s 資源集合管理和配置，並且方便回滾和更新。製品庫則統一遷移到 CODING 製品庫來做製品託管，實現應用製品的單一來源管控以及細粒度的許可權控制。
- 統一整合和部署流水線
經過多年的業務發展，SEE 小電鋪的應用數量非常多，缺乏體系化的流水線建設。少部分比較完善的專案工程使用 GitLab CI，還有一部分用 Jenkins 來做構建打包，大部分的應用還在使用 shell 指令碼拉取 jar 包進行釋出，已有的自動化部署耦合在 CI 裡，環境與配置複雜以後難以維護，不夠規範且效率低容易出錯。因此 SEE 小電鋪首先制定了 CI 流水線的規範，包括根據不同的技術棧設計符合的流水線流程，根據分支模型和 MR 流程劃分全量整合和增量整合，以及各個流程的耗時標準；之後把工具統一切換到 CODING 支援的 Jenkins，做好構建節點的資源規劃，確保每次流水線都會觸發自動化測試，包括程式碼格式檢查，程式碼規範和靜態分析，以及單元測試、整合測試和 E2E 測試的自動化執行。最終執行的一個結果會通過企微機器人同步到專門的工作群。
持續部署的流水線設計，主要是藉助 Spinnaker 來進行編排，配置好 Bake 和部署流程，這裡面的交付製品統一使用 Helm Chart，並且藉助 CODING 的持續部署功能來進行釋出單的管理，包括建立提單，並行部署，人工審批等。
雲原生基礎架構
除了以上這四步以外，SEE 小電鋪的 DevOps 實踐還貫穿了很多其他理念。首先在基礎架構方面，SEE 小電鋪貫徹雲原生的理念，把整個應用進行了 K8s 容器改造，直接使用騰訊雲 TKE 產品來託管叢集，幫助快速完成容器化改造，進行微服務和 BFF 架構風格下的高效容器編排，實現應用的標準化交付，確保資源隔離性和高效的利用率，並能保證環境的一致性。同時在面對流量潮汐時，也能夠基於 HPA 和 Cluster AutoScaler 實現 Pod 和節點靈活快速的擴縮容，從容應對業務的各種活動和大促。同時藉助 K8s 的 Readiness Probe 和 Liveness Probe，能夠比較好地實現服務的自愈和容錯。在把 K8s 引入基礎架構以後，SEE 小電鋪通過引入服務網格技術 Service Mesh 實現了更加精細化的服務治理。通過 Istio 服務治理中核心的 Virtual Service 和 Destination Rules 這兩個 CRD 結合 CODING 的持續部署可以實現自動化灰度釋出，取代原有的叢集藍綠髮布策略，把資源利用和流量控制做到一個相對比較極致的水平，並且把微服務架構裡難以落地的服務治理固化成了一個標準的基礎設施，讓開發能夠更加關注應用本身。
在上圖中，根據 Istio 裡面的配置規則可以實現按百分比把 10% 的流量打到新的應用裡，最終通過校驗以後可以把整個流量進行完全切換，實現精細化的流量轉移。
可靠性 & 可觀測性
SRE 方法論被 SEE 小電鋪引入指導可靠性建設。首先，SLO 可靠性建模包括三個維度：Availability 可用性、Latency 延遲和 Ticket 人工干預。這三個維度分別對前後端應用進行了白盒和黑盒監控指標採集，模型計算公式最終可以輸出整個服務指標。SRE 團隊基於此模型搭建了內部所有服務的可靠性看板，能夠實時對生產環境的服務可靠性指標進行檢視和跟進。SRE 方法論中還有一個非常好的概念，就是錯誤預算。基於 SLO 的模型，可以計算出一段週期內錯誤預算消耗了多少，從而決定是否調整這個週期內的版本釋出頻率以及節奏。比如說要維持 99.9% 的可靠性，那一個月內的不可用視窗期就是 43.2 分鐘。
可觀測性基於 EFK 日誌平臺做了所有服務的日誌收集與聚合，幫助做 K8s 改造後所有容器的收集；指標監控方面基於 Prometheus 和 Grafana 搭建了監控平臺，幫助進行釋出盯盤和對 Pod 異常指標進行記錄和告警。
質量內建
質量內建方面，SEE 小電鋪遵循了一些 DevOps 社群內較為流行的原則來實施。首先是質量門禁，內部的指標所有單元測試模組覆蓋率都必須大於 80%，老的系統也會在專案排期裡面不斷補充完善，web、小程式、iOS、Android 和 React Native 等應用要求要有 100% 的 E2E 測試來覆蓋所有的應用場景，質量門禁還需要管控合併請求，開發的 MR 需要通過 CI 自動化測試，CODING 遠端提供的程式碼靜態掃描以及結對程式碼 Review 以後才會被合併到主幹。其次，CODING 的測試管理成功將 SEE 小電鋪從原始的 Excel 管理測試用例中解放出來，支援用例的線上評審並制定迭代的測試計劃。DogFooding 自測允許在整合環境上進行冒煙測試，通過測試管理中的測試計劃進行追蹤，並組織提測前的 demo 演示。
成果
在半年多的 DevOps 變革和實踐裡，SEE 小電鋪實現了多項核心指標提升，單個服務部署時長從以前的數小時縮短到 5 分鐘，總的全量環境部署也從一兩個星期縮短到 1 個小時，開發 bug 率下降了 10 倍左右。調整迭代規劃以後，大概達到每週 2 次全量環境部署頻率，變更前置時間也縮短到 1 周以內，可用性也達到了 99.9%。更重要的是，團隊更加聚焦到了業務交付本身。
Q：Helm Chart 管理的資源很多，你們在這方面有沒有最佳實踐？
A：我們做了很粗暴的一刀切，前端的應用是公共的 Helm Chart，後端的應用是另外一個 Chart，各個服務作為 Chart 中的子應用，是 Chart 裡面的其中一塊。在內部工程效能組規範化以後，所有的應用都是按照這個模板來做的。
Q：請問你們團隊是怎麼保證釋出後的質量的？
A：我們的可用性維持在 99.9% 左右，但難免還是會有洩露的 bug，我們要在業務創新和穩定性中取得權衡，這個權衡就是通過 SLO 的方式。我們通過確保整體的服務維持在 99.9% 的可靠性目標前提下，儘可能快地去釋出我們的應用。
溫馨提示：
更多講師 PPT 及演講稿脫敏後將逐步更新
點選開啟 CODING DevOps 雲上研發工作流