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