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

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

敏捷運維概述

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

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

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

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

這些原則以多種方式得到了證實：

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

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

#p#

障礙和沖突

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

但是，看花容易繡花難。就像Scott Adams所說：“任何你不懂的東西都很容易。”但道理會更加復(fù)雜。人們不會因為愚蠢的或者武斷的原因而支持實踐，但是會因為他們要緩解在外行看來不明顯的壓力而那么做。

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

審計和遵從

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

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

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

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

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

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

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

ITIL

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

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

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

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

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

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

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

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

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

歷史和文化

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

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

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

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

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

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

總結(jié)

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

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

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

【編輯推薦】

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