服务支持与业务连续性管理规范

一、先约定服务范围和联系办法

系统上线前，项目负责人应与客户写清哪些系统由我方维护、服务时段、报修方式、紧急联系人及替代联系人。还应约定响应和恢复目标、计划维护安排，以及第三方故障由谁协调。

服务级别协议通常简称SLA，用来约定服务标准和双方责任。“响应时间”是收到问题后多快确认或开始处理，“恢复时间”是多快让业务重新可用，两者应分别约定，不能混用。

公开安全问题报告邮箱为market@zyaps.com。项目紧急事件还应使用合同或交接资料中的紧急渠道。没有安排全天候值守的，不得向客户承诺已有24小时服务。联系方式变化时，项目负责人应及时通知客户并测试能否联系。

二、故障由谁负责，先处理什么

以上级别用于公司内部安排工作，不等同于国家规定的网络安全事件等级。一般故障也要检查是否伴随数据丢失、异常访问或其他安全影响。

每个问题应分别记录确认收到、开始处理、采取临时措施、恢复业务和完成修复的时间。计时起点、服务时段及暂停条件按合同约定，不能在故障发生后临时改变计算方式。

三、让故障能够被及时发现

运维负责人应按系统情况监控服务可用性、证书和域名到期、磁盘容量、资源异常、数据库、关键任务、备份结果、异常登录，以及外部服务额度。每类重要告警都要有接收人和替代联系人，并定期测试是否送达。

每个工作日或合同约定的值守日，检查严重告警、备份结果和未结问题；每月分析反复故障、容量趋势及关键供应商状态。看到告警后应登记判断和处理结果，不能仅标记已读。

影响客户的故障，应记录发生时间、已知影响、已采取措施和下一次更新时间。尚未确认的原因说明正在核查，避免给出没有依据的恢复承诺。

四、备份要能恢复，恢复目标要说清

项目负责人和运维负责人应为每个系统确认两件事：最多可以丢失多长时间内的新数据，以及发生故障后应在多长时间内恢复业务。 前者称为恢复点目标（RPO），后者称为恢复时间目标（RTO），应由双方结合业务和费用确定。

例如，每天备份一次，并不代表可以接受丢失一天数据，也不代表一定能在一天内恢复。需要更低的数据损失时，应安排更高频备份或其他方案，并实际验证。

公司要求至少每季度抽样恢复一次，备份方案或系统结构发生重大变化后增加验证。至少每年演练一次重要业务中断，可以选择数据库损坏、区域故障、关键人员无法到岗或供应商中断等场景。

没有达到约定目标的，记录差距、责任人和整改期限，并再次验证。演练记录填写实际结果，不能预先写成成功。

五、变更和故障恢复

生产变更应提前检查影响、授权、备份、执行窗口和失败后的恢复办法。紧急修复也要记录决定和必要操作，事后由第二人复核。

恢复服务前，应确认攻击入口或误操作原因已得到控制，必要时更换泄露凭据；选择可信的软件版本和备份，先在隔离环境检查，再逐步恢复。

恢复后实际验证登录、权限、关键查询和写入、后台任务及外部依赖。旧备份可能覆盖故障之后产生的有效数据，应先说明并决定如何合并或补录。只有文件恢复完成，不能宣布业务已经恢复。

严重故障恢复后，公司内部目标为5个工作日内完成初步复盘，说明原因、影响、永久修复措施、责任人和期限。需要更早履行的合同通知或法定报告，仍按其期限执行。

六、安全事件的通知和报告

发现疑似泄露或攻击时，立即限制异常访问、撤销泄露凭据或隔离受影响服务，同时保留必要日志和操作记录。安全负责人应及时通知客户指定联系人，说明已知事实和客户需要采取的措施，不等全部原因查清后才开始通知。

还要分清向客户通知和向主管部门报告的责任。我方作为运维或安全服务方时，应及时向客户报告并协助其履行义务；我方自身需要履行运营者义务时，也应按自身身份处理。

《国家网络安全事件报告管理办法》对较大以上事件区分不同主体的报告时限：关键信息基础设施运营者最迟1小时，中央和国家机关各部门及其直属单位最迟2小时，其他网络运营者最迟4小时。安全负责人应核对发现时间、实际主体、事件等级、报告渠道及行业要求，不能将4小时作为所有事件的统一期限。

初次报告时信息不完整的，先按要求报告已有情况，再补充调查进展。适用该办法的事件处置结束后30日内，按原渠道提交总结；涉嫌违法犯罪的及时报案。客户通知、主管部门报告和依法向个人告知，应分别检查，不能互相替代。

七、服务结束后的交接

项目负责人按合同清点源码、软件版本、配置、文档、账号、数据和资源，实际验证导出文件可读，并确认客户能够接管。接管后的备份、监控、费用和支持责任也应写清楚。

撤销我方不再需要的访问，按约定返还或删除客户资料。日志和备份尚需保留的，说明依据、权限及清除期限。未解决的问题、剩余影响和后续工作，列入交接清单，由双方有权人员确认。