什么是变更？
SRE对软件运行环境负责，这个过程中包括大量的资源的部署与配置，这些变更通常对应一定的风险 开发对代码质量和功能负责，这个过程中存在无数次的迭代，每一次的迭代都有能产生一定的未知风
总之和软件（应用）生命周期相关的所有改变都能称之为变更
实际中我们遇到了哪些问题？
概念、理论是相同的，也可能是人尽皆知的，但问题的原因和解决方案却不总是千篇一律的。一个优秀的SRE应善于发现问题 -> 总结规律 -> 提出基于当前环境（或者说现任公司技术架构）的合理解决方案。而不是凭我以往的经验，亦或是我之前在上家公司就这么做的，某某大厂就是怎么怎么样的，等等诸如此类的决策，但同时又不可否认的一点是，这些确实可以给我们一些启发。试想一下，如果一个方案或者是现成的产品可以拿到任何一家公司中进行实践，那开源产品中为什么没有一个合适的变更管理产品呢？这或许是一般开源产品中，少见优秀的《变更管理系统》的原因
场景举例：
- 线上突然收到大批量服务端502报错，on-call同事收到告警后立即展开排查，他先查看日志系统，分析报错原因，然后查看发布系统，查看代码是否有迭代，又到CMDB中查询对应的开发负责人，除了代码迭代是否有其他配置变更，这一套流程下来，时间已经过去很久了...
- SRE在调整网关nginx核心配置文件，多次反复自测，还是担心出现问题，他经过了很长时间的心里建设，最后决定上线，上线后，没收到告警于是他认为本次变更没有问题，便不再继续关注此次变更事件
- 当SRE团队中某个同事对生产进行变更时，没有及时周知团队成员或者leader，而是自行变更
需要解决什么问题：
- 我们需要一个能够清晰查看到当前已经发生的所有生产级变更事件，以便故障发生时，第一时间查看
- 需要对核心配置变更梳理一个可落地的流程，将重大变更尽可能的规范化、自动化，拒绝人工操作
- 需要对变更增加审核确认操作，一是允许此次变更的自动执行，二是变更事件触达团队成员
解决方案有哪些？
复杂的事情简单做，简单的事情认真做 我们认为，一个大的平台或是小的脚本工具也好，在实现之前，都应尽量简单化，无论是设计上还是代码实现上都要简单化。可以非常肯定的是，简单的东西，一定是易于维护的、易于排错的。SRE在通过开发手段解决某个问题时，要对代码质量负责，对设计模式负责。要避免为日后稳定性埋下隐患，避免为了解决问题而带来另一个问题
- 主动上报变更？：由变更人主动发起，提交变更相关表单信息
缺点：半自动化，需要人为主动提交 - 实现变更管理系统？：由变更管理系统做变更动作收拢，可以理解为所有的操作，将通过一个平台来进行
缺点：技术实现难度高，需要实现发布、修改配置等所有高危操作逻辑 - 主动推动变更？：由各系统打点至统一存储
缺点：侵入性高，各个系统需要植入打点逻辑
我们如何选择的？
首先我们的变更事件中心主要有三部分数据：
- 公有云变更事件
- 代码变更事件
- 配置、权限变更事件
有了这三部分数据，已经完全可以覆盖绝大部份的变更场景了，那么我们是如何获取到这些数据的呢？
- 公有云我们通过定时任务遍历云审计中的接口来获取
- 代码通过定时任务遍历jenkins中的job构建信息接口来获取
- 配置、权限类的，因为我们已经收口在工单系统上，这样直接读取工单系统中的数据即可
