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

圖一， 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 ?ag pattern ） 的方法來控制新功能要讓誰可以使用。功能開關其實是?種算法，用來控制所有正式環境中的功能可以被誰看到。當團隊開始開發一個新功能時，你可以在功能開關服務（ feature ?ag service ） 注冊這個功能，它默認是關閉不會被任何?人看到的，而當你的功能開發完成，準備好給某些?試用時，你可以在正式環境中針對特定使用者或群組開放你的功能。當你想要修改某個功能時，你只要關閉它的開關，不需要經過任何在線版本的發?或更動，就可以讓這個功能不會被任何?人看到或使用。 透過控制各種功能的開放與關閉，使用功能開關（feature ?ags）也提供了一個在正式環境進行測試的?法，我們通常會先對???開放新功能進?開發或測試，再來開放給先?使?者們試用，最后都沒有問題才會開放給其他?部分的使用者。透過功能開關，并搭配觀察新功能在在線運行的效能和使?者的使用狀況，可以讓我們確保新服務不會有意料之外的問題發?。 ?在某些?度來說，其實這也是循序漸進部署（Canary Release）另??面的延伸，不會讓系統存在潛在風險時（例如在在線環境時某些被期待的功能無法順利使用），就一次?對大量的使用者，?造成?部分使用者不好的使用體驗，而是透過逐步開放的?式，讓?多數人的使用者體驗都是好的，若有問題也能實時停止開放，修正后再提供給使用者。

原文地址：http://blog.sina.com.cn/s/blog_6408cdc70102w75e.html

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的From Agile To DevOps - 微软开发部门 DevOps 经验谈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。