变更管理制度

声明

本制度是思度安全进行汇总和编写，仅供学习、交流、讨论使用，支持付费批量下载
单次赞助 10元 可下载单篇原文联系我们

修订说明

• 烟台王较瘦 第一次编写 2022/5/1
• 思安 修订 2023/6/1

第一章 总则

第一条 目的

为了规范北京思度文库股份有限公司（以下简称“公司”） 变更操作，实施硬件资源的有序调配，保证硬件设施与系统软件配置能在最大程度上满足信息系统运行与安全需要，依据《中华人民共和国网络安全法》、《中华人民共和国数据安全法》、《中华人民共和国个人信息保护法》、《关键信息基础设施安全保护条例》特制定本制度。

第二条 适用范围

本制度适用于云平台中涉及到的软件、硬件、配置等变更或基于规避信息安全风险原则发起的其它变更。

第二章 术语定义

第三条 变更管理

对原有规范、程序、流程、文档或系统进行的任何修改、升级、更新、退役或废弃操作的计划、协调、执行和评估过程。

第四条 变更请求

提交给变更管理团队用于实现规范、程序、流程、文档或系统修改的一种书面或口头要求。

第五条 变更类型

指在变更管理中规定的一组分类，用于帮助人们理解变更的性质、范围和影响。

第六条 风险分析

对变更管理过程中的各项工作进行分析和评估，包括变更请求者提出的变更内容、实施过程、可能出现的问题和对组织产生的风险。 　　

第七条 实施计划

变更管理团队编制的文档，用于记录计划中的各项变更活动的名称、时间、目标、实施人员、控制措施和验证方法。

第八条 变更记录

用于记录变更管理过程中的各项活动和结果的一组文档或信息。

第九条 验证和确认

指用于确认变更实施结果符合预期的过程，包括验证实际结果和分析实施过程，以便于进行调整、反馈和改进。

第三章 岗位职责

第十条 变更管理委员会

(一) 负责制定变更管理制度，提出变更管理策略和政策，确保变更管理活动得到全面和持续的支持。 　　(二) 审批和控制所有需要进行的规范、程序、流程、文档或系统的变更请求。 　　(三) 对已批准的变更实施计划进行评估和监督，确保在变更过程中各项任务的合理分配和控制。 　　(四) 对变更实施评估结果进行评估并提供反馈，以便于调整变更管理策略和政策。 　　(五) 执行变更管理规划、承担变更管理决策、绩效度量和持续评价等职责。

第十一条 变更请求者

(一) 提出变更请求，确保请求满足变更管理策略和政策。 　　(二) 提供与变更相关的所有材料和信息，比如变更原因、变更影响、变更步骤等。 　　(三) 与变更管理团队协调沟通，确保及时反馈变更请求的进展情况。 　　(四) 对变更进行跟踪、分析、评估和报告，及时发现并纠正各种问题。

第十二条 变更管理团队

(一) 负责对变更管理制度中规定的变更请求进行评估、安排和跟踪。 (二) 制定变更管理计划、制定变更实施控制方案和变更确认方案。 (三) 实施变更，确保按时、按质完成变更请求。 (四) 通过变更记录跟踪和审计实施变更的过程和结果。 (五) 反馈变更管理结果，评估变更质量，实现变更风险控制。

第四章 常规变更

第十三条 日常操作管理

常规操作是指那些已有公认操作流程和处理方法，结果可预知的操作。常规操作一般不需要发操作审批流，只需按照规定的流程来进行即可。

第十四条 常规操作范围

除以下常规操作外，所有变更操作都需要发起审批流并获得相关方批准后方可执行: (一) 服务器维护， 包括机器的硬件维修，死机后恢复，磁盘清理等； (二) 报警处理，包括程序重启，异常冗余； (三) 预案执行。

第五章 上线操作

第十五条 上线操作定义

对线上服务的运行环境、程序代码、配置文件等进行变更升级的所有操作。上线操作会直接影响线上服务的运行状态，对线上服务的稳定性有重大影响。所以上线操作必须发起审批流程，经由研发和质量相关负责人确认操作步骤和影响范围后方可进行操作。

第十六条 变更申请流程

上线操作的第一步是发起上线变更申请流程，流程由开发者发起，在流程中填写操作对象、操作步骤、影响范围和回滚步骤等内容，提交审核。流程经过研发经理、质量和项目经历相关负责人审核确认后，方可进行下一步操作。在实际应用中，考虑到效率问题，可以根据变更类型和项目分级，对流程进行适度的裁剪。

第十七条 变更要求

变更阶段，研发工程师应该： 　　(一) 了解本次变更的目的和具体变更内容，评估其对当前系统的影响（压力、架构等），评估其是否符合运维规范的要求； 　　(二) 仔细审核上线步骤和回滚方案，了解其每一步的含义，评估其每一步的合理性和有效性； 　　(三) 对于上线步骤不明确、上线影响不明确、上线内容不符合规范、上线没有回滚方案的上线请求，一律打回并给出具体原因； 　　(四) 对于上线文件的操作，除提供文件本身外，还需要提供文件的md5校验码；

第十八条 变更操作

上线申请通过后即可进行上线操作，在上线操作中应该： 　　(一) 预先查看服务负载和流量，合理规划上线时间，尽量避免高峰期操作； 　　(二) 操作前需再次确认操作步骤和回滚方案可执行，必须对变更涉及的内容进行备份，以便后续回滚； 　　(三) 操作时，需相关研发和质量同事在线，以便能随时响应，确认效果或回滚； 　　(四) 操作时，需严格按照提交的上线步骤操作，如需临时调整，需后续邮件通报； 　　(五) 操作配置文件时，严禁直接对源文件进行操作，应该新建一个，在修改验证无问题后，再替换老的文件；

第十九条 变更检查

上线操作完成后，研发和质量同事确认变更后的效果符合预期；更新关联关系和相关运维文档，添加监控和新日志切分备份等；邮件通报整个上线过程，完成整个上线流程；

第六章 数据库操作

第二十条 变更申请流程

数据库操作前，申请者需要和数据库管理员沟通，以便于资源协调和部署优化；

第二十一条 变更操作说明

申请者通过OA提交数据库操作申请时，在平台中需通过注释详细写明各个字段的含义，给出主要的业务语句，以供数据库管理员参考。

第二十二条 变更审批

申请者提交SQL审核时，平台会根据规则自动检查SQL的合理性，只有通过检测的SQL方可提交审核，提交审核后会自动在OA平台生成审批流，由其直接经理和相关质量同事对本次操作进行审核

第二十三条 变更操作

审批流通过后，数据库管理员可在进行SQL上线。SQL上线后，申请者和数据库管理员需对服务功能、系统负载进行检查。

第七章 网络变更

第二十四条 变更管理

网络调整是指机房的网络设备维护，网络拓扑进行变更等一系列会影响服务器间连通性和连通质量的操作，一般牵涉的范围都比较广，需谨慎对待。

第二十五条 网络变更原则

(一) 调整前，需将调整的范围、调整的手段、预期的影响提前1周邮件通报，经各方讨论沟通，认为可行，方可进行后续的操作； 　　(二) 调整时，必须避开流量高峰期，并及时通报调整的进度； 　　(三) 调整后，需验证调整的效果，更新网络拓扑结构，并邮件通报大家知晓。

第八章 变更回滚管理

第二十六条 回滚原则

变更过程中，发现变更影响到线上服务主要功能时，需在第一时间回滚，禁止先查问题。

第二十七条 回滚操作

回滚完成后，需要检查服务状态，按照checklist检查系统和服务运行状况。

第二十八条 回滚复盘

服务正常后，需发回滚通报，向相关研发、质量和项目经历通报回滚原因和影响，造成事故的需要发起事故复盘会议。

第九章 附则

本制度自发布之日起生效。