微軟開發部⾨ DevOps 經驗談 (一) – 從 Agile 邁向 DevOps


在 2013 年 11 月 13 日,我們正式發行了 Visual Studio 2013,以及全新的 Visual Studio Online 服務。但在服務發表之後,Visual Studio Online 卻發⽣了異常,造成七個小時服務中斷,這是因為在服務上線時,我們沒有預想到它會⾯臨如此大的流量衝擊,所以僅使⽤⼀個擴展單元(Scale Unit)來運行我們的服務,但在歐洲和美國的服務上線時,我們的系統遭遇了流量的頂峰,必須要同時提供服務給上百萬的使⽤者,系統不足以乘載這麼大量的使用者導致服務中斷。在技術上來說,這次的上線過程可說是⼀個⾎淋淋的慘痛經驗,就算我們擁有許多已經開發完成,但暫時透過功能開關(Feature flag)隱藏,等待著推出給使⽤者的新功能,卻無法監控服務與服務的網路層級問題,才會造成線上服務中斷,這些監控機制其實對我們來說才是最重要的,也因為這次的教訓,這些機制馬上被我們列入接下來的主要開發項目中。

圖一、 Visual Studio 2013 發表時, Visual Studio Online 因為過⼤流量造成的服務中斷,但在市場層⾯來說,這次的服務發表其實是非常成功的,因為 Visual Studio Online 的使⽤者每個月以成倍速度成⻑。(而且在接下來的一年中,使⽤服務的⼈數持續成⻑,已擁有超過兩百萬名使⽤者)

在新功能開發與線上維運中取得平衡

⼀開始,Visual Studio Online 只有使⽤芝加哥資料中心的⼀個擴展單元(Scale Unit)提供服務。我們當然知道服務如果要能夠穩定運行,必須具備橫向擴展 (Scale out)到多個地區的能力,也要讓每個地區的部署可以獨⽴進⾏不互相干擾,但總是有更多重要的新功能等著我們開發,讓我們不得不將這些事情往後排。⽽在經過了 Visual Studio Online 上線時慘痛的教訓之後,我們決定推遲新功能開發,優先專注在提供穩定的服務上,我們調整了 Visual Studio Online 部署更新流程,改為使⽤循序漸進部署(Canary Release)⽅式。不變部署到芝加哥資料中心的動作,⽽是在部署到芝加哥資料中心之前,增加⼀個部署階段,稱之為 SU0 (Scale Unit 0)。 在新的流程中,每⼀個 Sprint 開發完成之後,都會先部署到聖安東尼奧 (SU0),也是我們工作所在地。然後我們會在內部進⾏⼀⼩段時間的新功能試⽤,當功能都沒有問題時,才會進行下一階段部署到芝加哥(SU1)。而如果我們在 SU0 遇到問題時,我們就可以即時停⽌部署過程並回頭修正問題,不會影響到其他部署單位的服務。在這之後,我們也陸陸續續把其他 Azure 資料中心加⼊我們的部署流程,在 2014 年秋天時,我們加入阿姆斯特丹作為第五個部署階段(SU5),很快地我們將要增加澳洲作為下⼀個部署階段。我們主要是透過 Visual Studio Release Management 來處理整個部署流程,也透過 Release Management 來將產品部署到全世界。

圖⼆、在 2013 年 11 月, Visual Studio Online 由單一資料中⼼擴展為多個,這讓我們可以進⾏循序漸進部署( Canary Release ) 及提供服務到全球。

在下圖中可以清楚看到我們一直強調維持線上服務品質的結果。在 2013 年 11 ⽉時是 43 LSIs,⽽在六個⽉後,我們已經減低到了 7 LSIs,並且只有兩個是公開的服務,我們也持續在 DevOps 上學習成長,讓我們提供的服務更加穩定。

圖三、相較於 6 個⽉之前 (2013 年 11 月 ) 發⽣了 43 次 LSIs,Visual Studio Online 在 2014 年 4 ⽉只發⽣了 7 次 LSIs ,只有 2 個是發⽣在公開的功能中。

從 Agile 到 DevOps 的過程

微軟擁抱 Agile 超過七年,並汲取了 XP(eXtreme Programming)的精華,使⽤更為 SOLID 的⽅式改善了超過 15x 個技術債。我們透過 Scrum,搭配跨部門或是不同的產品線協同合作,來訓練每⼀個團隊成員,並專注在創造對於客戶更有價值的產品,這也讓我們在推出 Visual Studio 2010 時,在客⼾中獲得了空前好評。 在發表 VS2010 之後,我們知道是時候開始將 Team Foundation Server 轉換為 SaaS 服務了。我們決定使用 Azure 作為 SaaS 版本的 TFS(也就是現在的 Visual Studio Online)的服務運⾏平台,這也代表著我們必須開始把資源投注在 DevOps 上,也必須將我們過去使用 Agile 的經驗,延伸到 DevOps 之中,但這兩者⼜有什麼差別呢?在使用 Agile 時,⼤家往往習慣遵循經驗豐富的 Product Owner 規劃,有經驗的 Product Owner 也會準備好 backlog 讓⼤家進⾏開發。相較之下,DevOps 的精神可以說是從使用中學習。在 DevOps 的開發流程中,我們會直接開發具有實驗性質的新功能,發行到正式環境並收集使用者對於這些功能的使⽤狀況及反饋,以此為基礎來決定下⼀輪 backlog 的內容,同時也由於在 DevOps 中,發⾏新功能是沒有負擔⽽且可靠的,所以我們可以經常的進行新功能的部署,快速的開發新產品或是測試市場反應的新功能,並且很迅速的從第一線使用者的使⽤體驗中得到回饋,再將所獲得的資料作為規劃下一輪 backlog 的基礎。相較於在傳統的軟體開發流程,我們總是會假設性的進行產品⼤範圍的規劃與使⽤情境想像,再經過漫⻑的開發過程,最後才能投入到市場一次定生死, DevOps 講求的是直接根據市場反應來修正產品的功能,與其不斷假設使用者可能的需求以及行為,DevOps 會直接開發新功能,投⼊市場取得產品營運的狀況以及使⽤者的回饋,馬上根據這些回饋修改⾃己產品來更貼近使用者。這也讓產品開發的⾵險⼤大降低,縮短從開發到獲得市場反應的時程,並且可以即時修正產品方向,讓產品永遠是針對使⽤者的需求提供服務。

在圖四之中,DevOps 延伸了 Agile 的四個準則進⾏開發。

圖四、從 Agile 延伸到 DevOps 。

和大部分一開始就提供雲端服務的公司不同,我們並不是一開始就有提供 SaaS 版本的服務,大部分的客⼾原本都是購買軟體在⾃己公司內部使用(像是 Team Foundation Server,從最早的 2005 版本到目前最新的 2015 版本)。⽽在我們決定開發 Visual Studio Online 時,我們決定讓雲端和地端版本的 Visual Studio Online 使⽤同⼀份程式碼基礎進行開發,並優先進⾏雲端部分的功能開發。當⼯程師簽入程式碼時,會⾺上觸發持續整合的流程進行軟體建置、自動化測試及檢查。每三週 Sprint 結束之後,我們就會更新雲端版本的產品,在 Visual Studio Online 中提供新功能給使⽤者搶先使⽤,累積了 4~5 個 Sprint 後,我們就會發⾏地端版本 Team Foundation Server 季度的更新 Patch 檔。(參考圖五)不論在 Agile 或 DevOps 之中,持續整合(Continuous Integration)的機制都是十分重要的,我們可以設定持續整合伺服器在程式碼被簽入時第⼀時間被執 ⾏,並同時進⾏程式碼建置、⾃動化測試及產⽣程式碼品質報告,讓我們在第一時間確認被簽入的程式碼是否有潛在風險,也讓問題可以在第⼀時間被解決,這麼一來可以避免掉許多以往系統上線時可能發生的環境問題,甚⾄是產品部署問題,隨時確保版本控制系統(Version Control)中的程式碼是可靠的。並透過自動化讓程式碼維持水準時,也不會增加⼤家開發的負擔。

圖五、我們使用同一份程式碼來同時滿足 Visual Studio Online 和 Team Foundation Server ,每三週會將最新版本的 Release 發行到 Visual Studio Online ,每⼀季發⾏一次 TFS 的更新。當我們發行 TFS 的主要更新時,其實也是由⽬前 Visual Studio Online 功能⽽來的。

控制功能曝光對象

當你開始使用 DevOps 的流程經營一個服務時,你會開始習慣頻繁的發⾏新版本,就像我們在開發 Visual Studio Online 時,每隔三週(⼀個 Sprint)會發行⼀次最新的版本到線上服務。這也同時讓我們有很多將新功能曝光的機會,因此我們必須對於要能夠讓哪些⼈看到這些新功能進⾏管理,以下是⼀些⽐比較常⾒的問題:

  1. 如何開發跨 Sprint 的需求?
  2. 如果有功能必須調整時,我們如何透過實驗來獲得使用者的操作體驗以及反饋(例如 A/B Testing)?
  3. 如何在你準備好將產品推出到市場之前,隱藏線上的新功能不被使⽤者發現?

基於以上這些原因,我們開始使⽤用了⼀個叫做功能開關模式( Feature flag pattern ) 的方法來控制新功能要讓誰可以使用。功能開關其實是⼀種演算法,用來控制所有正式環境中的功能可以被誰看到。當團隊開始開發一個新功能時,你可以在功能開關服務( feature flag service ) 註冊這個功能,它預設是關閉不會被任何⼈人看到的,而當你的功能開發完成,準備好給某些⼈試用時,你可以在正式環境中針對特定使用者或群組開放你的功能。當你想要修改某個功能時,你只要關閉它的開關,不需要經過任何線上版本的發⾏或更動,就可以讓這個功能不會被任何⼈人看到或使用。 透過控制各種功能的開放與關閉,使用功能開關(feature flags)也提供了一個在正式環境進行測試的⽅法,我們通常會先對⾃⼰⼈開放新功能進⾏開發或測試,再來開放給先⾏使⽤者們試用,最後都沒有問題才會開放給其他⼤部分的使用者。透過功能開關,並搭配觀察新功能在線上運行的效能和使⽤者的使用狀況,可以讓我們確保新服務不會有意料之外的問題發⽣。 ⽽在某些⾓度來說,其實這也是循序漸進部署(Canary Release)另⼀⽅面的延伸,不會讓系統存在潛在風險時(例如在線上環境時某些被期待的功能無法順利使用),就一次⾯對大量的使用者,⽽造成⼤部分使用者不好的使用體驗,而是透過逐步開放的⽅式,讓⼤多數人的使用者體驗都是好的,若有問題也能即時停止開放,修正後再提供給使用者。

參考資料

  1. Canary Release - 這是一個可以讓軟體在正式環境發行時,盡可能降低⾵險的發⾏⽅式,它的作法是透過逐步把功能開放給小部分的使用者,如果穩定了再慢慢開放給更多使用者,而不是在產品發佈時就⼀次開 放給所有人使用,避免一瞬間面對無法處理的系統衝擊(例如過大的使⽤者流量),或是系統異常造成的使⽤者負面評價。
  2. SOLID - 物件導向程式設計的五⼤原則。
Comments (0)

Skip to main content