IT 架构测试之基础架构运维测试简介

IT 架构测试之基础架构运维测试简介

测试对于 IT 领域来讲，是众所周知的重要概念，无论对于项目还是软件产品来说，测试都是贯穿始终的重要环节。 此次本文撇开大家熟悉的功能测试，集成测试，系统测试不谈， 聊一下 OAT (Operational Acceptance Testing) 又称基础架构运维测试， 是一种新兴的测试方法，目标是为客户提供健壮，可扩展， 高可用的 IT 架构， 同时为客户降低不必要的 IT 维护费用，节省项目整体开支。

一个健壮的 IT 架构的重要性在金融， 银行，保险领域日益凸显。状况频出的 IT 环境让对时间，成本"斤斤计较"的金融、银行、保险经理人对稳定可靠的 IT 架构的渴求愈发强烈。OAT 应运而生 - IBM GPS OAT 团队已经成功的将 OAT 测试服务推广到 IBM 在欧洲的若干重要的银行客户，通过对 IT 基础架构在数据完整性，高可用性，可恢复性，可维护性，可扩展性，以及安全及可监测性方面的综合测试， 降低产品上线之后产生相关问题时造成的高额修复成本。

下面我们就以银行为例，全面介绍 OAT

挑战

可能有很多人并不了解 OAT 到底包含什么范围， 我们可以先想一下当前银行的 IT 环境所面临的挑战 - 停电，硬件故障，网络故障，甚至于自然灾害，例如洪水，地震，台风等等，这些无疑都会给银行正常运营带来风险，系统在遭遇灾难时所产生的错误或失败会造成服务的中断，因此合理的设计，正确的配置是提高架构健壮性的根本 , 而 OAT 则正是在设计和配置方面予以多方面的验证， 从而保证系统在上线之后无论遇到各种问题，都能从容面对。

说了这么久，那基础架构层面的测试包含哪些内容呢 - 应用，中间件，服务器，存储， 网络以及多元化技术的部署。是不是看起来都是熟悉的东西，待我慢慢道来

下图是一张典型的银行 IT 架构图，包含应用软件，存储区域，交易处理，网络传输，监控报警等等。

图 1 . 银行 IT 典型架构图

而下面这种图呢，则是展示了 OAT 针对银行测试的关键要素即测试重点

图 2. OAT 测试重点分布图

数据完整性

银行无疑是最注重数据完整性的行业之一， 用户群庞大，交易量巨大，复杂性奇高是银行业务的特点。 数据完整性指的是能够维护和确保数据正确性及在其整个生命周期的一致性的能力， 针对数据完整性的测试对于银行而言至关重要

高可用性

银行三天两头"罢工"可不行，高可用指的是基于数据和应用，确保业务的可持续性，在最大程度上保护系统远离"灾难"的能力

可恢复性

如果灾难避无可避， 总得想办法恢复，不能置之不理，可恢复性指的是系统能够恢复到断点的能力，当然是在 SLA 规定的范围之内，一味求精也会导致弯路

可维护性

系统维护是必不可少的部分， 可维护性指的是维持系统功能，提供合理的支持流程以及责任到人的能力， 维护人员必须做到职责明确，系统出错时能迅速到位

可扩展性

不能"成长"的系统没有"前途"，业务的增长必然带来系统的升级、扩容，可扩展性指的是系统必须有一定的扩展空间来处理日益增长的业务需求， 通常是指横向纵向的扩展， 例如在数据容量， 计算能力以及性能方面的考虑

安全与监控

"安全生产"始终要摆在首位，特别是对于银行这种存储大量客户敏感信息的行业更是如此。安全策略要全方位立体式的部署，对于授权，敏感信息修改要有记录可查， 同时系统错误也要配置监管为维护工作提供依据

除此之外，银行 IT 是个"鱼龙混杂"的地方，各种技术交杂繁复，多重层面环环相扣，众多服务提供商层出不穷 , 可想而知，银行的 OAT 测试可谓挑战不断，难点重重

经验

作为 OAT 的先锋，IBM 团队已经向很多欧洲银行客户成功交付了许多关键项目的 IT 架构运维测试，确保系统的健壮性和性能在上线之前得到充分验证。通过对架构组件的针对性测试，降低"宕机"几率并提高性能。

OAT 由若干关键要素组成，每个要素针对一种挑战，仔细看下图

图 3 .OAT 测试要素组成图

针对高可用的测试

围绕负载均衡或者数据库及服务器的集群配置进行检查，从而确保高可用在设计考虑范围之内并且已经被启用。无论是硬件还是软件层面， 所有涉及高可用的部分都要通过测试验证，很多参数例如 failover 时长，对话保持及数据完整性都属于测试验证的范畴

针对备份功能的测试

确保系统具备对于应用 , 中间件，文件系统，数据库以及操作系统层面进行全备份和增量备份的能力，考虑备份及回复对于空间和时间的占用是否符合特定要求，这是验证的依据

针对安装配置的测试

安装配置是基础的基础，依据具体的安装实现文档，应用文档，配置文档针对生产环境的所有服务器，应用和中间件逐一进行安装和版本验证，确保符合项目需求

针对维护的测试

验证生产环境中对于服务器、中间件以及应用的维护模型已经创建，在系统一旦发生失败的时候， 能够构建正确的流程并通知到具体维护人员进行问题的迅速定位和解决。另外 , 系统自身的日常工作例如一些批处理作业，空间清理作业，应用程序的关毕重启设置，病毒库的更新等等也需要纳入考虑范畴

针对灾备的测试

检验灾备计划，根据项目需求，需要包含对于正常业务操作恢复的先后顺序进行合理排序。跨地域中心的灾难恢复测试也要进行

针对安全性的测试

检查系统的安全配置，在操作系统确定和应用程序正确安装的前提下，检查包括网络，防火墙，用户域，数据连接，用户授权，密码规则等方面的配置

针对监控的测试

为了确保服务器、中间件以及应用能够正常工作，需要有一双"眼睛"时刻监控。报警系统的正确配置则可以及时通知相关维护人员对特定问题进行处理，例如服务器宕机，硬盘空间不足，处理器使用率过高，甚至于严重事件的监测报警都在测试范畴

技术标准

OAT 作为业界的新兴技术，并没有现成的标准可以遵循，但是涉及到项目交付，从项目管理的角度来说，需要定义包含关键信息的可操作模型，诸如任务，目标，范围，组织架构，监管，服务，流程，功能，人员分配，报告及可持续发展机制。通过以上定义来帮助客户设定合理的预期及进一步建立良好信用

从技术角度来来说，创建合理的测试标准对提供项目评估非常必要， 而且可以在多个项目中重复使用并且逐步完善。标准的制定要基于风险等级需求，阶段不同，架构不同，技术不同，都需要纳入考虑范围， 全面而又能适应多数项目需求

结束语

本文只是针对 OAT 的基本概念和基础组成部分的概要介绍， 但相信大家已经对目前 OAT 的测试完备性及重要性有了一定认识。随着客户对各种新技术的应用，OAT 范畴也在不断扩展，测试集也在同步增容，希望将来有更多的 OAT 方面的知识能和大家继续分享。