SRE 最早在十多年前 Google 提出并應用，近幾年随着 DevOps 的發展，SRE 開始被大家熟知。而在國内，非常多的 SRE 部門與傳統運維部門職責類似，本質來說負責的是網際網路服務背後的技術運維工作。建構差別于傳統運維的 SRE、如何在業務研發團隊落地 SRE，是許多企業都在攻克的難題。
本屆全球運維大會 GOPS 上，阿裡雲彈性計算團隊技術專家楊澤強以《大型研發團隊 SRE 探索與實踐》為題，分享了在 SRE 體系建設上的思考和落地實踐。
本文為演講内容整理，将從以下三部分進行介紹：
· 阿裡雲彈性計算（ECS）自建 SRE 體系的原因；
· ECS 建設 SRE 體系的探索與實踐；
· 以彈性計算 SRE 體系建設的四年經驗為例分享對 SRE 未來的看法。
為什麼 ECS 要自建 SRE 體系？
ECS 團隊之是以會單獨建 SRE，與産品業務特性以及組織層面上的背景有關。
下圖展示了 ECS 的業務特點：
首先，從産品業務來看，ECS 是阿裡雲最大最核心的雲産品。ECS 作為阿裡巴巴經濟體的以及其它部署在 ECS 上的雲産品的底座，也支撐了國内外非常多的業務。
阿裡雲全球份額排名第三，其中 ECS 的貢獻毫無懸念是排名第一的，ECS 作為基礎設施底座，穩定性要求特别高。
其次，由于阿裡内部的經濟體上雲和整個雲計算普及，ECS 對外的 OpenAPI 調用量每年都出現數倍增長，這意味着系統的容量每年都會面臨新的挑戰。
而與此同時，阿裡雲彈性計算啟動了去 PE 的組織調整，即業務團隊沒有專職的運維工程師以及系統工程師，這将意味着運維類的事情、系統架構規劃與橫向産品需要有團隊來承接。
ECS 建設 SRE 體系的探索與實踐
從 2018 年剛開始建設至今，在一路的摸索中，ECS 的 SRE 體系建設借鑒了 Google 和Netflix 的做法，并結合團隊和業務的特性，最終 SRE 體系可以簡單概況為下圖的五個層次：
打基礎。阿裡雲的文化主張裡有一句話是“基礎不牢，地動山搖”。在團隊裡具體的事情就是全鍊路穩定性治理體系以及性能容量工程，也是重要的基礎。
定标準。這在一個大型研發團隊裡非常重要， ECS 團隊主要從軟體的生命完整生命周期來看，從設計->編碼->CR->測試->部署->運維->下線，各個環節定義了标準。通過定期的技術教育訓練和定期營運，先在意識上給大家普及，同時會通過小團隊的試運作來看效果，如果符合預期就想辦法自動化掉。
建平台。通過建設自動化平台來不斷釋放 SRE 的人肉工作。
做賦能。業務團隊的 SRE 除了做好橫向的基礎元件和自動化平台外，還要做很多推廣和協助業務研發的事情；同時 SRE 每天都要處理非常多的預警響應，線上問題排障以及故障響應，如何把 SRE 的價值最大化，我覺得最核心的是賦能。
建團隊。最後我将以彈性計算為例介紹一下SRE團隊的職責，文化理念以及如何成為一名合格的 SRE。
打基礎
基礎架構建設與性能調優
彈性計算的核心業務都是 Java 技術棧，還有少部分 golang 和 python，本質上是一個Java 研發大型分布式系統。在内部為了支撐業務規模和盡可能的抽象整合，我們自研了一系列基礎架構給業務同學使用，包括輕量bpm架構、幂等架構、緩存架構、資料清理架構等，其中每個架構的抽象和設計我們都考慮了規模化容量的支撐以及小型化的輸出，以工作流架構為例，我們支援了每天數億工作流的建立運作，架構排程開銷做到了5ms級别。
除了基礎架構，在性能優化上針對 JVM 進行了一系列調優，比如針對IO密集型的應用開啟了wisp協程，以及針對每個核心應用JVM進行調優，減少STW的時間。
另外，從服務性能角度，資料層，我們對全網超過100ms的慢SQL進行了調優；應用層，我們針對核心鍊路提供了多級緩存方案，可以保障最熱的資料可以從記憶體裡最快的傳回；業務層，我們通過提供批量API以及異步化改造。
全鍊路穩定性治理
上圖羅列了幾個比較典型的點，比如預警治理，普遍問題是預警量太大了，信噪比又不高，預警能提供的資訊非常有限，對于排查排障幫助比較局限。
早年間，我們也面臨同樣的問題，分享預警治理的兩個真實故事：
一個核心應用的資料庫在晚上down了，但預警配置的通知管道是email和旺旺，并且接收人不是目前應用owner，導緻owner在發現故障問題的時候花了非常長時間定位到是資料庫問題。
之前發生了一起全鍊路連鎖反應的故障，故障發生的起因是其中某一個業務導緻的，當時我們花了兩個小時來定位和恢複問題，在事後複盤才發現故障開始前5分鐘，已經有相關報警，但該報警接收同學的預警量太大，漏掉了重要預警。
是以，穩定性治理很重要的一部分就是預警治理，主要治理的方法就是監控分層、統一預警配置平台、統一預警優化配置政策，比如預警的接收人、通知方式等。
資料庫穩定性治理
資料庫是應用的命脈，發生在資料庫上的故障往往非常緻命。不論是資料的準确性或者資料的可用性受損，給業務帶來的災難通常是毀滅性的。
兩個難題：慢SQL和大表
當在使用MySQL做資料存儲的時候，最高頻遇到的場景就是慢SQL和大表這兩個難題。慢SQL會導緻業務變慢甚至産生全鍊路的連鎖反應導緻雪崩，而大表問題和慢SQL通常也分不開，當表的資料量大到一定程度，MySQL的優化器在做索引選擇的時候也會遇到一些奇怪的問題，是以在資料庫的治理上基本圍繞慢SQL和大表。
針對慢SQL的治理方案
大緻的解法是把采集的慢SQL同步到SLS上，通過SLS做近實時的慢SQL分析，然後通過庫表資訊把慢SQL分給指定團隊來修複，這個過程SRE同學會給出優化方案以及通用的基礎元件，比如針對大頁查詢的提供bigcache以及nexttoken方案，針對熱點資料的common cache以及讀寫分離降級能力。
針對大表的治理方案
針對大表問題，業界通常的解決方案是分庫分表，但是其帶來的研發和運維成本很高，我們内部一般業務更常用的方式是通過曆史資料歸檔來做，在這裡SRE也有統一的基礎架構提供，業務方隻需要給出資料歸檔條件以及觸發頻率，架構會自動将曆史資料歸檔到離線庫并把業務庫資料做實體删除，這樣通過騰挪資料空洞來達到空間的一定複用，保障有限的資料空間不擴容的前提來支撐業務的發展。
高可用體系
分布式系統的高可用可以分四個層次來看。從最底層的部署層，由下至上分别是運作時、資料層、業務層，我們的高可用體系也是按照四個層次來劃分的。
部署層，作為ECS的研發我們對外推薦的最佳實踐都是多可用區部署，理由很簡單，因為容災性更好、更柔性。
資料層，如前面提到的資料庫穩定性治理，我們資料層一方面的工作就圍繞像慢SQL、熱點SQL和大表的持續治理，另外一方面就是從技術架構上我們做了多讀和讀寫自動降級架構，可以将一些大表查詢自動降級到隻讀庫，同時可以保障讀寫庫異常情況，核心API仍然可以通過隻讀庫提供服務，進而來保障資料庫整體的高可用。
業務層的高可用體系，一個複雜的分布式系統，難題之一就是解決依賴的複雜性，如何在依賴方不穩定的情況下仍然保障或者有損保障自身的核心業務可以玩轉，這是分布式業務系統非常有挑戰與有意義的一件事情。
故障案例
我們曾經出過一個故障，一個核心系統被一個非常不起眼的邊緣業務場景搞到雪崩。核心系統裡引入了一個三方系統依賴，當依賴方服務RT變慢的時候，我們所有的HTTP請求由于設定的逾時時間不合理全部阻塞，進而導緻所有線程都block在等待該服務傳回，結果就是所有服務RT變長，直至不再響應。
要知道在龐大的分布式系統裡，沒有絕對可靠的授信鍊，我們的設計理念就是Design For Failure，以及Failure as a service。
可參考以下思路：
- 在設計階段時定義該依賴的性質，是強依賴還是弱依賴
- 對方提供的SLO/SLA是什麼，依賴方可能會出現什麼問題以及對我們服務的影響是什麼？
- 如果依賴方出現了預期/非預期的異常，我們的政策是什麼？
- 如何保障我們服務的最大可用性。最大可用性，意味着做出的響應可能有損，比如對端是弱依賴，我們可能會直接降級，傳回一個mock結果，如果對端是強依賴，我們可能采取的是隔離或者熔斷政策，快速失敗部分請求，并盡可能記錄更多資訊，友善後續通過離線方式進行補償。
定标準
彈性計算的研發人員大概是百人以上規模，同時還會有一些兄弟團隊以及外包人員一起參與研發，自SRE建設的第一天我們就開始逐漸建立各種研發标準和流程。
以UT标準案例為例，UT缺失導緻的故障占比高；難度是量大，研發不重視，實際沒辦法收斂。解法是通過建立UT标準，和CI自動化體系，量化名額來持續改進。效果是UT缺失導緻的故障大幅降低，從占比30%降低至不到0.3%。
研發流程體系
我們從設計到釋出幾乎各個環境都定義了一套标準。
1.設計階段。我們統一定義了一套設計文檔模版來規範和限制研發人員。從軟體工程角度來看，越早引入問題帶來的成本越低，是以我們的研發原則之一也是重設計。一個好的設計不僅要從業務上定義清楚問題，定義清楚 UserStory 和 UserCase 以及限制，從技術角度也要清楚的講清楚技術方案的 tradeoff 以及 Design for failure 如何實作、如何灰階、監控復原等等。我們希望研發多在設計階段下功夫，少在中途返工或者釋出後打更新檔。同時我們的評審機制也從線下大團隊評審轉變為小團隊線下+大團隊直播方式進行，盡可能少開會，節約大家時間。
2.研發階段。我們的研發流程類似 git-flow。是多 feature 并行開發，開發測試後合并進入develop分支，每天會有統一的流程基于 develop 進行 daily deploy，我們基于阿裡集團的 Java 規約做了擴充，加入了自定義的靜态掃描規則，同時統一的UT架構，實作了 CR 後自動運作規約掃描執行靜态檢查，同時運作 CI 産出 UT 運作報告，隻有靜态掃描，CI 結果主要是UT成功率和行增量覆寫率以及代碼點贊數同時滿足條件 MR 才會被合并，進入下次釋出 list。
3.測試階段。主要分日常測試，預發測試以及上線前的功能測試以及灰階期間的回歸測試。大規模研發團隊大家面臨的難題就是環境怎麼搞？這麼快速複制以及隔離？以往模式下我們隻有一套日常和預發，經常出現某個人代碼問題或者多人代碼沖突導緻測試特别耗時。後來我們做了項目環境，簡單功能可以通過容器方式快速複制全鍊路項目環境。針對有全鍊路聯調需求的 case，我們擴充了多套預發環境，可以做到每個業務研發團隊一套預發，大家互相不争搶，這樣預發的問題就解決了。
上線前的功能測試主要是針對 daily deploy 的，我們會在每天晚上 11 點自動從 develop 拉取分支，并部署到預發環境，同時這個時候會自動運作全量的功能測試用例來保障釋出的可靠性，在日常釋出如果 FVT 非預期失敗，會導緻釋出取消。
最後一個測試流程是灰階期間自動回歸 core fvt，我們的釋出是滾動釋出模式，通常會灰階一個地域來做灰階驗證，core fvt 就是做這個的，當 core fvt 運作通過後可以進行後續批次釋出，反之判斷是否復原。
變更流程體系
在 SRE 建設的時候，我們特意規劃了變更管控流程。針對目前的變更類型做了不同的标準要求，比如資料庫變更 checklist+review 機制，日常釋出/hotfix/復原的批次以及暫停時長，還有就是中間件的配置規範以及黑屏變更等。
有了變更流程和規範隻是第一步，接着我們針對高頻率的運維操作做了工具化建設，其中有部分和現有的 DevOps 平台合作，遊離在現 DevOps 之外的部分我們都自己做了研發支援，比如日志清理以及程序自動重新開機，并開發了自動化工具可以自動化清理大檔案以及重新開機故障程序。
舉一個例子就是資料訂正，資料都是通過異步編排來實作最終一緻性，是以資料訂正會是一個特别高頻的變更，簡單的一條訂正 SQL 蘊藏的威力有時候超過我們的想象，我們之前有一個故障就是因為一條資料訂正錯誤導緻，影響非常嚴重，排障過程也非常困難。
建平台
SRE 自動化平台
我們做 SRE 自動化平台就是為了将标準通過自動化方式來實作，比如研發階段的高可用體系裡的讀寫降級，限流等。我們在提供架構能力的同時，提供了運維接口和白屏化工具，幫助研發實作自動化/半自動化的高可用能力。
彈性計算團隊的 1-5-10 名額
後面的變更、監控、預警、診斷、恢複，對應的就是 MTTR 的各個細分階段，在阿裡集團有個 1-5-10 的名額，意思就是分鐘發現問題，5 分鐘定位問題，和 10 分鐘恢複問題，這是一個非常難達到的高标準。
彈性計算團隊為了滿足提升 1-5-10 名額，建立了自己的監控平台和預警平台。我們做的是預警能力的二次消費，将所有的基礎監控包括系統名額 CPU 和 mem、JVM 監控以及各種中間件監控，還有非常多的業務監控做了分層，而每一個預警都會囊括各種 meta 資訊，比如歸屬團隊、重要性、關聯的診斷場景、快恢政策，以及推薦的變更等。
這就閉環了變更、預警、診斷、快恢整個過程。當一條預警出現的時候可以自動根據 TraceID 分析全鍊路尋找局點，同時推薦相關變更，并生成影響面比如多少 API、使用者是哪些，以及該預警推薦的解決方案是什麼，同時提供一個 hook 可以執行快恢動作。
舉個例子，有位同學訂正了一條業務，SQL 寫的問題有問題，導緻線上幾個大客戶的服務異常，在 SQL 執行完的幾秒内我們的監控系統就識别出了業務異常，并産生了預警資訊以及預警的 stack 和影響面分析，同時關聯的資料庫變更資訊也被推薦了出來，這些資訊組合在一起的1分鐘内我們就定位到了問題，并立馬執行了復原，業務很快就恢複了。當然該平台目前仍然有局限性，我們今年規劃會做更多智能預警和診斷的事情。
最後，必須要提一下演練，即混沌工程 Chaos engineering，最早由 Netflix 提出。在過去的兩年裡，我們通過故障演練，故障注入的方式多次回放了曆史故障，同時對發現線上問題也非常有幫助，故障演練現在已經作為一個常态化的事情融入到了日常。
分享完我們的 SRE 自動化平台體系，有了平台之後，非常重要的一個事情就是賦能。
我認為業務團隊 SRE 最大的價值就是賦能，通過賦能來使衆人行。
做賦能
全鍊路 SLO 量化體系
ECS 的上下遊依賴方衆多，任何一個環境出現不穩定都會影響 ECS 出口服務的穩定性。
舉個例子 ECS 向下對接的是虛拟化和塊存儲，隻要虛拟化和快存儲慢了展現使用者層面就是 ECS 執行個體啟動慢了，而這個快慢究竟如何評定呢？可能對于我們做分布式服務來說可能覺得 5ms 已經很慢了，但是對于虛拟化來說他認為我這個接口 1s 都是正常的，這個時候就需要 SLA 了。
做 SRE 的第二年，我們梳理了全鍊路數十個依賴以及數百個核心 API 與各個業務方選擇最關心的名額也就是 SLI，針對不同的置信空間設定了 SLO 值，并且建設了統一的量化平台，通過實時與離線方式持續跟進起來。通過 SLO 體系建立到持續營運的一年多時間，我們的依賴方可用性和時延的 SLO 達标率從最初的 40% 多治理到98%以上。這個直接産生的業務就是我們對使用者 API 成功率的提升，使用者的體感更加好了。
落地 SLO 的四個階段
- 選取 SLI，即和你的依賴方确定哪些名額是需要關注的，比如通常都關心的可用性和時延；
- 和依賴方約定 SLO，即明确某個 API 某個 SLI 的目标值 P99、P999 分别是什麼；
- 計算 SLO，通常的方式都是通過記錄日志，将日志采集到 SLS，通過資料清洗再加工計算出名額值。
- 可視化，通過将 SLO 做成實時/離線的實時報表，來做持續跟進。
知識庫
SRE 很大的一部分職責在于故障排查和疑難問題處理，同時我們做了一系列架構和工具，還要非常多的運維手冊以及故障複盤的資料，這些我們都按照統一模版沉澱下來，可以用來指導研發同學日常問題排查和變更使用，其中部分文檔我們還共享給了阿裡雲其它産品。
通過知識庫我們也賦能了非常多的兄弟團隊，另外我們研發過程中的很多業務基礎元件像工作流、幂等、緩存、降級、Dataclean 等架構也都有阿裡雲其它團隊在使用。
穩定性文化建設
SRE 是穩定性的捍衛者，也是布道師。隻有人人都意識到穩定性的重要性，我們的系統才可能真正的穩定。我們從建設 SRE 團隊的第一天就開始建流程，團隊内通過日報，周報，月報以及不定期的線上直播以及線下教育訓練來宣傳穩定性文化。逐漸在團隊形成我們特有的穩定性文化，比如 Code Review 文化，安全生産文化和事後故障複盤文化。
故障複盤實踐
在 SRE 初期，我們開始推行故障複盤。我們對于故障的定義是所有有損業務或者人效的異常 case 都是故障。一開始，故障複盤由 SRE 主導，由業務團隊配合，但整個過程非常不愉快。
随着後面 SRE 的一些自動化工具以及一些流程真正幫助了研發避免故障，以及在故障複盤過程中 SRE 的一些見解給到了研發正向回報，慢慢故障複盤的文化在團隊開始慢慢被接受，各個業務自己會寫故障複盤報告，并開直播分享，其它團隊的同學也會非常積極地給回報。文化真正的深入人心後，産生的會是非常好的良性循環。
建團隊
最後分享一下 SRE 團隊組建主要注意的幾個方面。
人
在彈性計算團隊，我們對 SRE 的要求是T型人才，要一專多能。
- 精通一門程式設計語言
- 兩個基本能力：抽象能力、标準化能力
- 擁有全局視野，具備賦能意識
事
事，基本上即是前面提到的建标準、建自動化平台、做基礎服務和賦能業務團隊，還有 on-call 支援等日常工作。
同時，我們需要在團隊中建立幾個共同的核心理念，我個人認為 SRE 幾條最核心的理念：
- 穩定性就是産品，穩定性不是一錘子買賣。SRE 要做的是賦予穩定性産品的靈魂，要按照産品一樣去養育，去不斷疊代，去持續演進。
- 軟體工程的方法論解決生産系統穩定性問題。SRE 差別于業務研發和運維的很大一點是，SRE 解決的是生産環境的穩定性問題，是通過軟體工程的方法論來重新定義運維模型。
- 自動化一切耗費團隊的事情。SRE 的精髓在于軟體工程定義運維，通過自動化以及賦能業務來最大化價值。
SRE 建設的回顧與個人展望
簡單概括下彈性計算團隊四年的 SRE 發展曆程就是，建體系-量化-自動化-智能化。
第一年：體系化探索
這一年主要的工作就是從0-1結合目前業務和團隊的現狀把SRE體系建設起來，比如基礎架構的統一建設，穩定性治理體系。
第二年：SLO體系
第二年的重點主要是針對全鍊路數十個系統依賴，以及内部系統的核心功能定義了 SLO（Service Level Object，SLO）量化體系，并跨BU完成了整個鍊路的 SLO 量化體系建設。同時開始重點建設穩定性營運體系，以及自己的資料營運平台，将内外部核心依賴的核心 API 的可用性，時延的資料全部量化并持續跟進治理起來。
第三年：自動化
我們把研發過程中從設計、編碼、測試、部署到上線後的預警響應等所有需要人工參與的事情都做了盡可能的自動化。比如在 CR 階段加入 UT 覆寫率卡點，不符合标準的 CR 會自動攔截。在釋出階段接入了無人值守，根據釋出期錯誤日志的情況來進行釋出攔截，當然這裡更好的方式可能是通過灰階機器的服務 SLA 等綜合名額來判斷。另外，在灰階地域釋出暫停期間，我們會自動化運作 corefvt 來回歸核心測試用例驗證釋出的可靠性，異常情況會自動攔截灰階，并推薦一鍵復原操作。
第四年：智能心智
今年我們正在做的一些事情是高度自動化，比如無人釋出值守，還有自動化預警根因分析等。當我布式系統規模足夠大，應用複雜度足夠高的時候，靠人的判斷是非常困難的。是以，SRE 要建設的自動化平台要有智能心智，通過系統化的能力來代替甚至超越人。
對SRE未來發展的個人看法：
穩定性即産品，我們真正是需要把穩定性當作産品來看待的，做産品意味着我們要清楚的定義問題，并産生解決方案，并且持續的疊代演講，這不是一錘子買賣，是需要養育的。
我覺得随着雲計算的普及，SRE 的技能會傾向于研發技能，當然系統工程的能力也是必須的，因為雲計算作為基礎設施會幫助我們屏蔽掉非常多的機房、網絡、OS 層面的問題，這樣SRE的重點就在于用軟體工程的方法論來重新定義運維，使用自動化來提高效能。
Netflix 提出了一個 CORE SRE 的概念，NetFlix 是這樣解讀 CORE 的，C 就是 Cloud，我們都知道 Netflix 是 run on AWS，Cloud 是基礎。
Operation 就是運維了，Reliability 和 Enginering 就不多說了。
而我對 CORE SRE 的另一個解讀是少量核心的 SRE 人員支撐并保障大規模服務的穩定性。
少量的 SRE 支撐大規模服務背後的最核心理念我覺得是自動化，盡可能最大化一切可以自動化的事情，并且要智能的自動化。
總結下穩定性就是，産品 + Dev 的比重會增大 + CORE SRE + 自動化一切。
以上就是我今天想要和大家分享的内容，謝謝大家的聆聽。