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

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

敏捷運維概述

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

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

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

1. 溝通
2. 短的反饋周期
3. 簡單
4. 勇氣
5. 透明
6. 承擔責任
7. 反應
8. 對技術優勢的持續關注

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

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

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

#p#

障礙和沖突

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

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

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

審計和遵從

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

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

我要向你講述一個關于支付卡行業數據安全標準的故事。其中的細節會有所不同，但總體上的意味是相同的。只是VISA還不會讓任何人坐牢。

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

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

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

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

ITIL

IT架構庫是針對IT運維過程的配置框架。這一大串文字不會告訴你詳細的內容，但是你應該對其有所了解。

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

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

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

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

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

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

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

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

歷史和文化

有時我認為創業公司的***優勢就在于沒有歷史。開發、運維和業務一起會推動企業的文化。在一家已經建立的公司中，在不同的組中同步文化的改變是很困難的。因此，在這項改變面前，總有一個組織的文化會被拋棄。在你自己的組之內的領導是受歡迎的，但是來自于另一個組的領導很少會是那樣。特別是當你尤其不喜歡另一個組的時候。

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

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

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

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

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

總結

在過去的十五年間，我們得到了很多關于引入敏捷軟件開發的教訓。遵守敏捷原則的團隊能夠在需要的時候從無到有改造實踐。相反，不遵守敏捷原則的團隊能夠效法實踐，但是不會繼承優勢。（并且，事實上，他們不會堅持執行那些實踐！）

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

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

【編輯推薦】

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