内部使用 变更管理制度 版本号状态拟稿和修改时间说明 V1.0新建 2021/02/10 V2.0修改 2023/4/2第一章总则 第一条目的 为了规范北京思度文库股份有限公司（以下简称“公司”） 变更操作，实 施硬件资源的有序调配，保证硬件设施与系统软件配置能在最大程度上满足信 息系统运行与安全需要，特制定本制度。 第二条适用范围 本制度适用于云平台中涉及到的软件、硬件、配置等变更或基于规避信息 安全风险原则发起的其它变更。 第二章术语定义 第三条变更管理 对原有规范、程序、流程、文档或系统进行的任何修改、升级、更新、退 役或废弃操作的计划、协调、执行和评估过程。 第四条变更请求 提交给变更管理团队用于实现规范、程序、流程、文档或系统修改的一种 书面或口头要求。 第五条变更类型 指在变更管理中规定的一组分类，用于帮助人们理解变更的性质、范围和影响。 第六条风险分析 对变更管理过程中的各项工作进行分析和评估，包括变更请求者提出的变 更内容、实施过程、可能出现的问题和对组织产生的风险。 第七条实施计划 变更管理团队编制的文档，用于记录计划中的各项变更活动的名称、时间 、 目标、实施人员、控制措施和验证方法。 第八条变更记录 用于记录变更管理过程中的各项活动和结果的一组文档或信息。 第九条验证和确认 指用于确认变更实施结果符合预期的过程，包括验证实际结果和分析实施 过程，以便于进行调整、反馈和改进。 第三章岗位职责 第十条变更管理委员会 (一)负责制定变更管理制度，提出变更管理策略和政策，确保变更管理 活动得到全面和持续的支持。 (二)审批和控制所有需要进行的规范、程序、流程、文档或系统的变更 请求。 (三)对已批准的变更实施计划进行评估和监督，确保在变更过程中各项任务的合理分配和控制。 (四)对变更实施评估结果进行评估并提供反馈，以便于调整变更管理策 略和政策。 (五)执行变更管理规划、承担变更管理决策、绩效度量和持续评价等职 责。 第十一条变更请求者 (一)提出变更请求，确保请求满足变更管理策略和政策。 (二)提供与变更相关的所有材料和信息，比如变更原 因、变更影响、变 更步骤等。 (三)与变更管理团队协调 沟通，确保及时反馈变更请求的进 展情况。 (四)对变更进行 跟踪、分析、评估和 报告，及时发现并 纠正各种问题。 第十二条变更管理团队 (一)负责对变更管理制度中规定的变更请求进行评估、安 排和跟踪。 (二)制定变更管理计划、制定变更实施控制方 案和变更确认方 案。 (三)实施变更，确保 按时、按质完成变更请求。 (四)通过变更记录 跟踪和审计实施变更的过程和结果。 (五)反馈变更管理结果，评估变更质量，实现变更风险控制。 第四章常规变更 第十三条日常操作管理 常规操作是指那些已有公认操作流程和 处理方法，结果可预 知的操作。 常 规操作一 般不需要发操作审批流， 只需按照规定的流程 来进行即可。第十四条常规操作范围 除以下常规操作外，所有变更操作 都需要发起审批流并 获得相关方批准 后 方可执行: (一)服务器维护， 包括机器的硬件维修，死机后恢复，磁盘清理等； (二)报警处理，包括程序 重启，异常冗余； (三)预案执行。 第五章上线操作 第十五条上线操作定义 对线上服务的运行 环境、程序代码、配置文件等进行变更升级的所有操作 。 上线操作会直接影响线上服务的运行状态，对 线上服务的稳定性有重大影响。 所以上线操作必须发起审批流程， 经由研发和质量相关负责人确认操作 步骤和 影响范围 后方可进行操作。 第十六条变更申请流程 上线操作的第一 步是发起上线变更申请流程，流程 由开发者发起，在流程 中填写操作对象、操作步骤、影响范围和 回滚步骤等内容，提交审 核。流程经 过研发经理、质量和项目 经历相关负责人审 核确认后，方可进行下一 步操作。 在实际应用中，考虑到效率问题，可以 根据变更类型和项目分级，对流程进行 适度的裁剪。 第十七条变更要求 变更阶段，研发工程师应该： (一)了解本次变更的目的和 具体变更内容，评估其对 当前系统的影响（压力、架构等），评估其 是否符合运维规范的要求 ； (二)仔细审核上线步骤和回滚方案，了解其 每一步的含义，评估其 每一 步的合理性和有效性 ； (三)对于上线步骤不明确、上 线影响不明确、上 线内容不符合规范、上 线没有回滚方案的上线请求，一 律打回并给出具体原因； (四)对于上线文件的操作， 除提供文件本 身外，还需要提供文件的 md5校验码； 第十八条变更操作 上线申请通过后即可进行上 线操作，在上 线操作中应该： (一)预先查看服务负载和流量，合理规划上 线时间，尽量避免高峰期操 作； (二)操作前需再次确认操作 步骤和回滚方案可执行， 必须对变更涉及的 内容进行 备份，以便 后续回滚； (三)操作时，需相关 研发和质量 同事在线，以便能 随时响应，确认效果 或回滚； (四)操作时，需 严格按照提交的上 线步骤操作，如需 临时调整，需 后续 邮件通报； (五)操作配置文件时， 严禁直接对源文件进行操作， 应该新建一个，在 修改验证 无问题后，再替换老的文件； 第十九条变更检查 上线操作完成后，研发和质量 同事确认变更 后的效果符合预期 ；更新关联 关系和相关运 维文档，添加监控和新 日志切分备份等；邮件通报整个上线过程， 完成整个上线流程；第六章数据库操作 第二十条变更申请流程 数据库操作前，申请者需要和 数据库管理员 沟通，以便于资源协调和部 署 优化； 第二十一条 变更操作说明 申请者通过OA提交数据库操作申请时，在平台中需 通过注释详细写明各 个字段的含义，给出 主要的业务语句，以供数据库管理员 参考。 第二十二条 变更审批 申请者提交SQL审核时，平台会 根据规则自动检查SQL的合理性， 只有 通过检测的SQL方可提交审 核，提交审 核后会自动在OA平台生成审批流， 由 其直接经理和相关质量 同事对本次操作进行审 核 第二十三条 变更操作 审批流通过后，数据库管理员可在进行 SQL上线。SQL上线后，申请者和 数据库管理员需对 服务功能、系统负 载进行检查。 第七章网络变更 第二十四条 变更管理 网络调整是指机房的网络设备维护，网络拓扑进行变更等一系 列会影响服务器间连通性和连通质量的操作，一 般牵涉的范围 都比较广，需谨慎对待。 第二十五条 网络变更原则 (一)调整前，需将调整的范围、调整的 手段、预期的影响提 前1周邮件 通报，经各方讨论沟通，认为可行，方可进行 后续的操作 ； (二)调整时， 必须避开流量高峰期，并及时 通报调整的进度 ； (三)调整后，需验证调整的效果，更新 网络拓扑结构，并邮件通报大家 知晓。 第八章变更回滚管理 第二十六条 回滚原则 变更过程中，发现变更影响到 线上服务主要功能时，需在第一时间 回滚， 禁止先查问题。 第二十七条 回滚操作 回滚完成后，需要检查服务状态， 按照checklist检查系统和服务运行状 况。 第二十八条 回滚复盘 服务正常后，需发回滚通报，向相关研发、质量和项目 经历通报回滚原因 和影响， 造成事故的需要发起 事故复盘会议。