《SRE，DevOps，PE的運(yùn)維本質(zhì)和價(jià)值都是為產(chǎn)品和業(yè)務(wù)服務(wù)》要點(diǎn)：
本文介紹了SRE，DevOps，PE的運(yùn)維本質(zhì)和價(jià)值都是為產(chǎn)品和業(yè)務(wù)服務(wù)，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

導(dǎo)讀：本文是我在3月4日數(shù)人云北京站線下活動(dòng)“當(dāng)西方的SRE遇上東方的互聯(lián)網(wǎng)”中的分享.

本文從SRE,Devops, PE間的關(guān)系開始,介紹企業(yè)該如何構(gòu)建適合自己的運(yùn)維組織架構(gòu)并管理團(tuán)隊(duì),講解持續(xù)交付、監(jiān)控、容量規(guī)劃等具體運(yùn)維場(chǎng)景實(shí)操,從工程實(shí)踐的角度解讀大規(guī)模復(fù)雜化的業(yè)務(wù)場(chǎng)景下運(yùn)維指導(dǎo)思想的落地.

王超 /?京東金融企業(yè)PE團(tuán)隊(duì)負(fù)責(zé)人

目前在京東金融平臺(tái)負(fù)責(zé)一個(gè)20人左右的應(yīng)用運(yùn)維團(tuán)隊(duì)(PE團(tuán)隊(duì)),也曾負(fù)責(zé)人人網(wǎng)PE團(tuán)隊(duì).現(xiàn)階段主要關(guān)注運(yùn)維與業(yè)務(wù)的融合、業(yè)務(wù)可用性保障,運(yùn)維平臺(tái)建設(shè)和團(tuán)隊(duì)管理.

我是今天最后的演講者,前面幾位都是很知名的運(yùn)維專家,對(duì)大家提到的很多運(yùn)維痛點(diǎn)我都感同身受,談到國(guó)內(nèi)運(yùn)維行業(yè)的發(fā)展,我沒(méi)有在國(guó)外工作的經(jīng)驗(yàn),今天講的經(jīng)驗(yàn)都是我在國(guó)內(nèi)不算美好的IT行業(yè)環(huán)境下的親身實(shí)踐和總結(jié),其中也吸收了很多國(guó)內(nèi)運(yùn)維行業(yè)專家前輩的指點(diǎn),希望對(duì)大家有借鑒的意義.

剛畢業(yè)時(shí)我在一家世界500強(qiáng)的傳統(tǒng)行業(yè)公司信息中心做應(yīng)用運(yùn)維,后來(lái)?yè)Q到人人網(wǎng),再后來(lái)就是京東金融.從傳統(tǒng)行業(yè)跳到人人網(wǎng)的時(shí)候,加入的是一個(gè)剛建立的技術(shù)運(yùn)維團(tuán)隊(duì),我從初期的運(yùn)維工程師,成長(zhǎng)為后來(lái)的運(yùn)維主管.2014年到京東金融的時(shí)候,從0開始搭建起整個(gè)應(yīng)用運(yùn)維團(tuán)隊(duì),從初期建設(shè)團(tuán)隊(duì)到一個(gè)比較穩(wěn)定的狀態(tài),把公司的業(yè)務(wù)支撐好,這里面有很多經(jīng)驗(yàn)可以和大家分享.

詳解DevOps

DevOps 是傳統(tǒng)瀑布流的交付方式中的Dev(開發(fā))和Ops(運(yùn)維)的關(guān)系.

開發(fā)和運(yùn)維有一個(gè)矛盾點(diǎn),開發(fā)的人覺(jué)得寫好代碼交給運(yùn)維,就可以上線部署了,后面的事與我無(wú)關(guān).代碼像炸彈一樣,上線后如果出了問(wèn)題總是運(yùn)維背鍋.運(yùn)維的人覺(jué)得開發(fā)的人總是找麻煩,總是不靠譜,于是把控變更的次數(shù)和審核流程,使開發(fā)的人不能申請(qǐng)更多的上線,比如一個(gè)星期只允許上線一次,就這樣阻礙了業(yè)務(wù)的發(fā)展.DevOps解決了這個(gè)矛盾,協(xié)調(diào)了技術(shù)運(yùn)營(yíng)、QA還有開發(fā)三者間的關(guān)系.

DevOps誤區(qū)

國(guó)內(nèi)有很多錯(cuò)誤的做法,比如寫著招聘DevOps職位,但描述的工作職責(zé)跟傳統(tǒng)的運(yùn)維沒(méi)有太多明顯的變化,還是做發(fā)布和SA；有的團(tuán)隊(duì)把名字改成了DevOps,但是做的是運(yùn)維開發(fā)的工作,要注意“運(yùn)維開發(fā)”不是DevOps.DevOps是一個(gè)落實(shí)到團(tuán)隊(duì)里的文化理念和最佳實(shí)踐,不只是運(yùn)維團(tuán)隊(duì)做,也不只是開發(fā)團(tuán)隊(duì)做,而是大家一起做DevOps,甚至有可能單獨(dú)設(shè)有有一些協(xié)調(diào)員去做發(fā)布、交付工作.所以,DevOps不只是一個(gè)團(tuán)隊(duì)的名稱.

我在人人網(wǎng)的時(shí)候, DevOps的概念比較火,公司建了一個(gè)DevOps團(tuán)隊(duì),后來(lái)在專家的指點(diǎn)下,我們把團(tuán)隊(duì)名稱改成了PE團(tuán)隊(duì).另外,DevOps并不是系統(tǒng)管理員加上自動(dòng)化工具就夠了,在部門里,SA做發(fā)布用了很多自動(dòng)化的工具,但大家要知道,自動(dòng)化只是一種手段和工具,要想好最終的目標(biāo)解決的是怎樣的問(wèn)題.最后,DevOps也不是把root權(quán)限給了開發(fā)人員.開發(fā)的人員有root權(quán)限會(huì)引入很大的風(fēng)險(xiǎn),DevOps需要控制這個(gè)風(fēng)險(xiǎn).

DevOps技術(shù)目標(biāo)

DevOps的最終目標(biāo)

DevOps的最終目標(biāo)是建立一個(gè)流水線、準(zhǔn)實(shí)時(shí)交互及時(shí)性的業(yè)務(wù)流程,快速把產(chǎn)品推上線,產(chǎn)生業(yè)務(wù)價(jià)值,最大化業(yè)務(wù)輸出.做事一定要想公司的路線圖是什么,公司要做什么樣的事情.公司新發(fā)布一個(gè)產(chǎn)品,上線一個(gè)在社交網(wǎng)站上的新消息流功能,目標(biāo)就應(yīng)該是把這個(gè)功能推上線,服務(wù)更多的人,而不是簡(jiǎn)簡(jiǎn)單單的做一個(gè)工單的處理.目標(biāo)不一樣,結(jié)果也是不一樣的.

從技術(shù)的角度或者是架構(gòu)的角度來(lái)講,DevOps需要快速部署的平臺(tái).這一點(diǎn)是大家都很認(rèn)可的,很多現(xiàn)在DevOps培訓(xùn)都僅僅做技術(shù)上的快速部署平臺(tái),但是缺少對(duì)DevOps其他方面的培訓(xùn).DevOps真正的價(jià)值是由業(yè)務(wù)的結(jié)果判斷的.最大化輸出業(yè)務(wù),而不止是IT項(xiàng)目的范圍或成果,就是對(duì)業(yè)務(wù)產(chǎn)生了多大的影響.

Facebook里有兩個(gè)詞說(shuō)得特別多,一個(gè)是Vision(視野),另一個(gè)是Impact(影響力).做事前想想這件事對(duì)公司是不是有正向的影響,影響力有多大?視野加上影響力很重要.舉個(gè)例子,做一個(gè)架構(gòu)的組件,可能短期內(nèi)公司用不上,但是在明年也許會(huì)產(chǎn)生很大的效果,產(chǎn)生很大的改變,那就可以做.做完以后今年可能沒(méi)有產(chǎn)生效果,但是明年可能對(duì)幾十人、上百人的開發(fā)效率產(chǎn)生非常大的提升,這就是有意義的.所以要看最終的結(jié)果,而不只從一個(gè)項(xiàng)目的角度去考慮.

DevOps速度&業(yè)務(wù)連續(xù)性

雙峰挑戰(zhàn).系統(tǒng)基本上都可以分為這兩類：是關(guān)注于快速上線的交互型系統(tǒng),還是關(guān)注業(yè)務(wù)的連續(xù)性的記錄型(SOR)系統(tǒng).我們公司是做金融的,其中的交易系統(tǒng)就屬于對(duì)業(yè)務(wù)連續(xù)性要求特別高的.有些產(chǎn)品則更關(guān)注于速度,比如web、app的開發(fā),上線后如果有問(wèn)題馬上回退就好,對(duì)用戶不會(huì)產(chǎn)生特別大的影響,這就是典型的交互型系統(tǒng),這類系統(tǒng)也比較適合用DevOps.要區(qū)分系統(tǒng)是否適合DevOps,銀行、證券的的核心系統(tǒng)要把控好,不夠成熟就不要上DevOps.

DevOps風(fēng)險(xiǎn)&安全

DevSecOps就是除了DevOps,還要注意安全.互聯(lián)網(wǎng)公司對(duì)三點(diǎn)很關(guān)注,那就是速度、成本和質(zhì)量.要快速的上線、快速的迭代,也要控制好成本.質(zhì)量不能出問(wèn)題,業(yè)務(wù)連續(xù)性不能斷,如果經(jīng)常丟數(shù)據(jù),業(yè)務(wù)不能使用,公司的品牌會(huì)受到很大的影響.金融公司則更關(guān)注于安全,假如數(shù)據(jù)被竊取了,用戶數(shù)據(jù)或交易紀(jì)錄被篡改,是致命的.數(shù)據(jù)非常重要,所以DevOps里又加了一個(gè)DevSecOps .

關(guān)注風(fēng)險(xiǎn),但沒(méi)有絕對(duì)的安全.DevOps的經(jīng)典書籍《鳳凰工程》里有一段情節(jié),有個(gè)做審計(jì)的人總是特別郁悶,因?yàn)榭傆X(jué)得IT的人不按審計(jì)的要求去修復(fù)所有問(wèn)題,會(huì)出非常大的問(wèn)題.但是最終的結(jié)果是審計(jì)成功通過(guò),因?yàn)楣纠镓?cái)務(wù)的人通過(guò)業(yè)務(wù)上的檢查,解決了發(fā)現(xiàn)的安全問(wèn)題,也就是說(shuō)即使IT上存在一些問(wèn)題,也可以通過(guò)業(yè)務(wù)的方式彌補(bǔ),達(dá)到最終的安全.DevOps告訴我們,你要關(guān)注風(fēng)險(xiǎn)而不簡(jiǎn)單是安全,在避免風(fēng)險(xiǎn)的前提下,制度不應(yīng)妨礙業(yè)務(wù)的發(fā)展和交互.另外,也要通過(guò)技術(shù)提升安全,簡(jiǎn)化流程,盡量實(shí)現(xiàn)自動(dòng)化.設(shè)計(jì)流程很容易,很多公司里面都有特別多的工單,但是你要想你的工單是不是有作用?比如說(shuō)是不是所有的項(xiàng)目的上線都需要安全的人審核,如果能自動(dòng)判斷沒(méi)有風(fēng)險(xiǎn)的話,能否自動(dòng)化流轉(zhuǎn)?

DevSecOps和DevOps一樣,也要加強(qiáng)人與人之間的溝通、協(xié)作,負(fù)責(zé)安全的人應(yīng)該和開發(fā)、運(yùn)維、測(cè)試人員一起防范風(fēng)險(xiǎn).

淺談SRE

談?wù)凷RE, SRE需要負(fù)責(zé)可用性、時(shí)延、性能、效率、變更管理、監(jiān)控、應(yīng)急響應(yīng)和容量管理等相關(guān)的工作,包括工程研發(fā)、日常運(yùn)維以及監(jiān)控響應(yīng)方向的工作.

深究PE

PE起源

重點(diǎn)分享我正在做的PE是什么,先介紹一下PE的起源.大家比較認(rèn)可的是從雅虎開始流行的,國(guó)內(nèi)最大的團(tuán)隊(duì)就是阿里的PE團(tuán)隊(duì),后來(lái)受阿里影響很多公司也設(shè)了PE職位.PE這個(gè)詞有的叫產(chǎn)品運(yùn)維工程師,有的叫業(yè)務(wù)運(yùn)維工程師,也可以直接認(rèn)為就是應(yīng)用運(yùn)維團(tuán)隊(duì),簡(jiǎn)單來(lái)說(shuō)就是負(fù)責(zé)業(yè)務(wù)或應(yīng)用相關(guān)的一系列工程上的事務(wù).

這是Facebook的招聘描述,PE既擁有軟件也擁有系統(tǒng)方面知識(shí)的工程師,要保障Facebook 的服務(wù)平滑的運(yùn)行,有足夠的容量滿足未來(lái)的規(guī)劃.這也是剛才說(shuō)的Facebook很強(qiáng)調(diào)兩點(diǎn)：一個(gè)是視野,一個(gè)是影響力.技術(shù)人要有視野,能預(yù)見(jiàn)公司未來(lái)的業(yè)務(wù)發(fā)展,根據(jù)視野做設(shè)計(jì).一方面要保證服務(wù)平滑運(yùn)行,另一方面要滿足未來(lái)的容量規(guī)劃,以此設(shè)計(jì)基礎(chǔ)組件,要有長(zhǎng)久規(guī)劃設(shè)計(jì)的能力.每個(gè)Facebook 產(chǎn)品,包括基礎(chǔ)設(shè)施,都有PE的人.

聽(tīng)阿里畢玄老師說(shuō),阿里的PE團(tuán)隊(duì)打散到不同的BU業(yè)務(wù)單元里.大家要根據(jù)自身的情況考慮,Facebook 團(tuán)隊(duì)比較大,每個(gè)大團(tuán)隊(duì)都有兩個(gè)PE的人跟進(jìn),他們有廣闊的視野和經(jīng)驗(yàn),背景也比較好,從整個(gè)團(tuán)隊(duì)來(lái)看,既有新人也有老手,組成了多樣化的團(tuán)隊(duì).

 

除了寫代碼,PE也要會(huì)寫文檔.做運(yùn)維的人一定不要抗拒寫文檔,不管在哪里,文檔都很重要.好的文檔能把事情描述清楚,給別人去看,傳播給更多人,而不只是在自己的腦子里面.PE要做容量規(guī)劃,像京東每年都有兩次大促,618大促,雙十一大促,PE要規(guī)劃容量和性能能否夠滿足業(yè)務(wù)的發(fā)展.PE需要調(diào)試處理最困難的問(wèn)題,所有運(yùn)維都知道調(diào)試排查問(wèn)題(Trouble Shooting),但是能做好的很難.很多公司做問(wèn)題處理的時(shí)候,如果有乙方的支持,只要問(wèn)題能解決,公司的人就不去想是問(wèn)題的原因.

我們需要反思,再去自我提高,好的PE問(wèn)題排查和總結(jié)范圍的能力都很強(qiáng),簡(jiǎn)單的問(wèn)題也可以找到深層次的原因并做長(zhǎng)期的提升改進(jìn).PE要加入到值班輪轉(zhuǎn)里,在值班的時(shí)候處理問(wèn)題.PE要做產(chǎn)品協(xié)調(diào)員,和工程師團(tuán)隊(duì)一同協(xié)作,這和SRE里相關(guān)的部分很像.

PE會(huì)和很多人打交道,這點(diǎn)對(duì)其他職業(yè)也是通用的.我很強(qiáng)調(diào)人與人之間的溝通協(xié)作,PE是一個(gè)協(xié)調(diào)員的角色,要和PM、產(chǎn)品經(jīng)理、程序員、網(wǎng)工,或者SRE溝通,與各個(gè)組協(xié)調(diào)把事情做好.我招PE的時(shí)候,很注意軟技能,如果軟技能方面有問(wèn)題,只想做技術(shù),很多事情都很難處理,后面的風(fēng)險(xiǎn)會(huì)更大.對(duì)于個(gè)人,不管是運(yùn)維還是其他職位,想更好的發(fā)展都應(yīng)該提升軟技能方面的能力,更多地與合作伙伴、同事共同協(xié)作,大家達(dá)成一致的目標(biāo),協(xié)作完成任務(wù).

目標(biāo)部分再說(shuō)一下,管理者還要評(píng)估PE的績(jī)效,保證業(yè)務(wù)正常運(yùn)轉(zhuǎn),這也是管理者的一項(xiàng)重要工作.PE或應(yīng)用運(yùn)維工程師如何做發(fā)展計(jì)劃?如果不轉(zhuǎn)型,還是按PE方向發(fā)展,我覺(jué)得發(fā)展為架構(gòu)師是很好的規(guī)劃.

總結(jié)一下我對(duì)PE的定位.首先,PE應(yīng)該是服務(wù)的第一響應(yīng)者,有問(wèn)題要馬上處理.大家要有這個(gè)意識(shí),有問(wèn)題要能快速處理,這也要靠公司機(jī)制去保證,并不只是靠人.人不可能7*24小時(shí)處理問(wèn)題,但是機(jī)制可以保證,包括輪班,一線二線的人分離任務(wù),在保證核心的人不要太累的同時(shí)處理問(wèn)題.性能分析師,利用有限資源承載更多的業(yè)務(wù),京東每次大促前都要做全鏈路壓測(cè),做評(píng)估、擴(kuò)容,先做性能分析,然后在進(jìn)行容量規(guī)劃.系統(tǒng)管理員是基本功,要懂操作系統(tǒng),懂網(wǎng)絡(luò),也要能寫Code,開發(fā)工具等等.開發(fā)工具并不要求是很大的平臺(tái),可以和專業(yè)開發(fā)人員一塊去開發(fā),解決問(wèn)題就好.最后,產(chǎn)品工程協(xié)調(diào)員,加強(qiáng)人與人之間的溝通.

落地PE實(shí)踐及心得

如何結(jié)合組織架構(gòu)設(shè)計(jì)技術(shù)架構(gòu)

三個(gè)角色的定義都說(shuō)完了,再說(shuō)說(shuō)如何結(jié)合組織架構(gòu)設(shè)計(jì)技術(shù)架構(gòu),這里有很經(jīng)典的康威定律原則——組織結(jié)構(gòu)會(huì)影響技術(shù)架構(gòu),技術(shù)架構(gòu)會(huì)影響到運(yùn)維架構(gòu).康威定律很重要的一點(diǎn)是說(shuō),假如團(tuán)隊(duì)里有N個(gè)人,每個(gè)人都要跟N-1個(gè)人去溝通,團(tuán)隊(duì)越大溝通成本越高.

如何設(shè)計(jì)結(jié)構(gòu)降低溝通的成本?傳統(tǒng)模式下很多公司都是職能型的團(tuán)隊(duì),開發(fā)、運(yùn)維、測(cè)試屬于不同的職能團(tuán)隊(duì),開發(fā)的人寫好代碼給運(yùn)維的人上線就行了.在新的互聯(lián)網(wǎng)公司中,除了傳統(tǒng)的職能型團(tuán)隊(duì)以外,還有實(shí)施矩陣式管理,做單元化、BU化組織架構(gòu)的,這樣可以降低溝通協(xié)作的成本.

我之前在人人網(wǎng)帶的團(tuán)隊(duì)有7、8個(gè)人,現(xiàn)在的團(tuán)隊(duì)比較大,有差不多20人.20人的團(tuán)隊(duì)怎么設(shè)計(jì)結(jié)構(gòu)?我把業(yè)務(wù)線打散到兩個(gè)不同的業(yè)務(wù)組里,這里也有一個(gè)2-pizza team的原則.假如兩個(gè)pizza都喂不飽團(tuán)隊(duì)的時(shí)候,團(tuán)隊(duì)的溝通成本其實(shí)是很高的,管理也有難度.要把團(tuán)隊(duì)打散劃分成更小的線,8人以內(nèi)是比較合適的.

我也會(huì)設(shè)一些虛擬的小組,類似于矩陣式管理,有一些技術(shù)小組做大數(shù)據(jù)、分布式緩存,Docker、Nginx 等等,目的是什么?有點(diǎn)像Google SRE的50%原則,50%的時(shí)間做開發(fā)任務(wù).但是我沒(méi)有辦法讓他將50%的時(shí)間完全去寫程序,因?yàn)橛泻芏嗍虑橐プ?而且我們也有專門的開發(fā)團(tuán)隊(duì),但我可以設(shè)一些技術(shù)的小組,分離業(yè)務(wù)和技術(shù)的事.每個(gè)人50%的時(shí)間去做跟技術(shù)相關(guān)的事情,這樣他們自己也會(huì)覺(jué)得有意思一點(diǎn),最終的目的不僅是做一個(gè)純業(yè)務(wù)的運(yùn)維,而是給PE們提升的空間.

SLM服務(wù)級(jí)別管理

下技術(shù)管理上的實(shí)踐,即使是互聯(lián)網(wǎng)公司,ITIL這樣偏傳統(tǒng)的管理方式也有很多可取的地方,我們現(xiàn)在也用得著,并不是拋棄掉所有傳統(tǒng)的理念,要根據(jù)公司的需要,不管是ITIL還是SRE,還是其它方法都可以借鑒,以此設(shè)計(jì)你的組織結(jié)構(gòu).我會(huì)保留傳統(tǒng)的東西,像SLM,在SRE里叫SLO.為什么叫SLO不叫SLA了?

因?yàn)镾LA是服務(wù)協(xié)議,更多時(shí)候是甲方和乙方簽協(xié)議.公司內(nèi)部沒(méi)有協(xié)議,而是設(shè)定一個(gè)目標(biāo),開發(fā)跟運(yùn)維間達(dá)成一致,要有數(shù)據(jù)化的考量.SLA或SLO都不只是一個(gè)可用性的目標(biāo),還包括很多的方向,比如維護(hù)的時(shí)間是否可靠?包括性能、備份、問(wèn)題解決的時(shí)間這些都是考量的指標(biāo),不只是數(shù)字.我們內(nèi)部的SLA會(huì)分得很細(xì),根據(jù)業(yè)務(wù)的類型,對(duì)不同業(yè)務(wù)的影響會(huì)有很細(xì)的評(píng)估.

變更管理

80%的故障都是變更引起.變更很頻繁,互聯(lián)網(wǎng)公司里面每天可能都幾十次、上百次的變更,測(cè)試環(huán)境沒(méi)有測(cè)試到業(yè)務(wù)的問(wèn)題的可能性是很大的.變更管理的內(nèi)容可以再看一下,比如CMDB,變更的時(shí)候還是要有基礎(chǔ)庫(kù)做記錄的,有了基礎(chǔ)庫(kù)后面才能做很多事情.

重大事件及故障管理

重大事件及故障管理,公司有問(wèn)題的時(shí)候怎么快速的解決,有很多的細(xì)則要做,我們?cè)O(shè)有服務(wù)臺(tái)、監(jiān)控這樣的崗位,通過(guò)數(shù)據(jù)更準(zhǔn)確的定位問(wèn)題,大家一同協(xié)作、排查.縮小排查范圍有法可依,比如根因分析法,排錯(cuò)法.不是簡(jiǎn)單的溝通好就行了,還要檢查變更記錄、收集問(wèn)題.

事件處理流程

很多時(shí)候,現(xiàn)場(chǎng)處理問(wèn)題動(dòng)作比較快,后面分析時(shí)復(fù)原問(wèn)題說(shuō)不清楚.操作前盡快的把問(wèn)題現(xiàn)象記錄下來(lái),包括監(jiān)控信息、堆棧信息等等,以便于后面分析.處理流程盡量梳理清楚,對(duì)應(yīng)的做分類,看問(wèn)題是常見(jiàn)的還是非常見(jiàn)的.常見(jiàn)的問(wèn)題有對(duì)應(yīng)的應(yīng)急案,快速的進(jìn)行處理就好,如果是非常見(jiàn)的,需要技術(shù)和決策人參與,看到底是緊急的問(wèn)題還是日常的問(wèn)題,快速?zèng)Q策和解決.這里更多的還是需要有協(xié)調(diào),有應(yīng)急預(yù)案,應(yīng)急的預(yù)案需要經(jīng)過(guò)演練.

故障分析會(huì)

分析會(huì)也叫復(fù)盤,有了故障以后組織故障分析會(huì),目的是為了避免相同的問(wèn)題重復(fù)的出現(xiàn),做改進(jìn).這時(shí),前面收集的信息就有用了,根據(jù)收集的信息復(fù)盤故障,大家看看當(dāng)時(shí)發(fā)生了什么問(wèn)題,怎么解決的,有沒(méi)有更好的辦法去定義故障級(jí)別,然后分析根本原因,這很重要.開故障分析會(huì)應(yīng)該放松心態(tài),開放共享,不要用指責(zé)的態(tài)度,而是追求事實(shí),去看根本原因,共同提高、改進(jìn),分清因和果.很多時(shí)候分析出的問(wèn)題并不一定是真正的原因,可能有更深層次的原因.

五問(wèn)法,?就是要多問(wèn),大家一起討論,不要停留在表面.每一個(gè)人從自己的視角去看當(dāng)時(shí)發(fā)生了什么,可以提出很多問(wèn)題,引導(dǎo)進(jìn)入深度思考.

瑣事—50%時(shí)間去做開發(fā)或虛擬技術(shù)小組的事情,SRE說(shuō)50%的時(shí)間做開發(fā),但是我認(rèn)為50%的時(shí)間不一定全做開發(fā),開發(fā)的時(shí)候也可以做一些技術(shù)的事,只要是長(zhǎng)遠(yuǎn)講,對(duì)你的組、對(duì)公司有好的影響的事,我覺(jué)得就可以了,目的是一樣的,多做自動(dòng)化,促進(jìn)大家提高能力.

自動(dòng)化—減少重復(fù)性工作,減少手工操作帶來(lái)的不確定性.很多公司做自動(dòng)化的同時(shí),導(dǎo)致風(fēng)險(xiǎn)也變多了,所以怎么樣做正確的自動(dòng)化?正確的自動(dòng)化減少了重復(fù)性的工作,減少了錯(cuò)誤,解放了人類,但是錯(cuò)誤的自動(dòng)化對(duì)應(yīng)的只是把人類機(jī)械化了.以前手工做很多次的,現(xiàn)在變成一次就執(zhí)行了,系統(tǒng)沒(méi)有給你正確的反饋.這和DevOps說(shuō)的一樣,不僅能更快速迭代的發(fā)布,還要有反饋的信息,收到有反饋的異常信息以后能快速的回滾,這點(diǎn)很重要.

很多的DevOps平臺(tái)都只是做了自動(dòng)化,但是風(fēng)險(xiǎn)是不是控制好了?系統(tǒng)能否有效反饋?發(fā)布失敗的時(shí)候能不能停下來(lái)?要做好對(duì)應(yīng)的信息反饋.錯(cuò)誤的自動(dòng)化對(duì)應(yīng)的會(huì)給出錯(cuò)誤的信息,導(dǎo)致決策失誤,這是一定要注意的.比如金融證券行業(yè),做了一定的自動(dòng)化交易(量化分析),程序自動(dòng)做投資、買賣股權(quán)、買賣股票,完全自動(dòng)化.但是如果系統(tǒng)沒(méi)有做好,就是災(zāi)難性的,風(fēng)險(xiǎn)還是很嚴(yán)重的.核心系統(tǒng)一定不要缺少人工干預(yù),并不是完全自動(dòng)化就不需要運(yùn)維了,決策或者風(fēng)險(xiǎn)非常高的地方,還是需要人去做.

最后一點(diǎn),理解構(gòu)建的東西,設(shè)計(jì)任何一個(gè)系統(tǒng)一定要知道下面具體的實(shí)現(xiàn).發(fā)布的時(shí)候告訴研發(fā)的人后面有什么風(fēng)險(xiǎn),系統(tǒng)是怎么設(shè)計(jì)的,懂了原理之后才能規(guī)避更多的風(fēng)險(xiǎn).

數(shù)據(jù)化運(yùn)維

現(xiàn)在都說(shuō)數(shù)據(jù)化運(yùn)維,有點(diǎn)類似于運(yùn)營(yíng),有些運(yùn)維做得比較好的話還是可以往公司的運(yùn)營(yíng)方向轉(zhuǎn).很巧的是,運(yùn)維和運(yùn)營(yíng)的英文的單詞都是“operation”,都是偏運(yùn)營(yíng)的方向,目標(biāo)也是一樣的,做運(yùn)維做得好的時(shí)候,應(yīng)該有更多數(shù)據(jù)化的東西給公司做決策參考.尤其是監(jiān)控跟線上處理相關(guān)的,對(duì)應(yīng)的數(shù)據(jù)都是你的來(lái)源,這些來(lái)源都會(huì)做智能運(yùn)維的數(shù)據(jù)采集,比如說(shuō)網(wǎng)絡(luò)監(jiān)控,操作系統(tǒng)監(jiān)控,DNS等服務(wù)監(jiān)控,基礎(chǔ)組件的監(jiān)控.基礎(chǔ)技術(shù)組件服務(wù),像DB、緩存、消息等,架構(gòu)的組件都需要做數(shù)據(jù)化的參考,沒(méi)有這兩部分?jǐn)?shù)據(jù)的話,做應(yīng)用級(jí)性能分析的時(shí)候就很難.

這些信息之間也會(huì)做一些聯(lián)動(dòng),舉個(gè)例子,比如某應(yīng)用的接口訪問(wèn)慢了,到底是因?yàn)榫W(wǎng)絡(luò)原因慢了,還是緩存慢了,還是DB慢了?要把這些信息做聯(lián)動(dòng)才能做更好的分析,如果做數(shù)據(jù)化運(yùn)維就需要很多數(shù)據(jù)做分析.京東金融也做了分布式調(diào)用的跟蹤,我們現(xiàn)在說(shuō)的微服務(wù),以前叫服務(wù)化,再往前是SOA,對(duì)應(yīng)的都會(huì)涉及調(diào)用鏈的關(guān)系.一個(gè)請(qǐng)求下來(lái)可能后面有幾十個(gè)、上百個(gè)應(yīng)用,這時(shí)怎么發(fā)現(xiàn)是鏈條上的哪個(gè)請(qǐng)求變慢了?我們用的是自己開發(fā)的分布式調(diào)用跟蹤系統(tǒng),也可以使用日志監(jiān)控,業(yè)務(wù)的解決方案,比如ELK、Splunk,日志易等.自己開發(fā)的系統(tǒng)能滿足我們大規(guī)模高復(fù)雜度場(chǎng)景的需要,還能和我們的CMDB,統(tǒng)一告警中心等系統(tǒng)做深度的整合.

下面兩個(gè)是業(yè)務(wù)指標(biāo),比如,支付系統(tǒng)會(huì)有支付可用率的指標(biāo)監(jiān)控,也有對(duì)應(yīng)每個(gè)銀行分類的可用率,全局業(yè)務(wù)的監(jiān)控大盤,這些都是業(yè)務(wù)方向的監(jiān)控需求,方便進(jìn)行快速的分析決策.所以,對(duì)業(yè)務(wù)連續(xù)性要求高的系統(tǒng)大多會(huì)設(shè)置一個(gè)監(jiān)控中心或是作戰(zhàn)指揮室,有很多監(jiān)控的大屏,做數(shù)據(jù)化的運(yùn)維,用數(shù)據(jù)做決策、分析.數(shù)據(jù)化運(yùn)維今后的發(fā)展空間是很大的.

智能運(yùn)維

采集大量的數(shù)據(jù)是基礎(chǔ),再發(fā)展的話,還會(huì)做事件匯總,打標(biāo)簽的數(shù)據(jù)積累.詳細(xì)來(lái)講,一方面做數(shù)據(jù)采集,一方面按事件分類.觸發(fā)一次代碼的變更上線,或者業(yè)務(wù)的機(jī)房間流量切換,或者一個(gè)網(wǎng)絡(luò)的工單,都是不同的事件,什么樣的事件導(dǎo)致了數(shù)據(jù)的波動(dòng),他們是有相關(guān)性的,要綜合的分析找出根本問(wèn)題.

再智能一點(diǎn),像我們報(bào)警會(huì)做降級(jí)或者是升級(jí),自動(dòng)判斷問(wèn)題.報(bào)警問(wèn)題對(duì)業(yè)務(wù)是否有影響?是不是重復(fù)報(bào)警?級(jí)別比較低,經(jīng)常重復(fù)報(bào)又不需要人去處理的就降低級(jí)別.另外,智能預(yù)估和自動(dòng)擴(kuò)容,人工的規(guī)則向機(jī)器學(xué)習(xí)過(guò)渡,多打數(shù)據(jù)標(biāo)簽,做一些智能化的處理.智能運(yùn)維是未來(lái)的方向,空間還是很大的.

END總結(jié)

從實(shí)踐經(jīng)驗(yàn)看,首先一定要明確公司團(tuán)隊(duì)的定位、發(fā)展方向,公司的使命、愿景和價(jià)值觀是什么.讓每個(gè)人都理解,才能產(chǎn)生比較好的團(tuán)隊(duì)作戰(zhàn)能力,根據(jù)公司的情況去看組織結(jié)構(gòu),根據(jù)組織架構(gòu)招到合適的人,設(shè)計(jì)系統(tǒng)、不斷實(shí)踐、持續(xù)迭代,分析、總結(jié),長(zhǎng)期規(guī)劃.我們雖然做技術(shù)、管理,很多時(shí)候也要借鑒商業(yè)的模式,怎樣更快速的做一個(gè)新的產(chǎn)業(yè)出來(lái).

最后一點(diǎn)我說(shuō)一下“帶來(lái)變化”,不管在哪家公司,都應(yīng)該嘗試一些新的改變,而不是簡(jiǎn)單的做重復(fù)的事情.要有一些長(zhǎng)遠(yuǎn)的規(guī)劃,多做長(zhǎng)期能帶來(lái)更大影響的事情,多做推動(dòng)個(gè)人,公司,社會(huì)進(jìn)步的事情.

文章來(lái)自微信公眾號(hào)：Charles雜談

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4227.html