73 论某铁路局通信网与办公信息系统运维服务项目的运营管理

ONEPSOFT | 软考学习知识库

---

2024年4月，我单位中标某铁路局通信网与办公信息系统运维服务项目，工作内容包括：负责制定办公内网管理制度、操作手册、维护手册，涵盖网络设备命名规范、策略配置规范、网络安全防护策略等内容；负责7×24值守，保障网络稳定运行；负责网络IP地址资源的规划与分配管理；负责机房和楼层配线间网络设备的日常维护、安装调试、配置文件管理与备份、系统升级维护、故障处置，并实时监控网络运行状态，结合监控数据定期生成网络运行情况分析报告。我担任该项目的项目经理（系统规划与管理师）。该项目覆盖铁路局机关本部及沿线主要站段的办公内网与通信辅助网络，涉及核心、汇聚、接入三层网络设备和配线间百余处，IP地址资源两万余个，服务保障范围广、链条长。由于各站段网络环境差异较大，很多排障技巧都依赖"老手"的经验积累，一旦人员流动，这些经验便随之流失。

由于运维服务强度大，而团队人员平均年龄较小、经验相对不足，人均工作负荷较重，项目运行半年后，团队离职率竟超过四成。更令人担忧的是，原有人员的运维经验和事件处理方法并没有落实在书面上，新入职人员对运维流程和常见问题的处理操作生疏，客户满意度明显下降。我们随即对离职人员进行访谈，大家普遍反映：经验都在脑子里，一走就全带走了，新人只能从头摸索。这让我们清醒地认识到，知识如果不能沉淀在组织中，人的流动就会变成服务的"失血"。经公司内部研究，决定以本项目为试点建立项目运维知识库，待成熟后上升为公司层面，全公司按需共享各项目的运维知识。由此，我在2024年10月正式启动了本项目的知识管理工作。

IT服务项目知识管理的目标，是将运维生产过程中产生的各类信息所蕴含的知识最大限度地提取、保留，通过评审后加以应用，实现知识共享与转化，避免知识流失，提高运维响应速度和质量。按照常规做法，我把本项目知识管理活动划分为知识的获取、共享、保留（归档）和评审四项。为了推动这项工作，公司成立了由我牵头、2名资深工程师和全体运维人员参加的知识管理小组，并明确了各组员的职责分工；我们还确定了以月度为周期的知识统计与通报机制，让知识贡献看得见、可比对。

一、知识获取

知识获取是知识管理的首要环节，需要考虑本项目需要哪些知识、能从哪些方面获取，并对相关知识进行分类。结合服务类项目的特点，需要沉淀的知识大致分为三类：以设备应用为核心的技术类、以标准流程规范为核心的管理类、以客户为核心的商务类。在此基础上细化为四级分类，如技术类（一级）—设备应用类（二级）—网络交换机（三级）—参数配置（四级），并注明每类信息的获取来源。在知识获取的组织上，我们采用了"日常沉淀+专项收集"两条线并行的方式：日常由各岗位人员在工作日志中记录故障现象与处置方法，专项则由小组每月集中整理运维记录、会议纪要和客户反馈，筛选出有价值的条目进入知识库候选池。

二、知识共享

知识共享的关键是制定共享制度并对知识设定保密级别。考虑到项目知识库最终可能上升为公司级别，本项目虽不涉密，我仍将知识密级划分为项目内部、公司内部、公共三类，其中前两类又按职责进一步细分，如项目内部的权限划分为服务台人员、技术支持人员、管理人员和商务人员；公共部分以公开的政策、标准、法规和产品使用说明书为主，面向客户开放。为鼓励知识贡献，我组织团队编制了《知识管理考核与奖惩机制》《知识管理信息采集管理办法》等制度，并修订日常考核机制，在月度绩效中加入"每月贡献有效知识条目"的考评项，将知识提交、共享与绩效直接挂钩。为了进一步降低共享门槛，我们把常见问题的处置步骤做成图文并茂的速查卡，并定期组织"技术分享会"，由处理过疑难问题的成员现场讲解，让隐性知识在交流中逐步显性化。我们还对共享行为设置了积分等级，积分不仅可以用于年底评优，还能兑换学习资源，进一步激发了成员参与的积极性。

三、知识保留

知识入库时须按规划的分类保存并审核。在各类信息鱼龙混杂的情况下，必须对知识的真伪和优劣进行鉴别，才能沉淀出真正对运维管理有用的内容。为此，我向公司申请了2名资深工程师，并采购某公司的知识管理平台，在建设初期对每一条入库信息进行审核，确保来源可靠、真实有效；同时由资深工程师建立信息间的关联，形成知识地图，便于项目成员快速应用。知识地图按"问题—系统—处置方案"三层组织，成员既可按设备类型浏览，也可按故障关键词检索，缩短了查找路径；对暂未核实的知识，我们设立"待审区"，只有通过资深工程师确认后才进入正式库，避免未经检验的经验以讹传讹。在平台选型上，我们调研了多家知识管理服务商，从产品客户群和市场评价等角度比较，最终选定知识关联与展现灵活、评价体系健全、易用性较强且能与日常考核紧密挂钩的产品。

四、知识评审

知识库运转起来后，需要定期组织技术专家团队进行全面评审。所选知识管理平台对每条知识设有评价打分机制，每季度自动生成使用率和评价报表；对评价不高或时效性不强的信息，系统自动筛查后，公司会组织部门经理级以上人员对库内信息进行定期评审。评审结果按"保留、修订、下架"三类处理，并形成评审纪要；对于连续两个周期被评价为"低使用率"的条目，我们还会倒查其来源，判断是知识本身过时，还是分类标签设置不当导致检索困难。借助评审报告，管理层对知识库的健康状况一目了然，也更容易把资源投向最需要沉淀和更新的领域。

结合项目实际，项目中的知识包括两类：大部分是存在于团队成员头脑中的隐性知识，还有政策标准、本项目SLA、客户响应流程等显性知识。知识识别的方法主要有三类：一是人工确定，由资深工程师事先定义或通过头脑风暴由现场实施人员提出常见、必要的知识；二是通过知识管理平台，将提问最多的问题匹配最优答案形成知识；三是以常用文件为依据的参考资料（文献）。项目上绝大多数有效的知识来源于团队经验这种隐性知识，而隐性知识最直接的来源是经验丰富的成员，因此人是知识管理中的最大风险点。为减少员工不愿分享的现象，我们一方面落实上述考核奖惩制度，另一方面在共享初期建立安全制度、界定知识密级，并在平台中对知识查阅进行权限控制，防止个别员工恶意打包下载知识库内容导致商业机密与核心知识外泄。

知识库建成并运行一段时间后，项目团队在客户响应速度和业务熟练度方面有了显著提高，团队整体素质的提升也明显优于其他运维团队，项目内部逐渐由忙乱无序向有条不紊的学习型组织过渡，客户的抱怨明显减少，团队成员工作积极性提高。知识管理对于IT运维服务的必要性和重要性，在本项目中得到了充分验证。截至项目考核时，知识库累计沉淀有效知识条目五百余条，月度知识引用次数由初期的三十余次提升至两百次以上，新人独立上岗的周期由三个月缩短至一个半月。回顾这段经历，我更加坚信：知识管理不是一朝一夕的工程，而是需要制度保障、文化引领和技术支撑持续推进的系统性工作，值得在今后的每一个运维项目中坚持下去。