最近我們聽到很多關(guān)于敏捷運(yùn)維的消息。包括很不錯(cuò)的演講、文章，還有一些激烈的討論。它被稱作是“創(chuàng)業(yè)公司的秘制調(diào)味醬”。對于我們這些并非處在創(chuàng)業(yè)公司或者Web 2.0公司中的人來說，它的意義何在呢？我們是否可以讓敏捷運(yùn)維在已經(jīng)創(chuàng)建的大型企業(yè)中發(fā)揮作用呢？

我想答案應(yīng)該是：“可以，但并不容易。”本文中，我會和你一起討論采用敏捷運(yùn)維的障礙，以及你可以使其發(fā)揮作用的一些方式。

敏捷運(yùn)維概述

敏捷運(yùn)維來自于兩個(gè)截然不同的陣營。首先，敏捷和精益軟件開發(fā)者意識到，很好的、密集的迭代會快速生成可發(fā)布的產(chǎn)品，但部署卻比較花費(fèi)時(shí)間。由于產(chǎn)出量的要求，這些團(tuán)隊(duì)發(fā)現(xiàn)，當(dāng)他們將代碼簽入到源代碼控制系統(tǒng)中時(shí)，價(jià)值流并沒有到達(dá)終點(diǎn)；只有把代碼部署到網(wǎng)絡(luò)上并開始創(chuàng)收的時(shí)候，價(jià)值流才到達(dá)終點(diǎn)。也就是說，情況是“完成，完成，才會完成”而不是“完成，就完成了”。在短迭代之后，發(fā)布會有很大的延遲，這樣也是不合理的。更壞的是，手動的部署和配置會引入人為的錯(cuò)誤。真正的敏捷團(tuán)隊(duì)希望可以自動完成所有重復(fù)性的任務(wù)，當(dāng)然也包括部署在內(nèi)。

另外一群將我們引入到敏捷運(yùn)維的人來自于快速增長的Web 2.0公司。這些公司有時(shí)會在兩個(gè)星期內(nèi)增加上千臺服務(wù)器。如果他們試圖手工完成，那么全美國一半的人會是Facebook的用戶，而另一半的人都是Facebook的管理員。顯然，他們需要一些辦法來將架構(gòu)納入到管理之中。這些公司從命令式（手工的）操作轉(zhuǎn)換為聲明服務(wù)器所需要的最終狀態(tài)，從而達(dá)到可擴(kuò)展的運(yùn)維。

盡管大多數(shù)關(guān)于敏捷運(yùn)維的演講都以工具為中心，但其實(shí)工具的重要程度***。從工具開始討論敏捷運(yùn)維，就像是通過學(xué)習(xí)JUnit和Hudson來學(xué)習(xí)敏捷軟件開發(fā)一樣。你可以模仿那些實(shí)踐，但是當(dāng)環(huán)境發(fā)生變化的時(shí)候，你就無法做出有效的響應(yīng)。工具應(yīng)該是用來支持敏捷原則的。對于運(yùn)維來說，敏捷原則包括：

1. 溝通
2. 短的反饋周期
3. 簡單
4. 勇氣
5. 透明
6. 承擔(dān)責(zé)任
7. 反應(yīng)
8. 對技術(shù)優(yōu)勢的持續(xù)關(guān)注

這些原則以多種方式得到了證實(shí)：

1. 完全自動化的系統(tǒng)構(gòu)建（并非只是啟動服務(wù)器，而是重新構(gòu)建一切）
2. 通過版本控制系統(tǒng)進(jìn)行配置管理
3. 對監(jiān)控和統(tǒng)計(jì)數(shù)據(jù)的廣泛訪問
4. 自愿的“壞了就換”機(jī)制
5. 優(yōu)先使用從系統(tǒng)中自動抽取文檔
6. 針對硬件隨需而變的態(tài)度添加或者替換服務(wù)器并不是大事件

和敏捷軟件開發(fā)一樣，敏捷運(yùn)維顯然與那些“牛仔”管理員的方式不同，他們只會狂亂地管理系統(tǒng)而沒有任何計(jì)劃和文檔。與之截然不同的是，敏捷運(yùn)維需要很好的自律。運(yùn)維必須確保所有一切內(nèi)容都在版本控制之下。他們只會接受徹底自動化的東西。永遠(yuǎn)不會允許手動操作的存在。

#p#

障礙和沖突

敏捷運(yùn)維聽起來很美好。只要簽入你的代碼，確保它在CI服務(wù)器上構(gòu)建，然后更新一個(gè)方法，就可以看著你的改變?nèi)ジ淖兪澜?。有些人看不到這樣做明顯的好處，他們都是老土，毫無希望，或者只是在保護(hù)他們的飯碗，不是嗎？

但是，看花容易繡花難。就像Scott Adams所說：“任何你不懂的東西都很容易。”但道理會更加復(fù)雜。人們不會因?yàn)橛薮赖幕蛘呶鋽嗟脑蚨С謱?shí)踐，但是會因?yàn)樗麄円徑庠谕庑锌磥聿幻黠@的壓力而那么做。

運(yùn)維小組總是會關(guān)注于利益相關(guān)者的不同甚至相反的需求。試圖引入變更，而不考慮這些力量，這會讓你非常沮喪，很可能會導(dǎo)致失敗。下面是運(yùn)維——不管是否是敏捷的——所要關(guān)心的問題。

審計(jì)和遵從

在努力達(dá)成有效監(jiān)管的過程中，運(yùn)維起到了很重要的作用。任何公開上市的公司都必須能夠證明他們的財(cái)務(wù)狀況的準(zhǔn)確性。在美國，從2002年塞班斯法案通過以來，如果發(fā)現(xiàn)財(cái)務(wù)結(jié)果被篡改，那么公司的主管就有可能被刑事逮捕。最關(guān)鍵的條款是第404條，它提出了公司要通過財(cái)務(wù)報(bào)表達(dá)到內(nèi)部控制。這沒錯(cuò)，如果審計(jì)者發(fā)現(xiàn)系統(tǒng)管理員和ICFR狀況很差，那么CFO最多可能會被判入獄20年。

但SOX內(nèi)容的含糊一直為人們所不滿。安全交易委員會（Securities Exchange Commission）和公共公司財(cái)務(wù)監(jiān)管委員會（Public Company Accounting Oversight Board ）都提出了多種指導(dǎo)意見。既便如此，審計(jì)者還是需要解釋許多問題。每年他們都會創(chuàng)建很多案例，然后對其進(jìn)行討論、接受或者推翻。這導(dǎo)致的不確定性，加上提供沒有發(fā)生篡改情況的證據(jù)的問題，使得公司對于他們的控制非常急躁。

我要向你講述一個(gè)關(guān)于支付卡行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn)的故事。其中的細(xì)節(jié)會有所不同，但總體上的意味是相同的。只是VISA還不會讓任何人坐牢。

這里的關(guān)鍵問題在于對“控制”的定義。在審計(jì)術(shù)語中，控制沒有技術(shù)上的標(biāo)準(zhǔn)，而只是一些過程，通過它們可以訪問標(biāo)準(zhǔn)，并在一定周期的基礎(chǔ)上進(jìn)行審閱。你的審計(jì)者會尋找的最重要的控制之一就是角色的分離。也就是說，編寫代碼的人不能來發(fā)布自己的代碼。此外，一旦代碼被發(fā)布，對于管理員來說，就不可以再對其進(jìn)行改變。在這里，“不可能”并不意味著文件是不可編輯的，而是意味著它不能在任何人都不知道的情況下進(jìn)行編輯。

在實(shí)踐中，這意味著敏捷運(yùn)維——特別是開發(fā)運(yùn)維——會在審計(jì)者的檢查中出現(xiàn)很多警告。我向你保證，如果開發(fā)與審計(jì)之間有爭論，審計(jì)肯定會勝出。你***祈禱，如果你在已經(jīng)上市或即將上市的公司中工作，那么在引入敏捷運(yùn)維之前就會遭遇審計(jì)問題。

敏捷運(yùn)維能夠提供補(bǔ)償式的控制。例如，如果生產(chǎn)環(huán)境中所有的變更都完全自動化，那么版本控制系統(tǒng)會保留每個(gè)人的修改記錄。這樣就很容易從版本控制工具中得到報(bào)表，從而審計(jì)會認(rèn)為這些變更是被授權(quán)了的。如果你對所有部署的程序包進(jìn)行SHA哈希加密，那么就可以證實(shí)沒有在自動部署過程之外做過任何的修改。這些機(jī)制可以支持合理的ICFR。

然而，如果在切換到敏捷運(yùn)維之前進(jìn)行討論的話，那么你還有很多工作要做。

ITIL

IT架構(gòu)庫是針對IT運(yùn)維過程的配置框架。這一大串文字不會告訴你詳細(xì)的內(nèi)容，但是你應(yīng)該對其有所了解。

ITIL為IT組織提供了高質(zhì)量運(yùn)維的藍(lán)圖。它是一種模板，源自英國政府十九世紀(jì)八十年代對大型機(jī)的運(yùn)維方法。是的，真的是那樣。ITIL現(xiàn)在***的版本是3，它已經(jīng)被多個(gè)公司采納，作為圍繞一系列日常任務(wù)進(jìn)行標(biāo)準(zhǔn)化過程的方式：“我們有什么？”，“它是否正常工作？”，“為什么它會出現(xiàn)故障？”，“誰應(yīng)該對其負(fù)責(zé)？”等等。

我們都不會喜歡ITIL。在***次培訓(xùn)的時(shí)候，我個(gè)人的反應(yīng)是對其持懷疑的態(tài)度。其中有非常復(fù)雜的變更管理過程，但是卻沒有涉及到真正的變更系統(tǒng)。對于發(fā)布管理過程也是一樣。

然而，一旦你對其深入研究，就會發(fā)現(xiàn)，其實(shí)ITIL的各個(gè)部分都是以合理的方式組合在一起的。大多數(shù)公司都不會實(shí)現(xiàn)ITIL所有的內(nèi)容，但是一般都實(shí)現(xiàn)了最重要的三點(diǎn)：突發(fā)事件管理、變更管理和發(fā)布管理。

正如我們在關(guān)注審計(jì)和遵從的時(shí)候所看到的，敏捷運(yùn)維實(shí)際上提供了一套很強(qiáng)的支持實(shí)踐。例如，在變更管理中的一個(gè)關(guān)鍵問題就是要識別每個(gè)會被變更影響的配置項(xiàng)目。如果所有的系統(tǒng)配置都在配置管理的控制之下，那么就很容易滿足這個(gè)需求。事實(shí)上，答案是它會比之前更加準(zhǔn)確。

與ITIL之間的沖突不在于基本的原則，而是在工具上。實(shí)現(xiàn)ITIL的組織一般都會從軟件廠商那里購買一套工具。實(shí)現(xiàn)ITIL通常就意味著要實(shí)現(xiàn)這套工具。因此，如果你想要通過你自己的工具集而不是公司的標(biāo)準(zhǔn)來完全滿足ITIL過程，就會遭到高層的抵制。

對于這個(gè)問題，我的建議是“不要同官僚作斗爭。”ITIL工具很昂貴，而且實(shí)現(xiàn)它會花費(fèi)很長時(shí)間。那意味著一些任務(wù)顯然會提交給他們。繞過工具集等同于對那個(gè)人挑戰(zhàn)?？赡苓@正是你想要的斗爭，但是讓我們先考慮一下另一種方法：使用API。所有這些工具都有各種各樣的程序接口，用來提交變更申請、更新配置管理服務(wù)器（CMDB）中的配置項(xiàng)目（CI）、打開申請等等。我們只需要調(diào)用這些程序接口來對工具進(jìn)行自動化，就像我們對于服務(wù)器進(jìn)行自動化一樣。你還是需要在變更審查會議中密切關(guān)注主要的事件，但至少你可以將很多煩人的工作自動化。

有個(gè)領(lǐng)域中敏捷運(yùn)維和ITIL可以很好地協(xié)作，那就是問題管理過程。一旦發(fā)生了突發(fā)事件，它就應(yīng)該作為問題指出。這會觸發(fā)完整的分離過程。突發(fā)事件管理只是要恢復(fù)正常的運(yùn)維，而問題管理會找到并修正產(chǎn)生突發(fā)事件的根本原因。例如，web服務(wù)器崩潰是一種突發(fā)事件。目標(biāo)是恢復(fù)服務(wù)器并讓它正常運(yùn)行，這可能只是意味著重新啟動進(jìn)程。如果再次發(fā)生，它就會被認(rèn)為是問題，這會讓我們對其進(jìn)行調(diào)試，查找內(nèi)存泄漏，在QA中重新創(chuàng)建bug，等等。

ITIL問題管理和敏捷運(yùn)維都喜歡使用“5個(gè)為什么”方法來進(jìn)行根本原因的分析。也就是說，不是只解決直接的問題，還要知道在什么時(shí)候會發(fā)生這種錯(cuò)誤。在這里我看到的是本能上的調(diào)整。

歷史和文化

有時(shí)我認(rèn)為創(chuàng)業(yè)公司的***優(yōu)勢就在于沒有歷史。開發(fā)、運(yùn)維和業(yè)務(wù)一起會推動企業(yè)的文化。在一家已經(jīng)建立的公司中，在不同的組中同步文化的改變是很困難的。因此，在這項(xiàng)改變面前，總有一個(gè)組織的文化會被拋棄。在你自己的組之內(nèi)的領(lǐng)導(dǎo)是受歡迎的，但是來自于另一個(gè)組的領(lǐng)導(dǎo)很少會是那樣。特別是當(dāng)你尤其不喜歡另一個(gè)組的時(shí)候。

是的，是這樣。開發(fā)和運(yùn)維小組有時(shí)互相都對彼此不感冒。

事實(shí)上，他們可能會是公開敵對的。

就像西弗吉尼亞山上的家庭爭吵一樣，這些事情會以多種不同的方式開始。通常，它開始于啟動失敗或者停電，然后是一輪激烈的指責(zé)。運(yùn)維團(tuán)隊(duì)的主管和軟件開發(fā)團(tuán)隊(duì)的主管之間的對立會讓爭吵升級。因?yàn)檫\(yùn)維和開發(fā)團(tuán)隊(duì)中所說的話都不一樣，所以很難彌補(bǔ)他們之間的鴻溝。幾年之后，指責(zé)和相互踢皮球就成為了根深蒂固的習(xí)慣。

和敏捷開發(fā)一樣，敏捷運(yùn)維需要所有團(tuán)隊(duì)之間高度的信任。但在從來都是敵對態(tài)度的環(huán)境中如何建立起這種信任呢？你的策略依賴于你在公司中的地位。在這里我只能提出三種真正的意見：

1. 不要試圖使用技術(shù)解決方案來解決文化的問題。文化高于過程，每次都是這樣。
2. 當(dāng)你處于防御的姿態(tài)時(shí)，是不可能敏捷的。
3. 很強(qiáng)的領(lǐng)導(dǎo)力是非常重要的。領(lǐng)導(dǎo)力不需要管理授權(quán)。你可以成為公司中任何級別的領(lǐng)導(dǎo)。

總結(jié)

在過去的十五年間，我們得到了很多關(guān)于引入敏捷軟件開發(fā)的教訓(xùn)。遵守敏捷原則的團(tuán)隊(duì)能夠在需要的時(shí)候從無到有改造實(shí)踐。相反，不遵守敏捷原則的團(tuán)隊(duì)能夠效法實(shí)踐，但是不會繼承優(yōu)勢。（并且，事實(shí)上，他們不會堅(jiān)持執(zhí)行那些實(shí)踐?。?/p>

采用敏捷運(yùn)維需要“忘掉”一些關(guān)于如何創(chuàng)建可靠過程的假設(shè)。涉及到這個(gè)事務(wù)中的人們必須意識到，它可以更快并且更有規(guī)范，質(zhì)量與便利并不矛盾，并且很值得花費(fèi)時(shí)間來消除***的5%的手工作業(yè)。

同時(shí)，我們必須記住，運(yùn)維和開發(fā)所服務(wù)的利益相關(guān)者是不同的。公司會依賴運(yùn)維團(tuán)隊(duì)來保證財(cái)務(wù)結(jié)果的尊嚴(yán)，并保護(hù)他們在客戶和投資方中的信譽(yù)。任何向敏捷運(yùn)維的轉(zhuǎn)變都必須保持這些重要的責(zé)任。

【編輯推薦】

1. 從敏捷開發(fā)到敏捷運(yùn)維：DevOps將帶來革命？
2. 高效程序員的45個(gè)習(xí)慣：敏捷開發(fā)修煉之道
3. 開發(fā)者與系統(tǒng)管理員的爭執(zhí):不要碰我的生產(chǎn)環(huán)境!
4. 資深系統(tǒng)管理員給Linux/Unix新人們的建議
5. SA，神仙與裝機(jī)男：運(yùn)維的工作到底啥樣兒？