Wise 的平臺工程 KPI 探索之旅
作者｜Lambros Charissis
翻譯｜Seal軟體
連結｜https://medium.com/wise-engineering/platform-engineering-kpis-6a3215f0ee14
平臺即產品（PaaP）已經成為軟體企業構建內部平臺的一種流行方式。在眾多軟體公司爭奪市場份額的同時，還有另一種更為微妙的競爭正在興起，例如怎樣讓軟體工程師以最快的速度釋出新功能？是否擁有最有效的內部平臺？
在這篇文章中，我將分享 Wise 的平臺工程團隊構建 KPI 樹的方法。從產品開發過程開始，是如何塑造平臺願景，從而產生一組可操作的 KPI，以及如何使用這些 KPI 來識別平臺最大的問題並持續衡量平臺的效能。
產品開發流程
KPI 樹的目的是幫助我們實施基於假設驅動的實驗和驗證學習[1]的產品開發流程。雖然有大量關於實施產品開發流程的文獻，但更困難的部分是確定適用於平臺工程領域的指標。
構建-測量-學習反饋迴圈由願景和模型提供資訊
如上圖所示，產品開發過程從平臺願景和模型開始。這些是應該不太會有改變的常數部分。模型是指標及其相互關係的表示。KPI 樹是我們在選擇後確定的模型表示型別。讓我們從定義我們的平臺願景開始，該願景最終會告知我們認為平臺可以影響並負責的相關指標或 KPI。
平臺願景
平臺願景構成了我們的最高目標，如果沒有平臺願景，我們就不知道應該衡量什麼。特別是對於 Wise 的自治團隊文化，願景對於建立一致性和問責制至關重要。在我們的產品管理團隊中，我們廣泛討論了我們的公司願景是否可以作為我們的平臺願景。
貨幣無國界——即時、方便、透明並免費
儘管 Wise 願景（或使命）是最終激勵我們的因素，但我們得出的結論是，它作為平臺願景並不能很好地為平臺服務。我們的平臺及團隊做出的貢獻讓 Wise 更接近實現其願景，但便利性與我們的平臺工程工作之間的聯絡並不明顯。因此，我們決定定義一個更相關的願景。
為 Wise 的穩定性奠定基礎，使團隊能夠比其他人更自信、更快、更高效地交付產品
儘管這一願景並非 Wise 特有，但它滿足了我們最重要的要求：這個願景能夠有效激勵平臺工程團隊，並明確了我們想要實現的結果。每個團隊和小隊都應該能夠認同這一願景，並且平臺工程師應該清楚他們的日常工作如何促成這一願景。基於這些願景和目標，我們構建了屬於平臺工程團隊特有的 KPI，這些 KPI 將作為我們 KPI 樹的基礎。
平臺 KPI 樹
如下所示，我們新增了一個額外的 KPI，為風險 Risk。風險構成了一種無形的約束，這意味著必須在保持在 Wise 的風險偏好範圍內的同時實現生產力、穩定性和效率。
平臺 KPI
根據 KPI 樹的四大基礎，我們現在可以開始推導模型。如果我們的目標是讓 Wise 更加穩定，我們需要了解提高 Wise 可靠性的根據是什麼。為了建立這些模型，我們依賴於現有框架以及圍繞開發人員生產力和 SRE 的研究。以下是我們列出的一些重要參考資料：
- 加速書籍和四個關鍵指標[2]
- 開發人員生產力的 SPACE 框架[3]
- 工程效能手冊[4]
- 谷歌 SRE 書籍[5]
閱讀上述材料是一個很好的開端，但平臺工程領域沒有非常全面的相關範例。因此我們花了很多時間自己集思廣益和開發模型。通過分享我們的方法，希望我們可以幫助其他平臺團隊加快這一過程。
注意事項
-
KPI 樹是模型，本質上是不完美的。也許有更正式的方法來建立 KPI 樹，但對我們來說，如果一個指標對其父指標（Parent Metric）有重大影響，該指標就可以成為一個單獨的分支。
-
好的指標應該是可操作的，具有可重現的結果，並準確地反映現實。我們的幾個平臺工程 KPI 由我們的產品工程團隊和平臺共同承擔責任，因此平臺有時無法做到可以復現結果。
-
在這裡我分享的 只是 KPI 樹的一部分。本文中所分享的 KPI 已足夠傳達我們的方法並幫助您開始進行類似 KPI 制定嘗試。
-
請注意，KPI 樹並不能取代使用者研究。指標將幫助您確定值得調查的領域，從而實現有針對性和更有效的使用者研究。但是您仍然需要花時間採訪您的客戶，以補充您通過指標獲得的見解。
接下來，我們將展示我們的平臺工程 North Star KPI 的 KPI 樹：生產力、穩定性、效率和風險。
生產力
開發人員生產力是一個有爭議的話題，重要的是不要濫用指標來衡量個人績效。生產力 KPI 樹有三個分支，它們分為單獨的部分以便於視覺化：交付時間、部署頻率和開發人員滿意度。
交付時間
交付時間是我們認為程式碼更改與將此更改釋出給我們的最終客戶之間的時間。這個 KPI 樹主要衡量 CI/CD 過程中的摩擦。
交付時間 KPI 樹
部署頻率
簡而言之，部署頻率 KPI 樹包含在進行程式碼更改之前捕獲摩擦的指標。例如，在開發人員更改服務之前，他們需要閱讀檔案以瞭解其工作原理。
部署頻率 KPI 樹
開發者滿意度
將開發人員的滿意度視為生產力的一部分可能很抽象。但事實證明開發人員生產力和開發人員滿意度是正相關且相互依賴的。一些人認為，平臺工程作為一個領域對開發人員的幸福感沒有足夠的影響，因為平臺工程對薪酬或個人成長機會等因素沒有影響。事實上，儘管平臺工程無法完全將開發人員的滿意度作為一個單獨領域對待，但平臺中的大部分工作都提升開發者體驗和滿意度做出了貢獻。由於開發者滿意度與生產力密切相關，因此對該指標密切關注至關重要。
開發人員滿意度 KPI 樹
穩定性
快速交付通常只是工作的一部分。穩定性 KPI 樹衡量內部平臺讓產品工程師能夠自信地進行更改且不會破壞最終客戶體驗的能力。它反映了 Wise 服務的整體可用性，並起到了應對變化的平衡作用。內部開發中平臺的穩定性根據包括提供可靠的雲原生平臺以及諮詢產品團隊的護欄和最佳實踐。
穩定性 KPI 樹
效率
生產力的目標是在輸入相同的情況下獲得更多的輸出，而效率的目標是在保持相同輸出的同時減少輸入。在我們的方法中，效率 KPI 樹涵蓋與成本相關的指標。這是雲資源、基礎設施和許可證的成本，以及我們平臺工程團隊的成本。
效率KPI樹
風險
作為金融服務提供商，風險管理是我們的首要任務之一。作為一個平臺工程組織，我們負責 Wise 的基礎，並負有實施變更控制和適當安全措施的特殊責任。我們還認為我們的產品團隊偏離最佳實踐和黃金路徑是風險的一部分。
風險 KPI 樹
KPI 樹級別
如注意事項中所述，出於本文的目的，我們僅描述了每個級別的 KPI 子集，並將深度限制為三到四個級別。為了展示 KPI 樹可以達到多深，您可以在下面看到交付時間這一分支下的垂直展開畫面。
具有五個級別的範例 KPI 樹
現在我們對平臺領域的相關根據和指標有了一定的理解，這是就需要使用到一些能夠收集和分析這些指標資訊的工具。在下一部分中，我將分享如何視覺化 KPI 樹以使其可分析和操作。
平臺 KPI 儀表板
在進行 KPI 視覺化時，我們需要牢記一點：平臺 KPI 是產品團隊和平臺工程團隊共同的責任。下圖展示了平臺使用的全域性工程檢視，當然我們根據團隊提供了篩選功能。平臺工程對比檢視可以為各個團隊量身客製化，幫助他們進行基準測試並最終優化他們的績效和表現。
平臺 KPI 儀表板線框
所有 KPI 樹的總範圍包括 200 多個不同的指標，但我們並未對所有指標無差別進行衡量。我們會根據潛在影響來確定優先順序，這樣有助於我們決定將多少時間投入在哪一方面以獲得更好的成果。如上所示的線框圖以兩種方式為我們服務：首先，設定預期目標，並以此作為與平臺外的利益相關者討論的基礎。然後，在實施團隊內部建立一致性並將 KPI 儀表盤視覺化。
下一步
全面衡量總結出的 KPI 數能夠幫助你瞭解需要關注的領域並量化平臺工作的影響。目前我們對 KPI 樹的上面兩層已經有較好的理解了，但分支下的指標覆蓋範圍仍不完整。這也意味著的 KPI 發生變化時，我們缺乏推斷原因的基礎資料。為了加快平臺 KPI 的覆蓋範圍，我們需要讓平臺和產品團隊更輕鬆地獲取資料並使其具有可操作性。
參考連結：