TOP網際網路公司都在用，為什麼SRE比傳統運維更搶手？

阿裡妹導讀：雙11的完美收官，2684億的銷售奇迹及順滑極緻的客戶體驗讓雙11背後的技術再次被推到風頭浪尖。而雙11技術熱點話題，不得不提集團核心系統100%上雲這一技術創舉。

作為集團上雲的底座産品，ECS承擔了集團上雲基礎設施的重任，對如何保障集團上雲的極緻穩定性及性能需求，彈性計算管控團隊做了長期的探索與實踐，竹澗作為SRE參與了這場“革命”，接下來他将分享ECS管控SRE在落地穩定性體系建設中的探索及背後的思考。

前言

SRE是什麼？

SRE（Site Reliability Engineering）即網站可靠性工程，提及SRE很多人會聯想到運維工程師、系統工程師，其實不然，SRE本質上仍然是軟體工程師，下面我們從SRE的發展曆史展開來進行介紹。SRE最早在十多年前Google提出并應用，近幾年逐漸在國内外TOP網際網路公司都開始廣泛應用。據筆者了解業界SRE落地成功的權威有Google、Netflix等，前者締造了SRE，并奠定了其權威的地位，而後者将SRE的實踐做到了極緻，據官方曝露的資訊，Netflix僅有的個位數的Core SRE支援了190個國家、數億使用者、數萬微服務執行個體業務規模的運維。近幾年随着DevOps的發展，SRE開始被大家熟知，國内的一線網際網路公司如BAT、美團也都逐漸從組織架構、招聘上均有展現。以阿裡為例，不同的BU均有設定SRE團隊，然而在不同的部門，SRE的職責劃分卻不盡相同，那麼SRE究竟在做什麼？

SRE的職責

SRE主要負責Google所有核心業務系統的可用性、性能、容量相關的事情，根據《Site Reliability Engineering 》一書提及的内容，筆者做簡單彙總，Google SRE的工作主要包括但不限于如下：

• 基礎設施容量規劃
• 生産系統的監控
• 生産系統的負載均衡
• 釋出與變更工程管理
• on-call（輪值） 與 Firefighting（緊急故障救火）
• 與業務團隊協作，共同完成疑難問題的處理
• ...

而在國内，非常多的SRE部門與傳統運維部門職責類似，本質來說負責的是網際網路服務背後的技術運維工作。差別于傳統的運維SRE，如何在業務研發團隊落地SRE，我們做了一年多的探索與實踐，筆者認為業務團隊SRE的核心是：以軟體工程的方法論重新定義研發運維，驅動并賦能業務演進。下文将重點介紹彈性計算落地SRE的一些實踐及背後的思考。

一、為何要成立SRE？

面臨的挑戰

ECS作為阿裡雲最核心的雲産品，對内承擔了集團上雲、雲産品On ECS的重任，是阿裡雲經濟體的基礎設施；對外作為亞洲最大的雲計算廠商，服務着遍布全球的大中小客戶（包括各種專有域、專有雲），而ECS管控作為核心排程大腦，重要性不言而喻。随着集團上雲、雲産品On ECS的程序加速，ECS的OpenAPI調用量達到了數億/日，ECS峰值建立量達到了 百萬/日，ECS管控排程系統在容量規模、極緻性能、高可用性等方面，面臨着一系列挑戰：

• 資料庫瓶頸，頂配資料庫空間仍然無法支撐業務半年發展。
• 慢SQL數量爆發式增長，應用穩定性岌岌可危。
• 全鍊路預警資訊最多每天200+，系統隐患逐漸暴雷。
• 工作流架構使用面臨瓶頸，無法支撐業務三個月的業務體量，人工運維風險極高。
• 人工運維頻率高，研發幸福感下降。
• 長尾請求嚴重影響服務品質，5XX錯誤持續走高，影響客戶體驗。
• 不一緻性資源長期無法收斂，資損無法解決。

SRE應運而生

如何在保障業務高速發展的同時，建構系統高可用的穩定性體系，同時在性能與容量上支撐業務未來3-5年的發展是團隊面臨的重大挑戰。在SRE團隊成立之前ECS管控團隊是按照業務域進行的團隊劃分如執行個體、存儲、鏡像、網絡、體驗、ESS、ROS等。而在上述組織架構下研發團隊可以在垂直領域做到精深，但團隊整體會缺少頂層的視角，很難從局部看到整體，進而看到全局。康維定律指出 “設計系統的架構受制于産生這些設計的組織的溝通結構”，簡單來說可以了解為：組織架構=系統架構，當我們系統穩定性體系需要跨業務團隊的頂層視角來建構的時候，最好的保障就是組織架構的落地，ECS SRE團隊應運而生。

二、SRE做了什麼？

前文簡單介紹了Google SRE團隊的職責包括容量規劃、分布式系統監控、負載均衡、服務容錯、on-call、故障應急、業務協同支援等，同時也簡單描述了國内偏系統運維的SRE團隊。而ECS SRE落地的探索過程中，吸取業界優秀經驗的同時也結合ECS團隊的業務及團隊特色形成了一套獨有的方法論及實踐體系。對于此，筆者的觀點是：沒有放之四海而皆準的标準，需要我們不斷探索的是與“當下、業務、團隊“契合的方案，古語謂之“天時、地利、人和”。下文将整體上介紹ECS SRE團隊在穩定性體系建設上所做的一些事情。

ECS SRE體系大圖

2.1 容量與性能

前文提到ECS的OpenAPI調用量達到數億/日，ECS建立峰值達到了百萬/日，在此背景下，管控服務的容量與性能面臨嚴峻問題，比如資料庫容量面臨枯竭、服務長尾請求頻現等。随着集團上雲、雲産品On ECS的演進需求，以及整個雲原生大環境的高歌猛進，未雨綢缪已然變成了迫在眉睫。以ECS管控核心的工作流引擎為例，在我們業務體量快速增長的背景下，工作流任務單表一個月的資料就達到了3T+，這意味即使是頂配資料庫也無法支撐業務數月的發展。除了工作流，核心的訂單、訂購、資源表均面臨相同問題，如何在業務高速發展的同時，保障業務延續性是我們面臨的頭号問題。為了解決當下的容量與性能問題，同時面向未來擴充，我們針對ECS自研的基礎組建包括工作流引擎、幂等架構、緩存架構、資料清理架構等進行了更新改造，為了後續可以賦能給其它雲産品或者團隊使用，所有的基礎元件全部通過二方包标準輸出。

基礎元件更新：通過對ECS管控自研的業務基礎元件進行架構更新來應對業務未來的規模化發展。

• 工作流引擎：14年ECS團隊自研的輕量工作流引擎，與AWS SWF類似， 18年改造後支援數億級工作流建立，我們目前還在做一些架構可用性、容量與性能相關的優化。
• 輕量幂等架構：通過注解自定義業務幂等規則，通過輕量持久化方式支援業務幂等。
• 資料異步清理架構：通過注解配置業務資料清理政策。
• 緩存架構：通過注解支援業務定義緩存命中與失效規則，并支援批量。

性能優化：多元度的性能調優政策來提升管控整體服務的性能名額。

• JVM調優：通過不斷調整優化JVM參數來減少其FGC次數及STW時間，縮短服務不可用時間，提升使用者服務體驗 。
• 資料緩存：核心鍊路多級緩存，減少資料庫IO，提升服務性能。
• SQL性能調優：通過優化SQL執行效率提升業務性能。
• 核心鍊路RT優化：業務優化保障ECS核心建立、啟動鍊路性能。
• API批量服務能力：批量的服務能力，提升整體服務性能。

2.2 全鍊路穩定性治理

穩定性體系化建設是我們在過去一年摸索中最重要的一環，對此筆者的心得是：穩定性治理一定要有全鍊路頂層視野，從上至下進行細分。下文将簡單介紹一下ECS管控穩定性治理體系。

1）資料庫穩定性治理

資料庫是應用的核心命脈，對于ECS管控來說，所有的核心業務全部跑在RDS之上，如果資料庫發生故障，對應用的損害無論從管控面或者資料面都是緻命的。是以，SRE做的第一件事情就是守住核心命脈，對資料庫穩定性進行全面的治理。首先，我們先來看一下ECS管控在規模化業務下，資料庫面臨的問題：

• 空間增長過快，無法支撐業務近期發展需求。
• 慢SQL頻發，嚴重影響應用穩定性。
• 資料庫變更故障率高，DDL大表變更引起的故障占比高。
• RDS性能名額異常，資料庫各種性能名額異常。
• RDS報警配置混亂，報警資訊存在遺漏，誤報的情況。

對于資料庫的問題我們的政策是資料庫+業務兩手抓，單純優化資料庫或者業務調優效果都不是最佳的。比如典型的資料庫大表問題，占用空間大，查詢慢，如果單純從資料庫層面進行空間擴容，索引優化可以解決短期問題，當業務規模足夠大的時候，資料庫優化一定會面臨瓶頸，這個時候需要業務調優雙管齊下。下面簡單介紹一下優化思路：

• 資料庫占用空間大問題，兩個思路，降低目前資料庫占用空間，同時控制資料空間增長。我們通過歸檔曆史資料釋放資料空洞來達到資料頁複用，進而控制資料庫磁盤空間增長；但是delete資料并不會釋放表空間，為了釋放已經占用大量空間的大表，我們業務上進行了改造，通過生産中間表輪轉來解決。
• 慢SQL頻發問題，資料庫優化與業務改造兩手抓。資料庫層面通過索引優化來提高查詢效率，同時減少無效資料來減少掃描行數；應用層面通過緩存降低資料庫讀次數、優化業務代碼等方式減少與規避慢SQL。
• 資料庫變更故障率高問題，管控流程增強，增加Review流程。DDL變更類型多，由于開發人員對資料庫的專業性與敏感度不夠導緻資料庫引發變更增多，對于這類情況，我們針對DDL變更增加了 檢查項清單與評審流程，控制資料庫變更風險。
• 資料庫性能名額與配置問題，以項目方式推進資料庫健康度提升，統一管控資料庫預警配置。
• 慢SQL限流與快恢的探索。慢SQL嚴重情況會導緻RDS整體不可用，目前我們正在探索如何通過自動/半自動化的方式限流慢SQL來保障資料庫穩定性。

下圖是ECS在資料庫穩定性治理上的幾個探索。

2）監控預警治理預警對于問題與故障的發現至關重要，尤其在規模化的分布式系統中，精準而及時的監控可以幫助研發人員第一時間發現問題，減少甚至避免故障的發生。而無效、備援、不精确的低品質報警不僅耗時耗力，影響SRE on-call人員幸福感，同時也嚴重影響故障診斷。ECS管控預警品質不高的因素主要包括：

• 數量多，平均每天100+，峰值200+，信噪比低。
• 管道多，大量重複報警，幹擾大。
• 配置異常，存在預警丢失情況，風險高。
• 損耗人力，預警反複出現導緻處理預警需要投入大量人力，人效低。
• 黑屏操作風險高，大量黑屏操作增加生産運維風險，風險高。

針對上述情況，我們的政策是針對預警進行體系化整理，實作預警的真實性、準确性、精确性、高品質。我們的打法大概分了以下幾個步驟：

• 删除無效報警，清理監控平台曆史無效的預警，提高預警真實性。
• 優化預警配置
• 統一預警接收人，保障預警隻投遞到正确的接收人。
• 優化預警等級，設定合理的預警級别。
• 劃分預警管道，按照預類型與嚴重程度進行管道劃分，如緻命預警電話預警、嚴重預警短信預警、普通預警釘釘預警等。
• 自動化一切人肉幹預的預警，反複需要人工參與解決的報警通過自動化方式來解決。比如大量業務日志導緻磁盤存儲空間不足，可以通過優化log rolling政策實作自動化。

3）故障診斷

關于故障恢複我們有一個1-5-10的理想模型，意思是1分鐘發現問題，5分鐘定位問題，10分鐘恢複問題。1分鐘發現問題依賴于前文提到的高品質的監控預警體系，5分鐘定位問題則依賴于系統的故障診斷能力，如何基于已有的預警資訊實作故障快速診斷面臨一系列挑戰：

• 系統調用鍊路長，從控制台/OpenAPI到底層虛拟化/存儲，RPC鍊路調用鍊路大概有10層以上，依賴系統30+，業務串聯難度大。
• 系統間依賴複雜，ECS管控自身有多層架構，同時與集團訂單、計費等系統互相依賴。
• 影響面分析困難，無法量化故障影響面。

在故障診斷體系的建設上，我們初步劃分三個階段：

• 全鍊路Trace模型建立，通過TraceID打通調用調用鍊路，實作業務串聯。
• 核心應用場景故障診斷模型，針對目前業務核心鍊路以及以往故障的高頻場景進行診斷模型訓練，由點到面的突破。
• 故障影響面模型，自動分析故障影響使用者、資源、資金，友善故障快速恢複及故障善後。

4）全鍊路SLO

沒有100%可靠的系統，對于終端使用者而言99.999%和100%的可用性沒有本質差別。我們的目标是通過持續疊代優化保障使用者99.999%的可用性服務體驗，而現狀是終端使用者發起的行為會經過一系列中間系統，任意一個系統可靠性出現問題都會影響客戶體驗。而全鍊路各個節點的穩定性如何衡量是我們面臨的問題，對此我們開始了全鍊路SLO體系建設，主要政策如下：

• 識别上下遊依賴業務方，簽訂SLO協定。
• 建設全鍊路SLO可視化能力。
• 推進上下遊依賴促成SLO達标。

5）資源一緻性治理

根據分布式系統CAP原理，一緻性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）無法同時滿足。ECS管控作為規模化的分布式系統面臨同樣的問題：資源一緻性問題，具體表現在ECS、磁盤、帶寬等在ECS管控、訂單、計量等多個系統存在資料不一緻問題。分布式系統為了保障系統可用性，通常會犧牲部分資料實時一緻性，轉而通過最終一緻性來解決。針對ECS的技術架構及業務特性，我們對保障資源一緻性的政策如下：

• 資料驅動，首先建立全鍊路可視化對賬體系，所有不一緻資源全部資料化。
• 财（錢）、産（資源）兩個抓手，從資源和資損兩個角度來度量一緻性問題。
• 離線（T+1）與實時（一小時對賬）兩種方式，及時止損。

2.3 SRE流程體系建設

ECS在 近百人并行研發& 核心應用每日釋出&全年數千餘次釋出 的背景下，可以做到故障率每年下降的關鍵因素之一，就是有一套相對完善的研發與變更流程保障。下文将簡單介紹ECS SRE在研發與變更流程體系上所做的的一些探索。

研發流程：整個軟體生命周期研發流程規範更新。1）設計流程與規範從軟體工程角度來看，越早引入問題帶來的人力消耗和經濟損失就越小。沒有被良好設計的系統後續在維護階段投入的成本要遠高于前期設計的投入。為了把控設計品質我們在設計流程與規範上做了如下探索：

• 加強前期設計，統一設計模版。（完整的設計應該包括架構設計、詳細設計、測試用例、橫向設計、監控預警、灰階方案、釋出方案等）
• 線上（釘釘直播）& 線下并行模式進行設計評審。

2）CodeReview更新之前ECS的CodeReview主要在GitLab平台，其主要問題是gitlab與阿裡内部持續內建相關元件內建不夠穩定、另外無法設定準入卡點，Aone CodeReview平台很好的解決了與Aone實驗室的內建問題，并且提供了代碼合入的卡點配置功能，另外我們定義了一套ECS管控的CodeReview流程，如下所示：

• 統一研發規範，包括（開發環境規範、編碼規範on 集團開發規約 等）。
• CodeReviw checklist
• git commit 關聯issues，做到代碼與需求/任務/缺陷關聯，可追蹤。
• 靜态掃描無Block。
• UT通過率100%，覆寫率不低于主幹（重點關注UT覆寫率）。
• 代碼規範符合阿裡巴巴代碼規約。
• 業務關鍵點Review。
• MR要提供标準報備資訊，說明變更内容。

3）全鍊路CI标準化我們将ECS管控所有核心應用按照标準模式統一遷移至标準CI平台，大幅提升CI成功率，減少頻繁人工幹預造成的人力損耗。我們的方案如下：

• 标準化CI接入方式，标準化CI pipeline：
• prepare environment
• run unit tests
• run coverage analysis
• UT并行運作模式改造，提升UT運作效率。

4）全鍊路日常/隔離環境打通ECS部署環境複雜度極高，具體表現在部署架構複雜、部署工具多樣、依賴多（幾乎依賴了集團和阿裡雲所有的核心中間件及應用），在近百人并行研發的模式下 穩定可靠的全鍊路日常環境是研發效能與品質的基礎保障。全鍊路日常環境的改造無法一蹴而就，我們目前等建構路徑大緻如下：

• 全鍊路容器化，同時支援日常環境與隔離環境。 
• 第三方服務依賴Mock。
• 全鍊路測試環境打通。

5）預發環境使用規範預發環境與生産環境使用相同的資料庫，很容易出現預發測試影響生産服務穩定性的問題。在預發與生産無法資料隔離的情況下，我們的短期方案是通過标準化流程來提升預釋出代碼品質，盡可能減少或規避此類問題發生。

• 預發等同于生産，一定要在CI通過、日常基本驗證通過後才可以部署預發。
• DDL及大表查詢需要Review後才可以上預發，避免預發慢SQL導緻RDS穩定性，進而影響生産環境。

6）FVT釋出準入每天淩晨通過運作基于OpenAPI的功能性測試用例集，來驗證預釋出代碼的穩定性，是日常釋出準入最後一道防線，FVT 100%通過率極大保障了ECS核心管控每日釋出的成功率。7）無人值守釋出的探索目前釋出模式是釋出前一天晚上值班同學基于Develop分支拉取release釋出分支部署預發，釋出當天觀察FVT 成功率100%通過後通過Aone進行分批釋出，每批暫停觀察業務監控、預警、錯誤日志，在該模式下核心應用每日釋出大概占用0.5人/日。為了進一步提升人效，我們在自動化釋出流程上進行來一些探索：

• 流水線自動部署預發。
• 自動釋出準入校驗，通過判斷FVT成功率根據業務規則進行自動釋出。
• 無人值守釋出，理想的釋出模型，持續內建及相關釋出準入卡點全部通過後，自動化進行釋出。

 變更流程：通過規範變更流程、接入GOC強管控、變更白屏化及變更自動化來提升變更效率，同時保障變更品質。

1）管控規範流程定義通過限制現有的管控變更行為如熱更新、配置變更、DDL變更、限制配置變更、資料訂正、黑屏操作等實作所有變更可監控、可灰階、可復原。2）強管控接入通過對接集團強管控，來保障所有變更可追溯、可評審。（也期望可以通過平台對接強管控消除人肉提變更的繁瑣）3）變更白屏化整合ECS全鍊資源、管控、診斷、性能、運維、可視化及老嫦娥運維能力，打造統一、安全、高效的彈性計算統一運維平台。4）變更自動化自動化一切需要人工幹預的繁瑣事項。

2.4 穩定性營運體系

穩定性體系的建設中，基礎元件的容量性能優化、全鍊路穩定性體系建設、研發與變更流程的更新是其安身立命的基礎，而若想細水長流則離不開文化的建立以及持續的營運。下面是ECS SRE在穩定性營運體系上做的一些探索。

on-call輪值：on-call 在Google SRE的模式是 7*24小時輪值，負責生産系統的監控預警處理，緊急故障救火等。SRE本質仍然是軟體工程師，在ECS管控團隊，SRE每個同學在負責研發的同時也要處理線上預警、應對緊急故障以及參與到疑難雜症的排查等日常繁瑣的工作，為了保障SRE同學核心研發工作不被打斷，我們開始嘗試使用on-call輪值機制。1）on-call的職責

• 監控預警處理，第一時間處理生産環境的監控預警。
• 緊急故障救火，協同業務團隊處理生産環境穩定性問題。
• 穩定性問題排查，挖掘生産系統穩定性隐患，進入深水區進行挖掘。
• 全鍊路穩定性巡檢，生産系統核心業務SLO名額、錯誤日志、RDS健康度、慢SQL巡檢等。
• 參與故障複盤，此處的故障包括GOC故障與線上的穩定性問題。
• 經驗總結輸出，将on-call過程進行的故障診斷、問題處理、故障複盤進行總結。

2）新人如何快速加入on-call

• on-call 模版化，新人按圖索骥，目标明确。
• on-call 知識庫，新人紅寶書。
• 參與到輪值，實踐出真知。

 如何做故障複盤？

故障複盤機制針對産生故障或者影響内部穩定性的問題進行事後複盤，在ECS内部我們将影響生産穩定性的問題統一定義為“内部故障”，我們的觀點是 所有“内部故障” 都可能轉化為真實的故障，應該被給予足夠的重視度。為此我們内部與集團故障團隊也進行了多次的溝通合作，在内部故障的複盤與管理模式上進行了一些探索，下面将介紹故障複盤的一些基本理念及ECS管控在故障複盤上的一些實踐。故障複盤不是為了指責或者懲罰，而是為了發現故障表象背後深層次的技術與管理問題。

• 避免指責
• 對事不對人
• 獎勵做正确事的人
• 協作與知識共享

1）故障複盤的方式

• 責任人填寫故障複盤報告。
• SRE與相關幹系人參與評審（嚴重故障線下會議對齊）
• 故障幹系人按照ETA保障故障Action落地。

2）故障複盤文檔庫故障複盤總結是我們重要的知識資産，我們内部針對每一次故障複盤進行了深刻的總結，形成内部知識庫 《Learn From Failure》

 穩定性日常營運

穩定性本身是一個産品，需要日常持續的營運，在ECS管控主要模式有穩定性日報與雙周報。

• 穩定性日報，T+1 FBI報表，彙總全鍊路核心的名額資料如工作流、OpenAPI成功率、資源一緻性及資損，主要目的是為了及時發現系統隐患，并推動解決。
• 穩定性雙周報，雙周釋出，郵件模式，階段性彙總全鍊路穩定性問題（包括故障、内部穩定性問題）、核心問題公示、核心鍊路名額分析等。

三、我認知的SRE

前文概要性介紹了ECS SRE過去的一些實踐經驗，筆者自18年開始以SRE的角色參與到ECS穩定性治理與研發工作，下文将談一下自己這一年時間實踐SRE的一些感悟，一家之言，供參考。

3.1 關于SRE的幾個認知誤區

1） SRE 就是運維

SRE不止于運維，确實部分公司的SRE崗位工作内容與傳統的運維或者系統工程師相近，但 主流或者說未來的SRE是一個技能綜合性崗位，不僅需要運維能力，也需要軟體工程能力、技術架構能力、編碼能力、以及項目管理與團隊協作能力。

2） SRE 不需要懂業務

脫離了業務的架構是沒有靈魂的！不懂業務的SRE是不合格的SRE，SRE要參與的技術與運維架構的優化與未來規劃，同時也要協同業務團隊完成故障排查，疑難雜症的處理，這些工作沒有對業務的了解是無法很好的完成的（甚至無法完成）。

3.2 SRE能力模型

前面在“SRE=運維”的誤區解答中，簡單說明了SRE崗位對技術全面性的需求，下面筆者試着給出一個未來SRE能力模型，僅供參考。

1） 技術能力

a.研發能力

業務團隊的SRE首先要具備研發能力，以彈性計算SRE為例，我們會負責業務公共基礎元件比如工作流架構、幂等架構、緩存架構、資料清理架構等業務中間件的研發，研發能力是基礎。

b.運維能力

SRE是運維在DevOps發展程序中進化而來，無論是手動運維，抑或自動化運維，都需要SRE具備全面的運維能力。在彈性計算團隊，SRE負責了生産環境（網絡、伺服器、資料庫、中間件等）的穩定性保障工作，在日常on-call與故障應急工作中，運維能力必不可少。

c.架構能力

SRE不僅要關注業務目前的穩定性與性能，同時要以未來視角對業務進行容量與性能的規劃，這一切都建立在對業務系統架構熟知，并具備優秀架構設計能力的基礎之上。作為彈性計算的SRE，有一項重要工作就是對技術架構作為未來規劃，并提供可執行的Roadmap。

d.工程能力

這裡的工程能力主要指軟體工程的落地能力以及反向工程能力，首先SRE必須具備軟體工程的思維，具備大型軟體工程的可落地能力。另外，SRE核心的日常工作之一是穩定性問題以及疑難雜症的處理，反向工程能力在分布式系統規模化下的異常問題排查起到關鍵作用，尤其在處理陌生問題方面。

2) 軟技能

a.業務能力

不懂業務的SRE是不合格的SRE。尤其是業務團隊的SRE，隻有在熟悉業務技術架構、發展狀況、甚至是業務子產品細節的情況下，才能更好的開展諸如架構規劃、故障排查工作。以彈性計算SRE為例，必須要熟悉目前彈性計算的業務大圖以及後續的發展規劃，甚至是核心子產品的業務邏輯也必須做到心中有數。

b.溝通能力

作為一名工程師，毫無疑問溝通能力核心的軟技能之一。對于SRE來言，需要參與的大部分工作都是跨團隊甚至是跨BU的，溝通能力顯得尤為重要。在彈性計算團隊，作為SRE對内我們要與多個業務兄弟團隊緊密溝通協作，保障業務穩定性；對外，要與集團統一的研發平台、基礎運維、監控平台、中間件、網絡平台等多方團隊進行核合作，甚至會走向一線直接面對外部客戶，此時談溝通能力與溝通技巧再重要也不為過。

c.團隊協作

SRE要非常重視團隊協作，尤其在故障應急上，要協作多方團隊，緊密合作，降低故障MTTR。而在日常工作中，SRE要積極協同業務團隊以及外部依賴團隊，主導并推動穩定性相關工作的落地。

d.項目管理

SRE的工作技術複雜度和事務繁瑣度更高，加上日常的on-call和Firefighting，如何保障所有工作可以有條不紊的健康運作，從團隊角度看，項目管理非常重要；從個人角度看，時間管理極具價值。仍然以筆者所在的彈性計算SRE團隊為例，為了保障穩定性體系的快速落地，在過去一年我們進行了多個小型項目的攻堅，效果甚佳。目前我們正在以虛拟組織、長期項目的方式進行管理運作。

3)思維模式

前面提到了SRE要具備的兩項軟技能包括團隊協作、及工程能力，與此同時需要SRE人員從思維模式上進行轉變升華，比如逆向思維、合作意識、同理心、随機應變。

3.3 SRE核心理念

以下是筆者自己的從業心得，個人認為的SRE核心理念：

• 軟體工程的方法論解決生産系統穩定性問題。
• 自動化一切耗費團隊時間的事情。
• 穩定性就是産品。
• 團隊協作與賦能是關鍵。
• 沒有銀彈，尋求适合業務與團隊的解決方案。
• 優先做最重要的20%，解決80%的核心問題。

3.4 SRE精神

舍我其誰，SRE要有強烈的責任意識與使命感，作為穩定性的守護者，在團隊協作過程中，要做到無界擔當，一杆到底。

• 敢于挑戰，包含兩層含義，其一，SRE要堅守穩定性底線，對于任何與之相悖的行為敢于說不；其二，要以未來視角看待問題，要善于創新，勇于挑戰。
• 敬畏生産，SRE是生産環境的守護者，更是破壞者。組織賦予了SRE最大的生産變更權限（給予了SRE最大的自由），這其實更是一種責任，SRE要比任何人都心懷敬意，拒絕一切僥幸行為。
• 擁抱風險，無論如何專業與謹慎，故障一定會發生。作為SRE要有學習從風險中學習的精神，科學的正視風險，通過不斷的學習風險應對，來避免失敗。

寫在最後

在資訊爆炸的時代，技術的發展可謂日新月異，技術人不僅要保持對技術對熱情，也要具備思考力，沒有放之四海皆準的方案，隻有因地制宜、因時制宜的方案。無論如何，從現在開始行動，前路慢慢，上下求索。

原文釋出時間：2019-11-29

作者： 竹澗

本文來自雲栖社群合作夥伴“ 

阿裡技術

”，了解相關資訊可以關注“ 

”。