55 论某"AI少儿编程学习平台"运维服务项目的战略规划

ONEPSOFT | 软考学习知识库

---

2024年3月，我司中标"某AI少儿编程学习平台"运维服务项目，合同金额165.2万元，服务期1年。我被任命为系统规划与管理师，全面负责运维管理工作。该平台是一款面向6至14岁青少年的编程学习产品，注册用户超过210万，日活用户40余万，平台由多家软件厂商先后参与开发，学员端App、后台管理端、家长端小程序等6个子系统架构风格不统一，系统仍处于持续升级中，部分功能模块之间耦合紧密，一次升级往往牵动多个子系统，客户对平台可用性的要求不低于99.9%，运维挑战很大。主要工作内容包括：硬件与云资源维护，即对12台云主机、15套云存储等进行实时监控、日常巡检和故障排查；软件系统维护，即对6个子系统的版本升级与故障排查；数据库管理与维护，包括定期备份、各渠道导入的数据仓库处理与商业智能分析，为客户管理层提供经营决策支持。

服务战略规划是运维项目的龙头，可以帮助服务供方识别客户的服务需求并进行全面分析，最终形成服务级别协议（SLA），为后续各阶段工作奠定基础。如果规划不到位，服务边界不清、目标不明，运营阶段就会陷入被动。本文结合我在该项目中的实践，从服务目录设计、服务需求识别、服务级别协议SLA/OLA/UC设计三个方面，阐述战略规划对达成运维目标的重要性。

一、有效执行服务目录管理活动，确保服务目录生成和维护

服务目录是整理服务产品和管理客户期望的重要工具，是服务供方为客户提供服务的集中信息来源，定义了服务供方所提供服务的全部种类和目标，使客户能够准确了解可获得的服务的范围、内容及相关细节。为快速梳理我方服务产品、管理客户期望，我建立了专门的内部网站用于创建和管理服务目录，组织团队成员按照以下六个步骤执行服务目录管理活动。

第一步，成立管理小组。我作为规划师担任组长，组建了由市场人员、质量负责人、资深云运维工程师、服务台人员及网络安全运维人员构成的6人小组，明确小组目标与各自职责，确保制定、修订服务目录时视角全面。第二步，列举服务清单。参考公司类似项目的服务目录，我们梳理出云资源与硬件维护、平台软件子系统维护、数据库与数据仓库管理维护等服务清单。第三步，确定服务类别与代码。按服务对象的技术维度将服务划分为云资源保障、应用系统维护、网络安全运维等类别，并为每类服务赋予唯一代码。第四步，编制服务详述。详细描述各项服务的内容、目标、级别与技术实现方式，逐一明确服务响应时限、解决时限和服务报告要求，形成服务目录初稿。第五步，评审并发布服务目录。我组织小组成员进行了多次内部评审，并邀请客户项目负责人参与评审，对服务内容描述中不准确、口径不一致之处逐条修改，获得批准后通过内部知识库正式发布服务目录1.0版本（如表1），作为服务交付与服务管理的基准。第六步，完善服务目录。服务目录管理是渐进明细的，在后续需求识别和运维过程中，我们根据客户需求及业务发展趋势持续改进，保持服务目录与自身服务能力相一致。

服务代码	服务名称	服务内容	服务方式	服务时间	服务级别目标
50201	平台软件系统运维服务	功能维护、故障处理、培训指导	现场+远程	5×8；重大事件7×24	30分钟内响应，2小时到场，4小时解决
50202	云资源保障服务	云主机与云存储监控、调测	现场+远程	5×8；重大事件7×24	每日巡检，30分钟响应
50203	学习终端设备运维服务	终端设备维修、故障处理	现场	5×8	提供服务报告

二、服务需求识别

服务需求对定义SLA、达成运维项目目标尤为重要。确定服务目录1.0版本后，我与客户接口人通过访谈、视频会议等方式，识别了可用性、连续性、能力、信息安全、价格和服务报告六个方面的需求。在可用性需求方面，平台注册用户超过210万，客户要求可用性不低于99.9%，每季度业务中断次数不超过3次，平均故障修复时间不高于2.8小时。在连续性需求方面，该平台是客户的核心产品和主要收入来源，要求7×24×365不间断运行；我深知灾难性事件后果更为严重，因此组织团队编制了灾难恢复计划，通过风险评估识别可能造成平台中断的潜在威胁，预测损失并制定控制措施、评估措施有效性。我们对云主机、网络设备、系统软件、应用软件及服务环节逐项开展风险识别，评估结果如表2所示，重点关注断电、火灾、病毒攻击等高风险场景，并据此确定了数据异地备份、关键节点冗余等应对措施。

风险来源	云主机	网络设备	系统软件	应用软件	服务
断电	高	高	—	—	—
火灾	高	高	—	—	—
水灾	中	中	—	—	—
人为误操作	—	—	—	中	—
无法登录	—	—	—	低	高
病毒攻击	—	高	高	—	—

在能力需求方面，平台晚间19时至21时为创作与评测高峰，评测服务需支持6000并发请求、响应时间不超过1秒；根据注册用户增长趋势，预计年末用户规模将突破260万，我们提前规划了云主机集群扩容方案。在信息安全需求方面，平台存储大量青少年用户及其家长的个人信息和支付信息，需符合个人信息保护相关法规要求；我们对家长端敏感接口增加动态令牌认证，对渠道导入的数据进行字段合规性校验，并约定每月开展两次安全渗透测试。在价格需求方面，我与团队根据服务条目和范围评估了服务成本，主要包括云资源费用、软件工具费用、人力成本及第三方支持成本，合计约136万元，为后续定价提供了依据。在服务报告需求方面，明确每周推送周报，每月召开运维服务报告会议，针对突发问题出具专项报告。

三、设计服务级别协议SLA、OLA和UC

基于服务目录和客户需求，同时兼顾成本控制，我组织团队设计了服务级别，并形成服务级别协议SLA，就供需双方、协定条款、违约处罚、仲裁方式、报告形式、双方义务、服务交付成果及保密要求等作出明确规定。协议核心内容包括：服务时间7×24×365，服务可用性不低于99.9%，可用性以月为周期计算；每季度业务中断次数不超过3次；一般故障30分钟内响应、2小时内到场处理、4小时内解决，重大故障优先保障；按月、按季、按年开展服务考核，考核结果与付款挂钩，如因我方原因造成用户损失，按约定条款承担违约责任。同时，协议明确了服务受理渠道、报告形式与保密条款，约定协议每年审查一次，变更须遵循约定的变更管理流程。为保证运维工作顺利开展，我与我司内部的备件、技术开发、客户支持等部门签署了运营级别协议OLA，明确了内部各环节的时限承诺，并与平台的软硬件供应商，包括学习终端生产商、云服务提供商、智能评测算法供应商等签署了支持合同UC，明确了第三方响应时限与责任边界，确保对客户的SLA承诺能够逐级落实。

2025年2月，运维合同到期，平台各项运维工作按照SLA约定完成，全年可用性达到99.94%，顺利保障了平台多次活动高峰，赢得了客户的一致好评，并顺利续签了下一期运维合同。这主要得益于我和团队扎实的战略规划工作，包括服务目录设计、服务需求识别以及SLA、OLA和UC的制定，使我方在服务启动前就与客户就服务范围、级别与责任边界达成了清晰共识。当然，服务过程中也存在一些小问题，比如服务目录管理初期对成员责任定义不够清晰，导致内部配合一度出现摩擦，我及时明确目标、澄清职责分工，保证了服务目录按期完成。通过这个项目，我更加体会到战略规划不是一纸文书，而是贯穿服务全程的契约和指南，规划越扎实，运营越从容。今后我将继续学习和实践ITSS、ITIL等相关标准知识，努力提升自己的系统规划与管理水平。