【51CTO專訪】在之前的一次專訪中，淘寶仲明簡單介紹了阿里運維部的代碼發布機制、監控機制和故障響應機制。今天，我們邀請到了SinaEdge平臺運維主管劉宇，來談談他們那里的相關機制。本文是采訪的***部分，介紹其代碼部署機制。

[[105787]]

SinaEdge平臺運維主管 劉宇（守住每一天）

劉宇網名是守住每一天，大家可以在微博上跟他交流。同時，他也是LinuxTone.org的創造人之一，在自動化運維方向有一定的研究。另，他現在在招人，需要中高級運維，感興趣的同學們可以去私信他。

以下為采訪實錄。

51CTO：劉宇你好，感謝您接受我們的采訪！那么，先請你聊聊新浪CDN的代碼發布機制是什么樣的，使用了哪些工具，走的哪些流程。

劉宇：公司級別的代碼發布的話，正常來講是有兩塊，但我們這邊主要用的是Git，然后Git去結合puppet這套來做發布。這是我們組專門做的，就相當于自己的一套比較簡單的代碼發布系統。

但是公司有一定的要求，就是代碼是要在公司里面去存檔的。公司那級別用的SVN。因為我們做代碼的話呢，會先要在公司的SVN里面去走一遍。這一塊其實也沒什么，update上去就完了，就相當于是一個存檔了。然后我們這塊主要就是通過Git去發布。

51CTO：相當于一個代碼庫同時走Git和SVN。

劉宇：對。代碼庫是這樣去存的。但是我們每一次的代碼發布的話，會把它打成一個包。目前我們的倉庫管理的話，主要是基于yum，因為我們線上大部分的設備都是CentOS，因此我們都通過yum去管理這個代碼的版本。然后每次打版本的時候，如果不是重大的那種變更的話，比方說現在的版本是v1.1.1，那我們在發布一個新版本的時候呢，會把它打成v1.1.2，然后同時會打一個v1.1.3。這相當于一個回滾的機制。我打包是v1.1.1，然后我要升級的包是v1.1.2，我會把原來的v1.1.1的包，打成v1.1.3。

51CTO：相當于單數的是一支，然后雙數的是另一支。

劉宇：對，就是相當于一種回滾機制。比方說，我要是說小范圍的，因為這個時候發現v1.1.2有問題，我在回滾的時候沒法去回滾到v1.1.1嘛。

51CTO：Git好像是可以回滾的吧？

劉宇：沒有，這個回滾指的是在線上發布的時候。如果只是代碼級別的回滾的話，那很容易去操作，我Git clone出來一個分支，check out這個分支，立馬就可以回滾回去。我們也可以采用開源的capistrano來實現代碼級別的發布。

但是如果你在生產環境中把它打包了，然后上線，要有一個逐步生效和配置的過程，因為有可能你的一個生產周期，不知道什么時候會有一個大的bug。這個時候回滾的時候，我們會有兩個包。

一般上線變更，公司會要求有三個梯度。

所謂梯度，是按照重要級別去做的。不同的梯度，一個是審核的長度不一樣。然后，如果你的是非常非常重要的一個代碼發布，那么走的梯度，除了線上的一些流程之外，還會有些線下的流程，包括人工的審核，兩個人的互相配合，兩個人去做代碼review，然后兩個人去做上線的review等等。

51CTO：這個梯度是怎么決定的？

劉宇：根據影響范圍，和上線的范圍，包括我這個上線的代碼的核心度，會影響到哪些主要的功能，然后會開一個小圓桌會議去討論一下。通常它影響的范圍會包括開發和運維，然后包括我們的boss會在一起去討論。

51CTO：就比如說，微博，它的聊天功能要做一個修改。你們怎么決定它是三級中的哪一級？

劉宇：打個比方，比方說前端我們要做一些URL的合并，讓來自一個用戶訪問10個的URL，如果是同一個App ID或者是同一個ID的內容，我們就把這個URL做一些合并，這樣我們回源去取數據的時候可以只取一份。通常來說很多軟件是不具備這種功能的，所以我們要自己要去開發，這就是一種功能。

在我們來講，這是一個代碼模塊。那我們把這個模塊上線的話，至少是一個***級別的變更。

51CTO：***級別？為什么呢？

劉宇：因為你不知道這個URL是不是會回源成功，是不是會回源去取真正的數據，有可能你會回源取不到數據，或者說這個URL會請求失敗，對用戶的影響，就是比方說5:1的比例能夠出現一個故障。因為它直接面對用戶。因為是用戶的URL請求的時候在回源去回數據，那么有可能這個用戶，你合并的時候出現了問題，或者說你沒有合成功。沒有合成功也好，你就單獨回去取數據，但是你不知道的原因，就是你有可能合了，但是你回源沒有取數據，對吧。或者說你在合的時候這個地方判斷失誤。

51CTO：這種就屬于級別***的了。

劉宇：嗯，可以把它列為級別***的。在判斷它是不是級別***的時候，其實沒有特別鑒定的標準，最重要的是根據影響來的。根據它對用戶的影響。

51CTO：那如果是一個比較冷僻的產品，或者只是某些性能上的調整，可能級別就低一些？

劉宇：低級別的話，可能我只是上線一個測試的一個模塊，對線上影響是幾乎沒有的，我們可以把它定義為不是非常重要的變更。

51CTO：相當于是由技術經理來做一個初步的判斷。

劉宇：對，我們做一個初步的判斷。

51CTO：那這個部署的時候也是先從一臺服務器開始，再部署十分之一，再推送這樣么？

劉宇：目前我們的部署，我覺得不是很智能，還沒做到那種像Akamai他們那種級別，或者像Facebook他們那種BT的部署方式，我覺得是很牛叉的。我們目前部署的話，至少可以做到程序員他們那邊自己的代碼程序，在線上是經過一輪測試的。他們自己的一輪測試是不需要我們運維去干預的，因為這塊時間是可以省下來的。他們自己會有單獨測試的環境。

51CTO：從開發提交到運維組，中間會有一輪測試么？

劉宇：這個地方目前是沒有人員介入的，會自動完成。所以說，它的這個版本，開發在自己的環境里面測試穩定了，才會去提交這個版本的發布。這個版本發布的時候，***個梯度上線的情況下，我們是不需要去干預的。它會先上線到我們提供的一臺不是很重要的一個服務器上去，只是一臺，然后這臺監控的話力度是跟其他的不一樣的，它的力度比較大。

一方面它的監控力度會比較大，另外每次也會根據它的功能去調整。如果說缺少某一項功能，那么在沒有舊功能的情況下，就會去增加，開發自己也會去做一些，因為開發對它這個功能的模塊是比我們運維要熟悉的。因此，它會在這個層面上面去做一些二十四小時的監控，以及一些人為的查看，以保證它的穩定性。一般我們的這個時候的周期一般在一兩天。

然后，開發會提代碼上線的需求，這個時候會走一些流程，然后我們就會進行一些判斷，比方說它是重要級別是多少，比方是一二三，三級別就是重要級別，那我們就會讓他去說，你這個上線周期可能會要到一個月。

我們按灰度上線，***的灰度其實是有一個月，有時甚至是有三到五個月。因為我們出現過那種變更，潛伏了個把月，然后再爆發出問題的。

51CTO：這是有可能。

劉宇：所以說公司對于這種灰度級別的重要變更，這些事情把握得比較嚴；但一年來說，一個平臺也就那么一到兩回。

如果是特別重要的那種，架構改變的情況下，那是另外一套單獨的審批流程。

51CTO：那個比級別三還要高？

劉宇：對，那個都不在代碼發布系統里面了，公司會有專門的架構評審，組織委員會對架構進行評審，各個細節的，更加復雜了。因為公司，反正從微博弄一直到現在，出了N多故障，其實是很正常的對不對。這其中可能有百分之九十幾，都是變更造成的。要不就是我變更的時候你沒有確認，然后完了，我就不管了。行，今兒沒問題，明兒沒問題，后天啪——全掛了。

51CTO：意思是開發變更的時候，運維沒確認？

劉宇：對，要不就是運維A變更了，運維B沒有跟進，會出現類似于這樣的事情；要不就是運維變更完了，開發沒有確認。因此公司為了杜絕這個事情，會要求每次變更的時候，灰度一級別的情況下，你不需要干預，做就行了；到達高一層級別的，就必須要有兩個人做這個變更，一個做一個review。到達***級別的情況就更不用提了，更多人會參與進來。

我說沒有做到像Facebook那種級別，就是因為人家改代碼上線是在全球的，那種BT發布系統，并且采用了一個算法，把變更推送給體驗用戶，只有體驗的用戶才會看到這個變更；有可能你不是體驗用戶，那我給你看到的不是新版。我看到的是新版，我有問題，我會根據后臺的一個界面，然后反饋所有的bug，然后提交上去。所以說，我們現在還不是這種牛逼的級別，因為這種東西一般會針對客戶端，而在于CDN廠商來講的話，一般來講要做得這么細致的情況下，可能會是發散到全國各個機房，每個機房里面去做一臺服務器的變更，然后這個沒有變更，這個沒有問題了，然后再擴充。我們現在只是到一臺服務器，然后再到一個節點，一個節點確定沒問題之后，然后再做灰度的慢慢逐步上線。這個變更的周期也是根據梯度來的。

51CTO：你們這邊做測試時用什么工具？

劉宇：我們代碼review都是叫開發自己做，我們不需要再做代碼的review。開發那邊會有開發的一套代碼review的流程，除了開發人員之外，還有開發經理在做。

我們更多的是關注于它的穩定性，它是不是有一些重大的bug，或者安全漏洞，然后會不會有一些很低級的那種錯誤，比方說它不規范，我們都會打回去。類似于這樣的情況。

51CTO：比如注釋做的不全之類的？

劉宇：對，這種都會。

51CTO：能不能具體說說，每個梯度需要多少人，或者是什么級別的人來審核？

劉宇：***級別的灰度比較低，通常兩個人審核就夠了，一個是開發主管，一個是運維主管，兩個人作為審核，交叉審核，交叉審核之后依然沒什么問題情況下，就會有一個人去實施，這樣的一個流程就夠了。所以實施就是運維一個開發一個，也就是說干活的人有兩個，審核的人有兩個，這個級別相對還是比較容易的，不會有太大問題。

往上一個級別后，會多一個經理進來，也就是開發主管和運維主管的上級。

第二級別的變更，其實是根據它上線的這個代碼的功能情況去做判斷，一般來講會根據它的影響范圍，判斷它是灰度幾，就是看它上線的這個東西會對用戶有多大的影響。

未知的更不用說了，如果都不知道會有什么樣的影響，那么就對不起了。每次上線的時候開發都必須跟我們去講，講明白這個東西是做什么用的，然后運維根據它這個需求去查一些相關的資料，去看一下可能會對線上造成什么影響。因為并不是所有的領域每個人都很精通嘛，我們只要把握在我們的關注點就行了，對我們而言，穩定***。

第三級別的話就是說，如果它上線的這個模塊，對用戶的影響是我們可以評估出來的，我們就會直接走到我們的部門總監那里，在部門總監那邊走審批。部門總監那把握度就會不一樣了，它那個級別的話，除了走線上的流程，還會走一些線下的流程。線下的流程可能就是一個指示單，然后會有一些協議，然后這個時候參與人員會變成運維兩個，開發兩個，就是在真正實施的時候，除了剛才我們說的局部到全局慢慢上線的之外，然后實施人員會變成四個，實施周期會變成至少一個月。

51CTO：這個周期是指上線之后還有監控觀察的周期？

劉宇：對，比方說我上線了一臺服務器，這個一臺服務器你至少要觀察七天，相當于一周。然后，你在上線到一個節點的時候，必須要觀察兩周，就類似于這樣的情況。然后觀察完成之后，你再逐步再上線，直至上線完成。一般情況下，至少是一個月，很少說在一個月能全部都上線完成的。總監一般會跟進一下這個事情。

51CTO：那比如說我部署到一個節點，然后出了問題，會怎么處理？

劉宇：因為在每一個環節，我們每更新一個，然后會通告，然后在一周之后匯報一下這個情況，如果ok，沒有問題，然后再說明我在繼續下一步，會做什么事情。然后到下一步之后，如果說出現問題了，在出現問題的情況下，就會走最開始我們說的那個版本回滾的機制。也就是說，現在它的版本已經更新到***版本了，我們在puppet只需要在后臺去改一下，然后可以立馬實施生效的，回滾非常的快，直接就完成回滾了。

51CTO：這相當于v1.0.2變成v1.0.3。

劉宇：沒錯，這相當于我們小版本往前走了兩個版本，實際上v1.0.3和v1.0.1是一樣的，實際上做變更是沒有做，但是至少我們通過這樣的方式就已經保證它的運行，并且回滾的非常快。

51CTO：對，而且這樣你就能知道中間做了什么。

劉宇：沒錯，畢竟我知道這個v1.0.2里面有什么問題，它有哪些bug，等等。如果這個時候再想要變更，那這個時候就要等到v1.0.4和v1.0.5了。我覺得在我們大平臺來講，這是個比較新穎的方式。