[[284090]]

前言

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要有學習從風險中學習的精神，科學的正視風險，通過不斷的學習風險應對，來避免失敗。

寫在最后

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

【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】 

戳這里，看該作者更多好文