本文轉(zhuǎn)載自：http://www.raychase.net/5054，本站轉(zhuǎn)載出于傳遞更多信息之目的，版權(quán)歸原作者或者來(lái)源機(jī)構(gòu)所有。

?偶然地，在會(huì)看這些年寫(xiě)的文章的時(shí)候，發(fā)現(xiàn)涉及到軟件工程方方面面的內(nèi)容，但是關(guān)于 Ops 的內(nèi)容卻非常少。我覺(jué)得這是不太合適的，因?yàn)樵趯?shí)際工作中，Ops 顯而易見(jiàn)地占據(jù)了一大塊比重。于是我調(diào)整了分類目錄，增加了這個(gè)單獨(dú)的分類，并且這一次，我想零零散散地講一講我關(guān)于 Ops 的一些經(jīng)歷，以及關(guān)于 Ops 的一些觀點(diǎn)。

所謂 Ops，指的就是 Operations，在中文翻譯上看，我覺(jué)得“運(yùn)維”這個(gè)詞可能是最恰當(dāng)?shù)?。作為一個(gè)軟件工程師，Ops 有時(shí)會(huì)特指?DevOps?，關(guān)于它的定義，在維基百科上有這樣一張圖片，我覺(jué)得基本正確地描述了 DevOps 涵蓋的內(nèi)容（見(jiàn)右側(cè)圖）。

可以看到三方面的內(nèi)容，可是，由于我們會(huì)把 Development 單獨(dú)拿出來(lái)講，會(huì)把 QA 單獨(dú)拿出來(lái)講，因此當(dāng)我們講起 Ops 的時(shí)候，我們更多的指的就是上圖中下面那個(gè)紫色的環(huán)。

我們都希望代碼可以一蹴而就，測(cè)試可以面面俱到，軟件和產(chǎn)品都可以順利而愉快地跑起來(lái)，可這些都是一廂情愿。我們需要把新版本軟件安全快速地部署上去，在出了問(wèn)題之后需要采取措施減小影響，分析問(wèn)題，并修復(fù)問(wèn)題……這些問(wèn)題都需要 Ops 這樣不可替代的環(huán)節(jié)。由于我個(gè)人認(rèn)識(shí)的局限性，在以往，Ops 顯然是被我輕視的環(huán)節(jié)。當(dāng)然，這可能也和我工作以前接受的教育也有關(guān)。讀書(shū)的時(shí)候，我們學(xué)開(kāi)發(fā)，我們學(xué)測(cè)試，可是我們從來(lái)都不學(xué)運(yùn)維?？梢哉f(shuō)，上面這三個(gè)環(huán)的于我而言的重視程度，顯然 Development > QA > Operations，這是不可否認(rèn)的。我猜測(cè)著對(duì)于許多人來(lái)說(shuō)也是如此。但是，隨著工作經(jīng)驗(yàn)的增加，我越來(lái)越意識(shí)到 Ops 本身的重要性。于是這些內(nèi)容，打算分為幾篇來(lái)講，來(lái)自一個(gè)并不喜歡運(yùn)維的軟件工程師之手。

我在華為的經(jīng)歷

我工作的第一家公司是華為，這是一家對(duì)于 Ops 有著深刻理解和豐富經(jīng)驗(yàn)的通訊軟件公司。有意思的是，這也是在我熟悉的公司中，在 Ops 上花專人投入比例最高的一家。有許多項(xiàng)目的發(fā)布和運(yùn)行，都是基于不同物理地區(qū)和物理站點(diǎn)的，這也是電信軟件非常典型的一種部署模式。具體來(lái)說(shuō)，就是華為的工程師，需要出差到電信運(yùn)營(yíng)商那里去，去安裝部署。如果是一個(gè)全新的項(xiàng)目，這個(gè)過(guò)程叫做開(kāi)局；如果是從別的服務(wù)提供商那里把項(xiàng)目接過(guò)來(lái)（比如一個(gè)項(xiàng)目，本來(lái)用的是中興的軟件，現(xiàn)在用戶體驗(yàn)基本不變的基礎(chǔ)上，挪到華為的平臺(tái)上），這個(gè)過(guò)程叫做割接。其他我在十年前第一次出差，在中國(guó)聯(lián)通 3G 機(jī)房，位置大概在北京上地，就是去開(kāi)局。和開(kāi)局花費(fèi)的時(shí)長(zhǎng)相比，割接通常更為迅速，但是壓力更大，因?yàn)楦罱拥膱?chǎng)景通常意味著目標(biāo)設(shè)備只有非常短的服務(wù)停止的時(shí)間，甚至要求無(wú)服務(wù)中斷；另外，有時(shí)候競(jìng)爭(zhēng)對(duì)手的關(guān)系，沒(méi)有辦法得到之前系統(tǒng)完整的信息，有許多決策需要根據(jù)經(jīng)驗(yàn)來(lái)判斷，甚至猜測(cè)——比如原?數(shù)據(jù)庫(kù)?要從前一家競(jìng)爭(zhēng)對(duì)手的老庫(kù)遷移到華為的新庫(kù)，數(shù)據(jù)轉(zhuǎn)移的時(shí)候，某一列原數(shù)據(jù)庫(kù)表里的字段在原始文檔里沒(méi)有，需要根據(jù)其內(nèi)容和結(jié)構(gòu)來(lái)推理其實(shí)際含義，再轉(zhuǎn)移到新庫(kù)恰當(dāng)?shù)奈恢蒙稀?/p>

這種方式明顯更為傳統(tǒng)一些，從客戶的角度來(lái)說(shuō)，好處在于，我們跑到客戶的地盤(pán)上，在他們的設(shè)備廠房里做文章，很多事情他們都更方便控制。對(duì)于一些復(fù)雜項(xiàng)目，需要有多家服務(wù)提供商協(xié)同合作的情況，甲方客戶可以和各家乙方面對(duì)面工作，溝通和組織都會(huì)更加順暢。至于這種方式的弊端之一——成本，對(duì)于國(guó)內(nèi)的三大電信運(yùn)營(yíng)商來(lái)說(shuō)，通常都不是一個(gè)問(wèn)題。

上述成本包括人力成本，畢竟這樣的方式需要有專職的運(yùn)維人員看守。出于安全、審查等等角度的考量，設(shè)備是隔離的，網(wǎng)絡(luò)是隔離的，運(yùn)維人員需要在現(xiàn)場(chǎng)駐守，以處理預(yù)期內(nèi)或預(yù)期外的各種問(wèn)題。我們把那里叫做前方。而研發(fā)基地的工程師團(tuán)隊(duì)需要和運(yùn)維團(tuán)隊(duì)溝通協(xié)作，解決各種各樣的問(wèn)題。這就是后方。通常后方的研發(fā)工程師沒(méi)有辦法直接動(dòng)手，而是需要和運(yùn)維工程師溝通以便采集數(shù)據(jù)和分析問(wèn)題，在特殊情況下，為了增進(jìn)效率，后方的研發(fā)工程師會(huì)出差前往前方現(xiàn)場(chǎng)，直接處理問(wèn)題。

我還記得在那次開(kāi)局的過(guò)程中，要和所有周邊系統(tǒng)協(xié)同調(diào)試工作，這個(gè)過(guò)程叫做聯(lián)調(diào)。由于整個(gè) 3G 系統(tǒng)龐大，我所負(fù)責(zé)的視頻運(yùn)營(yíng)平臺(tái)，以省為單位，要和不同的服務(wù)接口，比如計(jì)費(fèi)服務(wù)等等，而甲方客戶期望分散風(fēng)險(xiǎn)，每個(gè)省份的服務(wù)又都是獨(dú)立的，而且實(shí)現(xiàn)廠商都是根據(jù)招標(biāo)結(jié)果而來(lái)，每個(gè)省份都是獨(dú)立的。因此和我們聯(lián)調(diào)的服務(wù)來(lái)自各家廠商，這樣的協(xié)同合作變得無(wú)比困難。這里面多數(shù)都非軟件的問(wèn)題，而是管理和溝通的問(wèn)題。

出于成本的考量，如今互聯(lián)網(wǎng)公司的很多機(jī)器設(shè)備多為普通性能的廉價(jià)設(shè)備，而硬件損壞的容錯(cuò)是作為整個(gè)分布式系統(tǒng)設(shè)計(jì)常規(guī)的一部分進(jìn)行的?？赡莻€(gè)時(shí)候，電信運(yùn)營(yíng)商的機(jī)器設(shè)備和如今互聯(lián)網(wǎng)公司是大不一樣的。我還記得我們的軟件是部署在整個(gè)機(jī)架中間的數(shù)塊單板上的，存儲(chǔ)系統(tǒng)是部署在磁盤(pán)陣列上的，而數(shù)據(jù)庫(kù)是部署在 IBM 小型機(jī)內(nèi)的……于是我們?cè)S多的 Ops 操作，都是基于單臺(tái)機(jī)器進(jìn)行的。加上聯(lián)調(diào)的許多工作，存在大量重復(fù)性的勞動(dòng)。為此我寫(xiě)了很多 shell 腳本，來(lái)幫助提高工作效率，當(dāng)時(shí)覺(jué)得很自豪?？墒呛髞?lái)才慢慢感受到，真正優(yōu)秀的 Ops 流程，是不需要自己現(xiàn)場(chǎng)去手寫(xiě)這些腳本的，工具應(yīng)該幫我們干了幾乎所有的事情。手動(dòng)腳本是介于手動(dòng)命令和?工具?之間的手段，但總體來(lái)說(shuō)依然是一個(gè)容易犯錯(cuò)而且缺乏延續(xù)性的做法。一個(gè)成熟的運(yùn)維流程，應(yīng)該把這些犯錯(cuò)的可能減到最小。

這種 Ops 的模式可以讓研發(fā)團(tuán)隊(duì)的工程師更專注于本職的研發(fā)工作，但是也會(huì)帶來(lái)和實(shí)際場(chǎng)景脫節(jié)的問(wèn)題。比如說(shuō)，我在那個(gè)聯(lián)通項(xiàng)目之后，轉(zhuǎn)去做某一個(gè)新產(chǎn)品的基線版本了，基線版本多數(shù)情況并不直接上線，而是需要由定制團(tuán)隊(duì)進(jìn)行本地化和具體項(xiàng)目化的定制，之后才能發(fā)布上線。這就足以見(jiàn)得我們離實(shí)際產(chǎn)品部署有多么遙遠(yuǎn)了。由此產(chǎn)生的其中一個(gè)典型問(wèn)題就是，當(dāng)時(shí)我們做的那個(gè)產(chǎn)品中，網(wǎng)站的那部分，由于搜索引擎優(yōu)化等等問(wèn)題，居然被 Google 爬蟲(chóng)給爬死了。這樣嚴(yán)重的事情等一層一層分析、討論和傳播上來(lái)，等我們獲知這樣變體了多次的消息的時(shí)候，已經(jīng)過(guò)去了很長(zhǎng)一段時(shí)間，有一些具體的有價(jià)值的信息也丟失了，這讓我們覺(jué)得離實(shí)際的產(chǎn)品仿佛很遙遠(yuǎn)。

我在 Amazon 的經(jīng)歷

Amazon 的庫(kù)房遍布世界各地，而且更為零散和復(fù)雜，因而這種需要奔赴現(xiàn)場(chǎng)才能進(jìn)行 Ops 的模式，多數(shù)情況下都是不適用的。Amazon 的不同團(tuán)隊(duì)會(huì)負(fù)責(zé)不同的服務(wù)，多數(shù)服務(wù)只用中心數(shù)據(jù)庫(kù)或者數(shù)量有限的幾個(gè)區(qū)域數(shù)據(jù)庫(kù)，少數(shù)服務(wù)才在當(dāng)?shù)貛?kù)房里面設(shè)置數(shù)據(jù)庫(kù)。在 Amazon 內(nèi)部，有一套專門負(fù)責(zé)版本管理和部署的工具，軟件版本、依賴項(xiàng)目、包管理、分析、編譯、測(cè)試、部署，等等等等，全部都由這套工具來(lái)完成。無(wú)論是 1 臺(tái)機(jī)器，還是 100 臺(tái)機(jī)器，軟件工程師要做的，就是在適當(dāng)?shù)臅r(shí)候，盯著這套工具提供的界面，把軟件按照指定的某種方案，部署到實(shí)際的機(jī)器上面去。任意兩臺(tái)機(jī)器具體部署的代碼版本，通過(guò)工具就可以對(duì)比，如果要打補(bǔ)丁，要升級(jí)系統(tǒng)，要改權(quán)限，這套工具就可以完成。換言之，多數(shù)情況下都不需要 ssh 登陸到具體的機(jī)器上去。

我有一些互聯(lián)網(wǎng)大公司的朋友，包括國(guó)內(nèi)國(guó)外，從側(cè)面了解過(guò)，再加上如今我所在的公司，綜合比較起來(lái)，Amazon 內(nèi)部提供給工程師用于 Ops 的工具應(yīng)該說(shuō)多數(shù)都非常先進(jìn)，有些能夠領(lǐng)先業(yè)界好幾年，而這套部署工具尤其可以說(shuō)極少公司能出其右（我以前的一位老板打趣說(shuō)過(guò)它是 Amazon 內(nèi)部“四大金剛”工具之一）。其實(shí)，極少有公司愿意在沒(méi)有必要的情況下把一個(gè)內(nèi)部工具功能做得無(wú)比強(qiáng)大，更何況是以 frugality 作為領(lǐng)導(dǎo)力準(zhǔn)則之一的 Amazon。其原因之一就是，工程師的成本。招聘運(yùn)維團(tuán)隊(duì)的工程師，其實(shí)并不容易，而如果能夠用盡量少的研發(fā)工程師團(tuán)隊(duì)，“順便”去把運(yùn)維的事情做了，這無(wú)疑是很節(jié)約成本的事情。從這個(gè)角度說(shuō)，資源的限制才能促進(jìn)創(chuàng)新和發(fā)展。

有了一系列 Ops 工具，Amazon 不需要招特別多的專職 Ops 團(tuán)隊(duì)，而多數(shù) Ops 工作自然由不同的工程師完成。其中一個(gè)最典型的事情就是 oncall。所謂 oncall，就是值班，一般研發(fā)團(tuán)隊(duì)里的工程師輪值，一旦出現(xiàn)嚴(yán)重的線上問(wèn)題，警報(bào)就會(huì)想起，這個(gè)過(guò)程叫做 page，這種情況一旦出現(xiàn)，不管是上班時(shí)間還是下班時(shí)間，都要立刻投身問(wèn)題應(yīng)急處理的行動(dòng)中去。事實(shí)上，Google 也好、Facebook 也好，Netflix 也好，專職 Ops 團(tuán)隊(duì)的人數(shù)相對(duì)研發(fā)整體來(lái)說(shuō)都比較小，但是我依然認(rèn)為 Amazon 是其中最不容易的一個(gè)，因?yàn)?Amazon 的許多產(chǎn)品和服務(wù)尤其需要繁重的 Ops 工作，在如今的公司做了將近一年的云設(shè)施的工作才慢慢了解，和其它一些互聯(lián)網(wǎng)服務(wù)比起來(lái)，提供基礎(chǔ)設(shè)施的 AWS 需要的運(yùn)維工作量非常非常巨大。

有人說(shuō)，讓研發(fā)工程師去做運(yùn)維，能做好嗎？不是應(yīng)該讓專業(yè)的人去做專門的事情嗎？這個(gè)觀點(diǎn)是兩說(shuō)的，運(yùn)維技能的缺乏可以通過(guò)優(yōu)秀的運(yùn)維工具來(lái)環(huán)節(jié)；而另一方面，每多一種“專業(yè)的人”，就意味著整個(gè)工作系統(tǒng)中，多了一個(gè)角色，多了一個(gè) N 個(gè)需要溝通的環(huán)節(jié)，這些都是內(nèi)耗。我在這篇文章 里面曾經(jīng)比較過(guò)使用專業(yè)運(yùn)維人員和使用研發(fā)人員來(lái)代理運(yùn)維工作的情形。這種方式下，出現(xiàn)的問(wèn)題能夠最快速度和最大程度地引起開(kāi)發(fā)人員的注意，有反向強(qiáng)化軟件質(zhì)量的作用。我相信多數(shù)軟件開(kāi)發(fā)工程師都不喜歡 Ops，這也容易理解，但是不參與 Ops 是很難想象能夠做好產(chǎn)品的。

說(shuō)一個(gè)具體事例。我記得在 Amazon 的銷量預(yù)測(cè)團(tuán)隊(duì)工作的時(shí)候，有一次我 oncall 被 page 醒，因?yàn)樾掳l(fā)布的軟件本身暴露出來(lái)了一個(gè)問(wèn)題，于是著手回滾到上一個(gè)版本。可是經(jīng)過(guò) rollback 之后，發(fā)現(xiàn)問(wèn)題并未解決，調(diào)查獲知原因是客戶端緩存了前一個(gè)版本的某些有問(wèn)題的信息，于是連夜趕補(bǔ)丁，刷新客戶端內(nèi)的信息，從而修復(fù)問(wèn)題。事后，我們團(tuán)隊(duì)排查了類似的問(wèn)題，相當(dāng)于吃一塹長(zhǎng)了一智。這樣嚴(yán)重的問(wèn)題不經(jīng)過(guò) oncall 這樣典型的 Ops 經(jīng)歷，是很快速難反向強(qiáng)化回代碼上的。

在我目前的公司中，Ops 方面所采用的方式和 Amzon 是類似的，Ops 在每個(gè)研發(fā)團(tuán)隊(duì)中的占比不同，我見(jiàn)過(guò) 10% 的，我也見(jiàn)過(guò) 80% 的。在我目前的項(xiàng)目團(tuán)隊(duì)，由于種種原因，Ops 的比重大概占到 40% 左右，這比我今年在前一個(gè)項(xiàng)目組中的 Ops 高了近一倍，也比我在 Amazon 期間最后一個(gè)團(tuán)隊(duì)的 Ops 工作量 30% 高，以我的理解來(lái)說(shuō)，這明顯偏高。其中的原因比較復(fù)雜，我們希望我們能夠努力把它降到 25% 左右。當(dāng)然，這并不是一件容易的事情，我對(duì)此也有一些思考，有關(guān)的內(nèi)容等合適的時(shí)候再說(shuō)吧。

?

以上所述就是小編給大家介紹的《談?wù)?Ops（一）：我的運(yùn)維經(jīng)歷》，希望對(duì)大家有所幫助，如果大家有任何疑問(wèn)請(qǐng)給我留言，小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)?碼農(nóng)網(wǎng)?的支持！

總結(jié)

以上是生活随笔為你收集整理的谈谈 Ops（一）：我的运维经历的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。