如何获得讲师PPT：
扫码关注公众号，后台回复「Q115」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
Q&A环节答疑：
1、初期对于变更防控的规则的粒度是怎么选择的？有没有什么判断原则
在原则层面，我们会选择一些高频且重要的场景作为优先处理对象，例如发布场景。在选择完这些场景后，关于如何控制力度的问题，我们的做法是尽量减少非必要规则的添加。至于为何会提到通用规则和自定义规则，通用规则的存在是为了确保一些基础且必要的规则得到遵守，比如发布过程中必须先发布到UAT和预发环境等。同时，安全规则也是必不可少的，具体是否需要建设这些规则，可以根据业务需求来决定，并非每个业务都需要开启。此外，像业务SOP的检查，这种力度更多地是依赖于各个业务自身的需求来进行建设，它并非全公司统一要求的力度，而像SLO这种发布规则则是全公司需要遵循的力度。
2、请问管理变更这块，怎么平衡变更的数量和质量呢？既减少故障又保持业务的灵活性
与第一个问题相似，关键在于如何控制力度。非必要的内容不应随意添加，例如，仅与稳定性相关的内容才应纳入考虑，不相关的内容则应避免添加。这样，我们才能确保力度得到精准而有效的控制。
3、变更信息关联的时候，具体使用了哪些关联规则和分词技术？
我们对变更进行了结构化处理，使其维度变得清晰明了，能够准确追踪到变更的主体、时间和对象。这些对象不仅包括静态的CMDB拓扑关联，还涵盖了动态的trace关联。我们将这些信息输入到图数据库中，利用其关联模型和分析能力，有效地建立起各元素之间的关联。
为了进一步量化这些关联，我们内部采用了一种类似信用卡评分的算法模型。该模型能够计算关联节点上的权重，并整合出一个整体分值。当出现问题时，我们可以通过这个分值来快速定位与故障点位关联最大的变更部分，从而更准确地找出故障的原因和涉及的对象。
4、引入阿里的这个变更等级分层，你们有做啥本土化改进吗，可以具体讲下吗
阿里的等级分层体系具有高度的抽象性，它已经超越了单纯的业务范畴。因此，我们并没有对其进行具体的改造，而是主要利用其来指导我们的建设节奏。至于本土化改造，我们并没有刻意为之，因为这个体系本身就具备很好的通用性。
5、请问，变更感知背后的数据支撑是如何构建的，以及日常怎么管理和维护这些数据呢？
之前我们讨论过，在变更的定义阶段和托管阶段，你需要将所有的变更都清晰地定义并托管上来。这样，在日常工作中，一旦有变更发生，系统就会自动上报，无需再进行额外的维护操作。只要这个机制得以确立并运行，后续的所有相关数据都会自动上报，极大地提高了工作效率和准确性。
6、是需要根据不同变更场景的特点，定制不同的防控策略？
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫 