二戰時關于自相矛盾的軍事智能，有一個經典的笑話——對立面的兩個事物是不可能組合的。如今若用“商業”來代替“軍事”這兩個字眼，可以得到同樣效果。一些人認為，前沿的、昂貴的敏捷開發進程與守舊、笨拙的大型主機結合的做法是不可能的，尤其是當系統管理員抱有試圖管理遺留大型主機應用性能這樣的想法。

別擔心!目前廠商開發的工具和用戶最佳實踐證明，這么做完全可行。在我們過于激動之前，先來了解一下我們現在所處的位置。

敏捷開發勢不可擋

關于敏捷開發我寫過許多文章。在這里，我想沒有必要重述那些高度正面的分析內容。簡單地說，現在幾乎所有的軟件開發員都在談著敏捷開發。Scrum和敏捷商業智能(BI)，甚至是測試過的模塊與大規模新版本執行的持續融合，都已在各軟件開發機構中取得穩步進展。

過去四年中，敏捷開發者學會了如何按人數和代碼長度進行調節，與此同時，廠商工具從過去的應用生命周期管理(ALM)單元發展為與敏捷開發者進程有更多的關聯性。這些工具也擴大了自身的范圍，因此敏捷應用生命周期管理現在不僅意味著在測試與編碼間的不間斷往復，而且也還擔當著開發者與操作之間的協調功能。

大型主機不可動搖的目標

同樣在過去四年中--尤其是過去的兩年--高級管理層發現了一個事實，那就是，多年來，系統管理員顯而易見的一個盲點：應用性能，而不僅僅是應用的正常運行時間，才是重要的!

很長一段時間，IT只是集中精力讓應用保持運轉。而如今架構的復雜性和調整遺留應用的難度讓我們不得不正視這個問題的根本。現在，沒有良好的應用響應時間，性能問題和初試中斷出現了，好則只是引起客戶不滿和員工效率低下，壞則導致延長運行緩慢時間和試錯修復產生中斷。中斷和運行放緩會使關鍵應用長時間不可使用。這將對銷售和生產循環產生影響甚至導致停止。有時會給組織的盈虧造成重創。

這個問題對于大型主機型數據中心及其內部的遺留應用尤為重要。遺留應用通常不僅助力商業運營，而且越來越成為Linux應用落腳的地方。如果Linux應用響應速度慢得像蝸牛爬行一樣，將對全球在線用戶產生重要且深刻的影響。那就更不用說商業智能應用--這里不存在矛盾。

企業對遺留應用的日漸關注使得應用性能管理(APM)工具組件終于成為企業IT投資追逐的目標。同時，廠商也投入到開發應對新型架構組合的APM工具的“軍備競賽”中。顯而易見的選擇如IBM Tivoli，CA，以及Gomez/Compuware;較不為人知的選擇如Precise Software，它的工具增加了對分析內容的權衡，以及推薦修復方法的功能。我強烈推薦在整體架構中使用該工具。工具引入的結果是，這些針對系統管理員所關注的關鍵應用性能管理需求的工具取得重大進展，其結果是實現了監控：了解所有軟件級別，監督跨越云和其它網絡的應用，掌握負載競爭和復合應用的效果，利用積累的知識進行更快更深刻的根原因分析，并提出更好的修復建議。

#p# 不可動搖的目標遭遇不可阻擋的力量

雖然在z/OS上安裝可能有困難，敏捷開發還是有可能適用于貴公司大型主機上的Linux。我們就從這里講起。

我們的想法是，如有可能，把系統管理員的“性能問題數據”融入敏捷開發組織的快速反應故障修復進程和為下一次發布所做的努力中。希望開發中團隊最終能聽到系統管理員受表現緩慢，瓶頸式新發布內容的壓迫而發出的痛苦吶喊，將會給予快速修復。系統管理員，以同樣的方式，給敏捷開發者提供關于現實中的應用在發布后如何到達客戶的有價值信息。我們就把這些作為我們的主要目標，逐一分解。

第一步，識別和執行ALM計劃。該計劃要能涵蓋敏捷開發和大型主機管理--不用說應該允許使用某些大型主機APM工具。實際操作并沒有聽起來這么難。幾種主要的ALM工具的確在某種程度上，既適用于Linux和z/OS，又適用于Linux在大型主機和其它主要平臺上進行的敏捷開發。(這些主要的ALM工具，除了少數幾種情況，能夠在下列系統中運行并參與開發任務：zLinux,其它Linux，z/OS和其它操作系統--Window, UNIX等。能夠在所有這些平臺上工作的組成部分在細節方面有顯著區別，但這些不同點正在慢慢消失。)REXX和COBOL并不純粹適合敏捷開發，但它們在圍繞復合應用和前段遺留z/OS應用的網頁服務界面方面做了許多工作。在那些領域中，Linux/web功能性比重往往超出了新型大型主機匯編碼的數量。新的ALM應該能輕松滿足貴公司幾乎全部的需求，若有例外，預期可以臨時解決。

在期望的ALM計劃準備就緒，并取得初步的經驗之后，我們就可以回過頭來再討論那幾個關鍵目標：

·識別：利用現有或可獲取的APM工具，識別出管理員發現的重要性能問題的根源代碼。

·追蹤：如果可能，在敏捷開發者各自責任下，回溯追蹤應用中的特定代碼。方法是，讓系統管理員在存儲于ALM系統里的操作版本上作標示，然后把標示內容發送給該代碼現任開發者。

·整合：把故障報告與ALM系統的持續整合行動相融合，針對操作版本和現行開發版本，特別指出修復辦法。這是個棘手的過程，需要開發者在現行開發版本中進行修復操作，讓問題經由測試團隊返回到操作測試版本中，從而不致更進一步影響開發者。

·截取：盡快對新近修復的操作版本進行截取并反饋。可以反饋到預操作測試員或直接告知系統管理員，以便快速進行隔離測試和舊操作版本的更換。

·標準化：一旦上述總結的“識別-追蹤-整合-截取”幾個常規步驟在幾次案例中得到貫徹落實，就可以將此過程標準化。

在多數情況下，按上述操作可以實現快得多的操作故障修復，讓系統管理員滿意。并給敏捷開發員提供了數量驚人的信息，那些客戶不愿見到、讓人心煩的性能意外。也免了下一周忙著建立原型的苦差。

#p# 讓敏捷開發與你的大型主機共同運行的最佳實踐

你可能已經注意到，在我的描述中關于敏捷開發者在這里扮演的角色有諸多變幻。如果你是一名系統管理員，可能在想，“我是要開發者立即修復性能問題，而不是讓它淹沒在各版本和測試的切換之中。”這就是最佳實踐出現的地方--敏捷的最佳實踐。

你知道，有了敏捷開發，你不必設法達到最初的目的，就能實現最終的需求。特別是，當一個敏捷最佳實踐處于不斷重構時，不僅能使代碼從任何方向上進行變更都更容易，而且降低了現行版本中代碼與操作版本中代碼差異過大的可能性。這意味著回溯路徑是簡單明確的，能讓你在不到一周時間里把以往需要9個月才能完成的修復工作搞定。

第二個敏捷最佳實踐是“百花齊放”。換句話說，與其通知開發者修改故障或別的問題，應該鼓勵開發者或測試者--他們還能利用敏捷ALM工具修復之前的版本--在每周的建模競賽中添加越來越多能調校的敏捷選項。敏捷的關鍵要義在于把那些稱為“技術債”，日后務必要解決的遺留問題最小化。在此再次出現了敏捷的悖論：我們強調最大限度進行變更，并在此過程中，最小化技術債。從而使修復動作減到最少并提高質量。忽略時間，成本和質量，而我們卻能夠在這三方面比采用傳統方法達到更好的效果。這種情況下，即使不會更早，故障也能在周末前修復。這就是持續整合。

這里還有一個最奇妙的最佳實踐：提高系統管理員的敏捷度。你知道，能夠讓開發者深刻理解系統管理員調查結果的ALM工具同樣也能幫助系統管理員及他的APM工具發掘出開發者可利用的資料庫和處理進程。聰明的系統管理員將能夠利用這些資源，并在ALM工具的指導和幫助下，不再需要或者較少依賴開發程序就能夠修復應用中的故障。這意味著系統管理員能夠完全不求助開發團隊情況下也能完成修復;借由ALM把信息發送到開發團隊，必要時，修復會不可思議地穿插進他們的工作中。雖然要花點時間設置，但對于雙方來講是值得的。

大型主機的本質內容

聊夠了科學假想，現在讓我們回頭看一下可以立即著手的工作和相應的回報。出于回顧考慮，你會要加強ALM和APM來處理大型主機/系統管理員/敏捷開發者之間的交互作用。短期內，你希望系統管理員能看到更快的修復，敏捷開發者能看到更多的操作信息。為獲取最大效果，你可以采用我們提到的最佳實踐做法。你將會看到客戶滿意度大幅度提升，系統管理員提高了工作效率，技術債也減少了。那么這之后呢?

不過，為什么要問下一步呢?敏捷的價值在于能靈活應對意外情況，發掘并欣然接受變化而不是焦躁不安地試圖預期，并且能大膽采取行動--哦，科學假想。如果你非要問，也許你可以四處看看敏捷開發能修復的那些悖論情形。或許可以從商業智能入手，雖然解決這個矛盾可能需要更多一些時間。