【導(dǎo)讀】SRE和DevOps有什么區(qū)別和聯(lián)系？本文對(duì)此進(jìn)行了解讀，并著重從SRE實(shí)踐出發(fā)闡述了DevOps的建設(shè)思路。
【作者】汪照輝，中國(guó)銀河證券架構(gòu)師，專注于容器云、微服務(wù)、DevOps、數(shù)據(jù)治理、數(shù)字化轉(zhuǎn)型等領(lǐng)域，對(duì)相關(guān)技術(shù)有獨(dú)特的理解和見(jiàn)解。擅長(zhǎng)于軟件規(guī)劃和設(shè)計(jì)，提出的“平臺(tái)融合”的觀點(diǎn)越來(lái)越得到認(rèn)同和事實(shí)證明。發(fā)表了眾多技術(shù)文章探討容器平臺(tái)建設(shè)、微服務(wù)技術(shù)、DevOps、數(shù)字化轉(zhuǎn)型、數(shù)據(jù)治理、中臺(tái)建設(shè)等內(nèi)容，受到了廣泛關(guān)注和肯定。個(gè)人公眾號(hào)：技術(shù)思維創(chuàng)新
SRE就是在用軟件工程的思維和方法論完成以前由系統(tǒng)管理員團(tuán)隊(duì)手動(dòng)完成的工作。SRE的職責(zé)是運(yùn)維一個(gè)服務(wù)，該服務(wù)由一些相關(guān)的系統(tǒng)組件組成，為最終用戶（可以是內(nèi)部用戶也可以是外部用戶）提供服務(wù)。SRE的終極責(zé)任是確保該服務(wù)可以正常運(yùn)轉(zhuǎn)。為達(dá)成這一目標(biāo)，SRE需要完成開(kāi)發(fā)監(jiān)控系統(tǒng)、規(guī)劃資源容量、處理緊急事件、跟蹤修復(fù)事故根源等。SRE對(duì)重復(fù)性、手工性的操作有天然的排斥感，并有足夠的技術(shù)能力快速開(kāi)發(fā)出軟件系統(tǒng)以替代手工操作。
DevOps的核心思想是協(xié)調(diào)開(kāi)發(fā)Dev和運(yùn)維Ops關(guān)系，使之能有效溝通和協(xié)作，通過(guò)工具鏈、流水線高效銜接，持續(xù)反饋，實(shí)現(xiàn)研發(fā)Dev到運(yùn)維Ops流程的持續(xù)優(yōu)化和完善。
一、理解SRE和DevOps異同
有人說(shuō)SRE就是DevOps，DevOps等于SRE，其實(shí)是不對(duì)的。DevOps是一種協(xié)調(diào)開(kāi)發(fā)和運(yùn)維之間協(xié)作關(guān)系的思想理念，SRE是在Google類似于DevOps思想理念的一種實(shí)踐。SRE更關(guān)注站點(diǎn)或產(chǎn)品或應(yīng)用服務(wù)等運(yùn)行的穩(wěn)定性，以“錯(cuò)誤預(yù)算”協(xié)調(diào)開(kāi)發(fā)和運(yùn)維之間的利益關(guān)系，所以SRE其實(shí)更多是在Ops端。但關(guān)注“運(yùn)維Ops”這無(wú)疑是正確的，和我們習(xí)慣于更關(guān)注“開(kāi)發(fā)Dev”是不一樣的。SRE強(qiáng)調(diào)用工程化的手段應(yīng)對(duì)運(yùn)維問(wèn)題。軟件運(yùn)維問(wèn)題達(dá)到一定規(guī)模時(shí)，也確實(shí)只能通過(guò)軟件工程化的手段來(lái)解決。
SRE團(tuán)隊(duì)替代了很多研發(fā)Dev的工作，使Dev更專注于業(yè)務(wù)應(yīng)用或產(chǎn)品的研發(fā)，而不再關(guān)注軟硬件基礎(chǔ)設(shè)施和中間件工具，所以研發(fā)的工作就聚焦化了。同時(shí)通過(guò)SRE團(tuán)隊(duì)所構(gòu)建的自動(dòng)化工具鏈、流水線等提升了研發(fā)效率。
DevOps和SRE的關(guān)系類似于SOA和ESB的關(guān)系。SRE是DevOps思想落地的一種方式。SRE模型成功的關(guān)鍵在于對(duì)工程的關(guān)注，如果沒(méi)有持續(xù)的、工程化的解決方案，運(yùn)維的壓力就會(huì)不斷增加，也就需要更多的人來(lái)完成工作。SRE的終極目標(biāo)是推動(dòng)整個(gè)系統(tǒng)趨向于無(wú)人化運(yùn)行，也就是智能化，不僅僅是自動(dòng)化。“如果系統(tǒng)正常運(yùn)轉(zhuǎn)中需要人工干預(yù)，應(yīng)該將此視為一種bug”。
SRE既做運(yùn)維也做開(kāi)發(fā)。其開(kāi)發(fā)時(shí)間不少于50%。既保障SRE有足夠的時(shí)間和精力去進(jìn)行真正有創(chuàng)造性的、自主性的研發(fā)工作，同時(shí)也保障了SRE團(tuán)隊(duì)有足夠的運(yùn)維經(jīng)驗(yàn)，深度理解運(yùn)維的需求，從而讓他們?cè)O(shè)計(jì)出切實(shí)解決問(wèn)題的系統(tǒng)。但SRE只是關(guān)注于運(yùn)維工具和流程自動(dòng)化的研發(fā)，而不做業(yè)務(wù)應(yīng)用或產(chǎn)品的研發(fā)。這也從實(shí)踐說(shuō)明了DevOps的建設(shè)是需要靠自己而不是靠外部廠商。因?yàn)檫@是一個(gè)持續(xù)的，不斷變化改進(jìn)的過(guò)程。
二、研發(fā)和運(yùn)維之間的利益沖突
企業(yè)中研發(fā)Dev和運(yùn)維Ops之間最主要的矛盾就是應(yīng)用服務(wù)迭代創(chuàng)新的速度與應(yīng)用服務(wù)穩(wěn)定運(yùn)行程度之間的矛盾。我們總是強(qiáng)調(diào)敏捷研發(fā)、敏捷交付，但是研發(fā)之后交付之后改怎么運(yùn)維卻考慮的比較少。雖然目前智能運(yùn)維AIOps等很多人都在講，但個(gè)人覺(jué)得目前更多只是噱頭，遠(yuǎn)未到智能運(yùn)維的階段。試想基本運(yùn)維都沒(méi)做好就去做智能運(yùn)維，就像讓不會(huì)走的小孩就要跑起來(lái)，有點(diǎn)可笑。要解決Dev和Ops雙方的利益沖突，則需要同時(shí)能關(guān)注矛盾雙方的訴求、保障矛盾雙方的利益。既要保證“速度”，更要關(guān)注“穩(wěn)定性”。但任何軟件系統(tǒng)都不應(yīng)該一味追求100%可靠。對(duì)最終用戶來(lái)說(shuō)，99.99%、99.999%和100%的可用性并沒(méi)有實(shí)質(zhì)的區(qū)別。因此DevOps建設(shè)就是追求這種矛盾的統(tǒng)一。
我們說(shuō)過(guò)，在軟件整個(gè)生命周期過(guò)程中，研發(fā)階段可能只占20%，大部分時(shí)間都是在運(yùn)維、在持續(xù)優(yōu)化。所以SRE關(guān)注運(yùn)維是正確的。解決方式就是通過(guò)軟件工程化、系統(tǒng)化的方法來(lái)解決運(yùn)維問(wèn)題，這也就是很多人說(shuō)的“研發(fā)運(yùn)維一體化”（這里的研發(fā)是“運(yùn)維研發(fā)”，不是“產(chǎn)品研發(fā)”）。企業(yè)DevOps建設(shè)就需要設(shè)法協(xié)調(diào)研發(fā)與運(yùn)維之間的矛盾，滿足雙方的利益訴求。SRE是通過(guò)高層所定下的“錯(cuò)誤預(yù)算”來(lái)協(xié)調(diào)雙方矛盾的（但錯(cuò)誤預(yù)算有其局限性，我們將在后續(xù)詳細(xì)討論DevOps效率建設(shè)問(wèn)題）。在DevOps建設(shè)中，研發(fā)關(guān)注需求、CI，CD則需要和運(yùn)維協(xié)作，這也是我們一直反對(duì)在容器云平臺(tái)做流水線做CICD的一個(gè)原因。運(yùn)維平臺(tái)、運(yùn)維工具、運(yùn)維方法、運(yùn)維流程、運(yùn)維組織和運(yùn)維思想的首先建立是必要的。做好運(yùn)維，將會(huì)更好的支撐敏捷研發(fā)和持續(xù)部署發(fā)布，真正實(shí)現(xiàn)敏捷。
三、DevOps建設(shè)思路
對(duì)DevOps的錯(cuò)誤理解之一就是一個(gè)人什么都干。要提升軟件工程效率，就必須實(shí)現(xiàn)分工。這和社會(huì)生產(chǎn)發(fā)展規(guī)律也是一樣的。只有分工才能提升效率。因此DevOps建設(shè)首先就需要考慮職責(zé)分工。從SRE實(shí)踐我們看到，DevOps建設(shè)要關(guān)注運(yùn)維，運(yùn)維要分層，職責(zé)要輪換，體系要簡(jiǎn)單，追求矛盾的統(tǒng)一。用軟件工程化的方式建設(shè)軟件基礎(chǔ)設(shè)施來(lái)支撐產(chǎn)品研發(fā)，提升研發(fā)效率。
（1）DevOps建設(shè)重點(diǎn)在運(yùn)維
Google SRE雖然也做運(yùn)維工具和運(yùn)維組件的研發(fā)，但本質(zhì)上是運(yùn)維團(tuán)隊(duì)。只有運(yùn)維團(tuán)隊(duì)把軟硬件基礎(chǔ)設(shè)施準(zhǔn)備好了，應(yīng)用或產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)才能更好的享受軟硬件基礎(chǔ)設(shè)施所帶來(lái)的便利。研發(fā)的敏捷性往往是由運(yùn)維的穩(wěn)定性驅(qū)動(dòng)的。只有持續(xù)構(gòu)建部署穩(wěn)定可靠的應(yīng)用服務(wù)，研發(fā)才能真正地實(shí)現(xiàn)敏捷迭代，而不是陷于應(yīng)對(duì)繁瑣的基礎(chǔ)設(shè)施工作中不能自拔。這和我們習(xí)慣的關(guān)注CICD的DevOps理念是不同的。只有從整體上考慮DevOps，從頂層設(shè)計(jì)考慮DevOps，才能把DevOps建設(shè)好。開(kāi)發(fā)和運(yùn)維的工作量基本上是2：8，完成開(kāi)發(fā)，應(yīng)用或產(chǎn)品的生命周期才剛剛開(kāi)始不久，更長(zhǎng)生命階段是在運(yùn)維和完善。因此軟硬件基礎(chǔ)設(shè)施的建設(shè)和完備是產(chǎn)品研發(fā)的基礎(chǔ)和巨人的肩膀。
（2）軟硬件基礎(chǔ)設(shè)施運(yùn)維分層
軟硬件基礎(chǔ)設(shè)施內(nèi)容眾多，這也是DevOps建設(shè)比較困難的一個(gè)地方。從SRE來(lái)看，其通過(guò)團(tuán)隊(duì)職責(zé)的細(xì)化實(shí)現(xiàn)了基礎(chǔ)設(shè)施的分層運(yùn)維。這涉及到組織架構(gòu)的優(yōu)化。和我們傳統(tǒng)一個(gè)團(tuán)隊(duì)什么都運(yùn)維的思路是不同的。通過(guò)專業(yè)化的分工使運(yùn)營(yíng)效率大幅提升。而通過(guò)提供服務(wù)化的方式又可以和其他團(tuán)隊(duì)平滑合作。
DevOps建設(shè)中運(yùn)維內(nèi)容我們可以簡(jiǎn)單的劃分為：硬件基礎(chǔ)設(shè)施（服務(wù)器、存儲(chǔ)、網(wǎng)絡(luò)、DataCenter、機(jī)柜、機(jī)架……）資源、軟件基礎(chǔ)設(shè)施和通用工具（OS、通信、認(rèn)證、權(quán)限、監(jiān)控、日志、調(diào)度、配置、消息組件……）、數(shù)據(jù)平臺(tái)和數(shù)據(jù)工具（數(shù)據(jù)庫(kù)、大數(shù)據(jù)平臺(tái)、機(jī)器學(xué)習(xí)平臺(tái)……）、應(yīng)用支撐平臺(tái)（虛擬化、云管、PaaS、服務(wù)治理平臺(tái)、負(fù)載均衡器、中臺(tái)服務(wù)……）、業(yè)務(wù)應(yīng)用和業(yè)務(wù)系統(tǒng)等。業(yè)務(wù)應(yīng)用和業(yè)務(wù)系統(tǒng)在這些軟硬件基礎(chǔ)設(shè)施之上部署運(yùn)行，由各個(gè)運(yùn)維團(tuán)隊(duì)來(lái)進(jìn)行日常維護(hù)和管理。同時(shí)這些團(tuán)隊(duì)需要完成日常運(yùn)維工作所需的工具開(kāi)發(fā)、自動(dòng)化流程等。
我們可以很容易的看到，軟件產(chǎn)品的研發(fā)需要考慮的內(nèi)容很多。如果沒(méi)有運(yùn)維的經(jīng)驗(yàn)，軟件產(chǎn)品也很難設(shè)計(jì)好。比如組件的部署方式、部署位置、部署數(shù)量等等。因此要設(shè)計(jì)研發(fā)出真正好的軟件產(chǎn)品，需要具備相應(yīng)的運(yùn)維意識(shí)和能力。
（3）職責(zé)輪換，促進(jìn)理解和提升技能
這里職責(zé)輪換包含兩個(gè)循環(huán)：一是Dev和Ops職責(zé)的輪換，二是Ops內(nèi)部開(kāi)發(fā)和運(yùn)維人員的職責(zé)互換，這部分其實(shí)就是google的SRE。開(kāi)發(fā)和運(yùn)維角色互換，更有助于開(kāi)發(fā)理解運(yùn)維工作，而運(yùn)維的經(jīng)驗(yàn)也讓開(kāi)發(fā)人員更關(guān)注部署、運(yùn)維的細(xì)節(jié)，避免開(kāi)發(fā)導(dǎo)致的部署和運(yùn)行缺陷。
很多開(kāi)發(fā)人員從來(lái)沒(méi)做過(guò)運(yùn)維，沒(méi)有運(yùn)維經(jīng)驗(yàn)和體會(huì)，不理解應(yīng)用服務(wù)和產(chǎn)品的穩(wěn)定性運(yùn)維運(yùn)營(yíng)問(wèn)題，所以也很難設(shè)計(jì)出滿足穩(wěn)定性的產(chǎn)品和應(yīng)用來(lái)，在穩(wěn)定性、客戶體驗(yàn)等眾多方面都達(dá)不到要求，也使很多開(kāi)發(fā)人員難以虛心求教，反而自以為是，帶來(lái)大量的產(chǎn)品問(wèn)題。
以O(shè)ps內(nèi)部小循環(huán)帶動(dòng)DevOps大循環(huán)，真正理解軟件工程生命周期過(guò)程，減少設(shè)計(jì)和編碼缺陷，提升系統(tǒng)穩(wěn)定性和用戶體驗(yàn)，這才是建設(shè)DevOps的意義，也是軟件人員快速成長(zhǎng)的捷徑。不過(guò)這樣的方式無(wú)疑改變了傳統(tǒng)的項(xiàng)目管理方式和組織管理方式。組織改進(jìn)最嚴(yán)重的阻礙是來(lái)自于組織文化、領(lǐng)導(dǎo)想法和領(lǐng)導(dǎo)魄力。打破傳統(tǒng)守舊的文化和思維體系，可能難于上青天。不過(guò)若要獲得成功，就必須在整個(gè)組織里培養(yǎng)一種生機(jī)型的文化和組織戰(zhàn)略。
（4）保持簡(jiǎn)單
軟件工程的一個(gè)關(guān)鍵思想是保持簡(jiǎn)單。把復(fù)雜的系統(tǒng)簡(jiǎn)化，是一個(gè)合格的軟件架構(gòu)師、工程師必須考慮的問(wèn)題。軟件系統(tǒng)本質(zhì)上是動(dòng)態(tài)的和不穩(wěn)定的。需求在不斷的變化，軟件系統(tǒng)在不斷的改進(jìn)和調(diào)整。唯一不變的是變化。DevOps的工作就是在系統(tǒng)靈活性和穩(wěn)定性之間選擇平衡，在敏捷研發(fā)部署和系統(tǒng)穩(wěn)定運(yùn)行之間達(dá)成一致。最簡(jiǎn)單的流程和步驟將會(huì)是最高效的。軟件的簡(jiǎn)單性是穩(wěn)定性的前提。
大道至簡(jiǎn)，保持簡(jiǎn)單就需要從軟件工程的各個(gè)階段各個(gè)層次以最簡(jiǎn)單的方式解決最復(fù)雜的問(wèn)題。至簡(jiǎn)源碼、最短鏈路、最小依賴、自動(dòng)化、自服務(wù)等首先軟件工程和業(yè)務(wù)系統(tǒng)的簡(jiǎn)單化，從而實(shí)現(xiàn)可預(yù)期的穩(wěn)定性。
1.最簡(jiǎn)化源碼
刪除不需要的源碼和注釋，使代碼最簡(jiǎn)化。我們知道添加到項(xiàng)目中的每行代碼都可能引入新的缺陷和錯(cuò)誤。敢于剪除多余的冗枝，綠植往往會(huì)長(zhǎng)的更好。沒(méi)有什么可以去掉的時(shí)候，往往才是最好的、最合適的。所以在編碼階段就要敢于刪除冗余不用的代碼，不要想著某一天還會(huì)用到。不刪除，基本上這些代碼永遠(yuǎn)也用不上了。
2.最短鏈路
我把最短鏈路作為微服務(wù)設(shè)計(jì)的一個(gè)原則。一方面是效率考慮，一方面也是簡(jiǎn)單化。避免復(fù)雜鏈路的容易出現(xiàn)的循環(huán)調(diào)用。最短鏈路在DevOps建設(shè)中也可以作為一個(gè)原則，指導(dǎo)研發(fā)人員服務(wù)的設(shè)計(jì)和系統(tǒng)架構(gòu)。
3.最小化依賴
最短鏈路原則會(huì)減少服務(wù)、系統(tǒng)之間的依賴關(guān)系。但不僅僅是服務(wù)之間。其實(shí)我們?cè)谟懻撊萜髟破脚_(tái)設(shè)計(jì)時(shí)也說(shuō)過(guò)，引入的不必要組件導(dǎo)致了整個(gè)平臺(tái)的復(fù)雜化、資源浪費(fèi)和不穩(wěn)定。
4.自動(dòng)化
自動(dòng)化是DevOps建設(shè)的基本要求之一。自動(dòng)化才能消除眾多的人工重復(fù)性操作，從而減少人為錯(cuò)誤，提升工作效率。最簡(jiǎn)單的例子，我們有數(shù)百臺(tái)容器節(jié)點(diǎn)，每三個(gè)月需要按要求修改密碼。如果人來(lái)做，是很大的工作量，而自動(dòng)化，幾分鐘就可以按規(guī)則修改完畢。Google SRE就是通過(guò)軟件工程的方法實(shí)現(xiàn)自動(dòng)化運(yùn)維，把人工運(yùn)維工作降到最低。
5.自服務(wù)
首先團(tuán)隊(duì)需要實(shí)現(xiàn)自給自足。這在團(tuán)隊(duì)職責(zé)劃分、團(tuán)隊(duì)服務(wù)能力抽象整合、標(biāo)準(zhǔn)化信息服務(wù)API等建設(shè)都需要有合理的規(guī)劃和設(shè)計(jì)。SRE開(kāi)發(fā)工具、自動(dòng)化流程、平臺(tái)等一方面實(shí)現(xiàn)自身運(yùn)維運(yùn)營(yíng)需求，另一方面支撐產(chǎn)品研發(fā)團(tuán)隊(duì)可以自己掌控和執(zhí)行自己的發(fā)布流程。
四、總結(jié)
我們可以把SRE看作是DevOps理論的一項(xiàng)具體實(shí)踐。SRE的很多方法和做法是值得我們思考和嘗試的。同時(shí)也不能完全照搬SRE的實(shí)踐，不能把它當(dāng)作最佳實(shí)踐神化。SRE以軟件工程化、系統(tǒng)化思路是用錯(cuò)誤預(yù)算來(lái)解決開(kāi)發(fā)運(yùn)維之間的協(xié)作問(wèn)題，有其合理性，也有局限性。不過(guò)其關(guān)注運(yùn)維、限制SRE運(yùn)維總時(shí)間投入以確保研發(fā)能力、保持簡(jiǎn)單化、運(yùn)維分層等思想是非常值得吸收的實(shí)踐經(jīng)驗(yàn)，值得我們?cè)诮ㄔO(shè)DevOps中思考和采用。
