本文是一篇比較有價值的、介紹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更加純粹，避免在項目結束之後變爲業務運維之類的角色。
合作原則
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的真正作用。
我個人認爲理想的業務應該是一個個可以正反饋的閉環，相關成員都能夠在保證交付的前提下，提升業務的可靠性，並從中得到技能提升和成就感。作爲項目管理人員，應該細化項目的迭代週期，考慮項目可能存在的風險點，避免因爲操之過急，導致開發進度和可靠性都無法滿足。