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

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

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

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

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

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

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

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

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

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

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

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

我在 Amazon 的經(jīng)歷

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

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

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

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

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

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

?

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

總結(jié)

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

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