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

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

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

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

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

我在華為的經歷

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

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

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

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

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

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

我在 Amazon 的經歷

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

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

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

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

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

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

?

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。