作者介紹

王曄倞，現任職好買財富平臺架構部技術總監，負責好買中介軟體及平臺化的研發及運營，團隊管理和實施重大技術決策。參與了整個公司應用和技術架構變遷、系統建設，輾轉過不同的業務團隊，對技術與業務都有一定的深入瞭解。

現在只要搞開發的人，都在談微服務，只要搞運維的人，都在談DevOps，但對於大部小夥伴來說幾乎沒什麼經驗，對於大部分企業來說也只處於嘗試階段，雖說如此，可感覺大家在制定目標時，都不太喜歡給自己留餘地，把規劃寫得很大，功能很全，甚至恨不得一夜之間所有問題都會通過微服務與DevOps的設想憑空消失。而從本文起，我將通過一個系列向與大家聊一聊 “我們在實施DevOps時遇到的挑戰”。

挑戰一：敏捷文化

1、切換敏捷之前的過渡區

對於許多草根程式設計師來說，提到敏捷所能帶來的收益，條件反射地會說 “能快呀”、“不用寫文件啦” 。

不能說這種說法有問題，只是不夠專業，在實際的工作中，我們是否經常會聽到這樣的對話？

行，就按照你說的做，我寫個需求規格說明書給你

好的，寫完別忘記給領導審批，然後我按照需求做個設計給你看下

……

開發結束啦，已經提測了，你問問測試吧

……

問問測試吧，什麼時候可以釋出模擬環境

……

又改需求了？別忘記先改需求規格說明書，要不然程式碼和文件對不上了，改完我再開發

……

對於長期適應於「需求 -> 設計 -> 開發 -> 測試 -> 運維」的企業來說，直接切換至敏捷模式，無論對業務、技術及架構都是非常具有挑戰的，這種挑戰多半來自於業務場景與公司文化的限制，甚至是組織結構的侷限性，不但不能快起來，甚至會帶來一些意想不到的災難。

（圖：職能化筒倉式組織結構）

先用迭代讓業務快起來，敏不敏捷不著急

對於金融類企業來說，多半是業務驅動模式，業務關心的是 “快上線” 、 “別出事”，至於技術是用什麼實現，敏捷也好，糊上牆也罷，他們其實並不關心。

為了快速讓業務獲得收益，在採用敏捷之前我們選擇迭代進行過度。舉例說明下迭代給業務帶來的價值：要計劃製造一輛汽車，它最核心的功能是可以在路上跑，所以我們可以先製造一個踏板車，依次迭代為滑板車、自行車、摩托車、汽車。

（圖：正確理解迭代的方式）

瀑布 – 迭代 – 敏捷，三者的差異是啥呢？

（圖：瀑布與迭代的區別）

（圖：瀑布的特點）

（圖：迭代的特點）

（圖：迭代與敏捷之間的區別）

2、大家都缺乏敏捷文化

從某種角度來講，目前我們還是按照 「職能化筒倉式組織結構」進行分工協作的，開發和運維部門經常會坐在一起探討，就運維流程如何改變、自動化能力如何建設等，然而自始至終無法突破的終極問題就是：無論我們如何改變，如果萬一生產環境出了問題，誰承擔責任？因為DevOps能力的建設需要一個過程，開發團隊不敢承諾完全承擔責任；而運維因為弱化審批和控制力，也認為不該為其承擔責任。最終不了了之。

其實，使用迭代過度也只是權宜之計，真正的問題出在文化上，舊有的組織治理模式產生了各掃門前雪的官僚文化，沒有責任共擔，以及出現問題必然問責的文化。這種文化可能源自慣性的職能化思維，可能源自組織的績效考評和激勵制度。

（圖文：跨職能產品化的組織結構）

現代關於“系統論”的研究已經在很多著作中強調，一個組織就是一個由人構成的複雜系統，組織中每一個人所能獲得的資訊是有限的（包括最高管理者也是），每個人或團隊都只能基於自己有限的經驗、有限的資訊做出決策和行動。

如果系統發生失敗，例如生產環境出現問題，這必然是由於系統各個部分相互作用（從想法提出到軟體投產各個環節的相互作用、系統與其它系統間的相互作用）產生的結果，對其中任何區域性進行懲罰無非是尋找替罪羊，有害而無益。這時候組織真正應該做的，是相信每一個人都已經做出了最大努力，將相關干係人拉到一起對問題的根因進行分析，找到能夠有效避免類似問題再次出現的解決方案，並確保該方案得到實施，對其效果進行驗證。

這是ThoughtWorks在一篇DevOps文章中所提到的，我覺得一針見血，不過對於大部分企業，尤其是金融類企業，實踐落地所付出的週期與成本可能會更大一些。

再舉個例子，在「講個‘理論型’高可用架構的故事給你聽」我曾經說過，我們的架構部模仿餓了麼的 “隨機故障測試系統(Kennel)” 自研了一套 “混世魔王”，英文名叫“ChaosDevil”，這個 “魔王” 會根據策略每隔一段時間隨機將生產環境伺服器關閉，以此來測試生產環境的快速恢復能力，促使各團隊提升系統的穩定性；

（圖：網路遊戲 – 混世魔王形象照）

有趣的是被指定優先使用的團隊口頭全力支援，但實踐起來卻遲遲延誤，當然大家都比較忙，這也是可以理解的。不過我們可以設想下，如果沒有這個“魔王”，大家可以給領導講自己的系統很穩定（只要沒出問題）；

然而這個 “魔王” 可能會隨時暴露出自己的系統並不像自己所宣稱的那樣穩定，會降低自己在上級心目中的“有能力”印象，隨之而來的可能就是問責、懲罰；

這樣的文化下，大家真正關心的是如何給領導“表現”，而不是在真正的系統穩定性上追求卓越。

所謂敏捷文化是個啥？抄襲一張圖吧，簡單點：

（圖：敏捷，乃至DevOps所需要的文化）

挑戰二：配置檔案的困惑

1、沒有DevOps之前，配置檔案是怎麼玩的呢？

在「群雄割據」的時代裡，通常一個Jar或一個War就可以打天下，以Spring+properties為例，對配置檔案的適用場景基本可分為兩種型別：

配置檔案位於classpath下

使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer類載入Properties配置檔案，通過原始碼可以知道，預設載入的是classpath下的檔案，配置如下：

如果有多個配置檔案載入，則：

配置檔案位於外部目錄

但是對於外部目錄的配置檔案，使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以載入的，不過要修改他的路徑配置方式，如下：

這樣就可以成功載入外部目錄的配置檔案了，${user.dir}是系統變數，指使用者當前目錄所在。

當我們從「群雄割據」來到「天下一統」的時期後，雖然DevOps提升了交付效率，越來越滿足快速試錯的原則，可隨之而來的「技術汙染」卻與日體現：

• …………

• 配置檔案的版本如何與程式版本對應？

• 配置檔案的管理如何更加簡便？

• 配置檔案的修改該有誰來操作？

• 配置檔案的更新是否可以不影響正常服務？

• …………

無論哪一項汙染，只會與DevOps扯上關係，都是讓人頭痛不已。

擼起袖子，不要慫，咱們搞個配置中心吧。

2、有了DevOps之後，配置檔案又是怎麼玩的呢？

其實想通過DevOps獲得業務收益，無論從哪個環節啟動，都將是一場持久戰。

隨著系統產品化的改造，通過DevOps流水線的快速交付通道，任何一個交付版本都可以通過CI與CD環節後，利用自動化部署工具，輕鬆地完成升級或釋出；

這段看似美妙的誘惑，首先擋住去路的，就是配置檔案的使用與載入方式。

如果不將配置資訊外移至配置中心，在DevOps中會出現哪些問題呢？

1. 維護成本：系統拆分了更細了，增添CI與CD環境後，每個應用在每個節點下，都需要在本地維護一套完整的配置檔案；

2. 操作風險：配置修改隨意，無操作痕跡，易出錯；

3. 版本需求：一切皆產品，一切皆版本，配置檔案如何解決版本化控制問題？

圖：配置中心在DevOps快速交付通道中

你不是常說你們的場景都是持續汙染的嗎？談談如何在汙染環境下接入吧。

的確，在整個接入過程中可以說是一波三折，原因很簡單，之前「群雄割據」時期的每一位諸侯都有自己玩轉配置的一套方案，現在你說統一就統一

無法滿足我要求的，我不接。

這話表面看起來有些生硬，不過想想挺有道理的，所以在配置中心的方案中，我們提出了“三種介面卡，兩種推進器”的理念。

三種介面卡

圖：介面卡Trade，滿足原有使用Properites的諸侯們

圖3：介面卡Native，滿足已使用過自研獨立配置服務的諸侯們

圖4：介面卡Ccms，滿足使用Key/Value的諸侯們

兩種推進器

圖：希望採用 “檔案被動載入” 的諸侯們

圖：希望採用 “Key/Value實時推送” 的諸侯們

從某種角度來說，就算沒有配置中心的存在，我相信DevOps的推進也會順理成章，只不過相對不會如此平滑，或多或少給未來造成風險。

有了配置中心，諸侯們的確享受到了福利：

1. 配置統一在服務端維護，同一環境下所有應用節點共享同一份配置；

2. 配置控制檯提供鑑權、操作日誌等服務；

3. 配置控制檯實現了版本控制，修改的配置需要釋出後生效，減少誤操作；

4. 配置釋出後，實時通知應用端，無須重啟即可使用；

5. 配置版本支援一鍵回滾；

6. 配置控制檯實現了整體複製、匯出、批量修改等功能；

3、小結

本章主要講述圍繞配置資訊管理和使用在DevOps過程中的那點事，所以對配置系統自身的原理與技術實現並未做詳細的描述，如對這塊有興趣，歡迎大家在留言區中提出，我將通過獨立的整篇文章加以敘述。