[[284090]]

前言

SRE是什么?

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

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

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

SRE的職責(zé)

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

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

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

一、為何要成立SRE?

面臨的挑戰(zhàn)

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

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

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

SRE應(yīng)運(yùn)而生

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

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

二、SRE做了什么?

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

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

< ECS SRE體系大圖 >

2.1 容量與性能

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

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

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

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

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

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

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

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

首先，我們先來(lái)看一下ECS管控在規(guī)模化業(yè)務(wù)下，數(shù)據(jù)庫(kù)面臨的問(wèn)題：

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

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

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

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

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

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

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

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

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

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

3)故障診斷

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

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

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

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

4)全鏈路SLO

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

• 識(shí)別上下游依賴(lài)業(yè)務(wù)方，簽訂SLO協(xié)議。
• 建設(shè)全鏈路SLO可視化能力。
• 推進(jìn)上下游依賴(lài)促成SLO達(dá)標(biāo)。

5)資源一致性治理

根據(jù)分布式系統(tǒng)CAP原理，一致性(Consistency)、可用性(Availability)、分區(qū)容錯(cuò)性(Partition tolerance)無(wú)法同時(shí)滿(mǎn)足。ECS管控作為規(guī)模化的分布式系統(tǒng)面臨同樣的問(wèn)題：資源一致性問(wèn)題，具體表現(xiàn)在ECS、磁盤(pán)、帶寬等在ECS管控、訂單、計(jì)量等多個(gè)系統(tǒng)存在數(shù)據(jù)不一致問(wèn)題。

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

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

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

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

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

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

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

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

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

2)CodeReview升級(jí)

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

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

3)全鏈路CI標(biāo)準(zhǔn)化

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

• 標(biāo)準(zhǔn)化CI接入方式，標(biāo)準(zhǔn)化CI pipeline：
  • prepare environment
  • run unit tests
  • run coverage analysis
  • ...
• UT并行運(yùn)行模式改造，提升UT運(yùn)行效率。 

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

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

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

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

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

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

• 預(yù)發(fā)等同于生產(chǎn)，一定要在CI通過(guò)、日常基本驗(yàn)證通過(guò)后才可以部署預(yù)發(fā)。
• DDL及大表查詢(xún)需要Review后才可以上預(yù)發(fā)，避免預(yù)發(fā)慢SQL導(dǎo)致RDS穩(wěn)定性，進(jìn)而影響生產(chǎn)環(huán)境。

6)FVT發(fā)布準(zhǔn)入

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

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

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

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

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

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

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

2)強(qiáng)管控接入

通過(guò)對(duì)接集團(tuán)強(qiáng)管控，來(lái)保障所有變更可追溯、可評(píng)審。(也期望可以通過(guò)平臺(tái)對(duì)接強(qiáng)管控消除人肉提變更的繁瑣)

3)變更白屏化

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

4)變更自動(dòng)化

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

2.4 穩(wěn)定性運(yùn)營(yíng)體系

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

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

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

1)on-call的職責(zé)

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

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

• on-call 模版化，新人按圖索驥，目標(biāo)明確。
• on-call 知識(shí)庫(kù)，新人紅寶書(shū)。
• 參與到輪值，實(shí)踐出真知。 

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

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

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

• 避免指責(zé)
• 對(duì)事不對(duì)人
• 獎(jiǎng)勵(lì)做正確事的人
• 協(xié)作與知識(shí)共享

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

• 責(zé)任人填寫(xiě)故障復(fù)盤(pán)報(bào)告。
• SRE與相關(guān)干系人參與評(píng)審(嚴(yán)重故障線下會(huì)議對(duì)齊)
• 故障干系人按照ETA保障故障Action落地。

2)故障復(fù)盤(pán)文檔庫(kù)

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

• 穩(wěn)定性日常運(yùn)營(yíng)

穩(wěn)定性本身是一個(gè)產(chǎn)品，需要日常持續(xù)的運(yùn)營(yíng)，在ECS管控主要模式有穩(wěn)定性日?qǐng)?bào)與雙周報(bào)。

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

三、我認(rèn)知的SRE

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

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

1) SRE 就是運(yùn)維

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

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

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

3.2 SRE能力模型

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

1) 技術(shù)能力

a.研發(fā)能力

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

b.運(yùn)維能力

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

c.架構(gòu)能力

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

d.工程能力

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

2) 軟技能

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

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

b.溝通能力

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

c.團(tuán)隊(duì)協(xié)作

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

d.項(xiàng)目管理

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

3)思維模式

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

3.3 SRE核心理念

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

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

3.4 SRE精神

舍我其誰(shuí)，SRE要有強(qiáng)烈的責(zé)任意識(shí)與使命感，作為穩(wěn)定性的守護(hù)者，在團(tuán)隊(duì)協(xié)作過(guò)程中，要做到無(wú)界擔(dān)當(dāng)，一桿到底。

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

寫(xiě)在最后

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

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

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