技術文章 » 谷歌的SRE和開發是如何合作的

谷歌的SRE和開發是如何合作的

2022-07-22 15:00:28

本文是一篇比較有價值的、介紹SRE的文章。國內的所謂SRE職責其實並不明確，大部分其實還是幹普通運維的事。但文中介紹的谷歌的運作方式起點還是相對比較高的，無論對SRE、對開發，甚至對公司都有很高的要求。正如本文所述，谷歌的方式並不一定適合其他公司，但其SRE的建設經驗仍然能夠帶來一定的啟發。在閱讀本文的時候，我是比較好奇谷歌是如何解決SRE和開發相互推諉的問題的。

譯自：How Google SRE And Developers Collaborate

谷歌的SRE是一個專業的工程師組織，致力於設計、構建和維護大型產品服務。SRE可以是軟體工程師或系統工程師，但通常會同時具備這兩種技能。

谷歌的SRE的任務是：

  • 保證谷歌的產品和基礎設施能夠滿足可用性目標
  • 根據(1)，最大化長期特徵速度(feature velocity，用於評估新特性的釋出速度，參見Feature velocity and Serverless)
  • 使用軟體而非人力來完成(1)和(2)
  • 當SRE處理(1)和(3)的效率高於開發時，SRE才會參與其中

可靠性和速度並不是互斥的，通常速度可以受益於可靠性的提升，反之亦然。然而，在產品或服務未達到期望的SLO前，(當需要在可靠性和速度之間進行權衡時)SRE會優先考慮穩定性，而非速度。如果沒有達到SLO，此時產品的可靠性要位元徵速度更加重要。當產品滿足SLO後，以犧牲特徵速度為代價來換取額外的可靠性則會適得其反。相比採用粗暴的方式來滿足目標，SRE會採用工程和自動化方式(而非人力)來優化運維流程。

SLO是一個很好的判定何時該關注可靠性，何時改關注釋出速度的標準。的確，如果產品服務已經達到SLO，那麼繼續提升像效能、可靠性等標準可能會對產品的釋出造成很大影響。

作為一個專家團隊，(產品開發團隊，以下簡稱Dev對)谷歌SRE有著很高的需求量；SRE能夠帶來額外的價值的機會很多。在很多場景下，SRE可能會被放大。但如何某個問題可以被Dev組織解決，那麼僱傭一個Dev而非SRE反而是一種更靈活的方式，可以減少跨組織帶來的開銷。引入SRE的最終的目標是使用足夠的SRE來最大化影響和開銷的比率(即提高價效比)。谷歌的SRE不應該作為其他公司實現SRE的藍圖，但可以作為研究案例。每個組織都是獨特的，其需求和目標可能與谷歌不盡相同。但谷歌過去20年的實踐經驗提供了許多教訓，可以幫助其他公司加速其SRE程序。

谷歌的SRE並不是靜態的，它是持續演進的，谷歌的不同部門會根據需要採用不同的模型。與很多組織不同，谷歌的SRE是一箇中心化的團隊。SRE從最初的寥寥數人，目前已經發展為擁有近千人的團隊。如下圖所示，SRE團隊專於特定產品領域(PA)，並與該PA中的開發人員密切合作。SRE PAs的數目是可變的，可能會包含近百個SRE。SRE PAs由Dev夥伴組織提供資助，並在每個組織層面與之合作。一個SRE PA通常要比Dev夥伴組織小一個數量級，但比率可能相差很大。大多數SRE團隊都有兩個工作點，每個點有6到8個SRE，時區差為5到9個小時，以實on-call輪換。

可以看到谷歌的SRE是一箇中心化的獨立組織，更像是一個專案人力資源池。SRE和Dev會簽訂合作條約，規定合作範圍和內容，以及合作目標，並由Dev提供資金支援。

這種組織架構看起來更有點像甲乙方的關係。對於大多數公司來說其實並不適合，主要有以下幾個方面的考量：

  • SRE進入Dev其實也是有成本的，需要學習瞭解Dev的產品和服務功能。
  • 跨團隊運作存在溝通成本、職責明確等問題
  • 如果公司沒有足夠的業務資助SRE團隊，有可能SRE團隊優先會成為某些情況下的成本優化物件。

當然好處也是有的，就是更靈活，也讓SRE更加純粹，避免在專案結束之後變為業務運維之類的角色。

image

合作原則

SRE的工作是基於合作(engatement)的，與Dev同步展開。一個合作會同時涉及到兩方，通常會圍繞特定的服務或產品。大多數情況下，SRE和Dev之間的合作就是為了提升穩定性、基礎設施以及針對特定產品系統的運維而建立的夥伴關係。其他合作可則能會關注產品的端到端使用者體驗或某個水平架構主題。任何一種合作都可能會跨多個產品系統。一個典型的SRE團隊會與系統開發範圍內的Dev團隊保持一系列合作。

合作模型是谷歌SRE的基本觀念。它描述了合作和一系列最佳實踐(高效分配資源、溝通、協調以及SRE和Dev之間的共同作業)原則。它不是一個基於規則的靜態模型，但為相關方提供了清晰的界限並設定了相互預期，並且可以輕鬆識別異常或降低合作度。

本章描述了合作模型的原則，下面將討論合作型別以及如何在實踐中使用它們。

合作原則是這種組織架構核心。它規定了SRE的工作範疇，避免SRE淪為測試+運維角色。

對齊SRE的使命

如前所述，SRE的使命是提高可靠性、效率以及提高谷歌產品的釋出速度，保持團隊的健康。這種使命應該貫穿每個合作，且每次合作都應該對這些目標產生可衡量的積極影響。

倡導使用者

SRE是使用者和使用者體驗的倡導者--無論是外部使用者還是內部使用者。事實上，可以由系統(或系統組)羅列出SRE的合作內容，但這不應該削弱SRE對使用者如何感知可靠性(或缺乏可靠性)的關注。這種關注反映了強調端到端或以客戶為中心、SLOs以及SRE的職責重點是關注開發合作伙伴的可靠性差距和風險，即使這些不在SRE團隊的直接責任範圍內。建議首先在產品層面對齊，然後再讓SRE團隊關注關鍵使用者的歷程(critical user journeys (CUJs))或端到端體驗(即使SRE直接負責的特定領域被劃定在一組(可能比較寬泛的)服務下)。

這其實是對SRE的一個高要求，總體目標是做出一個好的產品。

清晰的價值定位

SRE只應承擔能夠比其他任何人更有效執行的工作。將一個特定的團隊新增到Dev團隊中會引入額外的組織複雜度並增加孤島風險。如果所有工作都能保證跟在Dev團隊內部一樣的質量和效率，那麼這種方案是可行的，但在需求變更時，讓所有團隊更加靈活地轉變工作並不是一件容易的事情。

SRE是技術嫻熟的專業工程師，他們是備受追捧的人才，薪酬與開發同行相當。為了判定是否新增SRE的headcount ，一個合作應該包括具有持久價值的大量可靠性工作，而不是以on-call內容為主。否則，新增Dev的headcount則更有意義。為了深入瞭解哪些工程流提供了最高的價值，可以引入一定量的on-call工作。但是，給訓練有素的工程師團隊提供大量on-call工作可能會導致SRE團隊內部的不滿。由於Dev團隊太小或由於Dev團隊在某個單獨的位置而無法覆蓋其on-call的工作內容而引入SRE是錯誤的，這並不是證明SRE參與的充分理由。

明確範圍

SRE團隊的工作範圍應該侷限於某些服務(或CUJs)，並且有明確的相關性和界限。SRE不會對特定的服務負責，通常會對Dev團隊的所有服務提供基礎的支援。Dev和SRE領導層需要定期協商合作範圍。

這一點至關重要，如果沒有明確的工作範圍和界限，SRE就可能被放大處理很多邊界模糊的內容，淪為集多種職責於一身的角色。

由開發資助

SRE PAs接受Dev組織授予的headcount 。SRE不通過其自身的管理連結受headcount ，也不能攜帶未分配的headcount 。雖然Dev資助了SRE團隊，但一旦轉移了headcount，則由SRE負責該headcount。SRE PA負責人有義務與資助的Dev夥伴進行協商，以便能高效、有效地使用該headcount。如果無法通過SRE工作提供比Dev夥伴更有價值的工作，則需要將該headcount返回給Dev組織。

資助應該是長期的。因為過程中會花費比較長的時間來招聘SREs，並讓其在SREs崗位上就職。出於這種原因，谷歌SRE計劃在兩年或兩年以上的時間範圍內為headcount 提供資金，並且不將資金與短期、有時間限制的活動掛鉤。員工人數的波動將導致效率低下，並且無法讓SRE團隊深度參與到產品中。

SRE和Dev領導會審視合作的資助程度，例如按年度進行資助。過程中應該考慮合作型別是否正確以及是否降低或增加資金(如通過授予或返還headcount ，或在SRE內重新分配)，最終雙方達成一致。然而，SRE領導層擁有在現有headcount的限制下分配專案優先順序的權利。否則，可能無法充分考慮到安排足夠的合作人員等因素。

戰略伙伴關係

卓越的產品是一項長期投資。合作不應該僅限於SRE PA層面。SRE PA作為一個整體，應該具有與Dev 組織相同並與之互補的戰略願景，不能僅僅進行一系列毫無聯絡的合作。SRE PA領導需要有SRE PA願景，並負責與Dev組織領導優先協商任務。

每個單獨的合作都是根據多年的規劃建立起來的。合作有望在Dev和SRE之間建立一個共同的路線圖，所開展的工作應該在SRE和Dev之間雙向移動。SRE不應僅僅執行Dev交過來的任務。

應該在安排出現問題之前設定預期值。否則在脅迫下，很難達成書面協定。系統及其元件會發生變化、合併和偏差。SRE需要小心地使用產品，如果沒有足夠的啟動時間，就不能立即支援新系統。

Dev所有權

不考慮合作的型別，服務本身以及服務的可靠性隸屬於Dev團隊(即便在某些形式的合作下日常生產許可權屬於SRE)。這意味著保障服務可靠性的責任並沒有下發到SRE團隊中，SRE團隊的成員是專業的可靠性工程師，他們通過某種型別的合作與Dev團隊建立夥伴關係，並幫助Dev團隊達到可靠性目標(這反過來規定了SRE對Dev的責任)。

積極、穩健的開發人員參與是服務健康的一部分。由於SRE並不會控制headcount的分派，因此不能單獨負責某個服務，歷史上，當Dev合作結束之後，這些服務仍然由SRE提供服務，但通常結局都比較糟糕。因此，如果Dev團隊打算減少人員設定，則還需要減少服務本身，並將剩餘使用者遷移到其他服務。一旦Dev不再資助，SRE的服務合作將立即結束，分配的headcount將在Dev合作結束之後返回給Dev團隊。

這也是谷歌PA的一種好處，合作是有期限的，因此開發團隊不會無限制地將一些事情交給SRE。一旦合作結束，SRE將不再管理該Dev團隊的事務。這反過來也對Dev團隊本身提出了一定要求。

聯合合作伙伴關係

開始並繼續與SRE進行合作是Dev和SRE雙方共同協商的結果。不能強制SRE接受某個合作，Dev也不能強制資助某一方，Dev和SRE任一方都可以結束合作。

如果Dev或SRE某一方想要結束合作，那麼就應該結束本次合作，並以符合上述資助原則的方式重新審查(重新部署或返回)headcount 職位。以非協商一致的方式結束合作是雙方應該避免的事情。

共同的努力

SRE和Dev可以帶來不同的專長：SRE注重可靠性原則、系統架構和生產最佳實踐，而Dev組織通常更加擅長其業務領域。服務的成功是一種共同努力的結果。除了不同的團隊擔任不同的角色外，雙方都有一個共同的目標。包括聯合OKRs(目標和關鍵結果)，並遵守錯誤預算策略(即當服務/CUJ達不到SLO時凍結特性發布)。Dev和SRE的共同目標是使用更有效的方式保證服務的SLO，因此違反SLO，對Dev和SRE 雙方都是一個嚴重的問題。

SLOs和錯誤預算提升了對可靠性目標的理解，並可以以此衡量合作是否成功。這也使得SRE和Dev需要聯合起來考慮如何在可靠性和特性速度之間進行權衡。凍結策略提供了一種簡單的方法，可以在客戶/使用者信任有被破壞的危險時，調整這種平衡，使其達到可靠性。

運維和on-call責任也是一項共同努力，隨著服務變得更加成熟，大部分(但不是100%)的維護責任通常由SRE承擔。

SLOs是一個很好的團隊粘合劑，可以讓雙方為同一目標而共同努力。但由於是不同的團隊，SRE領導也需要對專案的SLO進行評估，避免因為不合理的SLOs或不成熟的團隊導致無法達成目標。

SRE不是一個"運維團隊"

SRE的使命不是處理運維工作，而是提升系統的可靠性。on-call是結束SRE的一種手段，通常這種方式提供了其他方面無法提供的寶貴見解，但on-call工作本身並沒有長期價值。on-call不應該是SRE的核心工作，且單憑這一點並不能證明成立SRE團隊是合理的。應該嚴格限制SRE的運維工作，SRE團隊的苦力工作(中斷，生產清理等)不應該超過50%的時間。如果超過該閾值，Dev必須負責處理額外的運維工作。這種機制保障了SRE有足夠的時間來改善專案，進而降低運維壓力。

Dev應該至少承擔一部分運維職責。典型範例包括升級下的次級on-call輪換、非生產環境的所有權、和/或處理非關鍵運維工作。接觸運維對於維持和培養Dev團隊的生產知識至關重要。應以書面形式跟蹤責任劃分，以避免誤解。

谷歌能夠保證SRE的核心職責的一個原因也有組織架構的一部分因素在起作用。由於合作期限的約束，使得Dev團隊不能將所有運維和on-call職責都交給SRE。

運維並不是零和遊戲

SRE合作應該關注降低整體的運維壓力，而不是將運維職責從一處轉移到另一處。一個成功的合作會將運維壓力降低到理想程度。Dev應該保證24/7 on-call升級路線。

授人以漁

SRE不應該作為生產的人類抽象層。這種方法不可延伸，加強了孤島，破壞了關鍵反饋迴路，並將生產複雜性轉化為證明SRE存在的理由。相反，SRE應該幫助Dev更深刻地理解服務的生產特性

提升生產標準

SRE應促進使用通用生產平臺和標準化基礎設施。這種平臺有幾個優點：

  • 提供了一致的服務管理基礎設定，降低了實現跨服務需求的實現成本
  • 降低生產中運營個人服務的持續成本(例如，入職時間、工程師培訓時間、勞動)。
  • 總體降低支援生產中所有服務的成本；通過使傳授技能，工程師可以更輕鬆地處理不同的服務
  • 降低開發人員和SRE之間以及不同SRE團隊之間轉移服務的成本。
  • 提高工程師在團隊之間的流動性。
  • 簡化並降低生產風險
  • 提高工程師的速度
  • 提高整體的生產服務資源利用率

SRE應釋出SRE PA級別的生產平臺標準---該原則適用於服務，與SRE的支援級別無關。

有意義的工作

必須考慮工作質量。谷歌的SRE與Dev有著相同的流動機會，因此需要一個新穎、富有挑戰性、有趣的環境來實現個人發展。SRE在OKR規劃方面與Dev密切合作，但最終擁有自己的OKR。

進度追蹤

與SRE的合作是一項重大投資，需要結構化規劃和進度追蹤。SRE和Dev共用一個的路線圖，並跟蹤目標進展，定期審查服務的健康狀況、關鍵性、業務合理性和優先順序。 這可以通過業務審查、季度報告和生產健康審查等方式實現。

左移(shift left)

SRE合作可能發生在服務生命週期的任意階段--不侷限於生產啟動階段。通常在服務生命週期的早期(即"左移"，如，在設計和實現階段)引入SRE是最具影響力和效率的。在設計階段，可以很容易地更改基本架構和基礎設施決策，但對於一個完全產品化的系統來說，修改這些決策通常非常困難或代價高昂。早期與SRE建立合作關係可以防止以後出現嚴重的問題。

總結

谷歌SRE的成功帶有特定的企業基因：

  • 公司體量：保證了SRE的"就業市場"
  • 公司人員素質：保證了Dev和SRE團隊的人員能夠遵守相關流程約定，並能夠保證絕大部分人員的技能水平和職業素養。

因此谷歌的SRE並不一定適用於其他企業，但其所提倡的SRE中心化也有其存在的意義，除了靈活地支援各個業務線，也可以讓SRE避免淪為業務運維工具人。讓SRE和Dev以SLOs作為決定提高可靠性還是特徵速度的分界線，以此可以讓各個團隊有一個共同的目標。另外一個至關重要的是合作約定，該約定類似合同，除了保證SLOs的完成，也是可以避免SRE放大化的一個重要條約。

除了對SRE和Dev的硬性要求外，文中還提出了一些建議性的意見。但這需要各個團隊成員具有一定程度的職業素養，且能夠形成正反饋才能真正實現。文中所描述的SRE更像是個戰鬥旅和專家顧問的角色，不應該將其作為傳統運維或on-call輪崗人員，這樣會降低SRE的工作熱情，無法發揮SRE的真正作用。

我個人認為理想的業務應該是一個個可以正反饋的閉環，相關成員都能夠在保證交付的前提下，提升業務的可靠性，並從中得到技能提升和成就感。作為專案管理人員，應該細化專案的迭代週期，考慮專案可能存在的風險點，避免因為操之過急，導致開發進度和可靠性都無法滿足。