序

最近對(duì)DevOps比較感興趣，饒有興致的在京東上看了看推薦和評(píng)價(jià)，發(fā)現(xiàn)很多人對(duì)O'reilly的這本《SRE：Google運(yùn)維解密》評(píng)價(jià)很高 。不過(guò)，O'reilly出版社出版的計(jì)算機(jī)類(lèi)書(shū)籍，質(zhì)量還是靠譜的，于是找了一本來(lái)看，對(duì)我的啟發(fā)也是蠻大的。

軟件質(zhì)量是管理能力的延續(xù)--《SRE：Google運(yùn)維解密》

一個(gè)全球數(shù)一數(shù)二的IT科技公司，除了對(duì)外發(fā)布的產(chǎn)品穩(wěn)定性強(qiáng)，自己內(nèi)部使用的輔助軟件也是卓越不凡，這就不難解釋現(xiàn)在開(kāi)源世界的一些主流框架都是那么幾家公司的產(chǎn)品了?？粗@些頂級(jí)大師寫(xiě)的文章，自己當(dāng)然是佩服不已，畢竟自己真沒(méi)有這樣的能力，但可以朝著大師的方向去努力嘛。

全本書(shū)都是關(guān)于技術(shù)和管理的經(jīng)驗(yàn)，然而我的感覺(jué)就是：

軟件質(zhì)量是管理能力的延續(xù)。

這話(huà)是什么意思呢？就是大公司之所以為大公司，它的管理一定是高效而有力的。我曾經(jīng)也在電信行業(yè)的多家公司從業(yè)，書(shū)中談到的很多經(jīng)驗(yàn)針對(duì)的就是我當(dāng)年工作的痛點(diǎn)啊。

比如在谷歌，運(yùn)維人員并沒(méi)有低人一等，而是用上了自己開(kāi)發(fā)的能力保障巨大規(guī)模系統(tǒng)的運(yùn)行，并且遇到問(wèn)題還能自己定位，然后和研發(fā)一起完成。在我的老東家，作為研發(fā)的我，時(shí)常會(huì)接到運(yùn)維同事的工單，一開(kāi)始我還算客氣，后來(lái)便開(kāi)始煩躁，然而人家真的不懂，得靠你研發(fā)去排查和反饋。在我現(xiàn)在的崗位上，運(yùn)維只能做最簡(jiǎn)單的啟動(dòng)程序或關(guān)閉程序，有時(shí)候連啟動(dòng)和關(guān)閉都得請(qǐng)廠(chǎng)家過(guò)來(lái)，更不用說(shuō)接管程序的代碼，從程序運(yùn)行中提供更多的服務(wù)和擴(kuò)展了。

殺雞就要用牛刀

Google是當(dāng)今現(xiàn)有的為數(shù)不多的，愿意投入精英力量鉆研本質(zhì)問(wèn)題的公司，而且這些精英很多都有工學(xué)博士學(xué)位。工具永遠(yuǎn)只是解決方案中的一個(gè)小小組件，用來(lái)鏈接日益龐雜的軟件、人和海量的數(shù)據(jù)。書(shū)中沒(méi)有萬(wàn)能藥，沒(méi)有什么東西能解決一切問(wèn)題，但是這恰恰是本書(shū)的宗旨：相比最后的軟件結(jié)果、架構(gòu)設(shè)計(jì)而言，真實(shí)的設(shè)計(jì)過(guò)程、作者本身的思考經(jīng)歷更有價(jià)值。實(shí)現(xiàn)細(xì)節(jié)永遠(yuǎn)只是短暫存在的，但是文檔化的設(shè)計(jì)過(guò)程卻是無(wú)價(jià)之寶。SRE，站點(diǎn)可靠性工程師，用軟件工程理念和自動(dòng)化工具定義了這個(gè)行業(yè)，這就是我對(duì)Google充滿(mǎn)敬仰的原因之一，雖然Google的有些理念我也是不認(rèn)同的。

書(shū)中講到：

SRE（Site Reliability Engineering）和傳統(tǒng)的IT運(yùn)維有很大區(qū)別，SRE真正實(shí)現(xiàn)了DevOps：

• 首先，SRE深度參與開(kāi)發(fā)階段的工作，對(duì)應(yīng)用程序的設(shè)計(jì)實(shí)現(xiàn)方式、依賴(lài)庫(kù)、運(yùn)行時(shí)的資源消耗都有嚴(yán)格的規(guī)約；
• 其次，SRE工程師本身也要做不少編程工作，來(lái)實(shí)現(xiàn)各種工具用以自動(dòng)解決問(wèn)題和故障，換句話(huà)說(shuō)，SRE強(qiáng)調(diào)的是對(duì)問(wèn)題和故障的自動(dòng)處理，而非人工干預(yù)；
• 再者，按照SRE的約定，開(kāi)發(fā)人員自行負(fù)責(zé)程序上線(xiàn)部署更新，畢竟開(kāi)發(fā)人員對(duì)自己開(kāi)發(fā)的程序更熟悉，易于處理程序上線(xiàn)過(guò)程中遇到的問(wèn)題。
• 總之，作為Google的DevOps實(shí)踐，SRE非常注重開(kāi)發(fā)和運(yùn)維職能的結(jié)合，極大地加快了業(yè)務(wù)應(yīng)用迭代周期，提升了IT對(duì)業(yè)務(wù)的支撐能力。

以往的系統(tǒng)開(kāi)發(fā)和采購(gòu)，甲方往往會(huì)受到技術(shù)認(rèn)知的壁壘，把軟件架構(gòu)、軟件質(zhì)量和未來(lái)的擴(kuò)展性都交給廠(chǎng)家，這無(wú)異于與虎謀皮。當(dāng)我14天不在廣州卻無(wú)端被廣州賦了黃碼，直接同步到貴州的時(shí)候，我猛然發(fā)現(xiàn)十多年前算法老師說(shuō)的“軟件寫(xiě)不好是要害人的”，有了更深的理解。以前的程序多用于內(nèi)部業(yè)務(wù)的支撐和交互，是一個(gè)輔助工具，當(dāng)然很多時(shí)候上頭的程序出了問(wèn)題會(huì)第一時(shí)間賴(lài)上我們的網(wǎng)絡(luò)以及硬件。有一回，整好是我在負(fù)責(zé)這個(gè)工作的時(shí)候，多用了幾個(gè)命令去追蹤信息的時(shí)候，才發(fā)現(xiàn)問(wèn)題不在我們這，當(dāng)我有理有據(jù)的反饋之后，基本上再也沒(méi)收到類(lèi)似的問(wèn)題了。

軟件工程有的時(shí)候和養(yǎng)孩子類(lèi)似：雖然生育的過(guò)程是痛苦和困難的，但是養(yǎng)育孩子成人的過(guò)程才是真正需要花費(fèi)絕大部分精力的地方。但是，傳統(tǒng)軟件工程專(zhuān)業(yè)花費(fèi)了很多精力討論軟件的開(kāi)發(fā)過(guò)程，而不是其后的維護(hù)過(guò)程。有統(tǒng)計(jì)顯示，一個(gè)軟件系統(tǒng)的40%～90% 的花銷(xiāo)其實(shí)是花在開(kāi)發(fā)建設(shè)完成之后不斷維護(hù)過(guò)程中的。

行業(yè)內(nèi)流行的一個(gè)說(shuō)法是：一個(gè)系統(tǒng)如果已經(jīng)開(kāi)發(fā)完成，部署在生產(chǎn)環(huán)境上，那么它就是 “穩(wěn)定的”，就不需要那么多工程師花費(fèi)精力去優(yōu)化、維護(hù)。Google認(rèn)為這個(gè)說(shuō)法是錯(cuò)誤的。從這個(gè)視角出發(fā)，書(shū)中認(rèn)為如果軟件工程職業(yè)主要專(zhuān)注于設(shè)計(jì)和構(gòu)建軟件系統(tǒng)，那么應(yīng)該有另外一種職業(yè)專(zhuān)注于整個(gè)軟件系統(tǒng)的生命周期管理。從其設(shè)計(jì)一直到部署，歷經(jīng)不斷改進(jìn)，最后順利退役。這樣一種職業(yè)必須具備非常廣泛的技能，但是和其他職業(yè)的專(zhuān)注點(diǎn)都不同，Google 將這個(gè)職位稱(chēng)為站點(diǎn)可靠性工程師（SRE）。相比于很多教授和學(xué)者都看不上站點(diǎn)的開(kāi)發(fā)，可這是最傳統(tǒng)的工程，隨著用戶(hù)規(guī)模的增大，完全成為了一個(gè)專(zhuān)業(yè)，而不是看不上眼的能耐，我們的一流高校還是很缺乏這類(lèi)計(jì)算機(jī)基礎(chǔ)工程與科學(xué)的研究人才，實(shí)在是令人唏噓。

前路異常艱辛

或許是專(zhuān)業(yè)的緣故，我對(duì)軟件工程情有獨(dú)鐘，畢竟如果僅有技術(shù)而沒(méi)有工程的能力，大概率是做不好一個(gè)項(xiàng)目的。過(guò)程模式就是軟件工程中的一個(gè)大分支，過(guò)程模式講的是軟件生命流程（lifecycle）中，應(yīng)該如何去做需求、研發(fā)、上線(xiàn)、運(yùn)維以及宣告一個(gè)軟件的死亡。隨著互聯(lián)網(wǎng)的崛起，并為我們提供了許多公共服務(wù)，那傳統(tǒng)行業(yè)的軟件生態(tài)必然也被倒逼升級(jí)，軟件系統(tǒng)也面臨著針對(duì)用戶(hù)日益增長(zhǎng)的業(yè)務(wù)工作需要和系統(tǒng)的不平衡不充分的發(fā)展之間的矛盾，尤其是當(dāng)下一個(gè)系統(tǒng)按照流程走最快也要三年才能落地的約束下，我們真的需要探索一條新的路子。

這是一條異常艱難的路子，但是如果我們這些科班出身的專(zhuān)業(yè)人士不去努力探索一把，那我們對(duì)得起這十幾二十年的修行嗎？運(yùn)維某個(gè)程度也是研發(fā)，對(duì)于新的系統(tǒng)，運(yùn)維必須能啃下來(lái)，然后針對(duì)某些需求還能做調(diào)整盡量適應(yīng)業(yè)務(wù)處室的需求，這才是我們要的，而盡量規(guī)避因?yàn)闆](méi)有立項(xiàng)、沒(méi)有經(jīng)費(fèi)而無(wú)法支撐業(yè)務(wù)處室需求的無(wú)奈。一個(gè)項(xiàng)目建立可信度很慢，但是失去它卻非常快。反觀(guān)Google SRE部門(mén)的工程師的特點(diǎn)：

• 對(duì)重復(fù)性、手工性的操作有天然的排斥感。
• 有足夠的技術(shù)能力快速開(kāi)發(fā)出軟件系統(tǒng)以替代手工操作。

SRE團(tuán)隊(duì)和產(chǎn)品研發(fā)部門(mén)在學(xué)術(shù)和工作背景上非常相似，所以他們可以算是內(nèi)部系統(tǒng)的研發(fā)人員。從本質(zhì)上來(lái)說(shuō)，SRE 就是在用軟件工程的思維和方法論完成以前由系統(tǒng)管理員團(tuán)隊(duì)手動(dòng)完成的任務(wù)。這些SRE傾向于通過(guò)設(shè)計(jì)、構(gòu)建自動(dòng)化工具來(lái)取代人工操作，它的成功的關(guān)鍵在于對(duì)工程的關(guān)注。如果沒(méi)有持續(xù)的、工程化的解決方案，運(yùn)維的壓力就會(huì)不斷增加，團(tuán)隊(duì)也就需要更多的人來(lái)完成工作。傳統(tǒng)的Ops團(tuán)隊(duì)的大小基本與所服務(wù)的產(chǎn)品負(fù)載呈線(xiàn)性同步增長(zhǎng)。如果一個(gè)產(chǎn)品非常成功，用戶(hù)流量越來(lái)越大，就需要更多的團(tuán)隊(duì)成員來(lái)重復(fù)進(jìn)行同樣的事情。為了避免這一點(diǎn)，負(fù)責(zé)運(yùn)維這個(gè)服務(wù)的團(tuán)隊(duì)必須有足夠的時(shí)間編程，否則他們就會(huì)被運(yùn)維工作所淹沒(méi)。

結(jié)語(yǔ)

我在想，短期內(nèi)自己無(wú)法招募培養(yǎng)這樣的一個(gè)團(tuán)隊(duì)，能做的就只能是通過(guò)自己有限的力量，整合資源，提供寫(xiě)程序以及工程實(shí)踐的能力，看是否能把現(xiàn)有的團(tuán)隊(duì)提升成DevOps的實(shí)施團(tuán)隊(duì)。

倘若成功，這算是我個(gè)人計(jì)算機(jī)生涯的一次里程碑，我終于在軟件工程這領(lǐng)域找到屬于自己的立足之地了；倘若不成功，那也算我在自己的領(lǐng)域的一種求索，路漫漫其修遠(yuǎn)兮。