对我而言，IT系统就像个桀骜不驯的顽童。以我的经验与资历，在与这个小家伙的每次斗智斗勇中我总能小胜一筹。直到我变身为一家中等规模证券公司的IT主管，经历了公司的新业务系统上线，那令人焦灼、磕磕碰碰的63个日夜让我明白了什么叫失控，至此，我也终于彻底地被IT给尥了次蹶子。

　　【一】上线第一天：惊心动魄的40分钟

网上下单系统宕了，才刚上线就这样，你这什么破系统?速度地解决，咱这客户都给得罪光就该哭了!客户服务部主管老李一通怒吼，啪一声摔了电话。

我抬眼看了下时间，9:30开市，此时指针已无情地指向10:50分。系统已经宕机多久了?我不得而知。不过，我迅速在几秒钟内理清了目前形势：

1、努力三个月的新系统第一天就遭遇毁灭性打击，我几乎能预想到项目总结会上BOSS的一张阴沉脸。哎呀，这月工资必定被打折了。

2、算算时间，离中午休市仅剩40分钟，必须利用11:30到下午1:00的这段时间赶紧给系统做个体检，问题到底出在哪儿呢?

时间紧迫，我把IT部门一票人员火速聚集，对系统现状进行了简单描述，接着就是紧促的分工部署。

真是分秒必争，先是对核心物理设备进行细致盘查，接着是系统访问日志、数据库……丝毫没有头绪。这时指针已指向了11:00，随着宕机时间逐渐累积，紧张的情绪让我血脉贲张。

难道是高负载宕机?部门负责运维的小王指着一堆数据惊呼。今天有支股票走势异常，并发下单量也许已超我们预期了。

该死，竟然是高并发压力测试没过关。刻不容缓，我随即启动了可用性方案消除了宕机影响。

11:30，宕机扫雷行动圆满完成，兴奋之余我终于长吁口气。可谁会料想到：两天之后来自老李的另一通电话足以让现在每个人脸上的笑容凝固……

问题分析：

手动测试导致结果不精确

在线用户和并发连接并没有直接换算关系，在进行压力测试时要设置一个典型标准用户操作的场景来衡量。而完整的压力测试场景包括单场景、混合场景的压力（极限）测试、性能测试、稳定性测试……

采用手动测试，无法模拟完整的压力测试场景，可能导致测试结果不精确。

　　【二】48小时后：堵不住的漏洞

系统安全性，一直是我关注的重点，我绝不允许病毒在我的区域内肆虐。但事实证明，在Web应用世界，谁也不能妄自夸下海口。

一上班，我发现了公司网站正被某位黑客锁定。当然，我首先分析了下Web应用普遍的安全问题类型：

◆服务器向公众提供了不应该提供的服务，导致存在安全隐患。

◆服务器把本应私有的数据放到了公开访问的区域，导致敏感信息泄露。

◆服务器信赖了来自不可信赖数据源的数据，导致受到攻击。

但要对这三种类型进行甄别实在不是件容易的事，我需要对Web应用服务器使用端口扫描程序进行系统风险分析，查看是否有服务本不应该面向公众开放，是否有人修改了对外提供服务的应用程序的banner信息，使攻击者容易获取到Web服务器对外提供应用程序的相关版本信息，并根据信息找到相对应的攻击方法和攻击程序。

当然，最终，我总会找到Web应用攻击的来源的原因。但是，在这一过程中，公司网站已然受到了重创。

接下来，我花了26天的时间集中火力寻找Web应用漏洞和攻击来源。当然，我首先要对Web应用程序进行系统检查，查看是否在开发过程中存在安全漏洞（bug），其次，我也需要对Web应用环境进行系统的扫描，甚至要对可能存在的Web应用漏洞实施模拟攻击，以检验漏洞的真实性。通过这一系列操作，我最终分析得出了Web漏洞攻击原因。但即便这样，在接下来的30天中，我始终惴惴不安，Web应用总让我感到危机重重，我时刻担心着员工的上网操作、担心着从网上下载的某个文件会让再次将公司网站置于黑客枪口之下。

果然，在系统上线后的第58天，我的担心成了现实。

　　问题分析：

用笨办法检证漏洞耗时耗力

Web应用攻击之所以与其他攻击不同，是因为它们很难被发现，而且它可能来自任何在线用户，甚至是经过验证的用户。对CIO而言，发现和解决它们的过程十分艰辛。

对于Web应用攻击，我们确实需要一个智能的方式来正确监测到问题，检证实际的漏洞。也许，一个能够持续更新并不断发现Web应用层中已知与未知漏洞的工具对我而言十分必要。

　　【三】致命一击：客户投诉夺命call

现实往往不如想象中美好，怀揣对系统意外故障的战战兢兢，我等来了再一次的致命一击，但这次却不是Web应用漏洞惹的祸。

现在网上下单简直龟速，客服部电话快打爆了，你赶紧解决下啊。一阵风后，老李面目狰狞地冲进了我的办公室。

5分钟后，部门全员投入了新的一次救火行动。但是很奇怪，并没有检测到网络堵塞或是系统服务器忙。我感到有点困惑。

不如从前台来看下：登录网上下单系统，查阅了近期关注的几支股票，我对其中一支股进行了买进处理，居然发现了问题的症结。下单之后的反应速度确实很慢，页面一直处于操作等待状态。而经过后来的分析，我才弄明白：这是因为操作反馈的确认按钮弹出功能出现了问题。

面对这种系统功能的缺陷，我实在无语。于是，接下来连续5天，我总是将自己封闭在办公室中，系统上线以来的各种问题让我不得不重新审视系统软件质量监控的重要性。系统质量安全面前无小事，也许某一天，这些小问题会酿成大灾害，甚至可能毁掉我的职业生涯……

我应该选择一个信得过的合作伙伴来帮我对整个系统应用过程进行质量管理，想到这，我拨下了一串熟悉的号码：108007440327

　　编者小结：

三上IT系统，让CIO焦灼抓狂的63天：先是手动测试导致的系统压力峰值结果误差，然后是Web应用漏洞攻击，最后是软件功能缺陷。

其实，这三个问题都可以规避在系统上线之前。在软件开发测试过程中，通过智能的测试工具就可以轻松完成测试管理，加速测试过程、缩短测试时间；针对Web应用安全威胁，可以通过应用安全解决方案定期检查Web应用程序的安全漏洞，帮助IT团队实现即时安全监测、纠正安全漏洞；对于软件可能存在的性能或功能缺陷，通过系统性能测评评估方案可以在系统上线前尽可能排查发现可能存在的瓶颈。

针对案例中CIO面临的各种问题，惠普应用质量解决方案提供一套完整的解决方案。它包括质量中心、应用安全中心和性能中心。

质量中心主要提供的是测试过程中的测试管理、功能测试和业务流程测试功能。

应用安全中心在软件开发生命周期的每个阶段检查Web应用程序安全漏洞，帮助研发人员、质量保证（QA）团队和安全专家迅速高效的监测和纠正安全漏洞，全面修复整个应用程序的生命周期。

性能中心提供的是测试过程中对性能的测试和诊断功能，通过系统性能测评评估未上线系统的性能并发现可能的瓶颈。