[[284090]]

前言

SRE是什么?

SRE(Site Reliability Engineering)即網(wǎng)站可靠性工程，提及SRE很多人會聯(lián)想到運維工程師、系統(tǒng)工程師，其實不然，SRE本質(zhì)上仍然是軟件工程師，下面我們從SRE的發(fā)展歷史展開來進行介紹。

SRE最早在十多年前Google提出并應(yīng)用，近幾年逐步在國內(nèi)外TOP互聯(lián)網(wǎng)公司都開始廣泛應(yīng)用。據(jù)筆者了解業(yè)界SRE落地成功的權(quán)威有Google、Netflix等，前者締造了SRE，并奠定了其權(quán)威的地位，而后者將SRE的實踐做到了極優(yōu)，據(jù)官方曝露的信息，Netflix僅有的個位數(shù)的Core SRE支持了190個國家、數(shù)億用戶、數(shù)萬微服務(wù)實例業(yè)務(wù)規(guī)模的運維。

近幾年隨著DevOps的發(fā)展，SRE開始被大家熟知，國內(nèi)的一線互聯(lián)網(wǎng)公司如BAT、美團也都逐步從組織架構(gòu)、招聘上均有體現(xiàn)。以阿里為例，不同的BU均有設(shè)置SRE團隊，然而在不同的部門，SRE的職責劃分卻不盡相同，那么SRE究竟在做什么?

SRE的職責

SRE主要負責Google所有核心業(yè)務(wù)系統(tǒng)的可用性、性能、容量相關(guān)的事情，根據(jù)《Site Reliability Engineering 》一書提及的內(nèi)容，筆者做簡單匯總，Google SRE的工作主要包括但不限于如下：

• 基礎(chǔ)設(shè)施容量規(guī)劃
• 生產(chǎn)系統(tǒng)的監(jiān)控
• 生產(chǎn)系統(tǒng)的負載均衡
• 發(fā)布與變更工程管理
• on-call(輪值) 與 Firefighting(緊急故障救火)
• 與業(yè)務(wù)團隊協(xié)作，共同完成疑難問題的處理
• ...

而在國內(nèi)，非常多的SRE部門與傳統(tǒng)運維部門職責類似，本質(zhì)來說負責的是互聯(lián)網(wǎng)服務(wù)背后的技術(shù)運維工作。區(qū)別于傳統(tǒng)的運維SRE，如何在業(yè)務(wù)研發(fā)團隊落地SRE，我們做了一年多的探索與實踐，筆者認為業(yè)務(wù)團隊SRE的核心是：以軟件工程的方法論重新定義研發(fā)運維，驅(qū)動并賦能業(yè)務(wù)演進。下文將重點介紹彈性計算落地SRE的一些實踐及背后的思考。 

一、為何要成立SRE?

面臨的挑戰(zhàn)

ECS作為阿里云最核心的云產(chǎn)品，對內(nèi)承擔了集團上云、云產(chǎn)品On ECS的重任，是阿里云經(jīng)濟體的基礎(chǔ)設(shè)施;對外作為亞洲最大的云計算廠商，服務(wù)著遍布全球的大中小客戶(包括各種專有域、專有云)，而ECS管控作為核心調(diào)度大腦，重要性不言而喻。

隨著集團上云、云產(chǎn)品On ECS的進程加速，ECS的OpenAPI調(diào)用量達到了數(shù)億/日，ECS峰值創(chuàng)建量達到了 百萬/日，ECS管控調(diào)度系統(tǒng)在容量規(guī)模、極致性能、高可用性等方面，面臨著一系列挑戰(zhàn)：

• 數(shù)據(jù)庫瓶頸，頂配數(shù)據(jù)庫空間仍然無法支撐業(yè)務(wù)半年發(fā)展。
• 慢SQL數(shù)量爆發(fā)式增長，應(yīng)用穩(wěn)定性岌岌可危。
• 全鏈路預(yù)警信息最多每天200+，系統(tǒng)隱患逐步暴雷。
• 工作流框架使用面臨瓶頸，無法支撐業(yè)務(wù)三個月的業(yè)務(wù)體量，人工運維風險極高。
• 人工運維頻率高，研發(fā)幸福感下降。
• 長尾請求嚴重影響服務(wù)質(zhì)量，5XX錯誤持續(xù)走高，影響客戶體驗。
• 不一致性資源長期無法收斂，資損無法解決。
• ...

SRE應(yīng)運而生

如何在保障業(yè)務(wù)高速發(fā)展的同時，構(gòu)建系統(tǒng)高可用的穩(wěn)定性體系，同時在性能與容量上支撐業(yè)務(wù)未來3-5年的發(fā)展是團隊面臨的重大挑戰(zhàn)。在SRE團隊成立之前ECS管控團隊是按照業(yè)務(wù)域進行的團隊劃分如實例、存儲、鏡像、網(wǎng)絡(luò)、體驗、ESS、ROS等。而在上述組織架構(gòu)下研發(fā)團隊可以在垂直領(lǐng)域做到精深，但團隊整體會缺少頂層的視角，很難從局部看到整體，進而看到全局。

康維定律指出 “設(shè)計系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計的組織的溝通結(jié)構(gòu)”，簡單來說可以理解為：組織架構(gòu)=系統(tǒng)架構(gòu)，當我們系統(tǒng)穩(wěn)定性體系需要跨業(yè)務(wù)團隊的頂層視角來構(gòu)建的時候，最好的保障就是組織架構(gòu)的落地，ECS SRE團隊應(yīng)運而生。

二、SRE做了什么?

前文簡單介紹了Google SRE團隊的職責包括容量規(guī)劃、分布式系統(tǒng)監(jiān)控、負載均衡、服務(wù)容錯、on-call、故障應(yīng)急、業(yè)務(wù)協(xié)同支持等，同時也簡單描述了國內(nèi)偏系統(tǒng)運維的SRE團隊。而ECS SRE落地的探索過程中，吸取業(yè)界優(yōu)秀經(jīng)驗的同時也結(jié)合ECS團隊的業(yè)務(wù)及團隊特色形成了一套獨有的方法論及實踐體系。對于此，筆者的觀點是：沒有放之四海而皆準的標準，需要我們不斷探索的是與“當下、業(yè)務(wù)、團隊“契合的方案，古語謂之“天時、地利、人和”。

下文將整體上介紹ECS SRE團隊在穩(wěn)定性體系建設(shè)上所做的一些事情。

< ECS SRE體系大圖 >

 

2.1 容量與性能

前文提到ECS的OpenAPI調(diào)用量達到數(shù)億/日，ECS創(chuàng)建峰值達到了百萬/日，在此背景下，管控服務(wù)的容量與性能面臨嚴峻問題，比如數(shù)據(jù)庫容量面臨枯竭、服務(wù)長尾請求頻現(xiàn)等。隨著集團上云、云產(chǎn)品On ECS的演進需求，以及整個云原生大環(huán)境的高歌猛進，未雨綢繆已然變成了迫在眉睫。

以ECS管控核心的工作流引擎為例，在我們業(yè)務(wù)體量快速增長的背景下，工作流任務(wù)單表一個月的數(shù)據(jù)就達到了3T+，這意味即使是頂配數(shù)據(jù)庫也無法支撐業(yè)務(wù)數(shù)月的發(fā)展。除了工作流，核心的訂單、訂購、資源表均面臨相同問題，如何在業(yè)務(wù)高速發(fā)展的同時，保障業(yè)務(wù)延續(xù)性是我們面臨的頭號問題。

為了解決當下的容量與性能問題，同時面向未來擴展，我們針對ECS自研的基礎(chǔ)組建包括工作流引擎、冪等框架、緩存框架、數(shù)據(jù)清理框架等進行了升級改造，為了后續(xù)可以賦能給其它云產(chǎn)品或者團隊使用，所有的基礎(chǔ)組件全部通過二方包標準輸出。

 

• 基礎(chǔ)組件升級：通過對ECS管控自研的業(yè)務(wù)基礎(chǔ)組件進行架構(gòu)升級來應(yīng)對業(yè)務(wù)未來的規(guī)?；l(fā)展。
  • 工作流引擎：14年ECS團隊自研的輕量工作流引擎，與AWS SWF類似， 18年改造后支持數(shù)億級工作流創(chuàng)建，我們當前還在做一些框架可用性、容量與性能相關(guān)的優(yōu)化。
  • 輕量冪等框架：通過注解自定義業(yè)務(wù)冪等規(guī)則，通過輕量持久化方式支持業(yè)務(wù)冪等。
  • 數(shù)據(jù)異步清理框架：通過注解配置業(yè)務(wù)數(shù)據(jù)清理策略。
  • 緩存框架：通過注解支持業(yè)務(wù)定義緩存命中與失效規(guī)則，并支持批量。
• 性能優(yōu)化：多維度的性能調(diào)優(yōu)策略來提升管控整體服務(wù)的性能指標。
  • JVM調(diào)優(yōu)：通過不斷調(diào)整優(yōu)化JVM參數(shù)來減少其FGC次數(shù)及STW時間，縮短服務(wù)不可用時間，提升用戶服務(wù)體驗 。
  • 數(shù)據(jù)緩存：核心鏈路多級緩存，減少數(shù)據(jù)庫IO，提升服務(wù)性能。
  • SQL性能調(diào)優(yōu)：通過優(yōu)化SQL執(zhí)行效率提升業(yè)務(wù)性能。
  • 核心鏈路RT優(yōu)化：業(yè)務(wù)優(yōu)化保障ECS核心創(chuàng)建、啟動鏈路性能。
  • API批量服務(wù)能力：批量的服務(wù)能力，提升整體服務(wù)性能。

2.2 全鏈路穩(wěn)定性治理

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

1)數(shù)據(jù)庫穩(wěn)定性治理

數(shù)據(jù)庫是應(yīng)用的核心命脈，對于ECS管控來說，所有的核心業(yè)務(wù)全部跑在RDS之上，如果數(shù)據(jù)庫發(fā)生故障，對應(yīng)用的損害無論從管控面或者數(shù)據(jù)面都是致命的。所以，SRE做的第一件事情就是守住核心命脈，對數(shù)據(jù)庫穩(wěn)定性進行全面的治理。

首先，我們先來看一下ECS管控在規(guī)?；瘶I(yè)務(wù)下，數(shù)據(jù)庫面臨的問題：

• 空間增長過快，無法支撐業(yè)務(wù)近期發(fā)展需求。
• 慢SQL頻發(fā)，嚴重影響應(yīng)用穩(wěn)定性。
• 數(shù)據(jù)庫變更故障率高，DDL大表變更引起的故障占比高。
• RDS性能指標異常，數(shù)據(jù)庫各種性能指標異常。
• RDS報警配置混亂，報警信息存在遺漏，誤報的情況。

對于數(shù)據(jù)庫的問題我們的策略是數(shù)據(jù)庫+業(yè)務(wù)兩手抓，單純優(yōu)化數(shù)據(jù)庫或者業(yè)務(wù)調(diào)優(yōu)效果都不是最佳的。比如典型的數(shù)據(jù)庫大表問題，占用空間大，查詢慢，如果單純從數(shù)據(jù)庫層面進行空間擴容，索引優(yōu)化可以解決短期問題，當業(yè)務(wù)規(guī)模足夠大的時候，數(shù)據(jù)庫優(yōu)化一定會面臨瓶頸，這個時候需要業(yè)務(wù)調(diào)優(yōu)雙管齊下。

下面簡單介紹一下優(yōu)化思路：

• 數(shù)據(jù)庫占用空間大問題，兩個思路，降低當前數(shù)據(jù)庫占用空間，同時控制數(shù)據(jù)空間增長。我們通過歸檔歷史數(shù)據(jù)釋放數(shù)據(jù)空洞來達到數(shù)據(jù)頁復(fù)用，從而控制數(shù)據(jù)庫磁盤空間增長;但是delete數(shù)據(jù)并不會釋放表空間，為了釋放已經(jīng)占用大量空間的大表，我們業(yè)務(wù)上進行了改造，通過生產(chǎn)中間表輪轉(zhuǎn)來解決。
• 慢SQL頻發(fā)問題，數(shù)據(jù)庫優(yōu)化與業(yè)務(wù)改造兩手抓。數(shù)據(jù)庫層面通過索引優(yōu)化來提高查詢效率，同時減少無效數(shù)據(jù)來減少掃描行數(shù);應(yīng)用層面通過緩存降低數(shù)據(jù)庫讀次數(shù)、優(yōu)化業(yè)務(wù)代碼等方式減少與規(guī)避慢SQL。
• 數(shù)據(jù)庫變更故障率高問題，管控流程增強，增加Review流程。DDL變更類型多，由于開發(fā)人員對數(shù)據(jù)庫的專業(yè)性與敏感度不夠?qū)е聰?shù)據(jù)庫引發(fā)變更增多，對于這類情況，我們針對DDL變更增加了 檢查項列表與評審流程，控制數(shù)據(jù)庫變更風險。
• 數(shù)據(jù)庫性能指標與配置問題，以項目方式推進數(shù)據(jù)庫健康度提升，統(tǒng)一管控數(shù)據(jù)庫預(yù)警配置。
• 慢SQL限流與快恢的探索。慢SQL嚴重情況會導(dǎo)致RDS整體不可用，當前我們正在探索如何通過自動/半自動化的方式限流慢SQL來保障數(shù)據(jù)庫穩(wěn)定性。

下圖是ECS在數(shù)據(jù)庫穩(wěn)定性治理上的幾個探索。

2)監(jiān)控預(yù)警治理

預(yù)警對于問題與故障的發(fā)現(xiàn)至關(guān)重要，尤其在規(guī)?；姆植际较到y(tǒng)中，精準而及時的監(jiān)控可以幫助研發(fā)人員第一時間發(fā)現(xiàn)問題，減少甚至避免故障的發(fā)生。而無效、冗余、不精確的低質(zhì)量報警不僅耗時耗力，影響SRE on-call人員幸福感，同時也嚴重影響故障診斷。ECS管控預(yù)警質(zhì)量不高的因素主要包括：

• 數(shù)量多，平均每天100+，峰值200+，信噪比低。
• 渠道多，大量重復(fù)報警，干擾大。
• 配置異常，存在預(yù)警丟失情況，風險高。
• 損耗人力，預(yù)警反復(fù)出現(xiàn)導(dǎo)致處理預(yù)警需要投入大量人力，人效低。
• 黑屏操作風險高，大量黑屏操作增加生產(chǎn)運維風險，風險高。

針對上述情況，我們的策略是針對預(yù)警進行體系化整理，實現(xiàn)預(yù)警的真實性、準確性、精確性、高質(zhì)量。我們的打法大概分了以下幾個步驟：

• 刪除無效報警，清理監(jiān)控平臺歷史無效的預(yù)警，提高預(yù)警真實性。
• 優(yōu)化預(yù)警配置
  • 統(tǒng)一預(yù)警接收人，保障預(yù)警只投遞到正確的接收人。
  • 優(yōu)化預(yù)警等級，設(shè)置合理的預(yù)警級別。
  • 劃分預(yù)警渠道，按照預(yù)類型與嚴重程度進行渠道劃分，如致命預(yù)警電話預(yù)警、嚴重預(yù)警短信預(yù)警、普通預(yù)警釘釘預(yù)警等。
• 自動化一切人肉干預(yù)的預(yù)警，反復(fù)需要人工參與解決的報警通過自動化方式來解決。比如大量業(yè)務(wù)日志導(dǎo)致磁盤存儲空間不足，可以通過優(yōu)化log rolling策略實現(xiàn)自動化。

3)故障診斷

關(guān)于故障恢復(fù)我們有一個1-5-10的理想模型，意思是1分鐘發(fā)現(xiàn)問題，5分鐘定位問題，10分鐘恢復(fù)問題。1分鐘發(fā)現(xiàn)問題依賴于前文提到的高質(zhì)量的監(jiān)控預(yù)警體系，5分鐘定位問題則依賴于系統(tǒng)的故障診斷能力，如何基于已有的預(yù)警信息實現(xiàn)故障快速診斷面臨一系列挑戰(zhàn)：

• 系統(tǒng)調(diào)用鏈路長，從控制臺/OpenAPI到底層虛擬化/存儲，RPC鏈路調(diào)用鏈路大概有10層以上，依賴系統(tǒng)30+，業(yè)務(wù)串聯(lián)難度大。
• 系統(tǒng)間依賴復(fù)雜，ECS管控自身有多層架構(gòu)，同時與集團訂單、計費等系統(tǒng)相互依賴。
• 影響面分析困難，無法量化故障影響面。

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

• 全鏈路Trace模型建立，通過TraceID打通調(diào)用調(diào)用鏈路，實現(xiàn)業(yè)務(wù)串聯(lián)。
• 核心應(yīng)用場景故障診斷模型，針對當前業(yè)務(wù)核心鏈路以及以往故障的高頻場景進行診斷模型訓(xùn)練，由點到面的突破。
• 故障影響面模型，自動分析故障影響用戶、資源、資金，方便故障快速恢復(fù)及故障善后。

4)全鏈路SLO

沒有100%可靠的系統(tǒng)，對于終端用戶而言99.999%和100%的可用性沒有本質(zhì)區(qū)別。我們的目標是通過持續(xù)迭代優(yōu)化保障用戶99.999%的可用性服務(wù)體驗，而現(xiàn)狀是終端用戶發(fā)起的行為會經(jīng)過一系列中間系統(tǒng)，任意一個系統(tǒng)可靠性出現(xiàn)問題都會影響客戶體驗。而全鏈路各個節(jié)點的穩(wěn)定性如何衡量是我們面臨的問題，對此我們開始了全鏈路SLO體系建設(shè)，主要策略如下：

• 識別上下游依賴業(yè)務(wù)方，簽訂SLO協(xié)議。
• 建設(shè)全鏈路SLO可視化能力。
• 推進上下游依賴促成SLO達標。

5)資源一致性治理

根據(jù)分布式系統(tǒng)CAP原理，一致性(Consistency)、可用性(Availability)、分區(qū)容錯性(Partition tolerance)無法同時滿足。ECS管控作為規(guī)?；姆植际较到y(tǒng)面臨同樣的問題：資源一致性問題，具體表現(xiàn)在ECS、磁盤、帶寬等在ECS管控、訂單、計量等多個系統(tǒng)存在數(shù)據(jù)不一致問題。

分布式系統(tǒng)為了保障系統(tǒng)可用性，通常會犧牲部分數(shù)據(jù)實時一致性，轉(zhuǎn)而通過最終一致性來解決。

針對ECS的技術(shù)架構(gòu)及業(yè)務(wù)特性，我們對保障資源一致性的策略如下：

• 數(shù)據(jù)驅(qū)動，首先建立全鏈路可視化對賬體系，所有不一致資源全部數(shù)據(jù)化。
• 財(錢)、產(chǎn)(資源)兩個抓手，從資源和資損兩個角度來度量一致性問題。
• 離線(T+1)與實時(一小時對賬)兩種方式，及時止損。

2.3 SRE流程體系建設(shè)

ECS在 近百人并行研發(fā)& 核心應(yīng)用每日發(fā)布&全年數(shù)千余次發(fā)布 的背景下，可以做到故障率每年下降的關(guān)鍵因素之一，就是有一套相對完善的研發(fā)與變更流程保障。下文將簡單介紹ECS SRE在研發(fā)與變更流程體系上所做的的一些探索。

 

• 研發(fā)流程：整個軟件生命周期研發(fā)流程規(guī)范升級。

1)設(shè)計流程與規(guī)范

從軟件工程角度來看，越早引入問題帶來的人力消耗和經(jīng)濟損失就越小。沒有被良好設(shè)計的系統(tǒng)后續(xù)在維護階段投入的成本要遠高于前期設(shè)計的投入。為了把控設(shè)計質(zhì)量我們在設(shè)計流程與規(guī)范上做了如下探索：

• 加強前期設(shè)計，統(tǒng)一設(shè)計模版。(完整的設(shè)計應(yīng)該包括架構(gòu)設(shè)計、詳細設(shè)計、測試用例、橫向設(shè)計、監(jiān)控預(yù)警、灰度方案、發(fā)布方案等)
• 線上(釘釘直播)& 線下并行模式進行設(shè)計評審。

2)CodeReview升級

之前ECS的CodeReview主要在GitLab平臺，其主要問題是gitlab與阿里內(nèi)部持續(xù)集成相關(guān)組件集成不夠穩(wěn)定、另外無法設(shè)置準入卡點，Aone CodeReview平臺很好的解決了與Aone實驗室的集成問題，并且提供了代碼合入的卡點配置功能，另外我們定義了一套ECS管控的CodeReview流程，如下所示：

• 統(tǒng)一研發(fā)規(guī)范，包括(開發(fā)環(huán)境規(guī)范、編碼規(guī)范on 集團開發(fā)規(guī)約 等)。
• CodeReviw checklist
  • git commit 關(guān)聯(lián)issues，做到代碼與需求/任務(wù)/缺陷關(guān)聯(lián)，可追蹤。
  • 靜態(tài)掃描無Block。
  • UT通過率100%，覆蓋率不低于主干(重點關(guān)注UT覆蓋率)。
  • 代碼規(guī)范符合阿里巴巴代碼規(guī)約。
  • 業(yè)務(wù)關(guān)鍵點Review。
  • MR要提供標準報備信息，說明變更內(nèi)容。

3)全鏈路CI標準化

我們將ECS管控所有核心應(yīng)用按照標準模式統(tǒng)一遷移至標準CI平臺，大幅提升CI成功率，減少頻繁人工干預(yù)造成的人力損耗。我們的方案如下：

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

4)全鏈路日常/隔離環(huán)境打通

ECS部署環(huán)境復(fù)雜度極高，具體表現(xiàn)在部署架構(gòu)復(fù)雜、部署工具多樣、依賴多(幾乎依賴了集團和阿里云所有的核心中間件及應(yīng)用)，在近百人并行研發(fā)的模式下 穩(wěn)定可靠的全鏈路日常環(huán)境是研發(fā)效能與質(zhì)量的基礎(chǔ)保障。

全鏈路日常環(huán)境的改造無法一蹴而就，我們當前等構(gòu)建路徑大致如下：

• 全鏈路容器化，同時支持日常環(huán)境與隔離環(huán)境。
• 第三方服務(wù)依賴Mock。
• 全鏈路測試環(huán)境打通。

5)預(yù)發(fā)環(huán)境使用規(guī)范

預(yù)發(fā)環(huán)境與生產(chǎn)環(huán)境使用相同的數(shù)據(jù)庫，很容易出現(xiàn)預(yù)發(fā)測試影響生產(chǎn)服務(wù)穩(wěn)定性的問題。在預(yù)發(fā)與生產(chǎn)無法數(shù)據(jù)隔離的情況下，我們的短期方案是通過標準化流程來提升預(yù)發(fā)布代碼質(zhì)量，盡可能減少或規(guī)避此類問題發(fā)生。

• 預(yù)發(fā)等同于生產(chǎn)，一定要在CI通過、日?；掘炞C通過后才可以部署預(yù)發(fā)。
• DDL及大表查詢需要Review后才可以上預(yù)發(fā)，避免預(yù)發(fā)慢SQL導(dǎo)致RDS穩(wěn)定性，進而影響生產(chǎn)環(huán)境。

6)FVT發(fā)布準入

每天凌晨通過運行基于OpenAPI的功能性測試用例集，來驗證預(yù)發(fā)布代碼的穩(wěn)定性，是日常發(fā)布準入最后一道防線，F(xiàn)VT 100%通過率極大保障了ECS核心管控每日發(fā)布的成功率。

7)無人值守發(fā)布的探索

當前發(fā)布模式是發(fā)布前一天晚上值班同學(xué)基于Develop分支拉取release發(fā)布分支部署預(yù)發(fā)，發(fā)布當天觀察FVT 成功率100%通過后通過Aone進行分批發(fā)布，每批暫停觀察業(yè)務(wù)監(jiān)控、預(yù)警、錯誤日志，在該模式下核心應(yīng)用每日發(fā)布大概占用0.5人/日。為了進一步提升人效，我們在自動化發(fā)布流程上進行來一些探索：

• 流水線自動部署預(yù)發(fā)。
• 自動發(fā)布準入校驗，通過判斷FVT成功率根據(jù)業(yè)務(wù)規(guī)則進行自動發(fā)布。
• 無人值守發(fā)布，理想的發(fā)布模型，持續(xù)集成及相關(guān)發(fā)布準入卡點全部通過后，自動化進行發(fā)布。 

變更流程：通過規(guī)范變更流程、接入GOC強管控、變更白屏化及變更自動化來提升變更效率，同時保障變更質(zhì)量。

1)管控規(guī)范流程定義

通過約束現(xiàn)有的管控變更行為如熱升級、配置變更、DDL變更、約束配置變更、數(shù)據(jù)訂正、黑屏操作等實現(xiàn)所有變更可監(jiān)控、可灰度、可回滾。

2)強管控接入

通過對接集團強管控，來保障所有變更可追溯、可評審。(也期望可以通過平臺對接強管控消除人肉提變更的繁瑣)

3)變更白屏化

整合ECS全鏈資源、管控、診斷、性能、運維、可視化及老嫦娥運維能力，打造統(tǒng)一、安全、高效的彈性計算統(tǒng)一運維平臺。

4)變更自動化

自動化一切需要人工干預(yù)的繁瑣事項。

2.4 穩(wěn)定性運營體系

穩(wěn)定性體系的建設(shè)中，基礎(chǔ)組件的容量性能優(yōu)化、全鏈路穩(wěn)定性體系建設(shè)、研發(fā)與變更流程的升級是其安身立命的基礎(chǔ)，而若想細水長流則離不開文化的建立以及持續(xù)的運營。下面是ECS SRE在穩(wěn)定性運營體系上做的一些探索。

 

• on-call輪值：on-call 在Google SRE的模式是 7*24小時輪值，負責生產(chǎn)系統(tǒng)的監(jiān)控預(yù)警處理，緊急故障救火等。

SRE本質(zhì)仍然是軟件工程師，在ECS管控團隊，SRE每個同學(xué)在負責研發(fā)的同時也要處理線上預(yù)警、應(yīng)對緊急故障以及參與到疑難雜癥的排查等日常繁瑣的工作，為了保障SRE同學(xué)核心研發(fā)工作不被打斷，我們開始嘗試使用on-call輪值機制。

1)on-call的職責

• 監(jiān)控預(yù)警處理，第一時間處理生產(chǎn)環(huán)境的監(jiān)控預(yù)警。
• 緊急故障救火，協(xié)同業(yè)務(wù)團隊處理生產(chǎn)環(huán)境穩(wěn)定性問題。
• 穩(wěn)定性問題排查，挖掘生產(chǎn)系統(tǒng)穩(wěn)定性隱患，進入深水區(qū)進行挖掘。
• 全鏈路穩(wěn)定性巡檢，生產(chǎn)系統(tǒng)核心業(yè)務(wù)SLO指標、錯誤日志、RDS健康度、慢SQL巡檢等。
• 參與故障復(fù)盤，此處的故障包括GOC故障與線上的穩(wěn)定性問題。
• 經(jīng)驗總結(jié)輸出，將on-call過程進行的故障診斷、問題處理、故障復(fù)盤進行總結(jié)。

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

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

如何做故障復(fù)盤?

故障復(fù)盤機制針對產(chǎn)生故障或者影響內(nèi)部穩(wěn)定性的問題進行事后復(fù)盤，在ECS內(nèi)部我們將影響生產(chǎn)穩(wěn)定性的問題統(tǒng)一定義為“內(nèi)部故障”，我們的觀點是 所有“內(nèi)部故障” 都可能轉(zhuǎn)化為真實的故障，應(yīng)該被給予足夠的重視度。為此我們內(nèi)部與集團故障團隊也進行了多次的溝通合作，在內(nèi)部故障的復(fù)盤與管理模式上進行了一些探索，下面將介紹故障復(fù)盤的一些基本理念及ECS管控在故障復(fù)盤上的一些實踐。

故障復(fù)盤不是為了指責或者懲罰，而是為了發(fā)現(xiàn)故障表象背后深層次的技術(shù)與管理問題。

• 避免指責
• 對事不對人
• 獎勵做正確事的人
• 協(xié)作與知識共享

1)故障復(fù)盤的方式

• 責任人填寫故障復(fù)盤報告。
• SRE與相關(guān)干系人參與評審(嚴重故障線下會議對齊)
• 故障干系人按照ETA保障故障Action落地。

2)故障復(fù)盤文檔庫

故障復(fù)盤總結(jié)是我們重要的知識資產(chǎn)，我們內(nèi)部針對每一次故障復(fù)盤進行了深刻的總結(jié)，形成內(nèi)部知識庫 《Learn From Failure》

• 穩(wěn)定性日常運營

穩(wěn)定性本身是一個產(chǎn)品，需要日常持續(xù)的運營，在ECS管控主要模式有穩(wěn)定性日報與雙周報。

• 穩(wěn)定性日報，T+1 FBI報表，匯總?cè)溌泛诵牡闹笜藬?shù)據(jù)如工作流、OpenAPI成功率、資源一致性及資損，主要目的是為了及時發(fā)現(xiàn)系統(tǒng)隱患，并推動解決。
• 穩(wěn)定性雙周報，雙周發(fā)布，郵件模式，階段性匯總?cè)溌贩€(wěn)定性問題(包括故障、內(nèi)部穩(wěn)定性問題)、核心問題公示、核心鏈路指標分析等。 

三、我認知的SRE

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

3.1 關(guān)于SRE的幾個認知誤區(qū)

1) SRE 就是運維

SRE不止于運維，確實部分公司的SRE崗位工作內(nèi)容與傳統(tǒng)的運維或者系統(tǒng)工程師相近，但 主流或者說未來的SRE是一個技能綜合性崗位，不僅需要運維能力，也需要軟件工程能力、技術(shù)架構(gòu)能力、編碼能力、以及項目管理與團隊協(xié)作能力。

2) SRE 不需要懂業(yè)務(wù)

脫離了業(yè)務(wù)的架構(gòu)是沒有靈魂的!不懂業(yè)務(wù)的SRE是不合格的SRE，SRE要參與的技術(shù)與運維架構(gòu)的優(yōu)化與未來規(guī)劃，同時也要協(xié)同業(yè)務(wù)團隊完成故障排查，疑難雜癥的處理，這些工作沒有對業(yè)務(wù)的理解是無法很好的完成的(甚至無法完成)。

3.2 SRE能力模型

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

 

1) 技術(shù)能力

a.研發(fā)能力

業(yè)務(wù)團隊的SRE首先要具備研發(fā)能力，以彈性計算SRE為例，我們會負責業(yè)務(wù)公共基礎(chǔ)組件比如工作流框架、冪等框架、緩存框架、數(shù)據(jù)清理框架等業(yè)務(wù)中間件的研發(fā)，研發(fā)能力是基礎(chǔ)。

b.運維能力

SRE是運維在DevOps發(fā)展進程中進化而來，無論是手動運維，抑或自動化運維，都需要SRE具備全面的運維能力。在彈性計算團隊，SRE負責了生產(chǎn)環(huán)境(網(wǎng)絡(luò)、服務(wù)器、數(shù)據(jù)庫、中間件等)的穩(wěn)定性保障工作，在日常on-call與故障應(yīng)急工作中，運維能力必不可少。

c.架構(gòu)能力

SRE不僅要關(guān)注業(yè)務(wù)當前的穩(wěn)定性與性能，同時要以未來視角對業(yè)務(wù)進行容量與性能的規(guī)劃，這一切都建立在對業(yè)務(wù)系統(tǒng)架構(gòu)熟知，并具備優(yōu)秀架構(gòu)設(shè)計能力的基礎(chǔ)之上。作為彈性計算的SRE，有一項重要工作就是對技術(shù)架構(gòu)作為未來規(guī)劃，并提供可執(zhí)行的Roadmap。

d.工程能力

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

2) 軟技能

a.業(yè)務(wù)能力

不懂業(yè)務(wù)的SRE是不合格的SRE。尤其是業(yè)務(wù)團隊的SRE，只有在熟悉業(yè)務(wù)技術(shù)架構(gòu)、發(fā)展狀況、甚至是業(yè)務(wù)模塊細節(jié)的情況下，才能更好的開展諸如架構(gòu)規(guī)劃、故障排查工作。以彈性計算SRE為例，必須要熟悉當前彈性計算的業(yè)務(wù)大圖以及后續(xù)的發(fā)展規(guī)劃，甚至是核心模塊的業(yè)務(wù)邏輯也必須做到心中有數(shù)。

b.溝通能力

作為一名工程師，毫無疑問溝通能力核心的軟技能之一。對于SRE來言，需要參與的大部分工作都是跨團隊甚至是跨BU的，溝通能力顯得尤為重要。在彈性計算團隊，作為SRE對內(nèi)我們要與多個業(yè)務(wù)兄弟團隊緊密溝通協(xié)作，保障業(yè)務(wù)穩(wěn)定性;對外，要與集團統(tǒng)一的研發(fā)平臺、基礎(chǔ)運維、監(jiān)控平臺、中間件、網(wǎng)絡(luò)平臺等多方團隊進行核合作，甚至?xí)呦蛞痪€直接面對外部客戶，此時談溝通能力與溝通技巧再重要也不為過。

c.團隊協(xié)作

SRE要非常重視團隊協(xié)作，尤其在故障應(yīng)急上，要協(xié)作多方團隊，緊密合作，降低故障MTTR。而在日常工作中，SRE要積極協(xié)同業(yè)務(wù)團隊以及外部依賴團隊，主導(dǎo)并推動穩(wěn)定性相關(guān)工作的落地。

d.項目管理

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

3)思維模式

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

3.3 SRE核心理念

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

• 軟件工程的方法論解決生產(chǎn)系統(tǒng)穩(wěn)定性問題。
• 自動化一切耗費團隊時間的事情。
• 穩(wěn)定性就是產(chǎn)品。
• 團隊協(xié)作與賦能是關(guān)鍵。
• 沒有銀彈，尋求適合業(yè)務(wù)與團隊的解決方案。
• 優(yōu)先做最重要的20%，解決80%的核心問題。

3.4 SRE精神

 

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

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

寫在最后

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

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】 

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