基於產品思維驅動的運維服務建設

作者介紹

溫崢峰，百田信息運維技術專家，DevOps Team Leader，超過8年互聯網運維經驗，曾就職於網易遊戲，經受過各類海量規模互聯網業務模式的歷練，專註於運維自動化、DevOps實踐、運維服務體系建設與SRE時代下的運維價值挖掘。

知乎專欄：HiPhone運維之道

前言

技術人員轉型產品經理（Product Manager）並成功的有很多例子，牛逼的如業界大佬 Pony馬、雷布斯、張小龍、周鴻禕等等，不算牛逼的但也做出不俗成果的如你身邊的 XXX、YYY、ZZZ 等等。現在互聯網業界大多數 to B （即對企業級，區別於 to C）的 IaaS 或者 PaaS，如各種雲計算服務、存儲服務、安全服務、數據服務、監控服務、日誌分析服務、DevOps服務等等，這些產品顯然是一群既精通技術又懂產品設計的人所創造出來的。所以，技術和產品這兩項能力並非相互對立的，而是根據工作所遇的實際業務情況來選擇所需的思維能力，取長補短。

在知乎上看了大多數關於怎麼入門產品經理的回答，基本上都是各有各說法，沒有一個絕對權威的培養模式。不像程序員的養成方法基本是有業界共識的，一般是「數據結構 + 編程語言 + 常見演算法 + 常見框架 + 設計模式 + 大量編碼」這樣的主流套路。而產品經理本來就沒有所謂的科班出身，大部分 to C 業務招聘 PM 也不限制專業，而且大多都是放養式的培養方法，一旦跟對了好導師或者好項目，成長飛快，否則呵呵，不然也不會存在那麼多碼農想砍 PM 的段子。

為避免離題，本文先預設前提，就是定位於技術型的產品經理，而非對各種 to C 的五花八門業務形態。另外，雖然 title 有經理二字，但這並非一個管理職能，而是一個專業職能，可以理解為產品規劃師或者產品設計師。然後，我們再把議題聚焦到運維團隊設計與開發自動化平台這一個具體的實踐過程，運維工程師們該怎樣理解和應用產品經理能力？

什麼是產品經理能力

產品經理的職責是負責一個互聯網產品的設計、規劃以及其整個生命周期的管理，其能力高低有個比較核心的指標叫做「Product Sense」，翻譯成中文一般叫產品思維或者產品感覺。其意思是指 PM 能在分析業務問題的過程中，可以以各個緯度的角度去全面思考問題，並得出一個邏輯完備、有效、透徹、綜合的產品結果的能力。

作為技術人員看到這個指標首先會感覺很虛，因為我們通常都是習慣了「Talk is cheap，show me the code」的思維模式，但產品經理偏偏是一個以 Talk 為主的職能角色，這個核心思維模式的差異就決定了 PM 和碼農之間必然存在著某種代溝。

然而，一個好的 PM 能透過各種繁雜的技術細節找到問題的核心本質，也能製作出一份邏輯清晰、細緻、合理、能創造價值的 Talk，能最大程度地避免無意義的需求變更和回爐。另外，好的 PM 也是 Dev 的良師益友，特別是技術型的 PM 會著重於邏輯、落地、可行性、價值變現等細節，而非三天兩頭突然給你來個拍腦袋的所謂創意。

總的來說，優秀的產品經理至少需要具備以下能力：完備的邏輯能力、對業務細節的把控能力、對團隊資源的統籌規劃能力、時間和目標管理能力、ownership、自驅力等等，顯然，這些能力對於優秀的技術人員也是適用的，正如前文所說技術和產品能力並非對立而是可以互補。

產品經理能力在運維工作中的應用

回到正題，談談運維平台的設計和研發過程中該怎麼應用 PM 能力。

一個產品的生命周期主要階段有：市場調研、競品分析、產品規劃、產品設計、需求分析、需求評審、編碼實現、產品驗收、持續迭代等等，但我們真正做運維內部平台時肯定用不著每個步驟都刻意去走一遍流程，比如前期的競品分析之類的權重可以弱化。

Step 1 產品規劃

產品規劃階段包含比較多的子步驟，對於運維平台建設，我們至少要理清這些問題：

• 平檯面向的用戶有哪些，用戶角色怎麼劃分許可權，例如運維、項目研發、產品/策劃、QA、運營等；
• 每周、每月預計有多少的使用頻率，預計能為運維團隊節約多少人力資源；
• 有無開源或者商業解決方案，和自研對比有何優缺點；
• 開發周期預計時長，研發人力成本預估，第一個版本需要達到怎樣的效果；

可以看出，這些過程中已經包含了「市場調研」、「競品分析」等子步驟，因為對於面向公司內部的系統，這兩個子步驟的執行複雜度和權重都是比較低的，可以直接歸併到「產品規劃」中。

然而前面所述的都是一些具體問題細節，屬於戰術層面，而產品經理真正要做的是以更高的戰略層面思考整個運維團隊所需要規劃的內容。

對於運維團隊來說，產品規劃是團隊工作方向的綱領性指導思想，為了統一團隊目標以及提高團隊凝聚力，直白來說就是讓整個運維團隊都能圍繞在一個核心目標來開展工作，形成團隊合力。舉個例子，比如當前我們面臨的情況是監控不到位，故障發生時運維團隊卻後知後覺，所以季度規劃就是建設一套精細化、層次化、模塊化的監控體系，其他旁枝末節的事務在不影響線上環境穩定運行的前提下暫時擱置，整合整個團隊力量來完成季度目標，業務結果導向。

戰略面要思考的核心分別是運維團隊面臨的「問題」、我們所擁有的「資源」以及為了解決這些問題要達到怎樣的「目標」，思維導圖如下：

這是一個比較全面的問題集合，但我們還要在其中找到核心重點，按優先順序逐個擊破，不能面面俱到分散精力。

那麼問題來了，我怎麼知道當前面臨的問題是什麼以及該達到怎樣的目標？能否分析出問題和得到解決方案就是體現運維團隊價值的時候了，這隻能取決於決策者的能力和經驗。

Step 2 需求分析

需求分析階段算是整個開發周期最核心的部分，說其決定了項目成敗也不為過。

• 平台由哪些功能模塊組成；
• 眾多模塊的實現的優先順序排序；
• 功能模塊之間的相互依賴關係；
• 每個功能模塊預計完成時間；

這個步驟在我另外一篇文章有詳細描述：

Step 3 需求評審

這一步需要和團隊的資深運維和運維開發同事反覆進行，特別是針對一些實現難度或者複雜度較高的環節。

這個步驟的目的也是為了完善上面的需求分析，Step 3 和 Step 2 可能需要反覆執行幾次，直到把需求完善到整個團隊都能一致通過為止。

在這個過程中也需要幫助運維開發理解業務情況，通過反覆的會議討論加深他們對運維業務的理解，因為運維開發未必都真正操作過一線的運維工作，如何能讓他們更快、更好地正確理解運維工作也是本階段的重點。

Step 4 編碼實現

在這裡開始需要和開發同事有更多的互動，包含且不限於：

• 協助開發同事正確理解運維業務和功能需求；
• 將大的任務分解成可分配的獨立小任務，統籌分配開發人力資源；
• 對需求迭代進行質量與進度的把控，推進功能上線，如有遇到方向跑偏則及時修正；
• 共同解決某些疑難運維技術問題；

在這個階段為了更好地和開發同事溝通協作，運維產品經理要具備必須的面向對象思維，如：

• 面向對象：類、對象、介面、封裝、繼承、多態
• 設計原則：低耦合高內聚、單一職責、開閉原則、介面隔離
• 設計模式：單例、工廠、原型、反射、適配器、裝飾器
• 軟體開發過程：需求模型、領域模型、設計模型、實現模型
• 圖例：UML、用例圖、類圖、結構圖、系統順序圖

運維同事雖然編碼能力遠遠比不上研發同事，但在某些宏觀概念上的理解也要和他們達成一致共識，所以我們需要學習這些編碼理論指導方法論。當運維深入理解這些理論之後，對於需求設計也是具有指導意義的，你會潛移默化地把一些功能模塊化封裝、分層、復用，儘管未必參與實際的編碼過程，但對於整個軟體架構體系的理解也是可以做到的。

另外對於開發實踐過程也可以做更加合理地引導，如核心基礎組件API化，向上提供業務層的服務能力，具體例子如修改XX功能，你會馬上知道只需要稍微改一下底層的YY模塊，不需要動ZZ模塊。

作為技術型產品經理，需要理清所謂的技術邊界，即什麼事情在技術層面能否實現？是否容易實現？業務也必然存在約束與限制，成本與收益是否平衡需要在產品經理這一個環節就要確定，絕不能讓開發花費了大量工作時間才後知後覺發現事情收益太小不值得做。技術層面的約束和限制在運維平台的設計中起著重要的作用，它可以作為是架構設計的原點環節，也可以是功能迭代的驅動元素。

在這個過程中，運維產品經理需要做到：

• 深刻理解系統的每個層次模塊的定位和向上向下的意義延伸；
• 能結合運維業務理解和技術理解的雙緯度協助開發同事對系統架構的優化和調整；
• 用最少的研發人力獲得最大的邊際收益，即簡單問題簡單解決，複雜問題則創造條件來簡單解決；
• 能使得系統架構以及功能規劃盡量得適用於後期的業務需求發展；
• 利用自身的運維技術背景來預見未來可能面臨的問題，考慮長遠並避免無意義的重構；

總的來說，就是在效率、性能、成本、可靠性、擴展性、時間進度、人力資源等眾多因素中綜合考量得出一個相對較優的方案，這個過程通常是很艱辛的。因為這幾個因素是相互制約，如想快速出成果，就要多加人力資源趕進度；想做到高可用高性能的話就要考慮複雜的架構方案，可能會延緩進度和提高成本；想快速交付就不能太多考慮擴展性等等，又要馬兒跑，又要馬兒不吃草幾乎是不可能的。

如果沒有什麼特殊考量的話，以小目標來驅動快速交付永遠是正確的，因為老闆、領導、業務側不可能等你一年半載完成一個大project，需要快速落地見成果。最佳策略是既能滿足需求，又稍微超越用戶的期望，讓用戶對我們的下一次迭代更新有更高的期待。不要奢望做一個完美主義者，互聯網的工作模式是快速迭代、快速調整。

Step 5 產品驗收

建設一個完整的運維平台是個大工程，需要注意產品驗收需要先針對每一項獨立的小功能，再上升到完整的產品層面。切忌不分主次、貪多求全，必須以小目標驅動整個系統研發的過程。

Step 6 持續迭代

打造一個好的系統是不可能一蹴而就的，需要經歷反覆打磨、推翻、重構等一系列的過程才能完善起來。

太雞湯的內容就不多寫了......

業務價值挖掘

這一部分主要是需要產品經理以更高緯度地提煉以及量化我們所做產品的價值。

先舉一些其他業務形態的例子：比如某某業務功能同比增加了多少活躍用戶、提高了多少付費率，為公司創造了多少GDP等等。

那我們做運維平台的意義在哪裡呢？對內價值就是降低了多少故障率、提升了多少工作效率、節約了多少人力資源等；最好是不僅將其定位為一個內部輔助系統，需要將其和業務側的牆打破，介入業務發展的生命周期，這樣做才能將運維價值最大化地變現。

運維平台中和業務運營相關密切的功能模塊一般有數據分析、彈性伸縮、成本核算、用戶體驗優化等等，如何才能包裝好運維平台和為其講一個好故事，也是運維產品經理的職責所在。如何能讓不了解運維業務的領導們或者外部門的同事們都能理解、認可運維價值，其意義是非常重大的。

講故事的核心一般是圍繞四要素：「質量」、「效率」、「安全」、「成本」，每年的業績、KPI、成果彙報不外乎都是落在這四個緯度。

怎麼體現整個運維團隊的價值體現，簡單粗暴就是數據說話，因為老闆們才不管運維團隊具體用了什麼黑科技。

比如：

• 核心業務全年可用時間達 99.999%，全年故障次數低於 3 次；
• 人均維護機器數 10000 以上，人均維護業務集群數 5 個以上；
• 日持續發布頻率達到 30 以上，故障率低於 0.1%，發布時長低於 60 秒；
• 大數據平台數據量 1000T 以上，全國 CDN 流量 10000G 以上；
• 硬體成本降低50%，每年為公司節省10個億；

備註：以上數據純屬虛構！

總結

所謂的產品思維在不同的業務形態中可以演化出不同的能力，而運維也是一種特殊的業務形態，我們可以利用產品思維來更好地解決工作中遇到的問題。把運維服務當作一種產品，我們可以將這個產品平台化、精細化、實體化，通過實踐 DevOps 理念，打破業務側、研發側、運維側之間無形的牆， 然後用一種類似 PaaS 的方式來為業務團隊提供高質量、高性能、高可用、低成本、快速的運維體系服務。而基於產品思維來驅動運維團隊，也許能讓運維工作更有意思。