為了解決這些痛點，在2013年，Jagan 開始負責開發(fā)甲骨文內(nèi)部持續(xù)交付的 PaaS 平臺，名叫 Carson，目的是為公司內(nèi)部所有的開發(fā)團隊提供統(tǒng)一的，自助式的持續(xù)交付平臺。
在底層 DevOps 工具的選擇上，為了滿足團隊開發(fā)語言多樣化，需要統(tǒng)一，自助式軟件交付流水線的管理，跨團隊之間協(xié)同構(gòu)建，發(fā)布等需求， Jagan 比較了很很多工具，最終選擇了 Artifactory 和 Jenkins/Hudson 作為底層的工具，在上層開發(fā)了 Carson，實現(xiàn)了統(tǒng)一，自助式持續(xù)交付的平臺。目前這個平臺已經(jīng)為甲骨文內(nèi)部幾萬個開發(fā)者使用，為公司管理了1億多個軟件包。
Jagan 成功主導(dǎo)了甲骨文中間件，數(shù)據(jù)庫等產(chǎn)品線的 DevOps 變革。如果您也想成為公司內(nèi)部推動DevOps的領(lǐng)袖，就來參考下 Jagan 經(jīng)驗！
1、甲骨文的痛點
Stack Build 構(gòu)建耗時很長。
Stack Build 是指的 A 構(gòu)建時依賴 B，B 構(gòu)建時依賴 C，導(dǎo)致在重復(fù) Stack Build 時，需要花費大量的時間。
同一個依賴包有多個版本被引用。
舉例：團隊 A 開發(fā)了一個共用包，比如是解析 MQ 消息通用服務(wù) common.jar V1.0。B 和 C 團隊都引用了，一個月后 A 團隊升級了，B 引用了common.jar V1.1，但 C 沒有升級，在集成 A，B，C 的服務(wù)時，這個通用服務(wù)被引入了common.jar 的兩個版本。
調(diào)用內(nèi)部接口。
舉例：當團隊A，急需獲得團隊 B的數(shù)據(jù)， A 雖然知道不應(yīng)該直接調(diào)用 B 的內(nèi)部方法，但 A還是會要求 B 提供一個內(nèi)部方法，等 B 定義好了外部接口，A 再來改代碼調(diào)用外部接口。但實際情況是 A 完成了功能交付了代碼之后，再也不會做重構(gòu)。這樣就導(dǎo)致了 A 和 B 模塊直接的緊耦合。
依賴關(guān)系混亂。
當某個中間件需要重構(gòu)，他并不知道公司內(nèi)部哪些產(chǎn)品會被影響到，因為每個人看起來都會被影響。
開發(fā)者的環(huán)境通常和生產(chǎn)環(huán)境不一致。
舉例：開發(fā)者在本地測試沒問題，放到客戶環(huán)境或者線上環(huán)境就出問題。
缺乏透明度，可視化。
團隊中每個人都看不到當前的流程，沒法評估當前流程有什么可以改進的地方。例如缺乏每次構(gòu)建的時間，測試覆蓋率，測試通過率，上線成功率，發(fā)布周期等指標的統(tǒng)計，導(dǎo)致。
傳統(tǒng)的工具難以適配新的技術(shù)。
例如 C/C++ 的依賴管理就是個很大的痛點，由于 C/C++ 的編譯依賴不能跨平臺，它依賴與編譯工具 cmake 或者 gcc，也依賴與芯片架構(gòu)，所有缺少一個類似于 Maven 的依賴管理工具來管理所有的包。
實現(xiàn)云化。
在申請計算，存儲，網(wǎng)絡(luò)資源時，依賴于硬件，沒有實現(xiàn)虛擬化，按需創(chuàng)建，消費資源。
2、Jagan在甲骨文推進DevOps的方法
1)定位問題。
作為公司內(nèi)部 DevOps 的領(lǐng)袖，你應(yīng)該讓開發(fā)，測試，運維的 Leader 坐在一起，從公司的角度來思考面臨的問題，確保三個團隊朝相同的方向努力。
實驗方案。
讓三個團隊的 Leader 一起討論如何改進公司的流程，討論每個團隊需要改變什么。在這個階段，要盡量進行足夠多的 POC，找個合適的方案解決公司問題。
2)實現(xiàn)方案。
和上一步 POC 的人一起進行方案的實現(xiàn)。此時你需要解決基礎(chǔ)設(shè)施的問題，保證基礎(chǔ)設(shè)施能夠支持這些方案。
在測試要注意元數(shù)據(jù)的收集，例如每次構(gòu)建的時間，測試覆蓋率，測試通過率，上線成功率，發(fā)布周期。這些數(shù)據(jù)將來是執(zhí)行持續(xù)度量的重要數(shù)據(jù)來源。
3)采用方案。
采用方案時，你需要為其他團隊準備好文檔，技術(shù)方面的支持，準備好工具。但并不意味著你準備好了文檔，工具，公司團隊就會配合你。公司可能有10-15%的團隊堅定的支持你，并且他們會需要更先進的工具和方案。
另一部分人30%會相對保守，他們知道轉(zhuǎn)型有什么用，并且會需要你來指導(dǎo)他們進行 DevOps 的轉(zhuǎn)變。
還有一部分人會拒絕改變，你要讓已經(jīng)實施 DevOps 的團隊作為示范項目，讓所有人看到基于數(shù)據(jù)的可視化報表，
4)看到他們的成果。
持續(xù)評估，持續(xù)度量。
此時做評估，度量，一定要用可視化的工具度量，不能憑感覺說話，必須依靠數(shù)據(jù)說話。
這就可以利用第三，四步中積累的元數(shù)據(jù)進行基于數(shù)據(jù)的度量，這個度量不僅僅是團隊內(nèi)部的，還可以是跨產(chǎn)品線的度量。當然評估之后會有發(fā)現(xiàn)新的問題，繼續(xù)循環(huán)繼續(xù)下去。
3、落地DevOps最佳實踐
1)協(xié)作。
團隊之間很難做到真正的互相傾聽，你需要作為那個中間人提供溝通的渠道?？隙〞腥擞匈|(zhì)疑，但愿意溝通就是好事，因為最后你會和大家一起定出來團隊之間協(xié)作的流程。
2)透明化，可視化。
有人會問為什么在持續(xù)交付的流程里需要收集這么多元數(shù)據(jù)，這些元數(shù)據(jù)是評估交付流程好壞的唯一標準，這些元數(shù)據(jù)將來會給公司的轉(zhuǎn)型代理巨大的價值。
你需要作為團隊交付流程透明化，可視化的領(lǐng)導(dǎo)者。Jagan 在甲骨文內(nèi)部搭建了 CI/CD 平臺叫 Carson，這個平臺為開發(fā)者提供可視化的構(gòu)建流程，自定義構(gòu)建流程編排，資源申請，數(shù)據(jù)統(tǒng)計等等很多功能。
可視化的 CI 流水線：
可視化的報表：
用這些可視化的數(shù)據(jù)，來度量 DevOps 獲得的收益，包括測試通過率，構(gòu)建成功率，構(gòu)建速度，發(fā)布周期，資源分配情況，基于數(shù)據(jù)做成正確的決策，才是 DevOps 帶來的價值。
3)團隊獨立自主。
每個團隊都應(yīng)該有自己的 CICD 流水線。Oracle 的實踐，他們?yōu)槊總€團隊提供自助式的構(gòu)建服務(wù)器的使用。從 QA 團隊，每個團隊也自助式的消費測試集群。
自助式CI服務(wù)編排:
4)基礎(chǔ)設(shè)施即代碼。
運維的團隊應(yīng)該應(yīng)該將所有的資源用代碼來描述，因為運維團隊的變更是沒有記錄的，也沒有被測試過，導(dǎo)致環(huán)境容易產(chǎn)生不一致性。所以基礎(chǔ)設(shè)施應(yīng)該作為代碼 checkin，然后進行測試。
5) 自動化。
為了提高效率，我們不應(yīng)該容忍在軟件發(fā)布流程里有任何人工審批的操作。通過大量的自動化測試的 Case 來保證軟件的質(zhì)量，并且將測試結(jié)果與發(fā)布的包關(guān)聯(lián)，實現(xiàn)基于元數(shù)據(jù)的包發(fā)布。
6)設(shè)置較高目標。
之前甲骨文的堆棧構(gòu)建發(fā)布流程要經(jīng)過2-3周的時間，最近已經(jīng)能夠達到每天多次的發(fā)布。
今天，整個產(chǎn)品發(fā)布周期從一年半，縮減到3個月。整個軟件架構(gòu)轉(zhuǎn)變?yōu)槲⒎?wù)架構(gòu)，每天多次發(fā)布服務(wù)。
Jagan 認為，為團隊設(shè)置一個較高的目標，這會讓團隊興奮，團隊會全力全完成它，通常，最后的結(jié)果是團隊證明了他們能夠達到這個目標。
7)持續(xù)度量。
流程以及產(chǎn)出物使用數(shù)據(jù)可視化工具可視化。
甲骨文中間件團隊一個數(shù)據(jù)中心的存儲量是80TB，每天的請求達到3千萬次，下載的數(shù)據(jù)量達到 85TB，全球有6個數(shù)據(jù)中心。
從 Artifactory 存儲量的角度看甲骨文 DevOps 落地的速度。2013年 DevOps 開始落地，開始從中間件的某幾個團隊開始試點，到14年后，這些團隊的成功案例影響到了其他團隊，從 Artifactory 存儲量可以看到，容量明顯增長，其他的團隊都來復(fù)制這個模式。15年開始，Artifactory 開始持續(xù)進行自動化的工件清理，節(jié)省了大量存儲空間。
通過可視化的度量，可以清楚知道產(chǎn)品的構(gòu)建速度，發(fā)布成功率，發(fā)布周期等等，這些度量指標將作為下一個開發(fā)周期目標的參考基準，為團隊指定合理的目標。
元數(shù)據(jù)也可以用來評估某個產(chǎn)品線占用的資源，投入產(chǎn)出比，做跨團隊直接的績效考評。
8) 快速失敗。
上游構(gòu)建的測試用例里要包含下游構(gòu)建的測試用例，這樣讓測試在上游測試階段失敗，而不是要等到下游測試，才發(fā)現(xiàn)測試失敗。
9)保持質(zhì)疑。
在每一環(huán)境都保持質(zhì)疑，問問自己，團隊能否做得更好，更快，更加自動化？
10) 這并不是工具的問題。
你是否真的相信 DevOps 能夠提高生產(chǎn)效率？如何更有快速，更自動化的交付軟件，這而不是僅僅工具的事情，而是公司文化的轉(zhuǎn)變。
4、總結(jié)
你要作為公司內(nèi)部主推 DevOps 的領(lǐng)袖，解決各種困難。
建立跨團隊的溝通機制，實現(xiàn) CI/CD 流程的可視化。
收集元數(shù)據(jù)做自動化發(fā)布，并且基于元數(shù)據(jù)做持續(xù)的評估，目的是縮減構(gòu)建時間，縮減上線時間，用自動化測試工具提供軟件質(zhì)量，提高發(fā)布頻率。
利用評估的體系，將最好的資源投入到最好的產(chǎn)品。
第三十六屆CIO班招生
國際CIO認證培訓
首席數(shù)據(jù)官（CDO）認證培訓
責編：content
免責聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個人認為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，請及時通知本站，予以刪除。
搶沙發(fā)
