谷歌技術工程管理與 DevOps 的經驗分享

07-04

前言

技術項目管理

技術項目管理的宏觀理論很多，而我在本次分享中以我在谷歌從事軟體開發和技術項目管理的角度，介紹一下我們採用的一些具體的、細化的實踐方法和工具。由於 Google 內部系統龐大，不同的團隊在不同的時間會採取不同的方案，我這裡只列舉一些常用的方法實踐，起到拋磚引玉的作用。

1、OKR 的制定

OKR 是指 Objectives and Key Results，與 KPI (Key Performance Indicator) 相比，OKR 更融入了戰略性的目標和計劃的成分。顧名思義，OKR 的制定分為兩個部分：Objectives 和 Key Results。

一個簡單的 OKR 例子：

Objective: 實現向新一代容器管理平台的遷移

KR1: 在 3 個實驗數據中心裡實現應用全部都運行在新的容器平台上

KR2: 實現 99%以上的故障可以通過容器平台自動修復

OKR 的制定是分層級的, 首先公司會制定一個公司級別的戰略 OKR，然後圍繞著這個目標，各個 PA（Product Area）、一直到各個行政組、一直到個人都會制定更細化的 OKR。一般 OKR 是按照每個季度制定一次，而公司層面通常會有更長遠的年度 OKR。

2、OKR 的審核

在每個季度結束時我們會審核 OKR 並給 OKR 做打分，由於 OKR 在制定之處是從公司到團隊到個人，在審核時我們同樣查看在不同層面、不同領域、不同團隊的完成情況。並在各個層面打出 0 到 1 的一個分數（1 表示完全完成，0 則表示沒有開展任何工作）。在打分時，我們十分強調功能上線並經過驗證；僅僅是代碼開發好但並未上線經過驗證的功能／任務，得分不會超過 0.6。OKR 的打分會影響到產品、團隊的績效和個人的 performance review，我們也會將當前季度的 OKR 與以往季度的 OKR 進行對比，來分析走勢。

一個有意思的問題是 Google 認為最理想的 OKR 平均得分是多少。答案並不是 1，而是 0.7。我們在制定 OKR 的時候，強調要有 stretch goal，要 be aggressive，所以大家很難把所有的目標都實現，而留有未完成的空間則會充分激勵大家盡量去縮小和「1」的差距。事實上，Google 整個公司的 OKR 是 0.67 左右。

3、技術進度的把控

Google 內不少團隊採用三層規劃的方式來把控項目進度：

季度 OKR 層面：如上所述，每個季度根據 OKR 結果來跟蹤進度。

Sprint 層面：一個季度內製定多次的 Sprint（衝刺），一般與每次發布對其，周期為 1 周到幾周不等。

每周的層面：每周的技術 Sync 保證當前的 Sprint 進展順利。

每天的層面：有的團隊會每天（或隔天）進行比較敏捷的「standup」，小組內大家站在一起，各自用簡短的語言彙報工作並確保「路障」能被及時清除。有意思的是，為了確保這個 standup 簡短有效，有的團隊要求大家在發言期間採取「Wall Sit」的姿勢（一般人 Wall Sit 一分鐘就會比較吃力），迫使大家或者簡潔或者好好鍛煉身體：）

除了外界熟悉的 Scrum, Pivotal Tracker 等敏捷開發管理方法和工具以外，不少 Google 內部技術開發團隊會採取一種 planning poker 的模式來對任務進行把控，具體流程如下：

首先，在每一個 Sprint 周期伊始，我們按照優先順序把該 Sprint 內所需完成的任務列表列出來，並賦予優先順序排序。

其次，我們拿幾個寫有斐波那契數字的牌：1, 2, 3, 5, 8, 13，其中數字代表一個任務的工作量的權重。

對於上述任務列表，團隊中的每個成員獨立打出一個牌來代表自己對於該任務的任務量評估。對於一個任務，當大家給出的分數不同時，會有給出最低分的人和給出分數最高分的人來辯論，而且大家進行二次投票。

一旦任務的權重被分配，我們會將會記錄每個 Sprint 周期內團隊所能完成的點數。幾個 Sprint 以後，我們就會有一個不錯的對於團隊效率的計算（例如一個 Sprint 平均能完成 80 個點），便於後面的任務安排和規劃。

4、SRE, Interrupts 與 release shepherd

谷歌內部非常注重開發與運維的分離；對於傳統的運維我們定義為手動的、重複性的、沒有長久附加價值的人工勞動。因為，谷歌內部鼓勵通過 Devops 的方法逐漸減少傳統運維的成分。例如谷歌內部採用自動化的集群管理平台（基於容器技術和容器集群管理平台 Borg 等工具），使得一名運維人員（與傳統運維人員不同，谷歌內部稱之為 Site Reliability Engineering）平均可以管理上萬台伺服器。谷歌具體的開發與運維分離方法包含兩種：

將開發者（SWE：Software Engineer）與運維者（或者谷歌特色的 SRE: Site Reliability Engineer）分崗，SRE 轉崗負責更多的平台級別的維護。同時，即使在 SRE 崗位內部，谷歌也嚴格控制每名 SRE 所參與的手動運維時間，盡量將其控制在 50%一下，保證 SRE 能有一半的時間投身於自動化運維工具、系統、平台的研發。當然，SRE 也有 oncall，當接收到緊急任務時（被傳呼），當值的 SRE 需要在 10 多分鐘內到達鍵盤前做出響應。

在開發者中也不可避免的從事一些運維或者處理應用突發事件的時候。例如當某個線上服務出現問題時，SRE 往往會找到對應的開發團隊協助調查原因並提交修復補丁。為了減少此類突發事件對於開發人員的研發任務影響，不少開發團隊採用 interrupts 輪崗制：在每一個產品版本發布周期內，輪流由一名開發者來擔當 interrupts 角色，並與 SRE 團隊協調，成為 SRE 的 point of contact，負責處理外來 interruption 和 bug 的初步診斷（triage）。

此外，谷歌的產品新版本上線有著嚴格的 QA 和測試流程，除了和大家所熟悉的開發、測試、生產環境的搭配使用以外，想突出兩個特點：

谷歌的產品測試不依賴於專門的測試工程師，而是要求軟體作者自己要去進行一系列的單元、整合測試，以及在測試環境的測試等。軟體作者在極大程度上是自己代碼的負責人。

在新版本的發布過程中，我們深度採用了不同形式的灰度測試機制。例如如果是平台軟體更新（例如容器集群平台，伺服器基礎鏡像升級），是按照一定的速度逐漸更新到不同的數據中心，例如第一天發布到一個數據中心，第二天發布到 5 個數據中心，以此類推，並在過程中不斷進行 A/B 測試和對比。如果是面向用戶的產品（例如廣告、購物等），則會採用基於用戶流量分流的灰度發布法，例如先選擇 5%的用戶流量使用新的版本，並且自動收集 metrics 來進行新、舊版本的比對。

技術人員機制管理

下面我簡單舉幾個有意思、有特色的內部人員管理機制實踐：

1、performance review

谷歌的績效考評被稱為 Performance Review，通常是每個季度或半年進行一次。其中很大的亮點就是該考評主要依賴於同事之間互評（peer review），同事的級別越高，review 越有份量。這樣的初衷是避免將員工的績效打分大權完全交給頂級上司，同時也為了促進健康的同事間關係和積極的互幫互助。Performance review 分為 below expectation, meets expectation, exceeds expectation, strongly exceeds expectation 和 superb 幾擋，其中每次 performance review 達到 meets expecation 以上的有近 40%左右。

2、team rotation

為了保證技術人員的創新活力，谷歌內部鼓勵一定程度的項目輪換。一般在同一個產品線或團隊中待滿一年並且績效考評達到要求後，可以自由的換崗。尋找新的產品團隊時既可以通過谷歌內部的招聘大會和招聘平台，也可以通過口口相傳。

3、20% time

谷歌一直以來有一個 20%的傳統，就是允許每一個工程師拿出 20%的時間去做一些對公司長期發展有利的「副業」，包括學習新技能，參加培訓課程，參加學術研究，做有意思的新產品等。這個制度的初衷是保持員工的技術積極性，同時保持谷歌的創業創新文化，例如 Gmail 就是從 20%項目發展而來的。然而今年隨著 20%項目在 Performance Review 中受重視程度降低，導致 20%項目有些名存實亡。