应用软件运行状况全掌握

　　在业务数据和业务处理逐步集中，信息化日益普及的大背景下，软件系统的大型化和复杂化是必然趋势，这就对软件系统的可用性提出了更高的要求。一般而言，软件系统的高可用性是由软件的各项技术指标综合决定的，如软件系统的稳定性、安全性、可维护性、系统性能等。系统实现了高稳定性、高可维护性、高安全性、高性能，即可以取得高的系统可用性。从应用角度来说，提高这些技术指标的方法可以分为两大类，一是在问题出现前预警，二是在问题出现后有高效的解决手段，通俗地说就是及早发现和快速解决。

　　如何为运维人员提供充足、及时的预警，如何为运维人员跟踪解决问题提供有力的支持呢？孙子说“知彼知己者，百战不殆”，现代军事领域也有一个论断是：“发现即被消灭”，说的都是侦察手段的重要性，如果战争一方的行动完全被对方掌握，那他被消灭就是很容易的事情。同样在应用程序运行维护过程中，如果应用软件系统的各种运行状态、各个模块、各个函数、甚至每个数据的变化都是可知的、可跟踪、甚至可预测的，也就是说这些信息完全被运维人员所掌握，那么系统正常运行就易于得到保障，即使出现问题解决起来也将不是很难的事情。

　　本文将应用软件在运行过程中以多种方式、多层次、多角度将自身运行情况呈现给用户的能力称为应用软件系统的可视性(application visibility)；相应地，具有良好可视性的应用系统称为可视化应用系统(visual application)。

　　应用软件的管理难题

　　全面掌握应用系统的运行状况对应用软件管理员而言非常重要，因为这可以提前发现隐患，一旦出现故障也能及时找到问题之所在。然而，做到这一点并不容易，其中面临着应用程序监控和系统运维过程的不确定性等诸多难题。

　　1.应用系统监控之难

　　与操作系统、中间件等基础性软件相比，应用程序的监控要困难得多。比如，中国人寿目前已经建立起来比较完善的基础平台监控机制，通过整合利用基础平台提供的各种监控接口，统一到监控平台上，形成一个完整的基础平台运行视图，并增加各种管理功能，取得了很好的效果。其之所以成功，一个很重要的因素是各种基础平台，包括硬件、操作系统、数据库、中间件等都是成熟的通用平台产品，这些产品自身都包含了丰富的运行监控接口(可称之为具有良好的可视性)，管理者或使用者所做的就是利用和挖掘这些功能，并根据自己的应用特点进行针对性的整合，以统一友好的界面展现给管理人员。

　　而应用监控虽然也取得了一些非常好的效果，但相比系统监控效果还是有不小的差距，最根本的原因在于应用系统自身没有提供足够的、有效的关于自身运行的详细信息，也就说应用软件自身不具有很好的软件可视性。仅从应用程序消耗的公共资源来判断应用运行情况具有很大的局限性，如跟踪Tuxedo服务队列可以判断某个应用功能的排队情况，但不能很好地给出进一步的信息。就好像一台高档中央空调，仅仅能够监控它的电压、电流、温度这些通用指标是没法很好满足监控需要的，要想知道空调运行情况还需要很多指标以反映其内部部件的运行情况。应用程序监控的另一思路是对应用日志的监控，但很多情况下应用程序日志也不能满足监控要求，需要反过来在源程序中增加针对性的日志输出。另外，不同应用系统源程序的结构差异使得增加理想日志信息的工作量和风险都具有不确定性，而且这种打补丁的方式缺乏规划和统一管理。这种状况其实是反映了程序原有的可视性不能很好满足应用监控的要求。

　　2. 系统运维过程的不确定性

　　目前由于主要应用系统运行文档、运维文档不够完善，系统运维过程中查看源程序仍是最重要的问题定位、问题分析手段。系统运行中出现问题时，界面上和日志文件中的报错信息是问题定位的切入点，如果报错信息、日志记录比较明确、比较完整，运维人员就比较容易跟踪到出错前程序的运行轨迹，继而根据程序上下文逻辑判断出现问题的根本原因；反之如果日志记录不明确、不完整。例如，在程序流程跟踪过程中某个关键变量的值变化没有记录下来，运维人员判断和解决起来就困难得多，虽然看得见却摸不着，这时候问题的解决就需要依靠运维人员的经验想办法进行问题重现，有时甚至要修改源程序加入调试信息并模拟运行。这种情况下运维的效率很大程度上依赖程序日志的详细程度，依赖运维人员经验的积累，这就导致整体上应用软件的问题定位效率具有不确定性，直接后果是系统高可用性无法得到保证。

　　分析其原因，一是目前主要应用系统提供的日志很多是软件在开发过程中加入的调试信息，并不能称为软件系统的运行日志；二是日志侧重于记录出错现场的异常信息，不注重正常运行信息，而在实际生产环境中，那些在测试环境中从来不出现异常的地方还是会出现异常。

　　如果解决了目前应用软件系统的日志不全面的问题是不是就可以适应将来的需要，尤其是大集中系统的需要呢？笔者认为仍然不能满足。按目前的模式，在源程序中加入全覆盖的日志，将对系统运行效率、运行日志空间消耗、日志跟踪效率带来新的问题，因为对于特大型软件系统，系统逻辑复杂，程序调用层次多，并发操作量巨大，而且规范的应用软件维护模式不是以源程序为基础的，源程序对运维人员是不开放的。

　　软件可视性的两个特征

　　要解决应用软件管理中存在的上述难题，需要从多方面着手，其中之一就是提高应用软件的可视性。理想的应用软件可视性应具有以下特性：

　　1.多角度

　　可视性良好的应用软件是一个“白盒”系统。不同类型的用户可以从各自的角度对其内部进行观察。用户可以是前台操作者、后台操作者、应用管理者或者系统审计者等。前台操作者和后台操作者可以非常直观地看到自己已经完成、正在进行、将要进行的操作，也可以看到操作对象的全面信息，包括历史信息、相关信息；应用管理者可以看到权限范围内系统中正在进行的所有操作员和操作对象的活动信息和历史信息；系统审计者可以看到权限范围内所有操作和对象的历史信息。

　　2. 结构化

　　可视性良好的应用软件可以实现结构化、系统化的观察(或监控)。如果软件的监控平台是软件的仪表板，应用软件可视性功能则是仪表板和各运行单元之间以及运行单元内部的传感器。软件系统的整体运行状况、各部件的运行状况信息可以通过传感器获取，并传递给仪表板，以方便及时地展现在用户的面前，给出一个软件系统运行情况的全貌。这是软件系统可视性的最基本要求。

　　在仪表板的基础上，可以对各个部件的运行情况进行进一步深入的展现，逐层展现部件内部的运行情况，类似于数据仓库中的下钻分析。相对于传统机械设备和模拟电子设备，应用软件系统作为纯数字信息系统，在数据采集、数据管理上具有更大的优势，应该比空调、汽车更易于实现。

　　关注可视性对运行效率的影响

　　目前，大型应用系统所消耗资源主要分为主机资源和存储资源两大方面。要实现应用系统完全的可视性，在主机资源和存储资源上的开销都将是十分巨大的，可能会影响系统的运行效率和存储效率。在运行效率方面，类似的情况如Informix的存储过程trace模式和非trace模式在效率上的不同，其运行效率有一倍以上的差异；在存储效率方面，保证良好的可视性特征所需的存储开销将随着业务处理集中程度的提高、业务规模不断发展而快速增长，如不进行有效管理，数据量可能超过业务数据量甚至存在数量级上的差异。

　　运行效率方面的问题解决可以采用类似于数据库的优化策略。这并行操作是关键，即将系统可视性方面的资源开销同程序主业务逻辑处理所占资源独立分配，如采用物理独立的数据库和文件系统以及独立的内存空间，主程序通过特定方式将可视化信息填写到这些专用的空间，再由专用的进程或工具进行整理、加工和展示。类似于Oracle 10g的自动负载仓库 (Automatic Workload Repository)机制。

　　存储效率方面问题的解决关键是分级管理，根据可视化数据的性质、时效、历史价值、用户等属性不同而采用不同的存储、转存、销毁策略。

　　笔者认为在主机资源上占用主业务逻辑处理程序的15%？20%；存储资源上占用主业务数据40%左右是值得的。值得注意的是，特大型应用软件系统的可视性对系统整体性能的影响。特大型应用软件系统都是多层结构。通常如果基本的三层结构无法满足开发效率上的要求，企业还会在公共中间层开发平台基础上开发出企业自己的更有针对性的中间层(企业中间件)，以提高开发效率。这样的中间层定位于通用标准中间件和应用软件之间，其效率高低对整个应用系统的影响是非常敏感的。同时其稳定性、可靠性要求也是更高。对这样的企业中间件，其可视性要求可以参照通用中间件软件如Tuxedo、Weblogic等的可视性功能机制，而不纳入应用软件的可视性要求范围，以减轻应用系统自身的压力。

　　应用软件可视性的动态启停也是实现可视性过程中值得关注的一个问题，对系统性能的影响也要考虑。应用软件可视化动态启停是指应用软件可视化特性实现逻辑与业务处理逻辑之间保持弱耦合，并支持运行间打开和关闭。目前应用系统普遍采用的日志模式和非日志模式两个版本程序，即正常情况下使用非日志模式程序，在需要进行程序运行跟踪的情况下启动日志模式程序。但这种解决方案是静态的，对于高可用性要求的应用程序，程序的启停需要时间窗口，代价和成本是很高的，需要探讨更高效的解决方案。

　　按此思路可以考虑在两种模式程序之上再包装一层控制逻辑，在这一层逻辑中动态调用日志模式或非日志模式程序，以实现可视化功能的动态启停。

　　有必要指出的是，可视性可能会带来IT系统安全隐患。为此，可视化特性要保证仅仅是“可视”而已，对主业务逻辑处理流程和业务数据是只读的，同时要配合进行用户和权限管理。针对前台操作用户、后台操作用户、系统管理员、系统审计人员提供不同的可视化界面，保证不会对主业务流程和物理数据造成安全性问题。另一方面，可视性包含了对主业务流程和数据处理的跟踪，事实上为业务流程和数据安全审计提供了技术支持。

　　总体而言，可视化特性不是一个具体的技术指标，但仍需要提出总体需求，并针对性地分解落实到业务需求和技术需求的各个模块中，贯穿系统构架、开发、 验收的整个过程。而在具体实现上，可视化特性可以继承和改进公司现有应用中某些效果良好的可视化功能。同时可以参考一些优秀的系统软件或工具软件的功能，如可视化开发工具的调试跟踪机制、Oracle 10g的自动负载仓库机制等，最终实现应用程序的全面可视、可控、可管以及可预测。

　　中国人寿数据中心 袁红 张斌

　　链接

　　不同维度看应用软件可视性

　　1.常态可视性和异常可视性

　　应用系统的可视性要求以多种方式记录系统正常运行的信息，包括已经执行的步骤并提供一定程度上的运行预测，以使用户确信它是正常运行，称为常态可视性。同时在系统运行出现异常的情况下提供现场信息，并提供问题可能原因分析或问题解决思路提示，为异常情况的解决提供支持，称为异常可视性，类似于飞机的黑匣子。这就要求可视性在软件的构架、设计、实现过程中要比软件业务需求功能部件具有更高的稳定性，绝不应该出现业务功能还在正常运行或刚出现异常而可视性功能却已经失效这样的情况。

　　2.静态可视性和动态可视性

　　静态可视性是指在系统已经启动，随时可以提供服务，但暂没有业务处理进行的状态。在应用系统上线之初这种情况特别突出。如果应用系统具有自检功能，可以给出明确的“I AM READY”这样的信号，将会给用户以极大的信心、并得到用户的充分信任；动态可视性指系统在运行过程中始终保持可视，是可视性要求的最基本内容。

　　3. 运行环境下的可测试性

　　运行环境下的可测试性是指处在生产状态下的应用系统，为了验证某些功能或问题，按正常的业务操作输入或导入非生产数据(测试或验证数据)，以查看系统的处理流程和处理结果是否正常。此处的非生产数据指通过某个特定的标志同生产数据进行区分，例如投保单号的某一位的特定值表示此投保单为测试投保单。系统内部对测试数据的处理完全同普通数据，但是在系统处理出口处会进行屏蔽或专门处理，例如业务统计时会将其过滤；发票和保单打印时可能会使用普通打印纸；在数据流向不具备生产环境可测试性的系统之前将测试数据自动拦截。

　　4.可视性的时效性要求

　　根据所展示的信息的时效性要求软件系统可视性可分为实时可视性、前瞻可视性和历史可视性三大类。

　　实时可视性：实时记录系统运行信息。记录粒度需要进行规划，既要保证最细粒度(如每一个程序变量值的变化)的信息跟踪完整性和效率，同时要保证对主机资源消耗的可控。

　　前瞻可视性：指对还未执行的操作进行预测或对异常情况进行初步自动分析。从这个角度上可以说应用系统某种程度上具有智能特性。

　　历史可视性：指对系统已经完成的运行情况进行展示和跟踪、典型的是对程序的运行日志进行管理，例如存储策略、权限管理、查询方式、分析工具等。