wordpress the7 建站,用上海注册的公司建的网站,easy ssl wordpress,成都网站的建设在变更风险防控领域#xff0c;对于线上变更元信息的分析是非常重要的一部分#xff0c;这是因为#xff0c;只有理解了变更元信息#xff0c;结合自主定制的变更规范#xff0c;才能够知道具体的变更风险在哪里。不同的变更风险防御能力#xff0c;实现的思路可能是不同…在变更风险防控领域对于线上变更元信息的分析是非常重要的一部分这是因为只有理解了变更元信息结合自主定制的变更规范才能够知道具体的变更风险在哪里。不同的变更风险防御能力实现的思路可能是不同的因此很有可能出现对于一次变更在信息的理解上有所不一致从而导致检测结果不够置信。基于此我们需要一个独立的变更元信息分析框架把所有的变更元信息分析过程和结果都归到一个独立的系统当中。这样从变更风险防御能力的视角变更分析的结果都是共享的、全局的、一致的从而能最大限度提升变更风险防御能力可挖掘的潜力。
本文就简单聊一下变更元信息分析框架设计的一些重点。 首先第一个问题是变更元信息的来源是什么简而言之如果要获取到变更元信息一个变更平台需要在发起变更、变更期间和变更结束之后都上报和当次变更相关的元信息给到分析框架。如果把一个企业内部所有的变更平台都考虑到一起那么变更上报次数量级是非常大的因此一个比较好的方法是通过一个变更事件MQ去承载变更元信息的上报和消费从而起到均衡性能的作用。在这样的基础上变更元信息分析工作就可以是异步的基于变更事件驱动的模式。
其次问题是分析的对象是什么可以简单划分成三类。第一类是变更的对象本身比如我们需要了解到某个服务的上下游链路如何重要度如何是否涉及资损风险这些都是服务本身的属性并且也是在变更过程中需要考虑的第二类是变更工单过程这个是核心的变更对象我们需要判断某次变更是否存在风险就需要对一次变更工单进行分析比如是否在高峰期发布是否通过管控赦免变更的需求背景等等都是变更工单维度的分析信息第三类是变更阶段这是在变更工单维度上向下拆解出来的一类分析对象描述变更过程每一个阶段的实际情况尤其是小批次灰度阶段的变更元信息是变更风险防御需要着重去关注的。
变更事件上报的信息一般是变更工单或者变更阶段维度的而变更服务实体这个维度在事件内容里不一定会有标准化的体现。因此如果要将变更事件和变更元信息分析结果做映射就需要标准化三类变更分析的对象的数据结构和元信息提取逻辑。
然后一个问题是分析结果会怎么出来这里有多种可能性一种可能性是框架本身在接收到变更事件后把事件dispatch给符合事件过滤条件的变更元信息分析器另一种可能性是分析器离线定时运行上传结果给到变更分析框架。为了兼容这两种可能性我们就需要标准化分析结果的存储接口以及分析对象的生成逻辑。尤其是有了后者以后不论是受控被调度的分析器还是离线分析器都能通过某种方式将分析结果映射到具体的分析对象这样就满足了兼容的需要。
最后一个问题是如何支持分析器的运作不论是离线还是受控的分析器有可能实质也是一个变更事件消费者是一个多节点运行的服务这样就会产生分析缓存数据共享的问题。因此分析框架在研发的过程中也需要考虑建设一些工具或者分析器框架去提升分析器的开发效率。就和游戏引擎一样通过工具插件为游戏开发赋能。
以上便是变更元信息分析框架设计的一些重点思路和考量。解决了以上问题一个简约的变更元信息分析框架则呼之欲出。
