bilibili《安全生产之变更防控设计与实践》

如何获得讲师PPT:

扫码关注公众号,后台回复Q115即可获得讲师PPT哟~

还能一键订阅后续精彩活动内容~

走出故障迷局的三重奏:逃生、复盘和推演

在原则层面,我们会选择一些高频且重要的场景作为优先处理对象,例如发布场景。在选择完这些场景后,关于如何控制力度的问题,我们的做法是尽量减少非必要规则的添加。至于为何会提到通用规则和自定义规则,通用规则的存在是为了确保一些基础且必要的规则得到遵守,比如发布过程中必须先发布到UAT和预发环境等。同时,安全规则也是必不可少的,具体是否需要建设这些规则,可以根据业务需求来决定,并非每个业务都需要开启。此外,像业务SOP的检查,这种力度更多地是依赖于各个业务自身的需求来进行建设,它并非全公司统一要求的力度,而像SLO这种发布规则则是全公司需要遵循的力度。

2、请问管理变更这块,怎么平衡变更的数量和质量呢?既减少故障又保持业务的灵活性 

与第一个问题相似,关键在于如何控制力度。非必要的内容不应随意添加,例如,仅与稳定性相关的内容才应纳入考虑,不相关的内容则应避免添加。这样,我们才能确保力度得到精准而有效的控制。

3、变更信息关联的时候,具体使用了哪些关联规则和分词技术? 

我们对变更进行了结构化处理,使其维度变得清晰明了,能够准确追踪到变更的主体、时间和对象。这些对象不仅包括静态的CMDB拓扑关联,还涵盖了动态的trace关联。我们将这些信息输入到图数据库中,利用其关联模型和分析能力,有效地建立起各元素之间的关联。
为了进一步量化这些关联,我们内部采用了一种类似信用卡评分的算法模型。该模型能够计算关联节点上的权重,并整合出一个整体分值。当出现问题时,我们可以通过这个分值来快速定位与故障点位关联最大的变更部分,从而更准确地找出故障的原因和涉及的对象。

4、引入阿里的这个变更等级分层,你们有做啥本土化改进吗,可以具体讲下吗

阿里的等级分层体系具有高度的抽象性,它已经超越了单纯的业务范畴。因此,我们并没有对其进行具体的改造,而是主要利用其来指导我们的建设节奏。至于本土化改造,我们并没有刻意为之,因为这个体系本身就具备很好的通用性。

5、请问,变更感知背后的数据支撑是如何构建的,以及日常怎么管理和维护这些数据呢?

之前我们讨论过,在变更的定义阶段和托管阶段,你需要将所有的变更都清晰地定义并托管上来。这样,在日常工作中,一旦有变更发生,系统就会自动上报,无需再进行额外的维护操作。只要这个机制得以确立并运行,后续的所有相关数据都会自动上报,极大地提高了工作效率和准确性。

6、是需要根据不同变更场景的特点,定制不同的防控策略?

针对不同变更场景的特点,我们需要定制相应的防控策略。在之前的经验总结中,我已经对这一问题进行了详细解答。你需要仔细区分各种场景,包括高频高危、低频高危、高频不高危以及高频低频不高危等类型。通过绘制象限图,将这些场景按照其特征进行归类。完成分类后,你可以将具体场景放入相应的象限中,从而清晰地了解应该采取何种防控策略。
此外,在选择防控策略时,还需要考虑实施这些策略所需的资源成本。例如,在大力推进某个项目时,可以适当提高防控级别。而在资源有限的情况下,应尽力在人力能力范围内提供最高级别的防控覆盖。这样,我们可以确保防控策略既符合实际需求,又具备成本效益。

7、能否分享一些具体的防控技术,比如封网拦截或SLO检查是咋实现的? 

封网拦截的主要目的是在特定时间段内限制某些内容的发布。为此,我们制定了一系列规则,明确哪些业务线在哪些时间段内发布内容时需要进行特定的审批流程。不同的业务线,其审批链也会有所差异。

而SLO检测主要是为了在发布过程中监控本节点的服务等级目标(SLO)是否出现下跌。不同的服务类型(如L0服务或L2服务)会有不同的SLO阻断阈值。例如,当某个服务的SLO低于某个特定值时,系统会自动进行阻断。 在阻断过程中,我们还需要关注上游服务是否受到影响,以及下一个服务是否正常运行。这更多依赖于SLO检测,它能帮助我们发现上游服务的问题,即使当前服务本身没有问题。为了更准确地判断问题所在,我们需要基于服务的动态调用链来查询上游服务的状态。 此外,我们还会关注与发布过程相关的日志和其他指标的异常。

目前,我们正在开发一个通用的变更检测服务,旨在提供更丰富的检查功能,以确保发布的稳定性和安全性。

 

本文来自投稿,不代表TakinTalks稳定性技术交流平台立场,如若转载,请联系原作者。

(0)
上一篇 2024年4月22日 下午5:25
下一篇 2024年4月22日 下午5:27

相关推荐

发表评论

邮箱地址不会被公开。