[[151149]]

運(yùn)維這個(gè)話題很痛苦，你做任何的產(chǎn)品都離不開運(yùn)維。不管你用什么語言、什么平臺(tái)、什么技術(shù)，真正能夠決定你產(chǎn)品成熟度的很有可能就是你運(yùn)維的能力。

云時(shí)代的運(yùn)維

以前的運(yùn)維那么痛苦，大家卻并未做多大的努力去改變這個(gè)現(xiàn)狀，為什么?

因?yàn)樵瓉砟阋约喝ソC(jī)房、自己去采購、去調(diào)研機(jī)房、采購服務(wù)器、采購帶寬，中間出了任何問題很大可能都是機(jī)房的問題。

在云時(shí)代，尤其是在AWS出現(xiàn)之后，很多美國(guó)團(tuán)隊(duì)的運(yùn)維方式發(fā)生了極大的變化。

為什么云時(shí)代的運(yùn)維跟原來的運(yùn)維不一樣?

首先是從云主機(jī)。云主機(jī)的出現(xiàn)以前跟機(jī)房有模糊地帶的爭(zhēng)議話題全部都抹平了。有了一個(gè)供應(yīng)商專門提供云主機(jī)的服務(wù)，被上億的用戶驗(yàn)證。提供的服務(wù)其實(shí)很簡(jiǎn)單，包括一些基本的監(jiān)控，一個(gè)部署服務(wù)的入口。如果說一個(gè)云主機(jī)的服務(wù)商一大半的用戶使用情況都是很穩(wěn)定的，基本上你碰到不穩(wěn)定的概率是比較低的。其可靠性是比自己建機(jī)房、找?guī)捁?yīng)商要高。

一個(gè)專業(yè)的云主機(jī)服務(wù)提供商能夠更專業(yè)的去解決基礎(chǔ)設(shè)施的問題。你不會(huì)再面臨那么多很痛苦的問題了。

另一個(gè)本質(zhì)轉(zhuǎn)變就是彈性運(yùn)算。點(diǎn)擊一個(gè)按紐就能申請(qǐng)到一臺(tái)機(jī)器，或者是運(yùn)行API就能拿到一臺(tái)機(jī)器，在兩分鐘之內(nèi)就能完成整個(gè)申請(qǐng)、測(cè)試應(yīng)用甚至上線的過程。以前需要幾個(gè)月完成的事情，現(xiàn)在可以在調(diào)用一個(gè)API的時(shí)間內(nèi)完成。

我個(gè)人感覺，是因?yàn)榛A(chǔ)設(shè)施的變化造成了云時(shí)代的運(yùn)維跟原來的運(yùn)維有本質(zhì)的區(qū)別。

原來你做的其實(shí)是很爛的事情，大家也不會(huì)太在意，因?yàn)榫退隳膫€(gè)環(huán)節(jié)做的不好，你的老板也感覺不到。實(shí)際上它帶來的變化就是彈性運(yùn)算。

當(dāng)基礎(chǔ)設(shè)施是彈性運(yùn)算之后，實(shí)際上所有的服務(wù)都可以變成彈性運(yùn)算。

彈性擴(kuò)容

初始做產(chǎn)品時(shí)你只需要做最小的容量。用戶增長(zhǎng)后再去擴(kuò)容。

灰度上線

過去前置條件很長(zhǎng)，長(zhǎng)達(dá)幾個(gè)月甚至無法做。因?yàn)榍爸脳l件的成本非常低。我們幾乎每做完一個(gè)小的特性馬上就去做灰度上線，因?yàn)榛叶壬暇€的時(shí)間越早、發(fā)現(xiàn)問題的時(shí)間點(diǎn)也會(huì)越早，這個(gè)系統(tǒng)穩(wěn)定的時(shí)間也會(huì)越短。

每天部署

擴(kuò)容、灰度上線，實(shí)際上是一個(gè)開發(fā)的過程。整個(gè)集群的部署我們每天都會(huì)做一些微調(diào)，比如增加一個(gè)新機(jī)房，在早期幾乎是不敢想象的。但是在現(xiàn)在這個(gè)年代，這都會(huì)越來越輕量。

新增加機(jī)房

現(xiàn)在云主機(jī)服務(wù)商群雄并起，在增加機(jī)房之前，你需要做充分的驗(yàn)證。驗(yàn)證過程包括部署一整套的東西，在上面跑一些測(cè)試用戶。新增加一個(gè)機(jī)房的成本其實(shí)也是很低的。

擴(kuò)容

擴(kuò)容的過程包括：

• 申請(qǐng)機(jī)器
• 配置DNS
• 部署應(yīng)用
• 部署監(jiān)控
• 自動(dòng)測(cè)試
• 分配流量

整個(gè)過程實(shí)際上在自動(dòng)化運(yùn)維里面就是一個(gè)腳本。通常擴(kuò)容就是3臺(tái)到5臺(tái)，即小粒度的方式擴(kuò)容。3臺(tái)到5臺(tái)耗時(shí)20多分鐘，實(shí)際上你也可以認(rèn)為這個(gè)擴(kuò)容過程就是一個(gè)灰度上線或者是灰度測(cè)試。每完成一個(gè)特性就去做擴(kuò)容，先灰度上線，上線成功之后就把它切到生產(chǎn)的流量并擴(kuò)容，同時(shí)把老版本的流量或者是容量下掉，就完成了一次擴(kuò)容過程。

廉價(jià)的分配過程

我理解的彈性運(yùn)算主要是兩點(diǎn)，一是需要的時(shí)候才分配。另一個(gè)是分配過程很廉價(jià)。

這是什么概念呢?過去，分配過程成本高昂，需要有很多的前置條件?，F(xiàn)在的分配過程很廉價(jià)，運(yùn)行一個(gè)API，調(diào)用他們的一個(gè)API接口，整個(gè)分配過程就完成了，包括主機(jī)的分配、流量的分配、IP的綁定、域名解析的配置?；蛘哌€包括其他的服務(wù)，比如存儲(chǔ)服務(wù)、load balancer等。

我最早用的服務(wù)是AWS，但是現(xiàn)在國(guó)內(nèi)的云主機(jī)服務(wù)商真的做到那么成體系、配套、完整的應(yīng)該還是沒有的。有一些已經(jīng)有API了，但是跟周邊一些自動(dòng)部署模塊的整合做的不夠好。

所謂的分配過程很廉價(jià)，彈性、擴(kuò)容、灰度非常方便，兩者結(jié)合就形成了彈性預(yù)算的重點(diǎn)。

用戶隨時(shí)在線擴(kuò)容

上文提到一個(gè)結(jié)論：就沒有自動(dòng)運(yùn)維就沒有彈性運(yùn)算。

而用戶隨時(shí)在線擴(kuò)容是另一個(gè)概念。不同之處在于，上文是以運(yùn)維者的角度，或者是以產(chǎn)品服務(wù)提供者的角度來講這個(gè)問題。

我們服務(wù)的目標(biāo)用戶，早期用戶量非常少只是做驗(yàn)證沒有付費(fèi)，用戶量越來越多發(fā)現(xiàn)延遲變大了，查監(jiān)控?cái)?shù)據(jù)發(fā)現(xiàn)每天的在線用戶很多、每天交互次數(shù)很多，現(xiàn)在的通道不足以支撐那么多的用戶，你的通道可能需要去擴(kuò)展。

以前的做法是打電話給商務(wù)說“再多交一點(diǎn)錢，你們?cè)俳o我多開一臺(tái)服務(wù)器”。

我覺得那個(gè)還是傳統(tǒng)服務(wù)，云服務(wù)就應(yīng)該是純自助的。

發(fā)現(xiàn)通道不夠用了就去申請(qǐng)，考慮到主要用戶是在上海、南京，或者在西藏、西安，就需要去根據(jù)具體情況在不同區(qū)域擴(kuò)張通道。這個(gè)事情應(yīng)該是用戶自己去做，但是他需要我們?nèi)椭?，那我們幫助他的辦法是什么?實(shí)際上很簡(jiǎn)單，我們會(huì)看到哪里有資源、哪里缺資源，實(shí)際上買資源的過程就是自動(dòng)擴(kuò)容的過程。

自動(dòng)擴(kuò)容不是由運(yùn)維來驅(qū)動(dòng)，而是由使用我們服務(wù)的開發(fā)者來驅(qū)動(dòng)。

自動(dòng)擴(kuò)容

每天，我們會(huì)通過監(jiān)控系統(tǒng)查看各個(gè)模塊、各個(gè)組件的情況，一旦到了一定的基準(zhǔn)線之后，以前需要人工干預(yù)，現(xiàn)在各個(gè)環(huán)節(jié)成熟度足夠，實(shí)際上不需要人工去干預(yù)。例如，做一個(gè)配置，每天晚上12點(diǎn)到早上8點(diǎn)，哪一部分東西容量出問題了，就啟動(dòng)自動(dòng)擴(kuò)容過程。

相比之下，就算每天有運(yùn)維人員盯著，后半夜的工作能力是很弱的。其實(shí)很多運(yùn)維做的事情都可以被標(biāo)準(zhǔn)化，尤其是像擴(kuò)容這種事情，很多事情可以簡(jiǎn)單的通過擴(kuò)容讓他撐過很長(zhǎng)的時(shí)間。不管你中間運(yùn)維程序?qū)懙牟缓?、代碼不好，甚至因?yàn)槟氵x的 Erlang 沒有用 Go 的原因，無論什么原因，只要把那條路加寬就可以讓車全部通起來。

舉云巴自己的例子：有一次，系統(tǒng)突然出現(xiàn)瓶頸，超時(shí)、丟包，其中有一個(gè)集群的壓力很大。我只做了一件事情：把它的容量擴(kuò)充了一次，從原來是20臺(tái)機(jī)迅速擴(kuò)成40臺(tái)機(jī)。壓力馬上就下去了。

我就跟團(tuán)隊(duì)說“就是這個(gè)模塊里面有瓶頸”，我們沒有去看日志、也沒有去抓包。得出這個(gè)結(jié)論的原因就是發(fā)現(xiàn)入口數(shù)據(jù)一直在增長(zhǎng)、出口的數(shù)據(jù)沒有變，調(diào)用依賴模塊的請(qǐng)求數(shù)量沒有增加，入口一直在堆積、出口上不去。很簡(jiǎn)單，就說明他這個(gè)管子太細(xì)了。

#p#

云計(jì)算跟企業(yè)服務(wù)不同之處

企業(yè)服務(wù)出現(xiàn)了問題立馬停下來，但是云服務(wù)是不行的，現(xiàn)在可能有成千上萬的用戶正在用你的服務(wù)，停一分鐘就會(huì)有人開始罵人了，你的電話、你的QQ群、你的郵箱都會(huì)爆滿。正確做法是離線的去找問題在哪里。

我們將來想做的事情

把任何模塊的出入口都做很詳細(xì)的監(jiān)控，每一次請(qǐng)求甚至是每一個(gè)協(xié)議包都做監(jiān)控，我們會(huì)找出一些范式。應(yīng)該進(jìn)去多少、出去多少，出去哪些到模塊A、哪些到模塊B、哪些到模塊C，我們都有預(yù)測(cè)。一旦發(fā)現(xiàn)哪個(gè)模塊有壓力，馬上做自動(dòng)擴(kuò)容。上文提到，有壓力不僅僅是因?yàn)槿萘康膯栴}，也可能是程序有BUG。不管為何，應(yīng)該先讓它通起來，這是我一直在構(gòu)思的事情。我們后面也會(huì)在這方面投入很大的精力，希望盡快和大家分享。

團(tuán)隊(duì)分工和運(yùn)維工程師的角色

我們以前開發(fā)團(tuán)隊(duì)的分工是什么呢?就是寫代碼的人寫代碼、測(cè)試的人測(cè)試、運(yùn)維的人去敲各種命令去部署。

有一個(gè)很有趣的悖論，其實(shí)寫代碼的人比測(cè)試的人更清楚要怎么去測(cè)試，寫代碼的人比運(yùn)維的人更清楚應(yīng)該怎么去配置和部署。

實(shí)際上我們有過慘痛的教訓(xùn)，以前做極光推送的時(shí)候，每次做升級(jí)，我會(huì)在辦公室放兩個(gè)很大的白板，準(zhǔn)備出3支筆，黑色、藍(lán)色和紅色，把開發(fā)人員、運(yùn)維人員、測(cè)試人員全部叫在一起，一起寫一個(gè)很復(fù)雜的作戰(zhàn)地圖。如果一次遷移涉及到9個(gè)模塊，就把9個(gè)模塊全部畫出來，那個(gè)過程有點(diǎn)像話劇的腳本。我先說A你要先做什么事情，做完之后你要運(yùn)行什么確認(rèn)之后通知B同時(shí)要告訴我，B要干什么事情，B干完之后也要告訴我通知下一個(gè)C，然后你要干什么事情，可能有一個(gè)事情需要我們幾個(gè)人同時(shí)做。

相信大家應(yīng)該明白，A做了之后B應(yīng)該在幾秒鐘之內(nèi)立即完成另外的動(dòng)作，要不然就會(huì)出問題。這樣的事情我們每個(gè)月會(huì)做一次，凌晨2點(diǎn)干到早上5點(diǎn)鐘，還要盯到早上8點(diǎn)才能回去睡覺，非常辛苦。每次運(yùn)維要問，這個(gè)東西到底怎么配置、配置文件到底在哪里、每個(gè)項(xiàng)目是什么意思，等等。最后發(fā)現(xiàn)在強(qiáng)求每一個(gè)人寫文檔。所有的文檔寫完之后我都要去重寫。

寫文檔的代價(jià)很高，所以它的時(shí)間成本是很高的，大部分的情況大家未能寫出很好的文檔。就算寫出很好的文檔，運(yùn)維和測(cè)試也需要要花很長(zhǎng)時(shí)間去看。這三個(gè)角色之間溝通的成本非常高，溝通的效果也是非常差的。

怎么去解決這個(gè)問題?

答案：Devops

讓運(yùn)營(yíng)來參與開發(fā)。

實(shí)際上我們的做法是沒有測(cè)試和運(yùn)維。所有的事情都是由開發(fā)來做。大家的分工會(huì)有一點(diǎn)交叉，可能5個(gè)人寫一個(gè)模塊，這個(gè)模塊可能又被分成5個(gè)小模塊，可能是做特性A的人可能做了特性A的30%測(cè)試，測(cè)試用例的代碼和部署的代碼。做特性B的人做70%的特性A測(cè)試和一部分特性A的部署，這樣大家可以互相交叉。

你在寫測(cè)試和部署程序的時(shí)候，你實(shí)際上對(duì)那個(gè)東西的理解可能比寫代碼的人更深刻。因?yàn)樵谡麄€(gè)產(chǎn)品開發(fā)里面寫代碼是最簡(jiǎn)單的事情。一個(gè)好的產(chǎn)品，寫的東西大概只能占30%，還有其他的因素占到70%。

一個(gè)好的產(chǎn)品是由你運(yùn)維水平來決定的，而不是由你寫代碼的水平來決定的。

實(shí)際上部署腳本的代碼量有可能是遠(yuǎn)遠(yuǎn)超過特性的代碼，寫一個(gè)代碼會(huì)造成一大片測(cè)試腳本/運(yùn)維腳本和部署腳本的調(diào)整。DevOps 并非我們首創(chuàng)，在國(guó)外一些團(tuán)隊(duì)已經(jīng)實(shí)踐了幾年。他們沒有測(cè)試也沒有運(yùn)維，所有的人又是開發(fā)、又是運(yùn)維、又是測(cè)試。

我們開發(fā)團(tuán)隊(duì)每一個(gè)成員，除了寫好特性以外也會(huì)寫測(cè)試用例、寫部署腳本。我們招人的時(shí)候會(huì)招全棧工程師，因?yàn)槟阍趯憸y(cè)試腳本和部署腳本的時(shí)候會(huì)反思你原來寫的東西。

過去經(jīng)常遇到的問題是，運(yùn)維的人會(huì)抱怨“你這個(gè)程序怎么寫的、這個(gè)配置怎么這么復(fù)雜，根本就不知道你在搞什么”。測(cè)試的人也會(huì)說“你的接口怎么定義的?我完全看不懂，我怎么寫你的測(cè)試用例?”

現(xiàn)在，每一個(gè)工程師就會(huì)經(jīng)常反思，原來寫是否合理、是否考慮到以后將來的維護(hù)，這樣反過來又可以提高你編碼過程的質(zhì)量。

理想的部署方式

早期有很多傳統(tǒng)部署工具，比如Puppet，有一個(gè)很大的悖論。他們是用一套集群或者是用一套已經(jīng)部署好的東西，在去管理另外一些沒有部署好的東西。這就有一個(gè)雞生蛋和蛋生雞的問題。

Puppet本身的集群你怎么去做?原來的做法是運(yùn)維把機(jī)器弄好了、把所有的機(jī)器都裝好、配置全都配好，這個(gè)過程成本非常高。

我個(gè)人比較喜歡的做法是，新機(jī)器只需要支持SSH。標(biāo)準(zhǔn)的做法是申請(qǐng)好之后，把key導(dǎo)到部署機(jī)器上，調(diào)用一個(gè)API主機(jī)申請(qǐng)，用sudo權(quán)限即部署完成。配置新機(jī)的方式其實(shí)好多都申請(qǐng)好了。這和Puppet一類的部署系統(tǒng)比照，它的成本更低，沒有Master，沒有Agent，只要在這臺(tái)機(jī)器上可以連上目標(biāo)機(jī)就可以了。

Ansible概述

找到 Ansible 的過程

最早我們用 SSH 寫很多腳本，要用 SSH 連過去，也是在某一臺(tái)機(jī)器上執(zhí)行，不用在目標(biāo)機(jī)上登陸。這種做法在相當(dāng)一段時(shí)間內(nèi)是我們實(shí)際使用的手段，它實(shí)際上比 Puppet 有效。但是它有一些問題：管理成本高、腳本會(huì)越來越多。部署的過程有很多的基礎(chǔ)部件需要反復(fù)部署，幾乎是沒法管理。

后來我們用了 RunDeck，它有界面、有一定的管理能力。我們還用過 Fabric，即批量執(zhí)行命令，能做到類似部署的事情。但是，目標(biāo)機(jī)規(guī)模大了之后僅有管理的能力是不夠的。后來我們又調(diào)研過 Salt，不認(rèn)為有太大的差別。

選擇 Ansible 主要因?yàn)樨S富的相關(guān)支持，包括很多現(xiàn)有的組件和模塊和開源的 Ansible 部署和腳本。我們的團(tuán)隊(duì)不喜歡糾結(jié)。我們發(fā)現(xiàn) Ansible 沒有太本質(zhì)的區(qū)別，就開始用起來。如果沒有明確理由，我們就憑感覺選一個(gè)用。

Ansible 是通過 SSH 連接到目標(biāo)服務(wù)器，上面這兩個(gè)東西是我想了很久，我希望去擁有的特性。一個(gè)是完整的集群，只需要有一個(gè) inventory 去定義，寫出清單就可以定義集群。每一個(gè)角色的具體功能有若干 playbooks 來定義。

Ansible Inventory

這是一個(gè) Inventory 的虛擬例子。這定義了兩個(gè)角色，一個(gè)是 web-group，一個(gè)是 db-group。

Playbook的詳細(xì)案例。我們用的是 Ubuntu 12.04，所以先用 Nginx 的 PPA。

Ansible 的開發(fā)過程是寫大量 Playbooks?，F(xiàn)在 Ansible 支持的有251個(gè)模塊，特別是對(duì)于云服務(wù)的支持。像 AWS、Docker、Rackspace、OpenStack，部署腳本都放在一個(gè)子目錄下。這就意味著把別人寫的腳本拿過來，或者把別人寫定義的Playbook拿過來非常容易?，F(xiàn)在關(guān)于 Ansible 的開源腳本數(shù)量龐大，有 3000 多個(gè)項(xiàng)目，我相信這數(shù)字會(huì)越來越大。因?yàn)樗姆窒矸绞秸娴暮芎?jiǎn)單，只要把目錄拷過去即可。

關(guān)于作者

張虎

weibo: @Tiger_張虎， 云巴 (yunba.io) 創(chuàng)始人，yunba.io 云后端服務(wù)。 JPush 創(chuàng)始人，原CTO。 Oracle VM 創(chuàng)始團(tuán)隊(duì)成員。

【本文來源：運(yùn)維幫微信號(hào)】