生產就緒審查(PRR):SRE 憑什麼接手一個服務

前面十五篇,講的幾乎都是「服務已經在線上了,怎麼讓它更可靠」——SLO、監控、postmortem、降級。但有一個更前面的問題一直沒問:一個新服務,憑什麼可以上線、憑什麼值得 SRE 接手扛 pager? Google SRE 的答案是一道關卡——Production Readiness Review(PRR,生產就緒審查)。這篇講這道關:它審什麼、為什麼一定要在上線「前」審,以及它背後那個對 lead 最有用的槓桿——SRE 可以說不。

PRR 是一道關,不是一份文件

先看問題根源。傳統做法是開發把服務做完,丟過牆給 ops/SRE「顧」。但這裡有個致命的不對稱:功能可以事後慢慢加,可靠度不行。 上線後才發現沒監控、沒 rollback、某個依賴一掛就整個倒——那時候補,是最貴的補法,而且通常是伴著一場半夜的事故補。SRE 的解法很直接:在服務上線、SRE 接手之前,先過一道 PRR。它不是官僚簽核用的表格,是一張把可靠度變成「上線硬門檻」的 checklist:

PRR 審什麼:把前面每一篇,在上線前驗收一遍

PRR 的清單看起來嚇人,但你會發現裡面沒有一項是新的——它就是把這個系列學過的東西,在上線前用一張表逐條驗收:

• SLO 定義了嗎?(SLI/SLO)沒有目標,就無從判斷「夠不夠可靠」,後面的告警與容量也都失去基準。
• 監控與告警?(四個黃金訊號、對症狀告警)上線的第一刻就要能被看見、能在真的痛時把人叫醒。
• 容量與壓測?(load shedding)知道自己的極限在哪,過載時主動卸載,而不是硬吞到一起爛。
• 發布與 rollback?(發布工程)壞了能不能一鍵、快速、安全地退回——這是上線後最常用到的逃生門。
• 依賴與失效模式?(降級)某個依賴掛了,是降級到堪用,還是整條鏈一起倒?
• Runbook 與文件?(事件應變)on-call 半夜照著就能操作,而不是只有作者腦裡知道。

一句話:PRR 不引入任何新要求,它是把整個系列的實踐,壓進上線前的一次體檢。 你前面每一篇學的,PRR 就是那張驗收表。

為什麼一定要在「上線前」:把可靠度左移

同一個缺口——沒有 rollback、沒有降級路徑——在什麼時候補,成本天差地遠:

反思

SRE 最大的槓桿,是「pager 是一種貨幣」

帶團隊這幾年我最有感的一課:可靠度要求如果沒有一道「上線前必須通過」的關,它永遠會被 deadline 擠掉。 「上線後再補監控」「先出再說,rollback 之後再弄」——這些話我聽過太多次,而它們幾乎總是變成「上線後炸了才補」。PRR 給 SRE 的,是一個實打實的籌碼:「要我們接手扛 pager,就先做到這幾件事。」 這個籌碼之所以有用,是因為 pager 是稀缺的——你不能無條件承諾為任何東西半夜起床。一旦「SRE 支援」不是免費贈品、而是要掙來的,可靠度就從「有空再說的善意」變成「上線前要兌現的條件」。我現在帶新服務,第一件事不是排功能,是先問一句:這東西上線後半夜炸了,誰扛、照什麼做? 答不清楚的,就還沒到可以上線的那一步。

PRR 不是橡皮圖章,是一場設計 review

最糟的 PRR,是上線前一天丟出來的一張表,大家趕著在既成事實上打勾。它最有價值的時機恰恰相反——要早,在架構還改得動的時候就介入。因為好的 PRR 會逼出的,往往是架構級的問題:「這個下游依賴根本沒有降級路徑,它一掛你就跟著死」「這個寫入不是冪等的,重試會製造重複扣款」——這些一旦上線就幾乎改不動了,只能靠一堆維運 workaround 硬撐。所以我把 PRR 定位成 SRE 對開發槓桿最大的一次協作:它不是驗收,是趁還來得及,雙方一起把可靠度設計進去。把它做成事後打勾,等於把最值錢的時機浪費掉。

接手不是終點,engagement 是可撤回的

最後補一個常被忽略的下半段。服務會 decay:今天過了 PRR 乾乾淨淨,一年後可能塞滿 toil、SLO 長期破、runbook 早就過期。SRE 的 engagement model 有一條我很認同的原則——接手之後,如果服務長期爛到把 SRE 拖進 toil 泥沼,SRE 有權把 pager 還回去。 這不是威脅,是保護:它讓「可運維」不只是上線那一刻的快照,而是一個要持續維持的狀態,也逼開發不能上線後就放著不管。這也收束了整個系列——從 error budget 到 PRR,SRE 這一整套的底層邏輯,始終是同一句:可靠度不是誰的善意,是有明確門檻、有籌碼、可以被拒絕的工程契約。