| 项目一：中国万网关键业务平台数据库改造项目 |
| 项目简介（功能与用途）： 中国万网是国内最大的域名注册和虚拟主机服务提供商，一直专注于中国e网络体系（e-infrastructure）建设。中国万网关键业务平台是中国万网对外的电子商务平台，提供7×24小时的服务，客户利用互联网通过该系统进行域名注册、主机、邮箱及其它各类业务的订购及续费，并支付货款，还通过该系统对个人资料及已有业务的属性进行维护。该系统为万网最为重要的业务支撑系统，只有该系统稳定高效的运行，才能保证万网各项业务的顺利开展。 该系统已投入运行，随着运行时间的增长和业务量的不断膨胀，也暴露出一些问题，数据库的运行效率、高可用性及安全性需要得到进一步提升。
项目难点与解决方案： 该项目为一个典型的对在用系统的数据库平台进行改造的项目。 其难点在于如何确保改造的过程中，系统能够稳定、正常的运行，近可能减小可能的负作用，并赢得广大开发人员及其他相关人员的积极配合。 对于此类项目，首先应该对系统运行状况进行比较全面的监控与检查，找出潜在的问题，提出解决方案，实施不必一步到位，可以由易而难分步实施。对于开发人员及其他相关人员，要做好充分的沟通，并进行相关的培训，使其理解改造的合理性，得到他们的支持与配合。 一、性能方面的改进 我首先利用Oracle的statspack对系统的几个典型时段的运行情况进行抽样分析，利用实时监控工具对数据库的运行情况进行跟踪，通过操作系统的监控工具掌握系统CPU、I/O、内存换入换出操作等的情况。再有，通过对业务数据的统计分析，进一步了解业务量的分布及增长情况，掌握定时批处理程序的分布，这样对系统的整体运行状况有一个比较全面的了解，哪些方面需要改进也就清楚了。 通过众多专家及自己亲身经验表明，应用软件的优化往往是整个计算机系统优化的关键，与数据库参数、操作系统参数的调整以及硬件的升级相比，其往往会收到更好、更经济的效果（当然这只是多数情况下，具体问题也还需要具体分析）。而SQL的优化又是基于数据库应用优化的重要组成部分，而如何让开发人员认识到这一点的重要性呢。恰好这时，随着系统运行时间的增长与数据量的增加，某些应用的效率问题突现，有的已影响到业务的正常开展，开发人员已有了对系统进行优化的愿望，我就抓住这个时机，在内部开展了关于应用及SQL优化的技术交流，主要阐述了如下观点： 1、 应用及SQL优化的重要性； 2、 全表扫描与索引检索的适用条件； 3、 索引不是越多越好（通过数据结构讲解索引的本质、索引的开销、适用性、索引列的选择及复合索引各字段顺序的选择）； 4、 多表查询的主要方法（循环嵌套（nested loops join）、哈希连接（hash join）及排序归并连接（sort merge join））及其各自的适用情况； 5、 不要轻易相信某些结论（如or不能用索引等等），而要以真实的执行计划为准； 6、 要及早重视性能问题，开发环境模拟真实的数据量，上线前进行压力测试。 在交流中，我没有空谈理论，而是将我在检查、监控系统时收集的有明显优化潜力的SQL拿出来分析，并将优化前后的效果进行现场对比，多数都有10倍以上的差距，使大家切实感受到优化的潜力与效果，也明确了优化的方向。 这样在交流结束后，在相关负责人的组织下，一方面对部分重点SQL进行优化，另一方面删除、调整十余个索引，释放大量存储空间的同时系统的逻辑、物理读写都下降40%以上，系统性能得以明显提升。 二、在备份、恢复策略及高可用性方面的改进 我大体上分三个步骤来提高系统的可用性： 第一步：在不增加任何软、硬件成本的前提下，更改相关设置，达到单库构架下的最大可用性 将Oracle中重要的控制文件、联机日志文件进行多路镜像，开设数据库归档方式，并进行定期的物理备份，测试验证备份的可恢复性，继续保留原有逻辑备份作为必要的补充，使系统在最短时间内并不增加任何成本的前提下有了相对完善的备份、恢复策略，提升了系统的可用性。 第二步：争取到一台新机器，实施Oracle Data Guard Data Guard的实质是在生产数据库运行的同时，再建一个实时的恢复系统。以传统方式恢复数据库时，首先要将数据库的备份恢复到原机器或一台新机器上，之后还需要应用备份之后产生的日志以使数据库恢复到故障点。而如果数据库比较大，产生日志又比较频繁的话，恢复用时就比较长，从而影响系统的可用性。为了加快恢复，在生产库运行的同时，事先利用数据库的一个备份在备用机器再建立一个数据库，生产库产生的日志以异步或同步方式传输到备用库并进行恢复，这样一旦主数据库发生故障，备用数据库可以很快完成恢复提供服务。如果主库与备用库分处不同的地点，Data Guard还能起到容灾的作用。 由于Data Guard本质还是数据库的备份/恢复，所以复杂性并不是很高，实施与维护的风险也比较小，除了增加一台机器外也没有更多的成本支出，而可用性的提高却是非常显著。 第三步：实施RAC+ Data Guard，即Oracle提供的最高可用性（MAA，Maximum Availability Architecture）架构。 RAC（Real Application Clusters）是其前身OPS（Oracle Parallel Server）的进一步发展，其特点是同一集群的多台主机可以同时以读写方式访问同一数据库，也就是说，各机器的CPU、内存、本地硬盘是独立的，但它们要同时操作在共享磁盘上的同一数据库。这样，平时多个节点可以进行负载分担，而当某一节点出现故障时，连在其上的会话可以透明、均衡、迅速地分布到其它节点上。 我们实施的是最高可用性（MAA，Maximum Availability Architecture）的一种实现方式，即主站点采用RAC，附站点是单机，两者之间的同步通过Data Guard实现。这一架构实施后，使系统的可用性得到进一步的提升。 在此期间，我还在公司内部主持了关于备份、恢复与高可用性方面的专题技术交流，普及了相关概念，使相关人员对这一问题有了更为全面的了解。 三、安全性方面的改进 安全性的问题涉及多个层面，在我力所能及的范围主要采取了以下一些措施： 1. 应用程序与数据库连接的用户与数据库对象的属主用户相分离 2. 修改系统用户默认密码； 3. 建立规范的口令的管理制度，对口令的复杂度、分发、更改、有限周期进行管理； 4. 配置Oracle可执行文件权限； 5. 限制OS验证，禁用远程OS验证； 6. 限制表空间限额； 7. 根据实际情况，开启审计功能，进行适度审计，分析用户访问行为； 8. 断开其它数据库对生产库不必要的连接（dblink），只允许来自特定节点的访问； 9. 加强数据库的实时监控，对异常现象及时进行调查分析（如通过分析系统负载的变化发现注入漏洞，及时反馈给开发人员补救），堵塞漏洞； 10. 对敏感数据加密保存； 11. 从归档日志中挖掘历史以供分析。 通过以上措施，使数据库系统的安全性得以提升。
项目成功与失败的经验归纳： 该项目为典型的对在用系统的数据库平台进行改造的项目，其成功的经验在于： 1. 为了保持系统运行的平稳，尽量不要采用急风暴雨式的措施，而是采用小步快跑的方式，稳步推进系统的改造（CMM关于软件过程改进的思想同样适用于此类项目，“改进是在一系列微小的、不断发展的、而不是革命性的创新步骤中实现的”）； 2. 实施人员要与开发人员及其他相关人员进行密切的沟通，使他们理解并支持改造工作； 3. 任何改进措施都要在测试环境下进行测试后才能应用到生产系统，对可能产生的风险进行充分评估，准备好相应的应急预案； 4. 善于利用有利时机，宣传改造工作的意义，推动项目的进展； 5. 实施人员一定要是数据库方面的专家，既要有坚实的理论知识，也要有丰富的实际经验；另外还需具备操作系统、存储方面的知识。
你在项目中岗位与贡献： 我是这一项目的负责人、设计者与执行者，负责原有系统的分析、提出改进措施并分步实施，还负责相关技术问题的交流与培训。 经过我上述三个层面的改进，中国万网电子商务平台的运行效率与可承受负载能力有了明显提高，负载均衡和高可用性在系统中得以体现，备份与数据库安全管理意识逐渐在技术团队中树立起来，而MAA架构的实现也为未来万网公司的业务的扩展奠定了坚实基础。
|
| 项目二：A省X市邮电局计费系统项目 |
| 项目简介（功能与用途）： 该项目为一个基于数据库的应用开发及实施项目。 该项目实施于1997年5月至10月间，为X市邮电局“九七工程”（电话业务计算机综合管理系统）中计费子系统的开发与实施项目。主要功能包括客户资料管理、计费管理、帐务管理、欠费管理、前台收费、统计查询及营收报表等。该系统为邮电局（当时电信与邮政、固话与移动还未分业经营）对固定电话用户进行计费、收费的系统，是电信企业最为关键的业务支撑系统之一。
项目难点与解决方法： 该项目为大唐电信计费系统第一个成功开局的项目，也是电信企业的计费帐务系统由foxbase/foxpro时代向大型关系数据库（DB2/Oracle/Sybase）时代的转变项目，双方都缺乏经验，主要难点体现在如下的几个方面： 1、对需求的把握 虽然在去工程现场之前也进行了开发，但依据的有些需求尤其涉及到一些细节的地方是猜想出来的，而到了现场之后，发现实际的需求与过去的想象有比较大的差距，尤其是涉及人机交互的部分更是如此。解决的办法就是深入业务处理的现场，去了解业务处理的现状，征求业务处理人员对新系统的想法，也只有你亲身体会到一些基层业务人员平时劳动的艰辛，你也才有更加强烈的愿望、也才可能通过自己的才能写出更加实用的程序去帮助他们减轻劳动负担，而不是用你在办公室通过臆想而编造出的程序给他们增添新的麻烦。 2、原有系统数据导入 邮电局原有的计费系统中的各类数据有自己的格式、编码规则及含义，而原有系统又缺乏规范的文档资料及说明，如何将其导入新的系统而保证不出差错。这一方面靠我们的技术人员与局方技术人员紧密沟通，尽量问清楚各表、字段及编码规则的含义后开始编制数据转换程序；另一方面在数据转换程序编好后，要多次进行转换对比实验，通过两个系统统计、查询、报表的差异找出潜在的问题。 3、遇到Oracle回滚段不足的错误 由于当时的计费程序为一个很大的事务，经常出现回滚段不足导致计费失败的错误（当时Oracle 版本为7 .3），最后采用事务开始前指定大的回滚段的方法解决了该问题。 4、长途话单表的设计 由于长途电话需要提供明细查询，每月都会产生大量的话单，在线保存六个月后从系统中清除离线保存。而当时使用的是Oracle 7，还没有提供表分区功能，所以只能将长途话单表进行水平分解，形成表名中带有后缀的六个表。 5、技术积累不足 当时参加开局的三个人都是象我一样刚从大学毕业一年左右的本科生或研究生，技术积累都不足，而现实的工作要求我们既要熟悉电信业务，还要掌握开发工具（powerbuilder）、数据库管理系统（Oracle）进行软件开发。也没有什么别的捷径，只有努力学习，除了吃饭、睡觉，我们所有的时间几乎都在机房度过，尽可能在最短的时间内完成任务。
项目成功与失败的经验归纳： 该项目成功上线运行。 经验： 1. 在系统上线前，经过多次原有数据的转入、出帐、收费的对比测试，保证了系统总体上不会出现太大的问题，即上线前的测试非常重要； 2. 选择业务量比较少的非工作日上线，这样发现问题可以及时改正并减少影响范围； 3. 项目开发人员编程比较规范，编程质量较高； 4. 该局业务量不是很大、 功能及性能需求也不是很高，选择它作为第一个试点局，有利于系统的成功上线，即第一个工程项目难度要低一些； 5. 局方技术人员大力配合，与我方人员结下比较好的个人友谊，帮助我们克服各种困难，是项目成功的一个关键； 6. 项目组成员虽然年轻、经验少，但精力旺盛、私心杂念少，大家团结一致、互相帮助，共同为了事业而努力工作； 教训： 1. 轻易在生产系统修改配置，导致系统运行受到影响（一次是在共享卷组建立文件系统导致集群异常，还有一次轻易在一个表上建立索引，导致主要查询执行计划变坏，严重影响系统效率）； 2. 没有意识到网络差异对系统性能的影响，开始编程时客户端与服务器端交互频繁，在开发使用的局域网环境下感觉不出问题，而实际环境有的营业网点通过共享64K DDN专线与中心机方连通（有的偏远的收费点甚至使用拨号上网的方式），试用新系统时明显感到反应速度无法忍受，只好重新修改程序，减少前、后台的交互； 3. 没有意识到不同子系统共享数据的危险性，在后来营业系统上线时，部分信息被不同的子系统互相覆盖更新，幸好发现及时没有引起大的损失与影响； 4. 由于当时缺乏经验，数据库索引的选取、物理存储的分布，都有很多可以优化的地方； 5. 系统刚运行时，只是每天采用export作为备份手段，而没有开启数据库的归档方式，一旦发生介质故障恢复将比较烦琐（由于当时已普遍采用RAID5技术，存储可靠性有一定提高，另外在邮电局办理各项业务都会有纸质单据，所以在最坏的情况下可以先将前一天的导出数据导入，再核对单据进行数据的补录，不会造成太大的数据丢失）；而以我现在的观点，即使采用RAID 0+1，对于生产系统也应开启归档方式，使系统更加健壮；
你在项目中岗位与贡献： 我是大唐电信计费帐务系统的主要开创者之一，系统最初只有我们三位开发人员，我们共同参与了计费系统的分析与设计、确定数据库的表结构，分工编码，我具体负责后台销帐、前台收费及部分查询功能的设计与编码。 我全程参与了该项目，包括前期项目的争取与后期项目的实施。在项目实施过程中，进驻现场四个多月，到各营业厅了解实际的需求，根据新的需求重新进行软件开发，编写了部分原系统数据的转换导入程序。系统上线前进行系统测试，上线过程中夜以继日地监控系统运行情况，对反应上来的问题及时进行修正，上线后对数据库进行优化以提高系统效率，为该项目的成功做出了重要贡献，也为大唐电信软件公司计费帐务系统的创立奠定了坚实的基础。
|
| 项目三：B省Y市邮电局计费系统项目 |
| 项目简介（功能与用途）： 该项目为一个基于数据库的应用开发及实施项目。 该项目实施于1997年11月至1998年3月，为Y市邮电局“九七工程”（电话业务计算机综合管理系统）中计费子系统的开发与实施项目。主要功能包括客户资料管理、计费管理、帐务管理、欠费管理、前台收费、统计查询及营收报表等。该系统为邮电局对固定电话用户进行计费、收费的系统，是邮电局最为关键的业务支撑系统之一。
项目难点与解决方法： 1、需求的变化 虽然已经有了一个计费系统的开局经验，但来到一个新局，发现许多需求与前一个局都有很大的不同，尤其涉及人机交互的前台程序更是如此，比如我负责的收费部分就是这样，想不对程序进行较大的修改就上线是不可能的。解决的办法就是再次深入业务处理的现场，去了解业务处理的现状，征求业务处理人员对新系统的想法，经过在营业厅的仔细观察，我最终决定重写收费程序，一方面是为适应新的需求，另一方面也是全面改进第一个版本中的不足。经过三周左右，终于完成了新版本的收费程序。 2、原有系统数据导入 该局数据转换工作较之上一个局复杂程度明显增加。首先数据量有明显的增加，而且有大量用户属于有一定预存款的用户（而上一个局基本都是现金用户），并且有些陈年欠费数据非常复杂，负责数据转换的同事虽然经过精心核对，但正式上线后仍发现有部分历史数据导入存在问题，前台收费厅曾一度秩序混乱。但这时，局方与我方之间、我方人员之间并没有互相指责，大家齐心协力想办法尽快解决问题，由于问题数据极其复杂，编写程序批量调整稍有不慎可能引起更大的混乱，所以决定逐一处理，我临时改写了相关程序以方便调整，局方抽调其他岗位的人员来支援，通过大家加班加点的努力，用了一天多一点的时间终于将数据调整正确，新系统也开始稳定运行。这一事件也再一次验证了那句话“三分技术，七分管理，十二分的数据”，数据的准确性对数据库应用的成功是何等的重要！ 3、涉及分布式应用 计费系统与营业系统有比较密切的关系，而这两个系统各有独立的数据库，所以两个系统的交互涉及分布是应用。当时营业系统客户资料的变更通过接口表的方式传递给计费系统；营业系统在给客户办理相关业务前需要检查该客户是否欠费，需要调用计费系统判断是否欠费的函数；而当欠费停机的客户交完欠费后，计费系统也需要调用营业系统的自动开机过程。上述分布式调用都是通过Oracle的database link完成的。 4、首次遇到Oracle经典的“快照太老”错误 那是1998年元旦，举国欢庆新年之际，我们在紧张地加班进行新系统上线，当新一月的帐务数据已计算完毕并核查没有什么问题后，我编写的后台销帐程序开始运行，该程序外层使用一个大的循环（用游标cursor实现）取预付费用户余额数据，如果余额能够抵扣该用户新的帐务数据，便进行一次后台销帐，每一次销帐成功作为一个事务。但运行了一段时间后，程序突然异常退出，我又试了一次，程序还是在运行了一段时间后异常退出。分析Oracle给出的错误，“快照太老”，我当时真是不知其所云，查阅Oracle资料对其的解释，由于我们当时对Oracle内部了解有限，绝大部分解释没看懂，但里面提到“大的游标（cursor）中如果穿插commit可能会导致此类错误”，而我的程序正好属于这种情况，但从逻辑上讲一次销帐作为一个事务非常合理，也不能等所有用户销帐完毕后再统一提交。当时我采取的解决办法是，在外层再嵌套一层循环，对此类错误引起的例外（exception）进行屏蔽，再根据相关的时间戳，继续提取近期没有进行过销帐操作的用户（即排除掉发生“快照太老”错误前已销过帐的用户）进行处理。这样，后台销帐可以顺利完成了，但通过检查日志可以发现，一次销帐过程要出现5-6次“快照太老”错误。后来，我优化程序，在提取用户数据时加一个排序，不仅整体销帐时间减少了一半，而且“快照太老”错误也基本不出现了。
项目成功与失败的经验归纳： 该项目成功上线运行。 经验： 1. 遇到问题要冷静，即使一时找不到最佳的解决方案，但也要想办法使系统先正常运转起来，再逐步优化解决方案； 2. 在系统上线前，经过多次出帐、收费的对比测试，保证了系统总体上不会出现太大的问题，即上线前的测试非常重要； 3. 选择业务量比较少的非工作日上线，这样发现问题可以及时改正并减少影响范围； 4. 编制了内部审核、校验程序，如：昨天系统用户预存款总额，加今天金额变化的量（考虑用户交款、扣款、冲帐、调帐等的影响），应等于今天预存款总额；如果实际结果相等，证明系统运行正常，如果不等，促使相关人员分析不等的原因，尽快找出系统漏洞。内部审核、校验程序增强了我方与局方对新系统正确运行的信心； 5. 局方技术人员大力配合，与我方人员结下比较好的个人友谊，帮助我们克服各种困难，是项目成功的关键； 6. 项目组成员虽然年轻、经验少，但精力旺盛、私心杂念少，大家团结一致、互相帮助，共同为了事业而努力工作； 教训： 1. 由于负责原有系统数据转换的同事没有参加第一次开局工作，所以经验相对缺乏，而且这个局历史数据也很复杂，虽然经过精心核对，但最后还是在数据上出了问题，所以数据库应用再怎么强调数据的准确性都不为过，尤其是需要进行新旧系统割接的项目更要倍加重视； 2. 由于当时缺乏经验，数据库索引的选取、物理存储的分布，都有很多可以优化的地方； 3. 系统刚运行时，只是采用export作为备份手段，而没有开启数据库的归档方式，一旦发生介质故障恢复将比较烦琐； 4. 当时对系统安全性也重视不够，协作单位开发数据采集系统的工程师也直接登录系统数据库，晚上误操作删除了用户资料表，如果不能及时恢复必将影响第二天的正常收费，而由于上述关于备份/恢复策略的缺陷，人工补录肯定耗时较长，幸好业务系统的用户信息表与我们使用的基本一致，而且平时我们也是从那里获取的信息，所以经过连夜的紧急加班恢复了数据，没有造成太大的影响；
你在项目中岗位与贡献： 这是大唐电信软件公司计费帐务系统所实施的第二个工程，我全程参与了该项目，包括前期项目的争取与后期项目的实施。在项目实施过程中，进驻现场将近五个月，到各营业厅了解实际的需求，根据新的需求重新进行软件开发。上线前进行各类的测试与对帐，上线过程中密切监控系统运行情况，对反应上来的问题及时进行修正，积极想办法解决数据导入后产生的问题，上线后对数据库进行优化以提高系统效率，为该项目的成功做出了重要贡献，也进一步扩大了大唐电信软件公司计费帐务系统的市场。
|
| 项目四：本地网综合计费系统开发 |
| 项目简介（功能与用途）： 本项目为大型数据库应用开发项目。 大唐电信计费系统在成功开通两个本地网后，当时根据合同，还有七个本地网要在比较短的时间内开通，这时两个本地网的开通一方面积累了宝贵的经验，另一方面也暴露出许多问题，要想顺利完成七个本地网的开通，必须对现有版本进行整合、对系统加以完善，开发出功能更加强大、稳定的版本，以供大规模工程之需。 公司决定集中开发“本地网综合计费系统”，功能包括客户资料管理、计费管理、帐务管理、欠费管理、前台收费、统计查询及营收报表等。另外该系统还要能够支持整个本地网，即将本地网下属的县局、农村支局也纳入计费系统中，而已开通的两个系统不包括县局与农村支局。该系统为电信企业对固定电话用户进行计费、收费的系统，是电信企业最为关键的业务支撑系统之一。
项目难点与解决方法： 1、需求的统一 已开通的两个本地网已存在许多差异性需求，而通过对将要开通的七个本地网的调研，也发现有很多本地化需求。为了使系统能够有更强的灵活性，在设计时引入不同类型的参数设置，努力在需求发生变化时，只需改变参数设置，而不需要更改程序。但在开发过程中，我们也认识到，软件的灵活性、参数化也应有限度，其代价往往是性能的与程序可读性的下降。不要寄希望于需求不发生变化，而是要加强软件过程管理，适应需求的变化，跟踪管理好需求的变化，加强软件版本控制与配置管理。 2、原有数据的转换与导入 在前两个本地网的开通过程中，都是我方的技术人员去努力了解原有数据的格式与编码规则并编写数据的转换与导入程序，这既浪费时间又容易出错，下面我们要面临七个本地网及其下属更多的县局与支局，我们不可能去逐个了解每个遗留系统（当时很多县局与支局都有自己独立的计费系统）的情况。针对这种情况，我们设计了一套较为简单的中间表格，由局方负责原有数据转换到中间表格，而由我方负责将中间表格的数据转换到新系统中。 3、处理的数据量加大 由于要将本地网的县局与支局都纳入到系统中，所以系统的数据量加大，为了更好地进行管理并提高系统性能，采用了Oracle 8新提供的分区技术。 4、更为复杂的人员权限管理 由于要将本地网的县局与支局都纳入到系统中，所以系统需要进行更为复杂的人员权限管理，由此设计了能与之适应的人员多级管理与授权功能。 5、各地报表需求种类繁多、格式各异，并有定制化需求 引入BO等相关工具及其设计思想，定义各类报表元素，在报表元素的基础上定制、组合各类报表，为解决此类问题进行了有益的探索。
项目成功与失败的经验归纳： 该项目取得了成功，为大规模的工程实施打下了比较好的基础。 经验与教训： 1. 软件设计时重视配置的参数化，使系统灵活性相对较好，但也需认识到软件的灵活性、参数化也应有限度，其代价往往是性能的与程序可读性的下降； 2. 认识到要加强软件过程管理，适应需求的变化，跟踪管理好需求的变化，加强软件版本控制，开始引入clearcase作为配置管理工具； 3. 在E-R模型向关系模型转换时，在遵循解规范化理论与转换原则的基础上，也清楚地认识到，并不是范式越高越好，为了加快查询速度可以适度加入冗余，非BCNF范式的关系虽然理论上可能会发生更新异常与冗余，但如果实际中该关系并不进行更新或更新的频度很小，其造成的负面影响也将十分有限；软件与数据库设计也是一门平衡的技术，究竟规范到什么程度，也要看具体的需求及平衡各方面的利弊，而没有一定之规； 4. 开发初期有过分强调数据库独立性的倾向，想达到不需要修改程序，只需修改简单配置，便可*选择数据库管理系统的效果，但经过一段时间的努力发现要达到该目的不仅非常困难而且成本很高，并在事务处理及性能方面都存在潜在的问题； 5. 在设计之初，没有很好地考虑有关历史数据的保留、清理与转储问题，也没有对用户这方面的需求进行很好地分析，给日后数据库的维护带来一定的麻烦； 6. 开始重视开发文档的编制与管理，编写的文档比原来齐全了，也较为规范，但现在看来，应该引入被普遍接受的建模思想与建模工具，提高开发文档的质量； 7. 在编码方面，制定了比较严格的编码规范并严格执行，代码的可读性有一定提高； 8. 测试方面，由于当时没有专职的测试人员，致使不少软件当中的Bug被带到了工程现场；
你在项目中岗位与贡献： 我是该系统主要的开发者之一，也是计费部门成立后的技术主管之一，与其他技术主管共同参与了软件的分析、设计及数据库设计，负责后台销帐、前台收费及部分查询功能的设计与编码，为该项目做出了重要贡献。由于我负责的销帐与收费模块设计合理、性能优良，保证了今后几年这部分程序在工程项目中版本的基本稳定，减小了现场实施的工作量，稳定了软件质量，减小了维护成本。
|
| 项目五：中国电信本地电信业务计费帐务系统统一检测项目 |
| 项目简介（功能与用途）： 随着1998年-1999年间，原中国电信“九七工程”（电话业务计算机综合管理系统）的全面展开与完善以及电信企业经营管理的需要，原来作为“九七工程”子系统的计费系统的重要性日益显著，有必要将其独立出来，开发与建设新的“本地电信业务计费帐务系统”。根据“九七工程”及其它信息系统建设的经验与教训，中国电信提出了“统一需求、统一设计、统一检测、按省实施”的工作方法，而“统一检测”是其中的关键一环，工作内容是对同中国电信签署了合作开发合同的六十余家软件厂商开发的系统进行检测。其目的主要在于保证本地计费帐务系统改造工作的顺利进行，保证本地计费帐务系统核心部分的统一性，为各省提供一个高质量的应用软件选择范围，促进应用软件开发商提高软件开发质量，不断完善、补充和修改应用软件。
项目难点与解决方法： 此项目的特点在于它是对基于数据库的应用软件进行大规模（参测厂商有六十余家）的入围检测。 此次应用软件检测工作是中国电信首次，也是中国计算机行业少有的大规模进行的针对应用软件的集中检测工作，难点在于没有任何经验可以借鉴，因此检测准备工作是否细致、充分，直接关系到检测工作的成功与否。为此，在原中国邮电电信总局的领导下，检测工作组很早即着手开展了应用软件检测的各项准备工作，包括与国内外公司、专家进行交流、学习和讨论，检测总体方案的制定，检测平台方案的制定，检测组织方案的制定，检测工作人员的培训，检测环境的搭建，测试数据的准备，测试用例的编制，检测标准的量化等诸项工作。最终形成了总体检测方案以及各分项检测方案，成立了相应的组织机构，制订了严密的制度与管理条例。以下几个环节是该项目成功的关键。 一、检测工作的定位与角度 此次检测不同于软件厂商内部进行的软件测试，内部软件测试是软件开发周期内的一个重要环节，其目的在于找出程序中存在的问题和错误。而此次检测是在应用软件内部测试的基础上，从符合度和规范性两个方面进行的检查和测试，即检测应用软件与中国电信相关规范的符合程度。 二、检测内容 根据检测工作的定位、角度及当时软件开发普遍存在的问题，检测的主要内容包括文档评测、安装评测、数据字典静态检查、功能检测、性能检测等五个方面内容。 1、 文档评测：当时国内软件开发还很不规范、重程序轻文档的现象普遍存在，而软件=程序+文档，没有规范的、与实际情况相符的文档，随着时间的推移与软件企业人员的流动，应用系统将越来越难以维护，这不仅是软件开发企业的问题，也将直接影响软件使用单位的利益。所以为了检查软件的开发过程是否规范，文档检查是必不可少的一环。 2、 安装评测：应用程序的安装应该快速、简便，尤其是客户端的程序，不仅开发人员可以安装，维护人员也应容易掌握。 3、 数据字典静态检查：相关规范规定各开发单位必须严格执行相关设计中规定的表名、字段名及字段类型和长度，不得修改。根据这些要求，我们开发出一套对数据字典进行检查的程序，该程序支持ORACLE、SYBASE、INFORMIX等数据库管理系统。 4、 功能检测：功能检测本着既全面又突出重点的原则，全面指的是测试用例所覆盖的功能点应含盖计费帐务系统的各个方面，重点突出指的是相关规范所强调的能够提高服务质量、增强竞争能力的一些有特色的新功能，这样既检测了计费帐务系统的完整性，又突出了新系统的重点，使功能检测的结果能够切实反应被测系统的真实水平。 5、 性能检测：计费系统是电信企业关键的应用系统，不仅要求有完备的功能，而且要求有良好的性能。本次性能检测主要考察两个方面，一是帐务周期整体出帐历时，二是模拟有多个联机用户的情况下收费程序响应时间。鉴于当时我国软件行业多数企业没有实力或没有意识到应在开发阶段对系统进行大规模压力测试，致使只有到了实际运行后，才发现效率方面问题的状况，本次检测工作，使用了国际上比较流行的性能检测工具，模拟大量用户同时联机操作的情况，一方面检测了系统承受一定压力的状况，另一方面也促使各开发厂商尽早考虑效率方面的问题，为各厂商提高开发质量起到了积极的推动作用。 三、搭建检测平台 向IBM、HP、DEC、SUN等四个厂家分别借用了配置基本相同的双机集群（CLUSTER）结构中高档小型机服务器作为主机系统；同时ORACLE、SYBASE、INFORMIX 等数据库厂家分别借给中国电信多套大型关系数据库，使得每个主机系统上均安装了上述三套大型关系数据库，共计十二种主机、数据库的组合供被检测方选择。 四、检测数据 检测数据一部分从现业局提取，一部分由检测工作组构造。 五、检测用例 检测用例参照检测范围，并结合检测数据编制而成，体现了既全面又突出特点的原则。 六、检测用程序 开发出一套对数据字典进行检查的程序，该程序支持ORACLE、SYBASE、INFORMIX等数据库管理系统。 七、实测 工作量由小到大逐渐展开，第一批安排一家、第二批两家、第三批三家，自第四批才开始满符负荷同时检测五家，在这个过程中，检测人员及时总结经验、解决新出现的问题，使测试工作得以顺利进行。
项目成功与失败的经验归纳： 本项目达到了检测的目的，取得了成功，主要经验如下： 1. 检测工作遵循软件工程理论的指导，并参考相关的国际、国家及行业标准； 2. 检测工作定位准确、目标实际，检测内容选择恰当，为具体工作得以顺利实施提供了前提保证； 3. 检测准备工作细致、周到，极大地减少了实测时可能遇到的风险与问题； 4. 组织这样大规模的测试，组织方需要有强大的协调能力，设备、技术支持到位（IBM、HP等公司的专家多次提供宝贵意见，Oracle、Sybase有专门工程师负责平台维护，有的工程师还进驻现场监控系统运行情况），后勤保障有力； 5. 检测工作组织管理有序，一方面人员职责明确、各司其职，另一方面能够发扬团队精神、互相帮助； 6. 检测结果客观、真实、准确，并尽量做到量化，有些检测项目还是由计算机来完成，尽可能减少了主观因素的干扰； 7. 采用流行的压力测试工具模拟大规模并发操作，促进软件开发企业尽早考虑系统性能问题。
你在项目中岗位与贡献： 本人为该项目技术支持组的成员与HP平台检测组组长，这一项目中的众多方案、流程、测试用例、测试报告及评判标准，多数都是由本人直接起草或是在本人的建议、指导下完成的，我还参与了检测平台的搭建，即在HP、DEC、IBM、SUN四套硬件平台上分别安装维护Oracle、Sybase、Infomix等三种数据库管理系统。我全程参与了对全国60多家计费厂商产品的测试工作，负责现场疑难技术问题的处理，我还自行开发程序对各厂家的数据字典进行依从性检查。通过这一项目，使我在基于大型关系型数据库的应用系统的测试方面积累了宝贵的经验，也使我在以后有机会参与了更多的测试项目。
|
| 项目六： 中国联通CDMA专业计费子系统上线测试 |
| 项目简介（功能与用途）： 中国联通是国内唯一一家对所有电信业务拥有经营权的电信运营商。为了发挥综合业务的优势，实现灵活多变的营销策略，中国联通提出以“一个体系，多个子系统”的思路来建设综合业务支撑系统，CDMA专业计费子系统正是本着这一原则进行建设的，由数据采集、预处理、一次批价、统计、联机管理、系统管理等模块组成。2002年初，为了保证CDMA网络正式运营之后计费子系统的准确性与高可靠性，中国联通决定在正式运营之前对各地的CDMA专业计费子系统进行一次全面的测试。 本次测试本着公平、严谨、科学的原则，对被测厂商提供的软件进行全面、规范的测试。测试工作分为两个阶段：集中测试和现场测试阶段。 集中测试阶段，测试范围覆盖预处理、一次批价、统计管理、系统管理等模块，重点测试系统的准确性与处理效率。现场检测阶段，测试范围覆盖数据采集、联机指令、监测等模块。
项目难点与解决方法： 当时有6家厂商承担联通全国31个省级计费系统的工程任务，该项目的主要难点在于如何能切实全面测试各地系统的运行状况，并得到软件开发商的全力支持。 为了能圆满完成测试任务，我们将测试工作分成集中测试与现场测试两个部分。其中集中测试主要测试各地计费系统*性的部分，而现场测试主要测试各地的差异性部分。 一、集中测试阶段 为了使测试取得更好的效果，测试人员做了大量、细致的准备工作，主要包括： 调研工作，为了使测试工作更具针对性，在项目启动之初，相关人员就做了大量的调研与收集资料的工作。其中主要包括向相关厂商及分公司发放调查表，了解目前系统运行情况及厂商对测试环境的需求；收集各地C网业务开通情况及现行的资费政策；收集交换机话单格式说明；收集局数据，为局数据核对做准备； 测试平台的搭建，根据厂商的需求，测试人员对测试用主机、网络进行了重新规划，并安排相关厂商安装了必要的软件环境； 测试用例的设计，软件工程理论与实际工程经验均表明，软件错误往往发生在系统输入与输出的边界值及一些特殊处理上，所以，测试人员在设计测试用例时重点考察了各种边界情况及其它一些易发生错误的地方（如通话跨时段、跨天等等情况）； 测试数据的构造与提取，为了使测试内容更加全面，测试人员熟悉了当时使用的全部6种交换机的原始话单格式，并在没有辅助工具的条件下，手工构造了测试预处理模块所需的原始话单（二进制格式）；另外，为了减轻被测厂商的工作量，测试人员还提前熟悉了各软件厂商内部的话单格式，尽可能依据厂商的内部格式，构造一次批价所需的数据；为了进行性能测试，相关负责同志还从某省提取了上千万的原始话单； 在测试工作的组织管理上，在项目启动之初，就形成了本项目的《总体方案》，之后又按计划逐渐形成了《测试流程》、《测试人员管理条例》、《被测厂商管理条例》、《测试机房管理条例》等管理文档，另外，还组织各软件厂商召开了测试工作的动员会，并向其发放了正式的通知函，这些都保证了测试工作有序、规范的进行。 正是上述充分的准备，为测试工作的成功打下了良好的基础。集中测试共对6家软件厂商的产品进行了测试，测试主要包括4个方面的内容： （1）功能测试：测试范围覆盖预处理、一次批价、统计管理、系统管理等模块； （2）性能测试：处理从现业局提取的约1000万原始话单，记录各阶段的处理时间； （3）局向数据审查：测试人员编写脚本，对比厂家提供的局向数据与结算中心提供的局向数据的差异； （4）对比测试：参加测试的厂商同时处理同一批话单，对比各自的计费结果，如有差异，核查其原因。 二、现场测试 集中测试结束后，测试人员又开始了现场测试的准备工作，主要包括以下几个方面： 试点测试，为了使现场测试更加全面和科学，首先在北京和河北两个分公司进行了试点测试，有关测试人员都参加了两个试点的现场测试，制定了统一的评判标准与统一的工作流程，保证全国的现场测试工作在公平、公正、科学的基础上顺利实施； 检查记录和测试用例的设计，为了使检测工作更全面，在进行了试点分公司的现场测试后，对检查记录和测试用例进行了进一步的修订和完善，并细化了现场交流的提纲； 在集中测试发现问题的基础上，测试人员准备了现场测试中需要重点检测和核实的方面，以便在现场测试时对厂家集中测试时发现的问题进行更深入的了解； 测试工作的组织管理方面，在《总体方案》的基础上，之后又按计划逐渐形成了《现场检测工作流程》、《现场检测座谈会流程》等管理文档，另外，还向各省分公司发放了现场测试通知及准备工作通知，这些都保证了测试工作能够有序、规范地进行。 上述全面、细致的准备工作，使得现场测试工作顺利进展。现场测试人员分成4组，每组平均对6~7个省进行测试，每个省的检测时间平均为2天半。共检测了由5个软件厂商实施的28个省级计费系统的现场运营情况，按计划在18天内完成了全国范围的测试。现场测试的主要测试内容包括： （1）文档审查：检查软件厂商提交给各分公司的文档的种类是否齐全； （2）采集模块的检测：由于系统已经上线运行，所以本次检测工作主要检查系统目前实际运行情况，听取相关技术人员的讲解，填写相关的记录表。如果生产环境允许，可以制造网络断点，以检查断点续传、自动告警、自动任务恢复等功能； （3）联机指令模块的检测：事先请各分公司准备好一定数量的测试号，测试时，通过综合营帐对这些测试号进行现场开通、增加特服、销号等操作，通过现场的拨打测试检查联机指令的发送是否成功； （4）监测模块的检测：检查应用系统是否能够完成对主机、数据库、网络和应用程序运行时的性能和状态进行监测； （5）对于在集中测试时，没有提供统计模块的软件厂商，现场测试时要检查其统计模块的功能。
项目成功与失败的经验归纳： 本项目达到了检测的目的，取得了成功。 1. 检测工作遵循软件工程理论的指导，并参考相关的国际、国家及行业标准； 2. 由于本次测试工作旨在CDMA系统正式运营之前，检查发现专业计费子系统中存在的问题，从而督促相关人员进行改进以降低正式运营后的风险。所以，为了使各软件开发商更加积极地参与本次测试工作以达到更好的测试效果，对于本次测试结果，不进行横向比较，不进行评级、打分，只作为系统改进的依据，这样极大地消除了软件提供商的顾虑与抵触心理，使他们更加积极地配合测试工作，而不是设置障碍，从而取得了比较好的测试效果； 3. 由于设计测试用例时重点考察了各种边界情况及其它一些易发生错误的地方，又引入了多家厂商处理相同话单后进行对比的测试方法，所以发现了软件当中不少深层次的错误，有的问题还很严重，促使厂商对软件进行修正。测试达到了预期效果，既减小了联通运营的风险，也减小了软件厂商日后维护的风险，达到了双赢的效果； 4. 集中测试与现场测试内容分配得当，即测试了各厂家计费系统的各个组成部分，也测试了各省本地化的内容，还最大程度上减少了核心部分的重复测试，节约了项目成本； 5. 组织这样大规模的测试，组织方需要有强大的协调能力，设备、技术支持到位，后勤保障有力； 6. 检测准备工作细致、周到，极大地减少了实测时可能遇到的风险与问题； 7. 检测工作组织管理有序，一方面人员职责明确、各司其职，另一方面能够发扬团队精神、互相帮助； 8. 检测结果客观、真实、准确，有些检测项目还是由计算机来完成，尽可能减少了主观因素的干扰。
你在项目中岗位与贡献： 本人为该项目技术方面的负责人，这一项目中的众多方案、流程、测试用例、测试报告及评判标准，多数都是由本人直接起草或是在本人的建议、指导下完成的。集中测试时，本人负责组织进行多厂家对比测试及现场疑难技术问题的解决；现场测试准备阶段，负责组织试点局的测试，制定统一的尺度与工作流程，对现场检查记录和测试用例进行了进一步的修订和完善，并细化了现场交流的提纲。现场测试时，负责北方七省区的现场检测工作，并协调、监控其他组的测试工作，为项目的成功做出了重要贡献。
|
说明：斜体字均为填写范例和说明，文字题写不受篇幅限制，请尽量详尽。
登记表格请同时提交信箱：bestdba@ciw.com.cn mulibox@yahoo.com.cn