微軟開發部門 DevOps 經驗談 (三) - 為 DevOps 量身打造的系統


本文接續:

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

微軟開發部門 DevOps 經驗談 (二) - 從經驗中學習

今天要來談的是如何為 DevOps 量身打造系統。


Visual Studio Online 是一個全球性的服務,必須提供 24x7x365 服務不中斷,也保證擁有 99% 的可靠度,甚至還有財務擔保。雖然這些 SLA 上的保證並不是我們產品的最終目標,但為了要讓我們的使用者更安心的使用我們的服務,我們必須至少要提供這樣的穩定性。Visual Studio Online 並不會因為需要維護而有任何的停機時間,也不會發生任何需要重新安裝設定的事情,所有的新功能都是透過更新的方式上線的,過程也是全自動化。這也代表我們服務架構必須要是低耦合性,明確定義服務與服務之間的邊界、溝通方式,以及準確的控制要更新程式碼的版本。為了能夠瞭解客戶的需求,Visual Studio Online 也是運行在 Azure 上,我們完全透過 Azure 所提供的功能來建立這項服務。

自動化部署

我們的開發部門中有一個叫做服務部署 (Service Delivery) 的小團隊,專門處理網站部署工作,以及維持我們服務穩定運行,這個團隊簡稱為 SD。在每個 Sprint 結束後的星期一,SD 會使用 Visual Studio Release Management 來進行部署 (參考圖 1)。通常我們會在上班時間進行新版本的發行,這是因為上線後我們必須要觀察線上運作是否正常,萬一有問題也能即時發現並修正。由於 Visual Studio Online 的服務中儲存了許多客戶的資料,加上資料庫的 Schema 經常更新,所以當遇到異常時,我們不會使用倒退版本 (Rollback) 的作法,來讓服務回復正常,而一律採用修復異常再更新新的版本來修正問題。我們的新版本發行後,也會如同前面所提到的 Canary Relase 流程,自動的從第 0 個擴展單元 (SU0),依序更新到其他的擴展單元,透過這樣的方式,可以讓我們的新版本在提供給所有使用者之前,控制使用新版本的使用者數量,並可以觀察新版本是否運作正常,和收集使用者體驗。

圖 1、透過 Release Management 控制部署流程,讓新的程式碼按照順序從一個擴展單元 (Scale Unit) 到下一個

要能夠讓一個服務在不停機的狀況下,就進行新版本的更新,是一項十分具有挑戰性的工作,除了表面上的部署流程必須經過精心設計,並且能夠按照部署計畫依序進行之外,我們還必須在開發新功能時,同時考慮與現有程式碼是否相容,甚至與目前的資料庫 Schema 是否能夠相容,這些對於開發人員來說都是一個艱鉅的挑戰。所以如何穩定營運服務的同時,並持續讓開發和部署流程都能夠配合線上的服務,也是我們在未來開發各種新功能時需要不斷關注,並持續改善的課題之一。

遙測技術

在 Visual Studio Online 中最重要的一項功能是遠端偵測 (Telemetry)。就算我們的服務發生問題,我們的監控機制也必須要可以正常運作。一旦我們的服務發生問題了,監控機制會發出警告,儀表版上必須馬上顯示問題所在,圖 2 中呈現了服務的健康狀態。

圖 2、Visaul Studio Online 中使用遠端偵測技術偵測健康狀態的圖表之一

儀表版中的每一個部分都是為了提供 Visaul Studio Online 各種面像的健康狀態,例如可靠度、執行效率、使用量以及是否有異常。我們的遠端偵測主要遵循三個原則。

  • 盡可能收集所有面向的資料。
  • 盡可能只產生有意義的圖表,而不只是華麗的數據。
  • 不僅僅只是收集資料,透過觀察使用者數據的反餽,來了解我們所做的實驗是否有效。

每一天,我們大約會收集 60~150GB 的遠端偵測資料。雖然我們收集的資料可以瞭解每一個帳號的使用狀況,但基於維護使用者的隱私權,所有收集的資料都是匿名的,除非使用者同意我們做進一步分析。以下是一些我們所收集資料的範例。

  1. 活動記錄- 我們收集所有對 Visual Studio Online 所發送的網路請求。這讓我們可以觀察每一個功能的執行時間以及執行次數,同時可以讓我們判斷是不是有功能或是相關的服務執行太慢,或是經常進行重試。
  2. 追蹤紀錄- 每一個異常發生時,都會記錄異常程式的呼叫歷程 (call sequence) 以及錯誤堆疊紀錄 (stack trace),方便我們除錯時使用。
  3. 工作歷史資料 - 每一個工作都是一系列在各服務間的操作所組合而成。
  4. 效能計數 - 這些計數就像我們平常對程式作效能除錯時,會追蹤系統資源以及健康狀態所使用的效能計數器類似。Visual Studio Online 每天約會產生 50M 的事件記錄。
  5. Ping Mesh - 這是針對網路基本層級單純的呈現,確保服務可以在世界上每一個地方都能連接到。
  6. Synthetic Transactions - 這同時也被稱為“外部進入測試”,透過我們的全球服務監控系統來執行,確保我們的服務在世界每個角落都是正常的。
  7. 使用者用量 - 我們觀察我們的服務入口的使用狀況,轉換樞紐,預測及分析使用量最高的客戶。
  8. KPI指標 - 這是根據遠端偵測所收集的各種資料統計而成,主要作為判斷目前我們的服務是否正常運作。

追蹤機制

當然,以上的紀錄與資訊都是透過長時間慢慢建置而成的。我們團隊倡導 線上優先” 的文化。也就是說,所有的事情都不會比線上的狀況更重要。當線上服務發生異常時,我們必須將解決問題列為第一優先。我們有一個關於所有狀況的儀表版,每一個人可以看到目前各項工作項目的狀況。

我們會把所有線上異常輸入到 Viusal Studio Online 之中,並追蹤解決問題發生的根本原因,每週也會重新檢視問題的狀況,圖 3 呈現了線上網站問題紀錄的範例。

圖 3、在正式環境的每一個異常狀況都會被詳細的紀錄發生原因,並持續追蹤直到問題解決

徹底解決問題對於營運一個線上服務來說是相當重要的,如果只有在表面上掩飾阻止問題的發生,可能也會在無形中留下了技術債務,而在未來的某個時間點,可能就會引發更加嚴重的異常,必須投入更多資源來解決,因此在問題發生初期就確實的找到根本原因是相當重要的,只有明確的瞭解每一個異常發生的背後意義,才能確保自己服務的健康狀況是可以掌控的。

環環相扣

我們最常被問到關於的 DevOps 問題是,什麼時候該進行下一步?”。服務部署團隊 (Service Delivery) 是讓我們能夠提供 24x7 服務的第一線維運人員,在全球各地都有這個團隊的成員。當線上有問題發生,服務部署團隊要回報問題給功能開發團隊時,他們會回報給功能開發團隊所指定的負責人 (Designated Responsible Individuals),在上班時間時,我們預期 DRIs 可以在五分鐘內被聯絡到 (例如透過網路電話),而如果在下班時間,也應該會在 15 分鐘內被聯絡到負責人。

我們相當重視徹底解決問題。除了能夠重現問題是如何發生之外,更重要的是找到問題發生的根本原因。我們的作法和豐田汽車 (Toyota) 工廠所採用的看板方法有點類似,每一個工作人員可以從看板上看到問題發生的紀錄,處理問題時也會經過完整的測試,並透過我們的循序部署流程更新到線上,避免問題再度發生,解決問題後的成效也會很快的在我們的線上看板中呈現。

除此之外,對於我們來說最棒的是,我們開發出了一套很好的警報系統,它可以準確的自動判斷服務是否有異常,甚至能夠自動回報 DRIs,不需要透過人力的介入。我們建立了一個關於服務健康的模型,讓它能夠有效過濾不精準、重複的警報訊息,判斷出哪些問題是我們真正需要注意的。如圖 4 所示,在 2015 年二月時,這個模型已經可以提供我們超過 40 個維度的監控指標,所有 P0 和 P1 的警告都可以正確並自動發送給相關人員。

圖 4、服務健康模型可以自動過濾重複的警告,並且判斷哪一個地方是造成線上服務異常的主要原因

透過自動化的監控機制,除了可以減少人力成本的開銷之外,還能夠大大降低人為誤判的機率,透過收集常有錯誤模式的數據,也可以持續的改善或增強監控機制,讓問題在發生的當下就能夠被警覺,而不是等待使用者回報後才發現自己的服務有異常發生,這也會大大的影響使用者的使用體驗。在收集數據、監控數據指標以及自動通報異常整個流程是一環扣著一環,透過基礎建設的持續改善,才能持續的讓我們服務穩定,而每次問題的發生又相對於提供我們一個新的監控指標,讓下一次發生問題的機率更加的降低,不僅僅只是對於產品本身做到持續改善,更要能夠讓自己的服務營運也能越來越穩定。

TechDays 課程相關推薦 - DevOps 內容開發運維一體化(DevOps)的敏捷九劍!

Comments (0)

Skip to main content