“怎么搞的嘛！系统越来越慢了！我抽根烟回来，订单界面还没有打开！”
　　“客户来电话查询货是不是已经发出了，等了七八分钟都没有反应，客户说，你们公司怎么了？”
　　“工单只打印了半截，而且规格数据还是错的，到底是让我相信系统还是相信纸？”
　　……
　　一夜之间，信息中心成为众矢之的。这还没有完，昨天半夜董事长闻娴打来电话，那时张承刚刚回来后不久，值班的生产经理发现系统又无法登录，就直接投诉到董事长处。
　　张承只好打车回公司查看，杀掉系统中的几个进程后，应用服务器和数据服务器又正常了。不一会儿，CIO张承就倒在沙发上就睡着了。
　　系统运行五个月，除了一些数据和功能Bug之外，没有什么异常，一直很稳定，不知什么原因，最近两三个星期问题频频出现。应用服务器的CPU由两颗增加到四颗，情况依然如故。刚刚被大家看好的张承，陷入危机之中。
　　成也平台
　　亨利光学仪器仪表公司在2008年上半年经历了一场重大的改组，40多个供应商都被统一到亨利的新工业园区，同时销售方式也由代理批发转向覆盖各地的加盟商，销售体系和供应体系的改造花了半年多的时间，调整过程困难重重。
　　闻娴董事长为了巩固调整成果，同意张承用知名软件公司银燕的开发平台与运营平台，由银燕提供平台，银燕的合作伙伴提供开发外包服务，张承负责提供需求，合作过程还是不错的。5个月的时间，系统就开发完成了，系统是基于业务的特性展开的，40多个模块在需求确认与开发实现的基础上顺利实施。
　　2009年元旦，系统正式上线，创造出了行业软件项目的一个奇迹，引来许多同行参观，银燕借此接了不少单子。运行五个月后，按照张承的计划，应该在执行方面加强督查，他甚至做出了专门的运营品质稽查表，以检查系统运行过程中的各种差异。而事实上，业务部门包括供应商都不习惯进行工作质量自查。到了五月份，系统性能问题一波接一波地出现，甚至有人开始以性能的问题来否定整个系统。
　　败也平台
　　眼下，性能问题引起的“并发症”还真的不少，系统升级后，改善的功能用户不愿意使用，用户不愿意验证，公司的许多改革成果就无法落地。
　　张承赶紧邀请银燕以及合作伙伴的工程师进行细致分析，同时在内部组成业务和技术的专门项目组。初步来看，原因主要来自几个方面：
　　1.数据库的索引没有做，导致应用程序调用数据进程缓慢，甚至挂起；
　　2.数据表没有规划，现在数据表接近3000个，按照一般的管理系统，应该在1000个左右；
　　3.在一部分的程序代码中存在Bug，包括编码规范也存在太多冗余的问题，造成系统访问循环增多；
　　4.局域网的网络结构没有及时改造，汇聚层的交换机需要升级。
　　早先对于平台的关注点就集中在业务的快速实现与需求的及时变更方面，性能方面到了问题聚焦的时候才发现。而且现在的业务量在持续上升，张承真担心系统会崩溃。
　　陷入困局
　　这个时候应该怎么办呢？董事长限定张承在两个星期内彻底解决问题，她才不管是平台问题还是技术问题。因为2009年下半年，她要去台州做一个几乎和温州一样模式的光学仪器基地，改造当地的几家同行。
　　张承也清楚，现在的问题看上去是聚焦到技术领域，解决起来应该有办法，但具体怎么做，他也没有经验，另外张承还担心未来的二期项目受当前的影响，随着项目的深入，公司将有更多的活动放在系统里，潜在的性能问题以及其他风险会怎么样不得而知。
　　张承应该如何驱动，如何组织，以彻底消除性能问题的影响，为未来的信息化项目管理，为IT与公司战略的协同减少风险？
　　（东经控股集团 王甲佳）
　　处理速度决定应用价值（赵元旭：中国石油大连石化公司信息中心高级工程师）
　　据需求变革企业运营模式是现代企业适应市场的重要手段，计算机、网络、数据库等IT技术能力为企业变革提供了重要的技术支持保障，同时也正因为信息技术因素，才衍生出当今管理界各种最新管理理念、管理方式、管理办法，技术为提升管理效果架起了桥梁，管理为提升技术价值提供了机会，两者在互动中共享、在共享中互动，其合力在推动企业不断发展。
　　查找原因对症下药
　　对系统集成环境下影响应用系统稳定性主要有如下五方面因素：
　　影响系统变慢的终端层面因素主要有：虚拟内存的设定、系统驱动程序设置是否合理、及时删除Windows多余的DLL程序、硬盘分区不合理、硬盘空间不足、内存偏小、不用的服务未及时卸载等，都会导致终端层面系统运行速度降低。
　　影响网络信息传递速度的影响很多，如网络的拓扑结构不合理、防火墙设置不合理、端口瓶颈阻塞、计算机病毒等。本案例的企业将40多个供应商统一到新工业园区，同时销售方式也由代理批发转向覆盖各地的加盟商，可能会在同一时间对某一个网络设备访问需求提出新的要求，而网络设备的性能偏低构成瓶颈，比如汇聚层交换机带宽不足的问题。企业内部其它业务模式改组也存在类似问题，应根据实际情况调整网络拓扑结构。当网速变慢时，我们可在网络使用高峰时段，利用网管软件查看路由器、交换机、服务器端口的数据流量，确认网络数据流通瓶颈的位置，设法增加带宽。
　　影响服务器运行速度的有缺少域、CPU状态不正常、操作系统设置不合理、磁盘I/O速度慢、网卡I/O瓶颈等，尤其是CPU占用率，如果经常在100%，那么就要怀疑是不是病毒已侵入系统。用优化大师等工具把不用的服务停掉，不用的动态库从内存中清除，可有效提高服务器运行速度。
　　本案例所说的索引表没有做、数据表没有合理规划、部分程序代码中存在Bug，包括编码规范也存在太多冗余的问题，造成系统访问循环增多都是影响数据库运行速度的原因。人们在开发系统时往往会过于关注系统业务功能是否正确，容易忽略不同的实现方法之间存在的性能差异，不恰当的索引设计、不合适的数据表规划、不充分的连接条件都涉及到数据库层的资源配置、网络层的流量控制、操作系统层的总体设计，充分利用索引，减少表扫描的I/O次数，清除程序Bug，便可有效提高数据库访问速度。
　　病毒入侵后，占用了系统大量的内存资源，导致正常程序运行因缺少主内存而变慢，同时病毒程序会迫使CPU执行无用的垃圾程序，使得系统始终处于忙碌状态，从而影响了正常程序的运行，导致计算机速度变慢。对系统构成系统化危害。因此及时升级防病毒系统版本，及时安装补丁程序非常重要。
　　全盘思考系统分析
　　本案例的公司组织模式是以信息技术应用为基础的，特点是充分利用公司原有投资基础的技术改造。当数据共享、系统集成复杂度提高以后，影响系统运行质量的制约因素也同步增加，本案例虽然结合公司变革需求开发了40多个业务模块，却忽略了系统整体技术性能的同步优化，累计运行时间便暴露出系统缺陷，技术的基础性支持没有得到很好发挥。
　　针对系统运行暴露出来的技术缺陷，抓紧整合信息部门技术力量，以提升运维服务能力为目标，按照事件管理、问题管理、配置管理、变更管理和发布管理的国际通行做法制定运维支持流程，理清问题思路，客观找出问题所在，提出行之有效的解决方案，将系统影响降到最低。
　　具体到解决系统运行速度问题，首先运用各种测试工具按照终端、网络、服务器、数据库、系统软件、应用软件的技术逻辑逐一排查，逐步缩小排差范围。处理IT问题通常是对IT人员综合知识能力的一次检验，比如数据库性能优化很多情况下与解决数据库以外的问题有关。
　　经验表明，对网络、计算机设备、操作系统、数据库参数优化所获得的性能改善，只占数据库系统性能提升的40%左右，其余的60%来自对应用程序和用户体验的优化。
　　影响运行速度的问题分析
　　异常情况响应快、系统运行速度快、故障问题处理快，是企业对IT部门的基本要求，系统用户满意度是衡量信息部门工作质量的重要指标。在充分调查研究基础上，定位性能瓶颈，找出最消耗资源的Bug应用，责成相关技术人员重新划分逻辑资源，从CPU、内存、磁盘I/O、网络入手，确定合理的性能优化步骤，优化指令代码提高服务器运算能力，优化索引条件提高数据库检索效率，优化网络拓扑结构提高网络通信能力，优化服务器系统配置参数提高服务器运行速度，有条件时可以采用冗余技术提高系统整体抗风险能力。
　　管理有序用户满意
　　构建IT部门运维管理体系，形成用户反馈和运行监督机制是保证系统稳定运行的管理保障。在企业内部网页上公布运维管理人员热线电话，让全体员工都熟悉IT系统出现问题时知道找谁，IT人员有能力及时获取运维请求信息，IT人员接到报告后第一时间到达现场情况，处理了什么问题，用什么方法处理问题，问题处理的结果如何，其他人员是如何配合的等，都需进行详细记录，这样做既可完成员工绩效评价，又可进行经验积累，监督考核并举益于强化员工责任意识、技能意识、服务意识，提升IT问题响应能力，提升部门服务质量，经验共享对于提升服务效率，引导一人多能，减少紧急情况对“关键人员”的依赖，降低服务成本更有独特的作用。
　　如何发挥小型IT部门有限的人力、物力、财力，正确的理念、规范的流程、明确的制度非常重要。IT运维首先是面向客户的服务意识，其次是明确的人员分工，建立简单的故障和问题管理流程，利用表格工具等记录故障及处理情况，跟踪用户体验，了解用户最新需求，定期总结并从中辨识和发现问题线索，建立变更管理意识和初步变更流程，减少变更操作的随意性，安排定时及规律性巡检，可以在很大程度上有效降低故障概率，将问题处理在初始状态，追求服务效率最大化。第三应该给应用服务建立一个能够量化的运维目标，这样不仅可以在工作中务实地提高服务质量和管理水平，也可以有效提高IT人员的成就感。
　　应该从根本上解决问题（尹传东：哈尔滨医科大学第二临床医学院远程医学中心总工）
　　案例确实带有一定的普遍性，案例从表面来看，似乎问题已经解决。张承杀掉系统中的几个进程后，应用服务器和数据服务器又正常了。以及与合作伙伴的工程技术人员进行细致分析，在内部组成业务和技术的专门项目组进行工作，原因主要聚焦到技术领域的几个方面。
　　寻求系统开发的方法
　　看起来出现的问题并没有那么复杂，而如何应对解决，说来是CIO在管理信息系统开发应用中的经验和方法问题，实质是系统开发应用的理论基础与实际相结合的问题，应该从根本上解决问题，让领导和使用员工真正看到解决问题的根本实质和能力水平，否则将来还会出现问题。
　　基本开发应用流程是经过系统调研、系统分析、系统设计、系统论证、系统程序和流程设计、程序编程、程序安装调试、系统测试运行、系统总结和评估、技术培训和维护等。按照用户至上的原则，采用结构化、模块化自顶向下对系统进行分析和设计。具体来说，它将整个信息系统开发过程划分为独立的六个阶段：
　　信息系统开发过程分为独立的六个阶段
　　这六个阶段构成信息系统的生命周期——软件的生命性。每个阶段都有它的内涵、方法、要求和意义，严格按阶段实施，可以规避一些大问题的出现。
　　许多企业或CIO等技术人员，不知道系统开发应用各个阶段和过程中的一些方法、作用和目的，只能通过损失和失败的代价来学到管理信息系统的开发应用过程，使信息系统波浪式地向前发展；分析很多企业，特别是中小企业这方面的问题确实较多。
　　系统按标准实施
　　管理信息系统的开发方式有自行开发、委托开发（外包）、联合开发、购买现成软件包进行二次开发几种形式。从企业技术力量、资源及外部环境来说，一般委托开发或联合开发较多。
　　在开发应用的过程中，各个阶段必然不同程度的存在一些问题，前期几个阶段没有付之运行，用户往往是体会不到系统运行起来的情况，以及会出现什么问题；只有交付运行使用，也就是后期阶段，非计算机技术人员介入使用后，问题的出现和反映才明朗化，有时潜在的问题存在于各个阶段，为了避免这些问题的出现，按软件工程的方法进行应用开发。这是多少年来开发应用过程中最常见的问题，出现问题的区别有时是时间的长短；出现问题的原因包括：系统设计（承载运行后）问题、结构（硬件网络及软件架构等）设计问题、需求设计问题、程序优化问题、操作使用问题、应用环境问题等；当然这里面的问题有大有小、全局或局部、表面或潜含等的区别。
　　在开发应用过程中，每个阶段按规范标准实施，问题就会少出现。当然，出现问题在所难免，对于CIO组织领导系统开发应用中，关键是出现问题的时间要短，影响要小，处理解决要快。
　　案例明显在前期设计、编程和运行测试过程中，存在着网络（汇聚交换机）环境的缺陷和问题，售后服务维护不及时，包括售后维护形式、方法和时间响应等方面都存在问题。往往较好而快速的维护响应时间和态度，可以弥补系统平台缺陷所带来的负面影响。
　　从企业CIO来讲，所掌握的管理信息系统开发的原则和基本知识，不能和企业所开发应用的实际相脱节，何况下一步面临的二、三期工程，应该有一个完善的系统应用规划，充分论证和可行的方案，按着管理信息系统的开发应用流程进行实施和要求；如果CIO没有这方面的技能，应该尽快补课，否则必然要走人。
　　目前，软件开发商也不同程度地存在或心知肚明的一些问题。案例中的问题责任很大部分在于软件开发商，“知名的软件公司银燕”对于这样的信息系统全过程的开发应用，要注意什么应该是很清楚的，这样的开发应用势必给公司带来不良的影响。
　　较大的软件开发商，系统开发和应用安装实施人员多是分开进行的，易出现用户需求的实现和系统维护及改动上的脱节，造成系统运行中的不稳定或潜在问题；而开发和安装实施人员一体化，对于小的应用系统来讲应该可行。如果软件应用系统的开发缺乏软件工程化和规范化，软件的生命周期将会缩短，应用水平也很难提高。
　　需要管理工作基础
　　进一步展开来说，应用系统的开发必须具有一定的科学管理工作基础。只有在合理的管理体制、完善的规章制度、稳定的生产秩序、科学的管理方法和准确的原始数据的基础上，才能进行开发和应用。否则，也会在推广应用中出现一些问题。例如，操作使用人员感到限制了一些权利或自由度，一旦系统出现问题会更加反对。
　　领导不能真正地重视和认可，即使是正常运行，也很难持久和体现它的价值，出现问题之后离系统关闭也就不远了。看来案例中的闻娴董事长对信息化建设还是比较认可的；同时，因为问题原因已经基本找到，相信通过分析和对问题的解决后，不会让张承走人；更换一个CIO，有时不如继续任用经历过问题而有经验的CIO更好。当然，前提是两周内要解决问题，诚恳说服领导和使用人员能够理解，在系统应用开发过程中难免出现问题。
　　至于技术层面的问题，因篇幅所限，也不是这里讨论的问题。
　　几十年来我们在解决类似的问题时，遵循如下的思路：问题→原因→解决方法。
　　出现“问题”不可怕，“原因”找到了，问题的“解决方法”也就有了。这里要注意，“原因”还存在层次性，需要进行再分；如上述“平台系统不能正常运行”还可以是一个“问题”，“分析”是设计问题，还是操作使用问题，或是网络环境问题等。当然，有时一些“原因”不太好分析，有些“原因”分析出来了，“解决办法”却无法实现，这有可能就是一个绝症了。
　　

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。