DevOps實施收益價值
云計算團隊 2020-03-16
對于我們完全自主研發(fā)的DevOps支撐平臺實際上在前面很多文章我都強調(diào)過，簡單理解就是將DevOps最佳實踐，包括研發(fā)過程管理，持續(xù)交付和技術(shù)運營全部融入到DevOps支撐平臺，同時底層開發(fā)基于微服務(wù)開發(fā)框架，組件運行依托在容器化PaaS平臺上，形成一個完整的整體。
對于DevOps支撐平臺實施收益和價值，今天再從業(yè)務(wù)和管理層容易理解的視角來進(jìn)行下闡述。
1. 企業(yè)研發(fā)管理過程的標(biāo)準(zhǔn)化和規(guī)范化
注意，在DevOps實施過程中，我們會協(xié)助企業(yè)進(jìn)行研發(fā)管理過程的規(guī)范化和流程化，不論是傳統(tǒng)的研發(fā)過程管理模式，還是敏捷開發(fā)思路，都需要對研發(fā)過程進(jìn)行標(biāo)準(zhǔn)化和流程化，再進(jìn)一步的自動化。這里面涉及到最基本的開發(fā)框架，開發(fā)規(guī)范，配置管理，變更和缺陷管理，測試管理，版本發(fā)布等諸多關(guān)鍵過程域，而這些在我們進(jìn)行DevOps支撐平臺實施的時候會協(xié)助企業(yè)進(jìn)行這方面的優(yōu)化和改進(jìn)。
2. 企業(yè)研發(fā)資產(chǎn)的可視化
在DevOps里面我們會強調(diào)研發(fā)和運維一體化，研發(fā)和質(zhì)量管理一體化，這些都沒有問題。但是DevOps有一個關(guān)鍵就是本身是完全包括覆蓋了傳統(tǒng)的持續(xù)交付和持續(xù)集成最佳實踐的。即整個研發(fā)生命周期過程應(yīng)該進(jìn)一步的可視化，同時通過微服務(wù)架構(gòu)設(shè)計和模塊拆分，進(jìn)一步的實現(xiàn)短周期迭代開發(fā)。
迭代開發(fā)最終交付的用戶可以使用的功能，而不是中間的半成品。但是如果半成品的輸出過程不可視，如何確保最終的功能輸出沒有問題？
不論是甲方企業(yè)，還是軟件企業(yè)本身，都需要對研發(fā)過程可視化，即對研發(fā)過程的關(guān)鍵中間節(jié)點做到完全可控，可視，而這里面最重要的就是做到中間輸出結(jié)果本身的可驗證。注意在整個DevOps流水線作業(yè)中，增加的代碼入庫和靜態(tài)檢查，構(gòu)建，自動化的單元測試等都是確保這些中間件節(jié)點可視，確實研發(fā)檢入的代碼是完整并可以編譯通過的。
從整個項目一開始研發(fā)資產(chǎn)就是可視的，那么最終研發(fā)完成后資產(chǎn)本身也是完整和可視的。研發(fā)資產(chǎn)應(yīng)該是屬于企業(yè)資產(chǎn)而不是個人資產(chǎn)，對于甲方企業(yè)來講，研發(fā)資產(chǎn)的交付應(yīng)該是在整個項目或研發(fā)過程中持續(xù)交付，而不是最終項目完成后一次性交付，只有這樣甲方對乙方的IT管控能力才能夠提升。
3. 協(xié)助企業(yè)進(jìn)行微服務(wù)架構(gòu)轉(zhuǎn)型的關(guān)鍵支撐
在傳統(tǒng)企業(yè)進(jìn)行IT架構(gòu)轉(zhuǎn)型，或者說轉(zhuǎn)向微服務(wù)架構(gòu)后，帶來的一個關(guān)鍵問題就是微服務(wù)模塊會越來越多，模塊之間的接口越指數(shù)級增長。這就導(dǎo)致我們在進(jìn)行模塊構(gòu)建，模塊部署，單元測試等工作的時候耗費大量的人力。而DevOps支撐平臺本身就集成了持續(xù)交付和集成各種關(guān)鍵工具集，通過平臺可以高效自動化的完成代碼檢查，編譯，構(gòu)建，打包，部署，環(huán)境遷移等各類工作。極大的節(jié)約人力投入并提升過程效率。
原來傳統(tǒng)模式下你部署一個業(yè)務(wù)系統(tǒng)可能感覺不到大的工作量，但是實施微服務(wù)架構(gòu)后一個業(yè)務(wù)系統(tǒng)可能已經(jīng)被拆分為了10多個微服務(wù)模塊，那么要部署這些微服務(wù)模塊，要準(zhǔn)備應(yīng)用服務(wù)器，要進(jìn)行打包部署工作量都會指數(shù)級增長，而這些完全可以由DevOps支撐平臺來幫你完成，同時在設(shè)計好流水線作業(yè)模板后，所有過程都是自動完成，而且在執(zhí)行過程中可以做到完全可視，可管控。
在實施微服務(wù)架構(gòu)的時候，我前面談到過兩點，一個就是前面的容器化技術(shù)支撐和持續(xù)集成自動化，一個就是后續(xù)的運維監(jiān)控能力要跟上。這兩個能力跟不上，那么微服務(wù)架構(gòu)實施將由于企業(yè)本身的IT信息化成熟度不足導(dǎo)致大量的問題。
記得在幾年前自己的一個朋友，原來是做工程設(shè)計咨詢的，但是在規(guī)劃設(shè)計項目中逐漸發(fā)現(xiàn)了有不少的信息化軟件開發(fā)需求，剛開始的時候走的全部外包但是發(fā)現(xiàn)不好管理和持續(xù)。因此開始著手建立自己的軟件開發(fā)隊伍，更我說起這個事的時候差不多也有了10多個人的軟件開發(fā)團隊。
記得是有一個晚上，朋友突然找我讓我出去聊下有急事，過去后才知道是由于內(nèi)部管理或利益分配的諸多原因，在這里不方便細(xì)問，這個開發(fā)負(fù)責(zé)人逐步要離職走準(zhǔn)備去單獨干，而且可能還準(zhǔn)備把幾個核心開發(fā)都帶走。由于我朋友本身也不是技術(shù)和IT出身，遇到這種事情本身還是一抹黑找不到對策，找到我的原因無礙乎是問我這邊的技術(shù)人員或團隊能不能先把他那邊的系統(tǒng)和開發(fā)工作先承接過去下。
前期沒有完整的研發(fā)流程，需求文檔也不完善，而且在離職的時候提交的文檔，代碼是否完備這些即使是有經(jīng)驗的技術(shù)人員去驗證本身也存在相當(dāng)?shù)碾y度，到了最后離職談判階段實際上我朋友本身已經(jīng)處于相當(dāng)被動的地位。在這個時候來談工作交接或找人接替本身也為時已晚。而實際上具體分析個人理解實際上這個問題很多非技術(shù)背景的領(lǐng)導(dǎo)都會遇到，造成的原因主要是：
1. 核心研發(fā)資產(chǎn)，包括需求設(shè)計文檔，源代碼往往掌控在關(guān)鍵的一個人手里面，或者干脆無文檔。
2. 研發(fā)過程不透明，研發(fā)資產(chǎn)沒有顯性化，他人很難短期接手。
而要解決這個問題，個人理解至少需要從幾個方面來考慮，第一就是我們常說的研發(fā)團隊劃分，崗位角色設(shè)置上面要考慮分離，關(guān)鍵崗位角色要考慮有備份和AB角，能夠相互替代。第二就是我們說的研發(fā)過程流程改進(jìn)，研發(fā)資產(chǎn)的可視化。
而對于第二點，實施DevOps平臺本身就是一個很好的支撐，即研發(fā)資產(chǎn)可視，過程可視，你每天新產(chǎn)生的代碼都要檢入，并進(jìn)行相關(guān)的代碼檢查和自動化測試，整個持續(xù)集成和自動化構(gòu)建確保了進(jìn)入到我們配置管理庫的代碼是編譯通過的。其次，我們自動構(gòu)建完成的部署包本身就是推送給測試人員進(jìn)行測試的部署包，中間不需要開發(fā)人員去插手或增加小動作，那么測試人員測試通過的版本，一定就是當(dāng)前代碼已經(jīng)實現(xiàn)的版本。
即在整個DevOps持續(xù)集成過程中，實現(xiàn)了研發(fā)資產(chǎn)的持續(xù)落地可視化，這個可視化不僅僅是整個研發(fā)版本的可視，更是中間各個階段的可視化，即使你團隊所有人員都離職，我們也應(yīng)該能夠確保當(dāng)前研發(fā)資產(chǎn)庫里面的代碼能夠自動化構(gòu)建完成并形成當(dāng)前的應(yīng)用版本。代碼當(dāng)前是全的沒有遺漏，而且代碼完全和當(dāng)前功能對應(yīng)。
還有就是，在實施SOA項目的過程中，我們也經(jīng)常和甲方溝通，當(dāng)時有一個甲方就提到一個關(guān)鍵點，當(dāng)要給完整的業(yè)務(wù)系統(tǒng)招標(biāo)選擇了要給供應(yīng)商來定制開發(fā)后，在項目驗收完成后雖然提交了相關(guān)的文檔，相關(guān)的源代碼，但是發(fā)現(xiàn)后續(xù)的運維甲方根本無法承接。包括乙方提供的源代碼本身都無法編譯通過，即使能夠編譯通過構(gòu)建出來的版本功能也和當(dāng)前生產(chǎn)環(huán)境功能有明顯差異。甲方如果本身不是專業(yè)的IT類公司實際上很難在驗收的時候發(fā)現(xiàn)這些問題，也就是說最終驗收你得到的文檔，代碼等內(nèi)容實際上完全無法支撐甲方運維。
而這個問題和前面一個問題很類似，就甲方來說如何加強對開發(fā)商的管控，如何確保開發(fā)商定制的系統(tǒng)版本和當(dāng)前的研發(fā)文檔，源代碼資產(chǎn)等是時刻同步的。如何確保最終驗收的研發(fā)交付文檔，代碼就是和當(dāng)前生產(chǎn)環(huán)境運行的系統(tǒng)版本是一致的？
如果所有的事情都到了驗收的時候才去處理，那么往往為時已晚，說得直白一點對應(yīng)乙方提供給甲方的業(yè)務(wù)系統(tǒng)對甲方來說就是一個黑盒子，里面的東西甲方完全搞不懂，只有乙方能夠進(jìn)行后續(xù)運維和定制維護。也就是甲方不得不承認(rèn)間接被乙方綁架的事實。
我們都知道最終的研發(fā)資產(chǎn)要能夠移交，要能夠可交維，但是里面的關(guān)鍵點究竟在哪里？
簡單來說就是研發(fā)資產(chǎn)的可交維必須是一個在一開始就持續(xù)增量不間斷進(jìn)行的過程，一個是按階段進(jìn)行持續(xù)的交付，一個就是按業(yè)務(wù)系統(tǒng)的功能點進(jìn)行持續(xù)集成交付。在整個過程中會分很多小的階段點，在這些階段點都需要植入相應(yīng)的自動化檢查和測試手段，確保最終入庫的資產(chǎn)質(zhì)量是滿足的。整個持續(xù)集成過程在一開始配置完成后，研發(fā)人員就不應(yīng)該過多的介入，而應(yīng)該是流水線自動進(jìn)行，確保中間沒有人為不確定性因素的加入。
我們在給甲方推DevOps絕對不是簡單的解決持續(xù)集成的問題，而是真正將研發(fā)過程管理的經(jīng)驗，包括研發(fā)資產(chǎn)的持續(xù)可視化融入到整個DevOps平臺，實現(xiàn)真正的研發(fā)資產(chǎn)可控，過程可控，降低對單個人，乃至單個團隊的強依賴。
我們在推DevOps平臺，會過度強調(diào)了整個自動化，持續(xù)集成流水線過程，強調(diào)研發(fā)和測試的協(xié)同，而忽視了研發(fā)和運維過程的協(xié)同。而研發(fā)和運維的協(xié)同是整個DevOps的另外一個關(guān)鍵內(nèi)容，研發(fā)的系統(tǒng)，包括每一個功能點應(yīng)該是做到從一開始就是可運維的，具備運維屬性。
一個系統(tǒng)的可運維，本身有一個潛臺詞就是系統(tǒng)可移交。而對于甲方來說也可以很名正言順的強調(diào)是為了整個研發(fā)管理過程的規(guī)范化，自動化和研發(fā)效率提升來推進(jìn)DevOps平臺工作。下面一篇將從完全云化角度來進(jìn)一步思考DevOps平臺的實施價值。
遠(yuǎn)行科技
遠(yuǎn)行云商
