系统运维 > 重点业务保障

1.重点周期保障

有一些项目上存在明显的重点周期，例如互联网企业的双十一、618等重大事件的时间内、部分和财务相关的系统有自己的结算周期（年度、季度、月度等）。关键周期时对系统有着很大挑战，一方面业务访问量会增长，另一方面大家对于稳定性要求会更高。

重点周期保障一般提前开展如下工作：

•提前进行系统使用情况收集和风险排查：

重点保障期前一个典型周期（例如一周或者一个月）进行系统使用情况的收集和风险排查，例如：

是否出现稳定性方面的问题，当前问题是否已经解决或者得到有效规避。

是否存在高风险报告：是指之前出现过的容易导致系统出现宕机或者性能下降的报告，是否已经完成整改或者可以在重点保障期间临时进行管控（收回权限禁止访问）。

当前阶段到保障期，是否还有新的报告或者业务要上线，如果有的话要进行风险评估。从数据量+访问量两个方面进行评定。或者和客户沟通是否可以延期上线。

对于重点报告（重要关注的业务报告 + 高频访问的报告），在重点保障期前进行一轮测试，确保正常工作。

进行一次巡检，排查是否存在风险项，有风险项提前处置。

•重点保障期内的工作

提前进行内部沟通，拉通各个部门建立保障机制，遇到紧急问题可以快速跟进解决，重点保障期间第一要务是恢复业务，第二是快速定位和问题彻底解决，因此要第一时间进行相关信息的收集（一般是收集bi.log、jstack、jmap等信息），之后优先确定业务恢复的方法。恢复方式一般是重启系统进行恢复，并排查出导致问题的具体报告或者数据集实行临时管控下线避免同样的原因再次导致故障的发生。

和客户建立沟通机制，指派专人对接，有问题能够及时进行沟通并解决。

2.升级保障

升级保障的重点在于问题的前置发现和提前解决，因此重点在于升级切换前的升级计划的制定和严格执行。

•升级计划的制定

升级周期：大版本的升级，至少需要安排6周的升级测试，一般在前三周完成测试环境的测试，第四周完成问题修复和回归测试，之后安排1周的生产迁移前的测试和1周的问题修复+回归验证。具体情况需要和客户侧沟通并严格执行。

升级前收集信息：

待升级的系统环境清单：硬件服务器配置、vividime集群的各节点情况收集。

定制开发功能收集：收集定开相关的功能并提定开升级流程，进行适配。

许可信息收集：收集当前系统的准确的许可情况，便于后续升级的许可申请。

安装包准备：要升级到的版本对应的安装包。

重点业务+高频访问的报告+重点关注的报告的收集，在升级测试时进行对比测试。

客户关注的重点新功能：包括希望通过升级解决的问题等。

升级计划要包含的内容：

1)a. 升级使用的服务器资源的准备+许可准备。

2)b. 测试环境升级操作手册拟订。

a)测试环境升级操作，并根据操作过程更新/修正升级操作手册。

b)测试环境基础测试验证：基础功能验证（基础流程+通路测试）、关键新功能验证。

c)新老版本的对比测试：通过升级比对工具对存量报告进行比对测试。

d)测试环境的集成测试：升级适配后的定开功能测试、集成环境适配后的集成流程测试。

e)测试环境重点业务+高频访问的报告+重点关注的报告：在测试环境进行重点报告组织业务人员进行测试。

f)测试环境发现的问题的收集+解决。

g)测试环境发现的问题修复完成后的验证。

3)生产环境的升级操作手册：结合测试环境的操作手册修订。

4)生产环境升级的环境准备和业务侧的相关功能验证（和测试环境类似，在生产环境重复c.2，c3, c.4, c.5）。

5) 解决生产环境升级中出现的问题，修复后进行回归验证，之后再进行正式的升级切换。

6) 选择时间点完成升级切换，并在切换后组织快速验证，涵盖集成环境、主要业务流程+重点报告等。

7) 每一个工作事项，都需要有明确的完成时间和负责人。整个升级需要有明确的项目负责人（客户负责人+vividime负责人）。

•升级计划的执行

升级计划需要和客户侧进行沟通后共同决定，并明确每一项工作的执行人和完成时间，按时间要求开展各项工作，并每周收集完成情况和存在的问题。

如果过程中出现延期（由于产品问题或者人力不足测试延期等），要及时和客户方沟通并调整计划。

•升级后的保障

升级后的一周和一个月，可能会问题高发。因此，升级切换完成并不是升级的结束，升级切换后还需要继续跟进。第一周内应该每天和客户对接人了解情况，第二周到第四周，应该至少做到每周和客户进行一次情况同步和问题收集。