本文要點
- 數據驅動決策可以支持軟件交付中的三大活動：產品管理、開發和運維，以提高軟件交付組織的有效性、效率和服務可靠性。
- 在產品管理中，假設可以用來確保產品決策的有效性；在開發領域，持續交付指標可用於確保開發流程的效率；在運維領域中，SRE的SLI和SLO可確保生產中服務的可靠性。
- 同時使用假設、連續交付指標和SRE的SLI/SLO，可以使軟件交付組織同時優化有效性、效率和服務可靠性！
- 引入假設、持續交付指標和SRE的SLI/SLO，對組織來說意味着重大的轉變，這一變化應逐步推廣開來，還應獲得實操培訓活動的支持。
- 通過使用假設的可測量信號、持續交付指標的值和SRE的SLO違規計數，可以對有效性、效率和可靠性做出數據驅動的優先級權衡。
數據驅動型決策系列概述了數據驅動型決策如何支持軟件交付中的三個主要活動——產品管理，開發和運維。
數據驅動決策系列
數據驅動決策系列文章概述了數據驅動決策如何支持軟件交付中的三大活動——產品管理、開發和運維。
全系列包括四篇文章，每篇文章討論了一個可以應用數據驅動決策的領域：
- 在產品管理中，假設可以用來確保產品決策的有效性。
- 在開發中，持續交付指標可用來確保開發流程的效率
- 在運維中，SRE的SLI和SLO可用來確保生產中服務的可靠性。
- 在這個文章系列中，我們還將展示如何同時使用假設、CD指示器和SRE的SLI/SLO，使軟件交付組織能夠同時優化有效性、效率和服務可靠性。
該系列中的所有文章都列在Vladyslav Ukis的InfoQ個人資料中。
簡介
軟件產品交付組織需要愈加頻繁地交付複雜的軟件系統。軟件交付工作涉及的主要活動包括產品管理、開發和運維（這裏我們的確指的是活動，而不是在談各個部門，後者是我們不推薦的說法）。在每項活動中，都必須快速做出許多決定以推進交付。在產品管理中，決策主要涉及功能優先級。在開發中，它關聯的是開發流程的效率。在運維中，它主要針對的是可靠性。
可以根據團隊成員的經驗來做出決策。另外可以基於數據做出決策。這將帶來更加客觀和透明的決策流程。尤其是隨着交付速度的提升和交付團隊數量的增加，保持透明的組織就能讓所有人無需耗時的同步會議，也可以一直走在同樣的軌道上。
在本文中，我們探討了如何使用 SRE 中的數據支持運維中的活動，以及如何使用這些數據實現快速的數據驅動決策。反過來，這會提高產品開發組織的透明度並削弱其官僚風氣，最終就能取得更好的業務成果，例如用戶對軟件更高的參與度和更高的應計收益等。
我們報告了持續交付指標在西門子醫療公司開發活動中的應用案例，這是一個由分佈於三個國家的 16 個軟件交付團隊組成的大型分佈式軟件交付組織。
決策數據
爲了以數據驅動的方式指導產品交付組織，我們需要一種使用數據來表達產品管理、開發和運維這些主要的產品交付活動的方法。
爲了以數據驅動的方式引導開發活動，我們需要一種使用數據來表達開發工作中主要活動的方式。這種數據需要被視爲當下發生的事情的流程指標，而不是用於員工評估的人員關鍵績效指標（KPI）。這是很重要的，因爲如果這種指標被用於員工評估，那麼員工可能傾向於以對自己有利的方式來調整要評估的數據。
重點在於，產品交付組織的領導者要將這種數據視爲流程指標，而不是評估員工KPI 的方法，以實現穩定的數據質量和數據評估流程。
產品管理指標
在產品管理中，核心問題之一是“要構建什麼？”。軟件功能構建完成卻不使用的話就完全是浪費，因此這一點很重要。
爲了解決“要構建什麼”這個問題，產品交付團隊會做一些小實驗以探索客戶的需求，在生產中進行實驗是最理想的。每個實驗都需要相關的測量數據，用於證實或推翻最初的假設。這個流程是假設驅動開發（Hypothesis Driven Development，簡稱 HDD）的主題。《如何實現假設驅動的開發》這篇文章對這個問題進行了很好的闡述。本質上，在 HDD 中，一個實驗被稱爲假設，並用功能/結果/可測量信號來描述：
假設：
我們認爲這個<功能>；
會導致這個客戶<結果>；
在生產中，看到這樣的<可測量信號>時，就可以知道我們成功了。
在功能實施開始之前，功能的假設定義就已經完成了。產品交付團隊聲明他們希望把哪個<功能>放入產品以實現特定的客戶<結果 >。 定義的<可測量信號>在生產中變得可見時，就能知道這個客戶<結果>已經實現了。也就是說，產品交付團隊把重點放在其提供給客戶的價值上，而不是僅僅計算交付給生產的功能有多少。
有關假設的更多信息，請參見：數據驅動型決策如何支持軟件交付（一）：用假設進行產品管理
開發指標
現在，我們已經將產品管理流程的重點放在了用戶的價值（有效性）上，我們希望在構建功能時能夠確保其有效性。因此，開發活動中的一個核心問題就變成了“如何有效地製造產品？”
通過分析軟件開發團隊的價值流，可以衡量開發流程的效率。價值流具體來說就是代碼→構建→部署，可以在團隊的部署管道上看到。
價值流中價值流動的速度是可測量的。同樣，也可以測量價值流的穩定性。所謂的穩定性和速度這兩大持續交付指標做的就是這些事情。這些指標是在Steve Smith的《測量持續交付》中定義的。
穩定性持續交付指標分爲構建穩定性和部署穩定性。速度的持續交付指標分爲代碼吞吐量、構建吞吐量和部署吞吐量。
構建穩定性指標包括構建失敗率和構建失敗恢復時間。
部署穩定性指標包括部署失敗率和部署失敗恢復時間。
代碼吞吐量指標包括主分支提交前置時間和主分支代碼提交頻率。
構建吞吐量指標包括構建前置時間和構建頻率。
部署吞吐量指標包括部署前置時間和部署頻率。
有關CD指標的更多信息，請參見：數據驅動型決策如何支持軟件交付（二）：持續交付指標助力產品開發
運維指標
現在我們已經使用假設讓產品管理流程專注在了用戶的價值（有效性）上，並且使用持續交付指標讓開發流程專注在了效率上，我們還希望在運維產品時能夠確保可靠性。也就是說，運維中一個核心問題是“如何可靠地運維產品？”
產品在生產中的可靠性由許多指標反映，包括可用性、延遲、吞吐量和正確性等。在站點可靠性工程（SRE）中，這些指標稱爲服務水平指標（SLI）。部署到生產中的每個服務都有一組 SLI，這些 SLI 共同反映了服務的可靠性。
在 SRE 中，每個服務的每個 SLI 都會分配一個目標。該目標稱爲服務水平目標（SLO）。例如，可以爲服務的可用性 SLI 分配一個 99.5％的 SLO。這意味着開發和運維服務的團隊運維服務時，會努力實現在 99.5％的情況下都可用的目標。
反過來說，對於 99.5％的可用性 SLO 而言，所謂的錯誤預算爲 100％-99.5％=0.5％。這意味着我們可以預計，在 0.5％的情況下該服務將不可用，並會公佈這個期望值。錯誤預算是在服務中產生錯誤的預算。在需要停機（預期停機）、遇到錯誤（意外停機）或因依賴項失敗而無法繼續服務（意外停機）時，都會消耗錯誤預算。
運維服務的開發團隊會跟蹤在給定時間範圍（例如四周）內剩餘的錯誤預算。一旦錯誤預算消耗完畢，團隊就會制定一個自定義的錯誤預算策略。錯誤預算策略的內容，可以是要求服務上的功能停止工作，並且僅執行可靠性工作，直到服務返回其 SLO 之內爲止。
有關SRE的更多信息，請參見：數據驅動型決策如何支持軟件交付（三）：站點可靠性工程助力產品運維
指標框架
上述這些指標在單獨使用時，可分別對產品管理、開發和運維流程進行單獨的優化工作。
但是，產品交付組織如果能將這些指標合併到一個用於數據驅動決策的總體指標框架（Indicators Framework）中，就可以更好地全局優化組織的整體價值流。如下圖所示。
功能假設（Feature Hypotheses）的定義，讓組織可以根據來自生產中的可測量信號測量產品管理流程。持續交付指標使組織可以測量開發團隊中開發/測試/部署活動的穩定性和速度。生產中運行的每個服務的SLI和SLO的定義，則讓組織可以測量運維流程。
功能假設、持續交付指標和SLI/SLO是相互依賴的。
假設用於確保產品決策的有效性。持續交付指標用於確保開發流程的效率。SRE的SLI和SLO則用於確保生產中服務運維的可靠性。
也就是說，如果同時使用假設驅動的開發、持續交付指標和SRE，我們就能同時影響產品組織的有效性、效率和可靠性！
所以我們建議的這三種方法如果同時應用，就能成爲一種非常強大的組合。
它讓我們能夠以數據驅動的方式同時做出以下系統性決策：
- 產品管理——構建什麼？
- 開發——如何有效地構建它？
- 運維——如何可靠地運維它？
引入組織
確定了指標框架後，我們很清楚，只有給團隊提供足夠的支持，把它引入擁有 16 支開發團隊的組織纔會產生效果。
我們首先引入了假設。六個月後，我們引入了SRE。又過了六個月，我們向組織引入了持續交付指標。我們使用了分階段的方法來引入這些變化，這樣組織每次只需關注一種變化即可。
就引入這些轉變的準備工作而言，假設是最簡單的。它擴展了我們的業務功能模板，併爲每個團隊帶來了一個研討會。
在準備引入站點可靠性工程（SRE）的過程中，我們爲兩個基礎SLI（可用性和延遲）實現了基礎架構。這一基礎架構能夠爲每個團隊的每個服務生成SLI和錯誤預算儀表板。最重要的是，它能夠在所有部署環境中針對錯誤預算消耗發出警報。除了這一基礎架構，我們還同各個開發團隊一起舉辦了許多研討會，以：
- 使團隊成員熟悉SLI、SLO、錯誤預算和錯誤預算策略這些SRE概念
- 爲可用性和延遲SLI定義初始SLO
- 微調警報
- 針對團隊所有的服務提出其他一些相關的SLI
- 設置待命名單，以及時有效地響應警報
爲了準備引入持續交付指標，我們實現了一個工具，可以用它來處理持續集成和部署環境中來自部署管道的數據。經過數據處理後，該工具可以直觀地展示團隊的部署管道，以及管道環境中的穩定性和速度瓶頸。這樣，團隊就可以立刻注意到這些瓶頸，並討論如何解決它們。
被組織採用
我們將推薦的指標框架引入了一個由 16 個開發團隊組成的組織中，這些團隊負責的是“teamplay"——這是西門子醫療團隊提供的一項醫療領域的全球化數字服務（有關“teamplay”的更多信息，請參見《西門子醫療團隊在teamplay中採用持續交付方法》）。
在下面提到“團隊”時，我們指的是開發團隊。他們定義了假設、軟件開發方式和SLO。他們還使用了來自假設的可測量信號、持續交付指標和SLO違規計數的結果數據。此外，我們還有一小支中央運維團隊，爲開發團隊提供SRE基礎架構。SLO違規計數也是運維團隊的一階數據。
指標框架引入後，這些團隊對假設和SRE表現出了非常濃厚的興趣。持續交付指標的主題需要更多的解釋，因爲它引入了一種通過價值流分析的視角來審視軟件開發的新方法，而這在軟件領域並不那麼常見。
假設定義流程可以幫助團隊在規範制定流程中儘早敲定功能的範圍。它爲將來的用戶故事映射和BDD場景定義奠定了良好的基礎。可測量信號的定義要求開發人員學習有關如何使用生產監控並從中獲取見解。爲了推動數據驅動決策，團隊開始應用可測量信號，並根據其值，針對未來的功能實現步驟做出相應的決策。
引入SRE需要花費大量時間，因爲它需要“將運維世界帶入開發領域"。每個團隊都參加了許多研討會，直到他們開始重視SLO違規所導致的錯誤預算消耗警報爲止。這裏的下一步是引入待命職責。爲了推動數據驅動決策，團隊需要評估哪些服務消耗錯誤預算的次數最多/速度最快，並且優先考慮改善可靠性，而不是開發新功能。
SRE數據也開始用在了數據驅動的預算分配決策中。我們的某些服務沒有足夠的開發人員來照料，所以無法提供較好的服務質量。團隊很難勸說高層爲自己增加員工人數，因爲其他部門也有自己的切實理由，表明對他們增加投入是有利的。一旦獲得了服務的SRE數據，團隊就能證明服務的可用性和延遲表現是不夠好的。團隊可以使用數據來證明當前的服務質量對客戶的負面影響，從而爭取更多的人員配備。
持續交付指標一開始是由少數幾支團隊開始採用的。這裏的第一個見解是，不同團隊的工作方式大不相同，並且直到他們看到工具顯示出來的數據，才意識到管道的穩定性和速度瓶頸。一個團隊查看了他們的所有瓶頸，並發現了部署失敗率中最大的那個。但是，部署失敗恢復時間很短。爲了推動數據驅動決策，團隊將部署失敗率瓶頸的分析工作放在了優先位置，並且在一天之內就可以顯著減小瓶頸。簡單的部署檢查可以確保各個環境都部署了必要的資源，以使應用程序能夠正常運行，從而降低了部署失敗率。時間一長，團隊就不再經常需要從部署失敗中快速恢復了。
優先級
我們的團隊需要更多和 SRE 的 SLI/SLO 相關的經驗，這樣才能一直都使用手頭的數據作爲優先級決策的輸入。這些數據有不同的形式：
- 來自假設
- 積極/消極測試的假設
- 來自可測量信號的意外見解
- 來自持續交付指標
- 大多數/中間/最不穩定的管道，表現爲
- 失敗率
- 恢復時間
- 最快/中間/最慢的管道，表現爲
- 管道環境之間的前置時間
- 環境中各個活動之間的間隔時間
- 大多數/中間/最不穩定的管道，表現爲
- 來自SRE
- 生產中最快/最慢的錯誤預算消費者（按服務端點）
- 就延遲 SLI 而言最快/最慢的服務端點
- 就可用性 SLI 而言，最多/最少可用的服務端點
- 每個定義的 SLI 都要考慮這些數據
既然有了數據，開發團隊（尤其是產品所有者）就必須考慮這些數據，以制定最佳的優先級決策。優先級決策的權衡包括：
- 投資於功能以提高產品效率和/或
- 投資於開發效率和/或
- 投資於服務可靠性
就是說，錯誤預算策略需要成爲一個具有約束力的文檔，該文檔的優先級應高於其他事項。
爲了實現數據驅動的優先級制定流程，最好創建一些儀表板，以簡化優先級決策流程的方式顯示團隊的假設、CD指標和SRE中的所有數據點。
未來的主題
我們可以基於假設、持續交付指標和SRE的SLI/SLO來考慮幾個未來的主題。
如上所述，爲促進數據驅動的優先級決策流程，我們需要探索如何在組合儀表板中可視化來自團隊的假設、CD指標和SRE的所有數據點。這將是我們下一步工作的主題。
另外，或許我們可以使用機器學習技術，基於部署管道上先前環境中的穩定性和速度數據來預測管道環境中的穩定性和速度表現。
我們也可以考慮結合持續交付指標和SRE的不同輸入來創建團隊整體分數。這樣做的好處還有待觀察。
此外，我們可以研究SLO違規與功能假設實現之間的相關性。我們目前的推測是，如果用戶工作流是用經常打破SLO的服務來執行的，那麼用這種工作流評估的假設不會得到正面的檢驗結果。
總結
總而言之，如果團隊優化了他們的：
- 產品管理流程（使用假設來優化），
- 開發流程（使用持續交付指標來優化）和
- 運維流程（使用SRE來優化）
那麼團隊就可以用數據驅動的方式逐步優化他們的工作方式。這樣隨着時間的推移，團隊就可以達到以下狀態：
- 構建的功能被用戶廣泛使用
- 有效地構建功能部件，避免其價值流（也就是部署管道）中的重大瓶頸
- 以明顯可靠的方式運維功能
最後，本文提出的總體指標框架，旨在爲軟件交付整體流程的持續改進提供一種全面的數據驅動方法。它能削弱軟件交付組織決策流程的官僚風氣，並讓決策流程更加透明。最後，它能提升組織的業務表現，例如用戶對軟件的參與度和軟件的營收。
致謝
有許多人爲本文背後的思想做出了貢獻。以下人員直接參與實施了文中所介紹的基礎架構和工具。
- Kiran Kumar Gollapelly，Krishna Chaithanya Pomar和Bhadri Narayanan ARR幫助創建了持續交付指標工具。
- Philipp Guendisch提出了概念，並實現了SRE基礎架構、SLI/SLO儀表板和警報。
感謝“teamplay”中的整個團隊引入和採用本文中的方法。
作者介紹：
Vladyslav Ukis先後畢業於德國 Erlangen-Nuremberg 大學以及英國曼徹斯特大學的計算機科學專業。他一畢業就加入西門子醫療，並一直致力於軟件架構、企業架構、創新管理、私有和公共雲計算、團隊管理和工程管理。最近幾年，他一直在西門子醫療數字生態系統平臺和應用（Siemens Healthineers Digital Ecosystem Platform and Applications）“teamplay”上推動持續交付和 DevOps 轉型。
原文鏈接：
Data-Driven Decision Making – Optimizing the Product Delivery Organization
相關閱讀：