58 论某市区域养老服务信息化运维项目的规划设计

ONEPSOFT | 软考学习知识库

---

2022年4月，我作为系统规划与管理师接手了某市区域养老服务信息化运维项目，合同金额158.6万元，服务期一年。项目服务对象覆盖全市39家养老机构、118个社区日间照料中心以及约4200户居家养老服务终端用户，涉及养老机构综合管理系统、居家养老服务派单平台、老年人能力评估系统、社区助餐结算系统，以及市民政部门统筹建设的养老服务综合监管平台等。整套应用部署在市级政务云上，依托政务外网运行。由于服务机构数量多、业务系统分散、使用主体差异大，梳理、协调与整合的难度非常高，一旦某个子系统中断，就可能直接影响老人的床位管理、餐食配送、上门照护等日常服务，民政部门对此高度重视。为此，我重点抓好了规划设计阶段的工作，从服务需求识别、服务目录管理、服务方案设计、服务成本评估、服务级别协议设计、支持合同管理等环节入手，力求把运维基础打牢。下面结合项目实践，就这几个方面进行论述。

一、服务需求识别

服务需求识别是规划设计的起点。项目启动初期，我组织团队成员分三路开展调研，一路走访养老机构的信息员，一路约谈社区日间照料中心的负责人，一路对接民政部门监管平台的业务骨干。通过访谈我们了解到，养老机构最关心的是床位管理与费用结算系统的稳定性，社区中心则希望助餐高峰时段派单不卡顿，而监管平台对各类数据的按时上报要求很高。针对这些分散的需求，我们以民政部门提供的服务需求文档为基准逐条核对，遇到表述不清晰的条目，就派专人到现场确认。例如居家养老服务派单平台涉及老人呼叫、服务商接单、上门结算多个环节，我们专门约请了平台建设方和三家服务商代表共同开会，把接口范围、异常场景逐项厘清，最终形成了供需双方认可的需求清单，为后续服务目录的设计打下了基础。调研中还发现，部分新设立照料中心的老人紧急呼叫终端型号不统一，故障排查往往依赖厂商，我们据此将终端兼容性问题纳入需求清单，并在方案中明确了统一接入和升级的规范，从源头上减少后续运维的隐患。

二、服务目录管理

需求识别完成后，我开始组织服务目录的编制。首先确定了项目的重要干系人，包括我方全体成员、民政部门信息化科室、各机构与社区的联系人。然后按照"可交付、可考核"的原则，把能够提供的服务逐条列出形成服务清单，再按服务对象的类别和系统归属进行编码分类，对每一项服务详细描述其内容、方式、时限与交付标准。服务目录初稿完成后，我们组织了两次评审会，邀请各机构代表提出修改意见；发布运行一段时间后，又根据实际受理情况补充了居家终端的远程指导等条目，使服务目录逐步完善，真正成为供需双方共同参照的服务依据。

三、服务方案设计

服务方案设计是整个规划设计阶段的核心工作。我们与民政部门及各服务对象就服务方案进行了多轮沟通并达成共识，从服务模式、服务级别和服务要素三个维度展开设计。

1、服务模式

综合各方反馈，我们最终确定采用"远程支持+驻场服务"相结合的模式。客服坐席按5×8小时提供远程支持，负责日常报修受理、问题解答和常见故障的初步诊断；驻场工程师按7×8小时在重点养老机构和服务平台现场值守，处理需要现场介入的事务。我们建立了统一的服务受理群，每天汇集各机构反映的问题，客服人员与工程师把常见问题的解决方案归纳整理，经资深工程师审核后形成知识库条目，方便机构信息员自助查询。对于知识库无法覆盖的问题，先由客服远程处理并记录事件，仍无法解决时再指派工程师到场。例如社区助餐结算终端的扫码支付异常、居家智能终端的定位信号丢失等，都需要工程师携带备件现场处理。

2、服务级别

考虑到服务对象的业务轻重不同，我们实行差异化的服务级别管理。对养老服务综合监管平台、养老机构床位管理、费用结算等核心系统优先保障，要求第一时间响应、快速解决；对辅助类系统和一般性问题，采用分级时限处理的方式，按1小时、2小时、4小时等不同时限安排处理，确保整体系统的可用性和连续性。我们还与民政部门共同明确了各系统的可用性指标，重点系统可用率要求不低于99.5%，并定期将达成情况通报各方。

3、服务要素

人员要素方面，我们设置了管理岗位、技术支持岗位和操作岗位三类岗位，管理岗位负责项目计划、进度审查与对外协调，技术支持岗位和操作岗位以现场支持为主，同时为各类人员制定了培训计划和绩效考核办法，保持队伍稳定。资源要素方面，建立了服务台、备件库和知识库，常见问题的处理方案经资深工程师审核后入库共享。技术要素方面，注重自有技术的沉淀和非自有技术的借鉴，制定了常见故障的标准操作流程（SOP），对突发状况提前开展风险识别并制定应急预案，例如定期对政务云上的数据库进行自动备份，每季度开展一次备份切换演练，确保数据出现异常时能平滑切换、快速恢复。过程要素方面，坚持以流程为导向、以客户为中心，组织民政部门代表、机构信息员和团队全体成员，对服务台受理、事件管理、信息安全防护、客户端安装升级等流程进行了模拟演练，验证流程的可行性与完备性。例如在一次模拟演练中，我们完整演练了某养老机构网络中断场景下从报修受理、远程诊断到现场抢修、事后复盘的全流程，发现并修正了派单环节响应偏慢的问题，使后续真实故障的处理效率明显提高。

三、服务成本评估

服务成本评估是服务方案能否落地的重要保障。在方案设计基本成形后，我组织财务和技术人员，依据服务目录逐项测算人力成本、备件成本、工具成本和管理费用。例如，考虑到驻场工程师需要覆盖早晚高峰和节假日值守，人力成本按轮班制测算；居家终端分布零散，备件储备和差旅成本按片区测算。经测算，驻场加远程相结合的模式在满足服务级别要求的前提下，总成本比全驻场方案降低了约两成，方案经公司评审和客户认可后，作为报价和谈判服务级别协议的基础。通过科学的成本评估，我们既保证了服务质量，又避免了盲目投入，为项目的持续运营创造了空间。

四、服务级别协议设计

在上述工作的基础上，我草拟了服务级别协议，内容涵盖协议双方、项目名称、服务起止时间、受理与投诉渠道、交付计划、验收标准、接口人、变更请求、考核要求与保密要求等条款。同时，我与内部相关部门签订了运营级别协议（OLA），与硬件厂商和平台建设方签订了支持合同（UC），各项协议有效期为一年，从制度上明确了各方职责。协议中还明确了月度服务报告、季度服务回顾和年度满意度测评的机制，考核结果与服务费用结算挂钩，促使我们不断审视和改善服务质量。

2023年4月，项目服务期满，我们团队保障了整套系统的稳定运行，顺利通过民政部门的验收并签订了下一期运维合同。回顾整个过程，我深感规划设计是运维服务的根基，规划设计做得扎实，服务质量才有保障，成本才能得到有效控制。当然，项目中也暴露出一些不足，例如一次监管平台接口调整时，因与建设方沟通不到位导致数据字段错位；居家终端集中呼叫时段压力测试不足，出现过短暂卡顿。这些问题的根源仍在于前期规划考虑不周。今后我会深入学习ITSS、ITIL相关标准，持续改进，把运维规划设计工作做得更加细致、更加贴合业务实际。