數據驅動型決策如何支持軟件交付(三):站點可靠性工程助力產品運維

本文要點:

  • 在數據驅動決策過程中,關於是要投資於服務可靠性還是要開發新功能的決策,可以使用SRE方法來完成。
  • 可以使用一組由開發和運維服務的團隊定義的服務水平指標(SLI)來衡量服務的可靠性。
  • 爲了能夠基於SLI來衡量服務的可靠性,需要爲每個SLI定義服務水平目標(SLO)。
  • 爲每個SLI定義的SLO確定了錯誤可用的預算——也就是每個SLI的錯誤預算——開發和運維服務的團隊將跟蹤這些預算。
  • 在開發組織中引入SRE方法,並定義好SLI和SLO之後,就能極大地促進產品、開發和運維之間的協作。

數據驅動決策系列文章概述了數據驅動決策如何支持軟件交付中的三大活動——產品管理、開發和運維。

簡介

軟件產品交付組織需要愈加頻繁地交付複雜的軟件系統。軟件交付工作涉及的主要活動包括產品管理、開發和運維(這裏我們的確指的是活動,而不是在談各個部門,後者是我們不推薦的說法)。在每項活動中,都必須快速做出許多決定以推進交付。在產品管理中,決策主要涉及功能優先級。在開發中,它關聯的是開發流程的效率。在運維中,它主要針對的是可靠性。

可以根據團隊成員的經驗來做出決策。另外可以基於數據做出決策。這將帶來更加客觀和透明的決策流程。尤其是隨着交付速度的提升和交付團隊數量的增加,保持透明的組織就能讓所有人無需耗時的同步會議,也可以一直走在同樣的軌道上。

在本文中,我們探討了如何使用SRE中的數據支持運維中的活動,以及如何使用這些數據實現快速的數據驅動決策。反過來,這會提高產品開發組織的透明度並削弱其官僚風氣,最終就能取得更好的業務成果,例如用戶對軟件更高的參與度和更高的應計收益等。

我們報告了持續交付指標在西門子醫療公司開發活動中的應用案例,這是一個由分佈於三個國家的16個軟件交付團隊組成的大型分佈式軟件交付組織。

流程指標,而非人員KPI

爲了以數據驅動的方式引導開發活動,我們需要一種使用數據來表達開發工作中主要活動的方式。這種數據需要被視爲正在發生的事情的流程指標,而不是用於員工評估的人員關鍵績效指標(KPI)。這是很重要的,因爲如果這種指標被用於員工評估,那麼員工可能傾向於以對自己有利的方式來調整要評估的數據。

重點在於,產品交付組織的領導者要將這種數據視爲流程指標,而不是評估員工KPI的方法,以實現穩定的數據質量和數據評估過程。

站點可靠性工程(SRE)

運維中的一個核心問題是“如何可靠地運維產品”?

產品在生產中的可靠性由許多指標反映,包括可用性、延遲、吞吐量和正確性等。在站點可靠性工程(SRE)中,這些指標稱爲服務水平指標(SLI)。部署到生產中的每個服務都有一組SLI,這些SLI共同反映了服務的可靠性。

在SRE中,每個服務的每個SLI都會分配一個目標。該目標稱爲服務水平目標(SLO)。例如,可以爲服務的可用性SLI分配一個99.5%的SLO。這意味着開發和運維服務的團隊運維服務時,會努力實現在99.5%的情況下都可用的目標。

反過來說,對於99.5%的可用性SLO而言,所謂的錯誤預算爲100%-99.5%=0.5%。這意味着我們可以預計,在0.5%的情況下該服務將不可用,並會公佈這個期望值。錯誤預算是在服務中產生錯誤的預算。在需要停機(預期停機)、遇到錯誤(意外停機)或因依賴項失敗而無法繼續服務(意外停機)時,都會消耗錯誤預算。

運維服務的開發團隊會跟蹤在給定時間範圍(例如四周)內剩餘的錯誤預算。一旦錯誤預算消耗完畢,團隊就會制定一個自定義的錯誤預算策略。錯誤預算策略的內容,可以是要求服務上的功能停止工作,並且僅執行可靠性工作,直到服務返回其SLO之內爲止。

服務的SLI和SLO由服務的產品所有者、開發人員和運維工程師來定義。這樣,我們可以讓所有相關角色以可衡量的方式,就服務可靠性的重要程度達成一致。

嚴格的SLO意味着開發團隊將花費更多的時間來保持服務處於可靠狀態,這會減少他們實現面向客戶的功能的開發時間。寬鬆的SLO意味着開發團隊將花費更少的時間來保持服務的可靠性,這樣就能花費更多的時間來實現面向客戶的功能。

因此,定義好的SLI和SLO可以輔助數據驅動的決策,決定何時進行可靠性投資以及何時進行面向客戶的功能投資。

當開發團隊採用基於錯誤預算策略的方法來管理可靠性時,他們就在使用數據驅動決策來決定何時投資於可靠性,以及何時投資於面向客戶的功能。此外,像這樣的團隊一直都能知道他們在生產中的服務是否處於已定義的SLO中,這是服務的用戶滿意度的一種代理指標。

相反,不遵循SRE(沒有SLI、沒有SLO、沒有錯誤預算策略)的開發團隊,難以瞭解他們的服務在生產環境中運行的可靠性。這樣的團隊通常會對用戶報告的服務中斷做出反應,並根據中斷的嚴重性來決定對可靠性的投資策略。

啓用SRE

引入SRE時需要與各個團隊開多次工作會議。初始會議奠定了SRE體系的基礎,例如SLI、SLO、錯誤預算、錯誤預算策略、警報和儀表板等。這樣可以確保所有團隊成員都跟上節奏。

之後的會議需要明確用戶規範(團隊正在優化這些用戶的體驗)、這些用戶的典型工作流程、生成的服務端點調用鏈、服務端點的SLO定義以及啓用警報等等。

對於SLI和SLO定義,我們使用微軟Azure AppInsights啓用了服務檢測。我們一開始研究的是兩個SLI:可用性和延遲。對於每個SLI,我們定義了一個SLO一般閾值(可用性爲98%,延遲爲500ms)。我們用這個閾值來確定是將SLO自動設置爲閾值本身,還是在開發團隊的工作區中手動設置SLO。低於定義的一般閾值的服務端點被認爲是運行良好的,並會獲得一個自動計算的,等於定義閾值的SLO。高於定義的一般閾值的服務端點需要仔細地手動設置SLO,需要經過PO、Ops和開發人員之間的一系列討論後才能確定。

通過這一過程,我們會爲足夠快速且可用的服務端點自動設置SLO。對於其他服務端點而言,我們會與團隊和利益相關者合作來手動設置SLO。這樣,我們就能將開發團隊的時間用在最棘手的領域。

我們的運維團隊爲所有服務端點提供了以下儀表板:


這些儀表板是根據微軟Azure AppInsights中提供的SLO定義和服務日誌自動生成的。

在左上角,我們可以看到服務的延遲SLI。延遲的目標SLO顯示爲水平線。每當服務打破延遲SLO時,就會消耗延遲錯誤預算。延遲錯誤預算隨時間的消耗情況顯示在右上角的圖形上。當右上角的圖形達到零時,延遲錯誤預算也就用完了。

在左下角,我們可以看到服務的可用性SLI。可用性的目標SLO顯示爲水平線。每次服務打破可用性SLO時,都會消耗可用性錯誤預算。可用性錯誤預算隨時間的消耗情況顯示在右下角的圖形中。當右下角的圖形歸零時,可用性錯誤預算也消耗完畢。

至於警報,我們針對錯誤預算消耗率設置了警報。這樣一方面可以確保我們及時發出警報,另一方面也不會給團隊帶來太多警報。

  • 短期警報:在最近的一個小時中每10分鐘掃描一次SLO違規情況。如果SLO在過去一個小時內被打破兩次,則立即發出警報。引發警報後,這種警報會暫停一個小時。
  • 長期警報:每24小時一次,查看最近24小時的SLI/SLO數據。如果最近24小時的錯誤預算比例被用完,則會引發一次警報。
  • 錯誤預算已用盡警報:每當錯誤預算用盡時,就會引起一次警報。

一旦錯誤預算在四周的週期內被SLO不達標情況消耗殆盡,我們便要求團隊遵循其自定義的錯誤預算政策。例如,團隊的錯誤預算政策可以聲明,將事件審覈中的積壓項目優先級提升到其他所有工作之上,直到完成爲止。

在諸如PagerDuty或OpsGenie之類的工具支持下,我們的未來工作將引入有效的事件審覈和On Call Rotas,並會使用SRE推動我們的文化進步。本着DevOps的理念,它確實有助於將產品、開發和運維整合在一起。

採用

我們將推薦的指標框架引入了一個由 16 個開發團隊組成的組織中,這些團隊負責的是“teamplay"——這是西門子醫療團隊提供的一項醫療領域的全球化數字服務(有關“teamplay”的更多信息,請參見《西門子醫療團隊在 teamplay 中採用持續交付方法》)。

所有團隊都對SRE活動表示歡迎,因爲他們希望通過SRE獲得更多的生產洞察力,並在他們向客戶展示自己的成果之前找出失敗的部分。

這些團隊針對所有環境的所有服務都啓用了微軟Azure AppInsights中的日誌記錄。這使團隊能夠自動獲取有關服務延遲和可用性的數據。

下一步,團隊面臨着定義非常具體和詳細的用戶配置文件的挑戰,這是爲了針對那些特定的用戶羣體來設置SLO。如果服務處於已定義的SLO中,則這些細分用戶羣會感到滿意。如果服務處於定義的SLO之外,則這些細分用戶羣會感到不快。

一開始,一些團隊提出的是比較寬泛的用戶配置文件,例如“放射科醫生”或“物理學家”。我們要求團隊區分得更加具體,以便更好地理解用戶的意圖。基於用戶意圖,我們就可以推斷出典型的用戶工作流程。最後,根據用戶工作流程,我們可以得出服務端點的典型調用鏈。

同時,一些團隊基於技術方面的考慮,快速指出了一些對幾乎所有用戶工作流都非常重要的服務端點。對於這些服務端點,我們定義了更嚴格的延遲和可用性SLO。

這些團隊很快就理解了SLI/SLO儀表板和警報邏輯。


一些團隊開始安排人員輪班響應警報。這也是爲將來在SRE活動中引入隨時待命服務做好準備。

我們從團隊那裏得到的一個非常普遍的要求,是在可用性和延遲之外再添加其他SLI。這裏,我們需要找到適用於所有團隊的SLI,以便用通行的方式擴展我們的SRE基礎架構。這也會讓運維團隊在基礎架構的創建和維護中付出的努力得到最大的回報。團隊一般會需求下面這些SLI:

  • 死信(Dead Letter)隊列長度
  • 證書過期

除此之外我們還瞭解到,一方面按團隊要求提供自定的SLI會大有裨益,另一方面這也將佔用我們運維團隊的能力,影響他們提供必要的SRE基礎架構擴展的工作。不過,我們可以讓團隊在向自定義SLI邁出第一步的時候,先不提供SLI/SLO/錯誤預算語義。我們一開始可以基於日誌查詢爲團隊提供生產環境中客戶SLI狀態的信息。只需每天兩次將信息推送到專用的Slack頻道即可。這總比運維時兩眼一抹黑要強得多。之後,我們可以擴展SRE基礎架構來逐個支持自定義的SLI。

最後一點,我們的運維團隊現在負責所有與SRE基礎架構相關的調整工作。一開始這沒什麼問題。但等到開發團隊熟悉了基礎架構之後,我們會讓他們自己來做更改,而不必等待運維團隊介入。

優先級

我們的團隊需要更多和SRE的SLI/SLO相關的經驗,這樣才能一直都使用手頭的數據作爲優先級決策的輸入。這些數據有不同的形式:

  • 生產中最快/最慢的錯誤預算消費者(按服務端點)
  • 就延遲SLI而言最快/最慢的服務端點
  • 就可用性SLI而言,最多/最少可用的服務端點
  • 每個定義的SLI都要考慮這些數據

既然有了數據,開發團隊(尤其是產品所有者)就必須考慮這些數據,以制定最佳的優先級決策。優先級決策的權衡包括:

  • 投資於功能以提高產品效率和/或
  • 投資於開發效率和/或
  • 投資於服務可靠性

就是說,錯誤預算策略需要成爲一個具有約束力的文檔,該文檔的優先級應高於其他事項。

未來的主題

我們可以基於SRE的SLI/SLO想到幾個未來的主題。

我們可以考慮結合持續交付指標和SRE的不同輸入來創建團隊整體分數。這樣做的好處還有待觀察。

此外,我們可以研究SLO違規與功能假設實現之間的相關性。我們目前的推測是,如果用戶工作流是用經常打破SLO的服務來執行的,那麼用這種工作流評估的假設是不會得到正面的檢驗結果的。

小結

總而言之,如果團隊使用SRE優化自己的運維流程,那麼團隊便能夠以數據驅動的方式逐步優化其工作方式,這樣隨着時間的推移,他們就能以可靠得多的方式運維各項功能。

數據驅動的SRE有助於使軟件交付組織的決策過程中的政治化和透明化。最後,它支持組織提高業務業績,例如用戶對軟件的參與度和收入。

本文是“軟件產品交付組織的數據驅動決策”系列文章的一部分。本系列概述了數據驅動的決策如何支持軟件交付中的三大活動——產品管理,開發和運維。以後的文章將探討開發和運維中的數據驅動決策,以及產品管理、開發和運維中的數據驅動決策組合。

致謝

有許多人爲本文背後的思想做出了貢獻。Philipp Guendisch概念化並實施了SRE基礎架構、SLI/SLO儀表板和警報。感謝“teamplay”中的整個團隊引入和採用本文中的方法。

作者介紹:

Vladyslav Ukis先後畢業於德國Erlangen-Nuremberg大學以及英國曼徹斯特大學的計算機科學專業。他一畢業就加入西門子醫療,並一直致力於軟件架構、企業架構、創新管理、私有和公共雲計算、團隊管理和工程管理。最近幾年,他一直在西門子醫療數字生態系統平臺和應用(Siemens Healthineers Digital Ecosystem Platform and Applications)“teamplay”上推動持續交付和DevOps轉型。

原文鏈接:

Data-Driven Decision Making – Product Operations with Site Reliability Engineering

相關閱讀:

數據驅動型決策如何支持軟件交付(一):用假設進行產品管理

數據驅動型決策如何支持軟件交付(二):持續交付指標助力產品開發

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章