前言
在剛結束的深圳 GOPS 2017 全球運維大會上，來自 JFrog 的全球研發副總裁 Jagan Subramanian 發表了演講。

Jagan 之前在甲骨文供職了16年，擔任高階研發總監。由於之前甲骨文收購了很多公司，這些新的團隊使用不同的語言開發，不同的倉庫儲存自研件，並且各種維護不同的上線流程，導致公司內部的軟體交付流程非常混亂。同時隨著軟體微服務架構的落地，團隊產生的包越來越多，團隊之間很難協作。

為了解決這些痛點，在2013年，Jagan 開始負責開發甲骨文內部持續交付的 PaaS 平臺，名叫 Carson，目的是為公司內部所有的開發團隊提供統一的，自助式的持續交付平臺。

在底層 DevOps 工具的選擇上，為了滿足團隊開發語言多樣化，需要統一，自助式軟體交付流水線的管理，跨團隊之間協同構建，釋出等需求， Jagan 比較了很很多工具，最終選擇了 Artifactory 和 Jenkins/Hudson 作為底層的工具，在上層開發了 Carson，實現了統一，自助式持續交付的平臺。目前這個平臺已經為甲骨文內部幾萬個開發者使用，為公司管理了1億多個軟體包。

Jagan 成功主導了甲骨文中介軟體，資料庫等產品線的 DevOps 變革。如果您也想成為公司內部推動DevOps的領袖，就來參考下 Jagan 經驗！

1、甲骨文的痛點

1. Stack Build 構建耗時很長。

   Stack Build 是指的 A 構建時依賴 B，B 構建時依賴 C，導致在重複 Stack Build時，需要花費大量的時間。

2. 同一個依賴包有多個版本被引用。

   舉例：團隊 A 開發了一個共用包，比如是解析 MQ 訊息通用服務 common.jar V1.0。B 和 C 團隊都引用了，一個月後 A 團隊升級了，B 引用了common.jar V1.1，但 C 沒有升級，在整合 A，B，C 的服務時，這個通用服務被引入了common.jar 的兩個版本。
3. 呼叫內部介面。

   舉例：當團隊A，急需獲得團隊 B的資料， A 雖然知道不應該直接呼叫 B 的內部方法，但 A還是會要求 B 提供一個內部方法，等 B 定義好了外部介面，A 再來改程式碼呼叫外部介面。但實際情況是 A 完成了功能交付了程式碼之後，再也不會做重構。這樣就導致了 A 和 B 模組直接的緊耦合。

4. 依賴關係混亂。

   當某個中介軟體需要重構，他並不知道公司內部哪些產品會被影響到，因為每個人看起來都會被影響。

5. 開發者的環境通常和生產環境不一致。

   舉例：開發者在本地測試沒問題，放到客戶環境或者線上環境就出問題。

6. 缺乏透明度，視覺化。

   團隊中每個人都看不到當前的流程，沒法評估當前流程有什麼可以改進的地方。例如缺乏每次構建的時間，測試覆蓋率，測試通過率，上線成功率，釋出週期等指標的統計，導致。
7. 傳統的工具難以適配新的技術。

   例如 C/C++ 的依賴管理就是個很大的痛點，由於 C/C++ 的編譯依賴不能跨平臺，它依賴與編譯工具 cmake 或者 gcc，也依賴與晶片架構，所有缺少一個類似於Maven 的依賴管理工具來管理所有的包。

8. 實現雲化。

   在申請計算，儲存，網路資源時，依賴於硬體，沒有實現虛擬化，按需建立，消費資源。

2、Jagan在甲骨文推進DevOps的方法

1. 定位問題。作為公司內部 DevOps 的領袖，你應該讓開發，測試，運維的 Leader 坐在一起，從公司的角度來思考面臨的問題，確保三個團隊朝相同的方向努力。
2. 實驗方案。讓三個團隊的 Leader 一起討論如何改進公司的流程，討論每個團隊需要改變什麼。在這個階段，要儘量進行足夠多的 POC，找個合適的方案解決公司問題。
3. 實現方案。和上一步 POC 的人一起進行方案的實現。此時你需要解決基礎設施的問題，保證基礎設施能夠支援這些方案。在測試要注意元資料的收集，例如每次構建的時間，測試覆蓋率，測試通過率，上線成功率，釋出週期。這些資料將來是執行持續度量的重要資料來源。
4. 採用方案。採用方案時，你需要為其他團隊準備好文件，技術方面的支援，準備好工具。但並不意味著你準備好了文件，工具，公司團隊就會配合你。公司可能有10-15%的團隊堅定的支援你，並且他們會需要更先進的工具和方案。另一部分人30%會相對保守，他們知道轉型有什麼用，並且會需要你來指導他們進行DevOps 的轉變。

   還有一部分人會拒絕改變，你要讓已經實施 DevOps 的團隊作為示範專案，讓所有人看到基於資料的視覺化報表，看到他們的成果。

5. 持續評估，持續度量。此時做評估，度量，一定要用視覺化的工具度量，不能憑感覺說話，必須依靠資料說話。這就可以利用第三，四步中積累的元資料進行基於資料的度量，這個度量不僅僅是團隊內部的，還可以是跨產品線的度量。當然評估之後會有發現新的問題，繼續迴圈繼續下去。

3、落地DevOps最佳實踐

1. 協作。

團隊之間很難做到真正的互相傾聽，你需要作為那個中間人提供溝通的渠道。肯定會有人有質疑，但願意溝通就是好事，因為最後你會和大家一起定出來團隊之間協作的流程。

2. 透明化，視覺化。

有人會問為什麼在持續交付的流程裡需要收集這麼多元資料，這些元資料是評估交付流程好壞的唯一標準，這些元資料將來會給公司的轉型代理巨大的價值。

你需要作為團隊交付流程透明化，視覺化的領導者。Jagan 在甲骨文內部搭建了 CI/CD平臺叫 Carson，這個平臺為開發者提供視覺化的構建流程，自定義構建流程編排，資源申請，資料統計等等很多功能。

視覺化的 CI 流水線：

視覺化的報表：

用這些視覺化的資料，來度量 DevOps 獲得的收益，包括測試通過率，構建成功率，構建速度，釋出週期，資源分配情況，基於資料做成正確的決策，才是 DevOps 帶來的價值。

3. 團隊獨立自主。

每個團隊都應該有自己的 CICD 流水線。Oracle 的實踐，他們為每個團隊提供自助式的構建伺服器的使用。從 QA 團隊，每個團隊也自助式的消費測試叢集。

自助式CI服務編排:

4. 基礎設施即程式碼。

運維的團隊應該應該將所有的資源用程式碼來描述，因為運維團隊的變更是沒有記錄的，也沒有被測試過，導致環境容易產生不一致性。所以基礎設施應該作為程式碼 checkin，然後進行測試。

5. 自動化。

為了提高效率，我們不應該容忍在軟體釋出流程裡有任何人工審批的操作。通過大量的自動化測試的 Case 來保證軟體的質量，並且將測試結果與釋出的包關聯，實現基於元資料的包釋出。

6. 設定較高目標。

之前甲骨文的堆疊構建釋出流程要經過2-3周的時間，最近已經能夠達到每天多次的釋出。

今天，整個產品釋出週期從一年半，縮減到3個月。整個軟體架構轉變為微服務架構，每天多次釋出服務。

Jagan 認為，為團隊設定一個較高的目標，這會讓團隊興奮，團隊會全力全完成它，通常，最後的結果是團隊證明了他們能夠達到這個目標。

7. 持續度量。

流程以及產出物使用資料視覺化工具視覺化。

甲骨文中介軟體團隊一個數據中心的儲存量是80TB，每天的請求達到3千萬次，下載的資料量達到 85TB，全球有6個數據中心。

從 Artifactory 儲存量的角度看甲骨文 DevOps 落地的速度。2013年 DevOps 開始落地，開始從中介軟體的某幾個團隊開始試點，到14年後，這些團隊的成功案例影響到了其他團隊，從 Artifactory 儲存量可以看到，容量明顯增長，其他的團隊都來複制這個模式。15年開始，Artifactory 開始持續進行自動化的工件清理，節省了大量儲存空間。

通過視覺化的度量，可以清楚知道產品的構建速度，釋出成功率，釋出週期等等，這些度量指標將作為下一個開發週期目標的參考基準，為團隊指定合理的目標。

元資料也可以用來評估某個產品線佔用的資源，投入產出比，做跨團隊直接的績效考評。

8. 快速失敗。
上游構建的測試用例裡要包含下游構建的測試用例，這樣讓測試在上游測試階段失敗，而不是要等到下游測試，才發現測試失敗。

9. 保持質疑。

在每一環境都保持質疑，問問自己，團隊能否做得更好，更快，更加自動化？

10. 這並不是工具的問題。

你是否真的相信 DevOps 能夠提高生產效率？如何更有快速，更自動化的交付軟體，這而不是僅僅工具的事情，而是公司文化的轉變。

4、總結

你要作為公司內部主推 DevOps 的領袖，解決各種困難。

• 建立跨團隊的溝通機制，實現 CI/CD 流程的視覺化。
• 收集元資料做自動化釋出，並且基於元資料做持續的評估，目的是縮減構建時間，縮減上線時間，用自動化測試工具提供軟體質量，提高發布頻率。
• 利用評估的體系，將最好的資源投入到最好的產品。

關於JFrog

世界領先 DevOps 平臺

公司成立於2008年，在美國、以色列、法國、西班牙，以及中國北京市擁有超過200名員工。

JFrog 擁有3000多個付費客戶，其中知名公司包括如騰訊、谷歌、思科、Netflix、亞馬遜、蘋果等。連續兩年，JFrog 被德勤評選為50家發展最快的技術公司之一，並被評為矽谷增長最快的私營企業之一。

文章來自微信公眾號:高效運維