在甲骨文主導 DevOps 的變革是一種什麼體驗？

​

在剛結束的深圳 GOPS 2017 全球運維大會上，來自JFrog 的全球研發副總裁 Jagan Subramanian 發表了演講。Jagan 之前在甲骨文供職了16年，擔任進階研發總監。在任職期間他成功主導了甲骨文中間件，資料庫等産品線的 DevOps 轉變，如果您也想在公司裡推動 DevOps，來參考下 Jagan 經驗！

甲骨文的痛點

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. 缺乏透明度，可視化。

   團隊中每個人都看不到目前的流程，沒法評估目前流程有什麼可以改進的地方。

例如缺乏每次建構的時間，測試覆寫率，測試通過率，上線成功率，釋出周期等名額的統計，導緻。

1. 傳統的工具難以适配新的技術。

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

2. 實作雲化。

   在申請計算，存儲，網絡資源時，依賴于硬體，沒有實作虛拟化，按需建立，消費資源。

Jagan 在甲骨文推進 DevOps 的方法

1. 定位問題。

   作為公司内部 DevOps 的領袖，你應該讓開發，測試，運維的 Leader 坐在一起，從公司的角度來思考面臨的問題，確定三個團隊朝相同的方向努力。

2. 實驗方案。

   讓三個團隊的 Leader 一起讨論如何改進公司的流程，讨論每個團隊需要改變什麼。 在這個階段，要盡量進行足夠多的 POC，找個合适的方案解決公司問題。

3. 實作方案。

   和上一步 POC 的人一起進行方案的實作。此時你需要解決基礎設施的問題，保證基礎設施能夠支援這些方案。

在測試要注意中繼資料的收集，例如每次建構的時間，測試覆寫率，測試通過率，上線成功率，釋出周期。這些資料将來是執行持續度量的重要資料來源。

1. 采用方案。

   采用方案時，你需要為其他團隊準備好文檔，技術方面的支援，準備好工具。

但并不意味着你準備好了文檔，工具，公司團隊就會配合你。公司可能有10-15%的團隊堅定的支援你，并且他們會需要更先進的工具和方案。

另一部分人30%會相對保守，他們知道轉型有什麼用，并且會需要你來指導他們進行 DevOps 的轉變。

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

1. 持續評估，持續度量。

   此時做評估，度量，一定要用可視化的工具度量，不能憑感覺說話，必須依靠資料說話。這就可以利用第三，四步中積累的中繼資料進行基于資料的度量，這個度量不僅僅是團隊内部的，還可以是跨産品線的度量。

當然評估之後會有發現新的問題，繼續循環繼續下去。

落地 DevOps 最佳實踐

1.協作。

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

1. 透明化，可視化。

   有人會問為什麼在持續傳遞的流程裡需要收集這麼多中繼資料，這些中繼資料是評估傳遞流程好壞的唯一标準，這些中繼資料将來會給公司的轉型代理巨大的價值。 你需要作為團隊傳遞流程透明化，可視化的上司者。

Jagan 在甲骨文内部搭建了 CI/CD 平台叫 Carson，這個平台為開發者提供可視化的建構流程，自定義建構流程編排，資源申請，資料統計等等很多功能。

可視化的 CI 流水線：

可視化的報表：

用這些可視化的資料，來度量 DevOps 獲得的收益，包括測試通過率，建構成功率，建構速度，釋出周期，資源配置設定情況，基于資料做成正确的決策，才是 DevOps 帶來的價值。

1. 團隊獨立自主。

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

   自助式CI服務編排:

2. 基礎設施即代碼。

   運維的團隊應該應該将所有的資源用代碼來描述，因為運維團隊的變更是沒有記錄的，也沒有被測試過，導緻環境容易産生不一緻性。是以基礎設施應該作為代碼 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 能夠提高生産效率？如何更有快速，更自動化的傳遞軟體，這而不是僅僅工具的事情，而是公司文化的轉變。

總結

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

建立跨團隊的溝通機制，實作 CI/CD 流程的可視化。

收集中繼資料做自動化釋出，并且基于中繼資料做持續的評估，目的是縮減建構時間，縮減上線時間，用自動化測試工具提供軟體品質，提高釋出頻率。

利用評估的體系，将最好的資源投入到最好的産品。

下載下傳JFrog Artifactory 開源版（代替 Nexus）：

http://www.jfrogchina.com/open-source/