二战时关于自相矛盾的军事智能，有一个经典的笑话——对立面的两个事物是不可能组合的。如今若用“商业”来代替“军事”这两个字眼，可以得到同样效果。一些人认为，前沿的、昂贵的敏捷开发进程与守旧、笨拙的大型主机结合的做法是不可能的，尤其是当系统管理员抱有试图管理遗留大型主机应用性能这样的想法。

　　别担心！目前厂商开发的工具和用户最佳实践证明，这么做完全可行。在我们过于激动之前，先来了解一下我们现在所处的位置。

　　敏捷开发势不可挡

　　关于敏捷开发我写过许多文章。在这里，我想没有必要重述那些高度正面的分析内容。简单地说，现在几乎所有的软件开发员都在谈着敏捷开发。Scrum和敏捷商业智能（BI），甚至是测试过的模块与大规模新版本执行的持续融合，都已在各软件开发机构中取得稳步进展。

　　过去四年中，敏捷开发者学会了如何按人数和代码长度进行调节，与此同时，厂商工具从过去的应用生命周期管理（ALM）单元发展为与敏捷开发者进程有更多的关联性。这些工具也扩大了自身的范围，因此敏捷应用生命周期管理现在不仅意味着在测试与编码间的不间断往复，而且也还担当着开发者与操作之间的协调功能。

　　大型主机不可动摇的目标

　　同样在过去四年中--尤其是过去的两年--高级管理层发现了一个事实，那就是，多年来，系统管理员显而易见的一个盲点：应用性能，而不仅仅是应用的正常运行时间，才是重要的！

　　很长一段时间，IT只是集中精力让应用保持运转。而如今架构的复杂性和调整遗留应用的难度让我们不得不正视这个问题的根本。现在，没有良好的应用响应时间，性能问题和初试中断出现了，好则只是引起客户不满和员工效率低下，坏则导致延长运行缓慢时间和试错修复产生中断。中断和运行放缓会使关键应用长时间不可使用。这将对销售和生产循环产生影响甚至导致停止。有时会给组织的盈亏造成重创。

　　这个问题对于大型主机型数据中心及其内部的遗留应用尤为重要。遗留应用通常不仅助力商业运营，而且越来越成为Linux应用落脚的地方。如果Linux应用响应速度慢得像蜗牛爬行一样，将对全球在线用户产生重要且深刻的影响。那就更不用说商业智能应用--这里不存在矛盾。

　　企业对遗留应用的日渐关注使得应用性能管理（APM）工具组件终于成为企业IT投资追逐的目标。同时，厂商也投入到开发应对新型架构组合的APM工具的“军备竞赛”中。显而易见的选择如IBM Tivoli，CA，以及Gomez/Compuware；较不为人知的选择如Precise Software，它的工具增加了对分析内容的权衡，以及推荐修复方法的功能。我强烈推荐在整体架构中使用该工具。工具引入的结果是，这些针对系统管理员所关注的关键应用性能管理需求的工具取得重大进展，其结果是实现了监控：了解所有软件级别，监督跨越云和其它网络的应用，掌握负载竞争和复合应用的效果，利用积累的知识进行更快更深刻的根原因分析，并提出更好的修复建议。

　　不可动摇的目标遭遇不可阻挡的力量

　　虽然在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系统的持续整合行动相融合，针对操作版本和现行开发版本，特别指出修复办法。这是个棘手的过程，需要开发者在现行开发版本中进行修复操作，让问题经由测试团队返回到操作测试版本中，从而不致更进一步影响开发者。

　　·截取：尽快对新近修复的操作版本进行截取并反馈。可以反馈到预操作测试员或直接告知系统管理员，以便快速进行隔离测试和旧操作版本的更换。

　　·标准化：一旦上述总结的“识别-追踪-整合-截取”几个常规步骤在几次案例中得到贯彻落实，就可以将此过程标准化。

　　在多数情况下，按上述操作可以实现快得多的操作故障修复，让系统管理员满意。并给敏捷开发员提供了数量惊人的信息，那些客户不愿见到、让人心烦的性能意外。也免了下一周忙着建立原型的苦差。

　　让敏捷开发与你的大型主机共同运行的最佳实践

　　你可能已经注意到，在我的描述中关于敏捷开发者在这里扮演的角色有诸多变幻。如果你是一名系统管理员，可能在想，“我是要开发者立即修复性能问题，而不是让它淹没在各版本和测试的切换之中。”这就是最佳实践出现的地方--敏捷的最佳实践。

　　你知道，有了敏捷开发，你不必设法达到最初的目的，就能实现最终的需求。特别是，当一个敏捷最佳实践处于不断重构时，不仅能使代码从任何方向上进行变更都更容易，而且降低了现行版本中代码与操作版本中代码差异过大的可能性。这意味着回溯路径是简单明确的，能让你在不到一周时间里把以往需要9个月才能完成的修复工作搞定。

　　第二个敏捷最佳实践是“百花齐放”。换句话说，与其通知开发者修改故障或别的问题，应该鼓励开发者或测试者--他们还能利用敏捷ALM工具修复之前的版本--在每周的建模竞赛中添加越来越多能调校的敏捷选项。敏捷的关键要义在于把那些称为“技术债”，日后务必要解决的遗留问题最小化。在此再次出现了敏捷的悖论：我们强调最大限度进行变更，并在此过程中，最小化技术债。从而使修复动作减到最少并提高质量。忽略时间，成本和质量，而我们却能够在这三方面比采用传统方法达到更好的效果。这种情况下，即使不会更早，故障也能在周末前修复。这就是持续整合。

　　这里还有一个最奇妙的最佳实践：提高系统管理员的敏捷度。你知道，能够让开发者深刻理解系统管理员调查结果的ALM工具同样也能帮助系统管理员及他的APM工具发掘出开发者可利用的资料库和处理进程。聪明的系统管理员将能够利用这些资源，并在ALM工具的指导和帮助下，不再需要或者较少依赖开发程序就能够修复应用中的故障。这意味着系统管理员能够完全不求助开发团队情况下也能完成修复；借由ALM把信息发送到开发团队，必要时，修复会不可思议地穿插进他们的工作中。虽然要花点时间设置，但对于双方来讲是值得的。

　　大型主机的本质内容

　　聊够了科学假想，现在让我们回头看一下可以立即着手的工作和相应的回报。出于回顾考虑，你会要加强ALM和APM来处理大型主机/系统管理员/敏捷开发者之间的交互作用。短期内，你希望系统管理员能看到更快的修复，敏捷开发者能看到更多的操作信息。为获取最大效果，你可以采用我们提到的最佳实践做法。你将会看到客户满意度大幅度提升，系统管理员提高了工作效率，技术债也减少了。那么这之后呢？

　　不过，为什么要问下一步呢？敏捷的价值在于能灵活应对意外情况，发掘并欣然接受变化而不是焦躁不安地试图预期，并且能大胆采取行动--哦，科学假想。如果你非要问，也许你可以四处看看敏捷开发能修复的那些悖论情形。或许可以从商业智能入手，虽然解决这个矛盾可能需要更多一些时间。