推动业务系统的有效实施可从两方面发力。一方面，要深入优化业务流程，制定可行规则，做到有法可依有据可査。另一方面，从基础架构的角度，深入业务系统核心进行规划设计及资源调配。

　　随着高校近年来的不断发展，信息化建设也呈现出快速扩张发展的趋势。在高校信息化推进过程中，除开展信息系统的建设外，如何将信息系统更好地运行使用起来，即如何做好信息系统的业务运维，成为一个突出问题，值得注意和思考。

运维现状

　　在高校信息化实践中，业务职能部门对于如何合理规范使用信息化管理系统缺少足够的认识及能力，在信息系统建设初期的需求调研阶段，未将日后运营的需求充分考虑纳入到其系统的设计方案中。同时，对用户体验、服务效率等指标重视不足。

　　上述现状应该引起重视，因为其会导致如下后果：信息化系统建设完成并正式投入使用后，信息系统的管理用户才发现缺少相应的业务运维服务，于是在没有提前合理统筹规划的情况下，业务管理用户经常要求临时增加零散的业务运维功能，但业务流程运行仍不通畅。期间，还不可避免地增加了诸多修修补补的开发工作，甚至是重复性技术工作，造成不必要的人力资源浪费。另外，还会给信息系统的普通用户留下该系统非但不能提高工作效率反而会增加额外负担的负面印象，为后续信息化工作的推进埋下隐患。

　　某高校“人力资源管理系统”曾发生过一次由不规范业务操作引发的严重生产事故。人事部门的工作人员未经逐级严格核查，直接手工导入存在大量错误的人员基础信息，且在发现数据有误后并未及时采取有效措施阻止错误向外蔓延，从而导致事件发展成为影响广泛的严重生产事故。业务管理部门和信息技术部门在对此次事故进行复盘分析时发现，在权限的设置管理、数据的审核及应急措施上都存在着重大漏洞和风险。

　　再如某校所使用的“OA系统”，在系统的初期设计中没有深入考虑业务运维的要求，使得后续问题接连不断。上线后两三年内，该系统一直未设计实施可进行界面操作的权限变更功能，也未考虑权限变更相应的业务流程，而是在未经任何审批核实的情况下，由一线技术人员按用户的口头要求，直接对该系统的数据库进行变更操作。由此，逐渐养成了业务用户懒于熟悉掌握业务系统，靠技术支持人员代为处理的习惯，甚至只要系统暂不支持的功能就理直气壮直接要求技术人员使用所谓“后台功能”，即违规直接操作数据库的方法，来满足其“特殊”需求。长此以往，恶性循环，信息系统彻底丧失其原本的价值和意义，甚至引发严重事故并造成不可预估的损失和影响。

　　由此可见，信息系统在正式运行后，能否真正有效发挥其作用，是否包含完整且周全的业务运维设计及保证执行实施其业务运维方案的质量效果，至关重要。

落地经验

　　从已有经验来看，信息系统业务运维实施落地可以从业务管理流程和基础架构的角度来尝试。

业务管理流程的角度

　　1.结合现有的组织架构，在最开始的设计阶段，将业务运维的职责和权限合理地分解、分层处理

　　以中山大学新开发建设的会务管理系统为例，在最初的规划设计阶段，就已将系统运维从横向和纵向两个维度进行划分，即横向分为业务运维和技术运维，纵向以校内的组织机构层级按各二级单位、业务管理单位及专门技术支持部门来划分各自的业务职能。

　　按照不同的业务领域和职责，将业务运维逐层逐级下放，以合理的颗粒度和强度分配给各层级的用户角色。一方面，能够覆盖足够多的业务运维范围，让更多用户参与到业务运维的运行中；另一方面，不会因为将业务运维的工作集中到少数人身上而成为额外的负担。

　　另外，对于原来存在的不合理现象，比如通过全面的清理，禁止使用“公共管理员权限”，所有的用户仅可使用所分配的唯一身份账号进入信息化系统，从根源上杜绝上文提及的事故发生的可能性。

中山大学

　　2.持续优化业务管理流程或规则，落实到信息系统上坚持做到“有法可依、有据可查”

　　严谨合理的业务管理规则，对业务应用系统的业务运维而言就像是“底气”。只要有了这样的规则或者实施办法，信息系统的推行使用就有了“抓手”，能够充分利用规章制度来规范和适当约束用户的使用操作行为，有效避免应用管理系统沦为用户“肆意妄为”的工具。以“OA系统”为例，经过几年的打磨和沉淀，该系统的业务主管部门最终制定颁布了新一版的校级公文管理规定。其中，对于此前被诟病的权限管理给出了明确且细致的管理规则。同时，技术部门根据最新的管理规定相应实施了优化调整，配合将管理规定落实到位。自此以后，权限管理就有了明确的规则依据，该系统的权限功能也更加完善，不会出现权限管理上的乱象。

　　可见，对于信息系统而言，除了本身的服务功能和技术能力外，对应的业务管理规则也同样重要，尤其是对业务运维推进上的影响更为明显。

　　3.引入专业客服团队参与其中

　　在系统设计中充分考虑专业客服人员的特点和长处，将业务咨询办理流程的链条考虑到设计方案中，用专业的服务，让用户感受到优质的服务体验。此外，在运维规划设计中，将对业务实施人员持续的业务培训作为实施落地的一个重要环节，以确保在正式上线运行后能顺利接手并稳妥执行其业务运维工作。

基础架构的角度

　　1.在系统的底层技术架构设计上，支持可扩展性，同时对业务优化始终保持欢迎开放的态度

　　在严谨的审核机制下，与技术部门或供应商共同推进迭代优化。支持敏捷的运行需求，在不随意变动底层业务机制的原则下，深入业务运行的核心，根据业务自身特点，规划设计和优化流程及调配资源。而对于未经深思熟虑的优化需求，经过谨慎的推敲斟酌后坚决说“不”，避免日后可能出现的隐性风险。

　　以中山大学的“大学服务中心”平台为例，自2016年上线以来，对业务流程服务一直秉持开放的态度，不断升级优化整个平台的服务能力，以满足平台用户的各类需求。同时，对于加入到该平台的所有业务流程，通过与业务所属管理部门的协调沟通，充分深入业务核心，严格把关业务需求，对于“不成熟”的业务需求，不允许盲目实施上线，直至梳理完成的业务需求达到要求才“正式开工”。经过几年的打磨，在“大学服务中心”平台上运行的多项业务已成为平台的“亮点”，得到了校内师生用户的肯定和认可。

　　对于潜在的重大风险，设计并制定出一套相对完备的应急响应方案，将自身系统及关联资源都考虑其中，做到最短时间内将影响和损失降到最低。在基础架构方面，数据备份恢复策略、双机运行、容灾机制及整理完善的人员职责清单等，都是常用的措施办法。

　　2.充分利用已有的数据资源进行业务整合，利用共享资源为业务部门提供业务优化的支撑和手段

　　在共享资源平台方面，学校已逐步建设并投入使用多个公共服务平台。其中，为了对校内应用系统的权限管理进行统一规范，规划建设统一的权限管理平台，通过对常见权限管理场景的支持，为各应用系统提供统一标准化的权限功能。“公文自动化系统”的权限功能已全部通过接入学校统一权限管理平台加以完善，从根本上解决了原来缺少权限管理功能的隐患。同时，通过接入权限管理平台，还能够进一步完善其自有权限管理的流程和服务。再如学校建设推出的“数据交换平台”，通过对全校各业务线全面的数据治理，建立起权威的“数据资源目录”，所有共享交换的数据都“有源可溯”，保证业务数据的准确性和唯一性。

思考与总结

　　让信息系统更好发挥其作用，需要转变传统运维模式，在对基础架构和系统运行质量进行主动式运维监控的同时，从真实用户体验的视角出发对业务系统的实际支撑环节进行关联和透视，并以此为基础构建起学校的业务运维支撑平台。

图1 业务运维三维立体模型

　　业务运维支撑平台的构建要从业务系统、业务管理和IT支撑三个维度入手，对所有信息管理系统进行有效梳理。业务系统是学校运行管理的基础，也是业务数据产生的源头，从功能上覆盖学校日常教学、科研、行政管理等，具体包括教务系统、人事系统、财务系统、科研系统、综合服务平台等；业务管理是解决学校内部人员、绩效问题的组织系统，包括业务流程、业务结果、业务效率和业务评价等；而IT支撑则不但要覆盖传统IT运维基础设施监控，还要包括针对网络、应用端主动监控和应用性能管理的相关产品模块。这三个维度的系统和数据构成了业务运维的三维立体模型，并根据业务指标与用户体验指标建立起基于业务质量的动态监控指标体系，形成相应的S-KPI、KQI，为后期业务运维建立指标基础。

　　运维部门遵循三维模型把业务系统、业务管理和IT支撑服务模块映射到底层应用拓扑，再从业务流程环节对设备、平台、云资源、应用/服务、外部API进行梳理和关联，得到业务拓扑的分层逻辑架构视图，通过基于用户行为的端到端全栈性能问题定位、基于全球分布式网络的用户体验主动感知、基于云端压力测试平台的业务容量规划系统，对不同数据源的业务数据和性能数据进行实时采集、处理、预测和关联分析。

表1 业务运维职能划分

　　最后，将业务指标数据、性能指标数据和趋势分析、预测数据在业务运维大屏上实时展示。运维人员可以业务视角开展系统运维工作，第一时间发现业务性能瓶颈，快速准确定位问题，提升业务和系统性能综合管理能力；运营人员能够实时了解前端用户体验、后端业务系统与底层基础设施架构之间的关联关系，正确应对各种突发状况；管理者能够根据数据分析报表做出准确的决策，从容应对快速变化的用户需求。

　　业务运维的落地，能够基于大数据技术对现有信息系统进行快速而高效的信息整合，围绕用户体验和业务价值实现用户、产品、业务环节之间实时交互和有效交流，让管理和运营的网络化、扁平化成为现实，为高校的数字化、智能化、服务化转型打下坚实基础。

　　作者：耿琦（中山大学网络与信息技术中心）

　　责编：朴艺娜

　　投稿、转载或合作，请联系：eduinfo@cernet.com