作者： 萬金

編輯：濟萌

作者簡介

萬金
ThoughtWorks 高階顧問

10年+知名外企與中國企業的IT從業經驗，包括IBM，華為，中興，Thomson. 具有7年雲端計算相關經驗，多系統的研發和運維經驗，熟練掌握敏捷和DevOps方法論和實踐，具有軟體研發生命週期工具與流程改進豐富經驗。

序言

在軟體吞噬時間的時代，在IT基礎設施多樣性與分散式趨勢中，部署的複雜性與規模日益增加，而大部分的軟體崩潰都發生在部署過程中。目前提高部署效率與穩定性成為了一個嚴峻的挑戰。本文討論在原生雲應用的場景下如何將軟體高效穩定的釋出到使用者手中。在本文的末尾會暢想智慧運維給軟體釋出與運維工作帶來的新能力。

本文的四個部分：

1. 數字化轉型的趨勢與挑戰;
2. 軟體釋出的各種坑;
3. 雲原生應用如何釋出軟體;
4. 下一站智慧運維。

(一)數字化轉型的趨勢與挑戰

1.1.分工協作提高效能達到增長極限

如果說到DevOps的精益，就不得不說亨利•福特將流水線引入到汽車生產當中。為什麼要說流水線呢？我們在傳統企業轉型中所使用的成功經驗，在現代數字化轉型的環境裡沒有辦法繼續複製成功。

原因主要有以下幾點：
第一，單一產品的競爭優勢被行業外顛覆：傳統汽車產品積累了多年的競爭優勢，在電動車出現後被顛覆。比如特斯拉，不使用機械引擎，競爭優勢不再可持續。

第二，低價高質不再是客戶選擇的關鍵因素：消費水平提高和體驗差異導致成本競爭不再是競爭的主要因素。相同的東西只要便宜一分錢都可能造成市場份額的巨大差距。如果一款手機賣十塊錢會有市場嗎？在同學聚會的場合你會用十塊錢的手機拍照發朋友圈嗎？這種賦予商品的個性標籤屬性，使得價格為主要競爭手段的情況已經不復存在了。

第三，人的延伸價值觀侷限（麥克盧漢筆下的所有商品都會以人的延伸的能力來衡量價值，而人類的能力種類是有限的,因此商品的總量也有侷限的）。現在的主流產品，可以參考結婚時候需要的幾大件商品。現在的住房裡需要的大家電數量都是有限的（電視，冰箱，空調，洗衣機），並且每一個電器品類的市場容量都是有限的。世界就就這麼大，人口就這麼多，市場總量也是有限的。如果業務已經達到飽和，還有什麼辦法可以擴大市場？一個企業如果沒有增長是個非常大的問題，如何來刺激業務持續增長成為新的挑戰?

1.2.追求個性化使用者體驗帶來新的增長

怎麼解決市場增長乏力的問題？答案是追求個性化的體驗，因為人的體驗有無窮多種。女生都有這樣的感受，衣櫃裡永遠都缺那麼一件衣服，就是你明天要穿的那一件衣服。我們買衣服並不是買紡織品這個產品，我們買的是穿衣服的體驗，或者我們買的就是我有很多衣服的感覺。

硬體和軟體的分離就提升了軟體的使用體驗。以前IBM的郵件軟體使用體驗不是很好，作為IBM的員工自己也說 Lotus notes 郵件軟體使用體驗不是很好。這個是沒辦法的事情，在市場充分競爭的情況下，一個有著優秀硬體基因的公司很難同時把軟體做到最好。展開來說，一個公司很難讓服務於消費者的終端手機生產與銷售業務做得很好；同時也在服務於全球前50的運營商的電信裝置市場也做得很好，並且2B和2C同時成功。這樣的的成功非常少見，即使是諾基亞做到的也只是暫時的成功。

服務與產品的分離，也提升了使用體驗。就是說，做產品但不把這個產品直接賣出去，而只把產品提供的服務租出去。比如亞馬遜的雲端計算，亞馬遜擁有這個雲端計算的平臺，但是隻以雲端計算的方式給客戶提供服務。對於賣硬體伺服器的廠商IBM、戴爾、惠普來說亞馬遜賣的服務是不一樣的體驗，有不一樣的體驗就帶來新的市場。

業務與實現分離，提供了比內部所提供的服務更專業，更便捷。這樣就有了IT外包市場，一個企業如果生產一個產品或服務的成本高於採購成本就會採購該產品或服務。只有當自己生產一個產品或服務低於採購成本才會自己生產該產品或服務，甚至向市場提供該產品或服務。

使用與擁有的分離就是共享經濟。由於維護一輛自行車比較麻煩（存放，維修，防盜），人們可能不會買一個自行車，但可以通過刷一下手機直接得到自行車交通服務。消費者買的是這種交通服務，把存放，維修，防盜的事情交給共享單車公司。

我們說軟體架構來自於建築的概念，但是軟體研發的過程和建築施工過程有著非常迥異的地方。對於建築來說，工程師有了圖紙後就確定完工後的樣子，即使換一個開發商結果也沒有明顯區別。而對於軟體研發過程來說，我更願意類比原型車的開發。當一個原型車設計完成，到買到這個原型車的量產車型，你會發現它們之間有很大的差別。這就是軟體的特點。即使按照軟體設白紙黑字簽下合同，當拿到軟體釋出時使用時候，由於技術與業務的不確定性，實際軟體與設計階段差異很大。

總而言之，企業把一部分業務外包出去，滿足個性化使用者體驗，在這個過程中產品/服務價值獲得了提升。

1.3.傳統行業面臨數字化轉型的兩個挑戰

數字化轉型對傳統企業會帶來哪些挑戰？以下兩點揭示了答案所在：

第一點，從內部看是通過網際網路的工具提升內部協作效率。比如說：減少溝通的成本，並進行視覺化以及各部門之間的資訊共享和協作，提高這種協作的效率。

第二點，如何把握使用者需求。這分為兩點：首先是精確。在不同場景下人們需要的產品是不一樣的。比如：早上起來開啟微信我可能看誰更新了什麼東西，而晚上可能要看還有什麼事情沒有做完。一個產品在不同的場景、時間、地點、環境下所需的特性是不同的，這就是需求的準確。其次是準確。其實很多時候為什麼我們的客戶都不知道自己要什麼？因為一般的通用的需求完全被滿足了。這是一個生產過剩的時代，你要挖掘客戶的需求，通過不斷與客戶溝通，去了解客戶心裡說不出的潛在需求，然後通過跟他不斷地互動，達到他在那個時間那個場景下相對可以達到的服務。

(二)軟體釋出的各種坑

本章節主要是介紹一下軟體釋出過程中各種坑。上圖可以簡化地去看第一塊，即：Codebase。所有的程式碼和分支都在程式碼庫中。

第一個動作是Build（構建），研發人員工作最終結果是以軟體包的形式交付一個可以執行的軟體環境。

第二個是Verify（測試），測試人員所有的工作都是在眾多可執行的軟體中找到達到釋出質量的軟體。

最後是將軟體釋出到生產環境中去。

上面各種複雜的分支、構建、和可以測試的環境，下面是研發，測試，和釋出，只有達到質量要求才能進入下一個環節。這個過程裡面其實有非常多的手動的工作，就導致了在研發過程中很多低效和沒有必要的動作，或者不產生價值的動作。怎麼去識別，如何避免研發過程中這些複雜的過程不會影響最後的Release（釋出）？

那麼對於上述過程，我們可以簡單的理解為以下三點內容：

1. 軟體編譯複雜：
• 軟體編譯第三方依賴關係複雜；
• 多技術棧解決方案複雜性高；
• 多分支並行開發策略複雜；

2. 測試經歷軟體測試環境類生產境等遷移：
• 測試環境搭建；
• 測試資料準備；
• 介面測試無法自動化；

3. 軟體釋出過程無法保證不出問題：
• 釋出流程與過程時間長；
• 手動或配置過程導致釋出失敗；

打個比方：原來研發幾個月的產品，最後上線的話可能要持續兩三天上線（週末釋出）。這就像看一個美劇連續劇（研發），我看了一年的連續劇到年底要出一個電影版（釋出），在最後的電影版裡哪些環節沒有做，哪些環節鋪墊的不夠好，都會在劇場版裡發現問題。如此複雜的過程要在短的時間內重現一遍，這就是釋出容易出現問題的根源。所以一個版本研發的功能越多，最後部署的風險就越大。釋出過程就是把手動的過程全部重新再現一遍，所以非常容易出錯。

(三)雲原生應用如何釋出軟體

3.1.Application Pass專案背景與挑戰

首先，說一下Application Paas的專案背景。我公司的客戶是歐洲的汽車製造企業。其中一部分的IT專案是外包給了供應商，這樣就會有很多的問題。因為這個外包做這個專案，那個外包做那個專案；所以不能有效把過往的專案整合起來形成合力。

客戶的痛點是，缺乏新技術新平臺的運營能力。隨著專案的增多，管理成本也會增加，管理一個供應商和管理十個、一百個帶來的複雜性差異是巨大的所以成本奇高。在全球上線多個供應商研發的不同銷售系統，其運維複雜程度可想而知，同時也很難實現功能的快速開發和上線。

最後就是之前說到轉型的最後一個挑戰：我們如何掌握最終客戶的需求。我怎麼和客戶互動？我們不是通過人工發放調查問卷，而是要通過平臺的方式收集相關資訊。這有利於研發出符合多樣化的使用者需求，並且成本可接受的產品。

3.2.DevOps軟體研發實踐

對於下DevOps實踐來說，其中最主要的實踐是要做自動化的部署（降低頻繁部署的成本）。首先要建立信任，並提供可見性。運維人員收到一個版本，卻不知道是新增的功能還是隻是一個補丁。如何能讓運維人員安心的部署到生產環境中去呢？通過開放監控給研發人員可以提高修改缺陷的速度的，最後是讓大家的上下文一致，讓研發和運維工作在同一個上下文中。通過相同的考核指標要求研發與運維人員（比如可用性指標）來達到相互配合相互信任的目的。

然後是文化。首先要尊重工程師的文化，要有責任共擔。一些創業的企業主說遇到的最大的問題就是：招聘的研發人員只管開發程式碼，上線的穩定性和他們無關，這個就沒辦法玩下去了。最後就是試錯，因為沒有人可以保證軟體轉換一個環境就一定好用。我們如何從錯誤當中學習，或者說可控的失敗。在不會造成很大風險的錯誤當中學習，讓我們的軟體從長期的角度來看既具備功能快速上線能力又有高可用性，這就是我們最終的目標了。

3.3.部署與功能分離：從專案到平臺

本小節主要一下思路：

1. 平臺部署能力與專案功能的分離。開始我們講了很多的分離，如軟硬體的分離。而現在來說的是部署與功能的分離。比如：CRM軟體。為什麼不能把軟體的部署抽取出通用的部署能力，並通過不斷的迭代來升級平臺的部署能力呢？滿足平臺上每一個專案的自動化部署，這樣就提升部署的體驗。
2. 對於研發和運維來說，這種要求的體驗是不一樣的。因為對於研發來說，要具有應對變化的彈性和適應性。在金融行業裡有很多的規則需要滿足，流程需要彈性，不能違反紅線規則。每個研發的檢查點，轉到下一個流程規則是什麼，都需要要滿足。運維在生產環境需要穩定性，又要隨時可以上線新功能，對於研發的適應性和運維穩定性要求都需要滿足。

3.4.Dev和Ops需要兩個PaaS平臺

就如上圖所示的一樣。對於Dev和Ops來說，他們需要兩個PaaS平臺：Application PaaS平臺和Production PaaS平臺。一個負責適應性一個負責穩定性。

3.5.Application PaaS架構

從Application PaaS的架構的角度來講，底層是的資源層對接雲端計算資源層。在這上面，我們可以構建兩層虛擬網路。在研發虛擬網路中的裡，我們有Web層和App層，其實就是對Jenkins做封裝。在App層有程式碼管理，自動構建，環境管理，軟體包管理，釋出管理，部署管理的核心能力工具。

這麼多的核心功能，通過Web層的程式碼流水線與使用者互動。核心能力在下面，融合下面的核心能力，通過Web層定製來滿足客戶的多樣化的需求用以實現適應性。為了保證生產環境穩定，需要把研發和運維要分開，前面是研發的PaaS，後面是運維的PaaS。在運維PaaS下面是監控和洞察的核心能力。

3.6.開源技術選型實現

我們公司的客戶還有一個需求就是不能被技術繫結；同時還要引入一些多樣性，在相同的團隊使用不同的工具去完成任務。為了達到這種靈活性，我們可以選擇一些開源軟體。這就是我們在做這種諮詢的時候，會給客戶提供的可定製性，也是客戶對Thoughtworks的認可的一個原因。

3.7.試驗性發布-灰度釋出關鍵環節

首先，說一下灰度釋出的定義。它是在從0到1平滑過渡的方式完成軟體釋出，有點像藍綠部署，也有點像金絲雀釋出，對客戶是有篩選的分流機制。最後可以達到讓我們在安全的環境下讓軟體釋出的風險在可控的範圍內，這樣做不能保證不出錯，但是會把出錯的影響降低到可控範圍內，並不會對生產環境的使用者造成影響。（灰度釋出過程中是有真實使用者參與的）

對於灰度釋出，有這樣的三個環節：

1. 應用監控資料；
2. 使用者分流規則；
3. 遞進發布策略。

3.7.1.應用監控資料：Kibana應用監控

的監控考量。

首先是功能測試階段。功能測試階段提交到生產環境的邊緣節點環境，但是沒有真實客戶上來。這個階段會監控錯誤請求的返回。比如我測試階段有沒有反回404這樣的錯誤，沒有錯誤的話我們就進入下一個階段。

然後是相容性測試。相容性測試主要是測試介面是否有正確的返回結果。

最後在效能測試階段，對比新舊版本的效能延遲資料。如果不存在效能惡化的現象就可以全網上線了。

整個灰度釋出過程從功能測試到相容性測試，再到效能測試，在生產環境下逐步地升級擴大範圍的過程，就是來保證在安全可控的前提下來做灰度釋出，做到對客戶零影響。

3.7.2.使用者分流實現：k8s邊緣節點（Edge Node）

對於使用者分流實現來說，我們要使用K8S邊緣節點的能力，用它作為生產環境持續交付的最終環境。有人會問：持續交付直接到生產環境中，那麼你真的敢上線嗎？上線之後對客戶有影響怎麼辦？解決辦法是：我們用前端的負載均衡把邊緣節點的使用者流量遮蔽掉，不會讓真實客戶進來。這個實踐與之前的類生產環境是不同的，它真的是生產環境的伺服器，配置完全一樣；但是區別是沒有真實客戶使用。

通過功能測試，效能測試環境，然後我們來一步步把最新版本升級到全網。首先邊緣節點環境用來做自動化功能測試。通過了功測試後，在新版本和舊的版本共存的情況下測試相容性的問題，最後相容性沒有問題的話，就進入下一步效能測試階段，直至全網釋出

3.7.3.遞進發布：Kubernetes滾動升級

最後，本小節從總體解釋灰度釋出的三個階段：

1. Phase-0 進行功能測試，當釋出包通過持續交付測試環境的驗證後，部署到生產環境的邊緣節點。配置釋出包在生產環境下測試是否能正常工作，這是生產環境下安全地做持續交付的方式。
2. Phase-1我們來做相容性的測試，要做資料的隔離。舉個失敗的例子，某個網站在做生產環境上的測試時，真的產生了購買兩百臺洗衣機的訂單，並且快遞員打電話要求收貨（收貨200臺洗衣機，畫面太慘不忍睹了）
3. 最後是效能沒問題了，我就慢慢滾動部署到全網環境了。

總結一下，灰度釋出是什麼？在生產環境最小範圍內沒有真實使用者流量情況下，驗證功能問題（無客戶影響實現持續交付）；以及在較小的範圍內，驗證相容性和效能問題（少量使用者SLA可控）；同時是在控制範圍內保障使用者體驗。那麼在驗證功能，相容性和效能之後我們再全網釋出。這樣就大大降低了風險，提高發布質量。

而以前的傳統釋出過程是非黑即白的過程。如果功能，相容性和效能出現問題會直接導致對所有使用者造成影響，造成嚴重的後果。那麼通過灰度釋出方式把風險控制在可接受的範圍內，才是實踐落地的可行性方案。

3.8.通過平臺能力開放，從單一產品競爭走向生態競爭

下圖講述的是：通過生態，大家的合作來達到整體的價值提升。比如：有做平臺的公司，有做平臺上特定業務的公司，有去把握這種使用者需求銷售產品的公司。有了很多最終服務客戶的公司之後，反過來平臺也不斷髮展壯大，同時使用者的體驗也得到了提升。

為什麼要有一個平臺？現在有很多開源的或商業的技術，但是多的技術能不能為你所用呢？答案是依靠簡單的整合是不能滿足企業要求的。因為企業有很多的限制條件，我們要把這些限制條件定義成平臺的流程和自動化的過程。這樣平臺構成了引入技術的能力，就是我們的第一個客戶挑戰。

有一次客戶對我說：我們不太擔心Thoughtwork的技術顧問解決不了客戶的問題，而是擔心當顧問完成工作後自己的外包員工技術水平搞不定這些新技術，這才是客戶最擔心的問題。那麼很多客戶的普通員工或者外包人員如何掌握新技術呢？答案是通過平臺降低新技術推廣的難度（平臺封裝技術細節，通過現有員工熟悉的流程平滑推廣新技術）。

總之，通過Application Paas平臺，公司內部團隊來控制業務的方向；然後，把業務的實現和交付外包給在這個平臺上的供應商。這就提升了業務實現和交付的體驗。

舉一個小團隊控制業務方向的例子。一家服裝企業”韓都衣舍“，負責設計團隊只有三個人，一個負責廣告，一個負責設計服裝，一個負責後面的與製造平臺對接。這個團隊如果能設計出爆款的話，一年幾百萬的獎金就拿到了。當然你要有平臺，在製造效率提升的前提下，才能來滿足服裝市場不斷化的多樣化的需求，以及使用者的精準的需求。

再則，公司存在的意義是什麼？公司存在的意義是：如果產品的生產成本低於購買成本那就自己生產；但是，如果採購成本低於製造成本，那就採購，這就是公司存在的意義（一個公司不是什麼都要自己做，而是做自己擅長的產品其他的都外包出去）。比如說Kubernetes，我需要對資源進行排程，但是我們不能自己做出一個Kubernetes。因為那是不可能的，這是谷歌擅長的事情，那麼我們就外包出去。我們就做最核心的業務，這是公司存在價值；你做的成本一定比別人低，這就是你存在的價值。

這是某國內大型通訊公司公有云實驗性發布的方案，在全球大概有二十多個資料中心，它最關鍵的實踐是包管理。而，我們之前講的都是在一個數據中心的內網釋出一個軟體。

在全球範圍如何實現灰度釋出？首先是策略，也許在不同的地域裡面業務都是不一樣的，那麼軟體包也是不一樣的。這要有更高一個層次的考量，並不是做了灰度釋出之後，就可以在一個數據中心或者在所有的資料中心上線。這是需要有一個統一的考量，也是全球化帶來的改變。把業務差異從應用邏輯中分離到資料中去，就可以實現應用的全球灰度釋出了。

(四)下一站智慧運維

最後，在本節讓我們暢想一下智慧運維的未來。當說到智慧的時候，我們談的到底是什麼呢？在丹尼爾•卡內曼的著作《思考快與慢》中提到了一個概念，我們的大腦有快與慢兩種作決定的方式。

這兩種思考系統：一個是不需要思考的；比如我和一個人交談，很容易就可以感覺到對方的情感的變化——這是人情感的感知，不需要思考就知道。看電影不需要思考就知道這個電影是不是一個爛電影，這就是人的經驗，不需要思考就能快速得出結論的思考系統。目前計算機並不擅長這樣思考系統，因為計算機的計算力和成本很難滿足這樣的系統。

第二種是需要邏輯思考。比如：檢視監控資料，找到故障記錄，分析原因和關聯性，最後解決問題。這個過程非常慢，但非常有效。它的正確率也很高，缺點是這樣思考大腦會消耗大量能量。對於人工智慧來說第二種思考系統正是計算機所擅長的。我們從第二種思考系統方式以及從資料的計算、資料關聯分析、系統的相關性入手解決問題。

這裡需要闡述一個問題：牛頓發現了三大定律，通過這三大定律推論得出物質執行的規律。但是，問題在於從科學研發到改變生活的週期和成本都是非常巨大的。就像沃爾瑪要規劃如何擺放貨物就有一個很好的實踐，啤酒和尿不溼只要放在一起就能賣得很好。還有像陰天時候甜品和蛋糕就賣得好。對於這些關聯性不需要知道科學原理，只要按照這個結果去做就可以提高我們的銷售額。那我為什麼要知道原理呢？也許當了解了原理之後，就像那個啤酒和尿不溼的銷售關聯性在中國已經失效了，中國的父親在買尿不溼的時候不會去購買啤酒。那麼，一般情況下，掌握關聯性並運用到實際的工作中就能獲得收益。

4.1.軟體研發流程的資料化和個體線上化

軟體在研發過程當中會產生很多的資料，比如需求實現的時長、釋出頻率、部署前置時間，穩定性，部署成功率、應用錯誤率等。上圖是業務相關的資料，比如效能、使用者體驗、使用者增長、使用者滿意度，轉化率、流失率等。如果我們將上述這些串聯起來，比如說有一個客戶想花三千萬獲取新客戶，如果效能不好的話，流失率就非常高（提示：頁面效能，點選反映速度的資料與轉化率相關性是很容易查到的）；但是效能變化提高20%的轉化率，那麼價值就直接可見了。

4.2.人工智慧的作用

軟體在開發過程中有三個特點：
1.軟體設計的不確定性。我們都知道拿到了軟體設計文件並根據這份設計文件來生產的軟體並不一定能有效果。因為，現實中進行交付軟體時，如果客戶說還可以，但是，要求加一個功能，才能通過驗收。這不是加一個功能的問題，其實是委婉否定了你前面所有的軟體的價值。

2.質量的不可見性。對於軟體快速上線來說，如果你加班的話，短時間也能通過測試並上線；但是，短時間的測試沒有辦法能測到所有的問題。因為一個好的軟體是寫出來的，短期測試沒有辦法保證軟體的質量。

3.價值的不透明性。對於價值的理解，就要說到我們大腦如何理解做事情的意義，我們生活的改變速度遠遠超出大腦的進化速度。比如一個原始人，他們做一面鏡子的意義就是用來打扮。但是，每天的軟體研發工作卻無法對映到最終上線上去，那麼這就顯得沒有多少意義。長此以往會對工作失去不斷改進的動力。

那麼對於上述問題，我們能不能通過人工智慧對以往同類項目的過程資料，制定出一條明確的研發過程。使得在研發，測試和釋出的工作中，每個人都清楚的感覺到自己的工作對最終的產品起到的意義。那麼，這種人工智慧資料化的方式就會給我們生活賦予意義，這就是我能想到並且能做的事情。

人工智慧從研發和運維過程中收集的大量資料入手，尋找關聯性使得工作的過程和結果直接產生聯絡，從而連線了研發與運維再到業務成功的鏈條，提升軟體研發過程的可預見性，為業務成功打下堅實基礎。

原文來自微信公眾號：DevOps時代