商家域稳定性建设之原理探索｜得物技术

原创

于 2025-03-18 10:50:15 发布 · 1.7k 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #服务器 #运维

一、稳定性及其意义

1.1 什么是稳定性？

我们先来探讨一个核心概念：稳定性。想象一下，一个系统、一个物体或一个过程在受到外部干扰或内部变化时，能否如一面坚实的墙壁，屹立不倒？在信息系统的世界里，稳定性的定义就如同这面的墙壁，它确保在各种干扰面前，我们服务依旧保持可用。

然而，尽管这个定义听上去很清晰，若要用它来推动我们的稳定性建设，却显得有些模糊。因此，我们需要深入探讨如何将这一概念转化为切实可行的方法论。

我们将方法论定义为影响结果的公式，并为稳定性写下了如下公式：

稳定性 = 全局风险可见性 * 风险转化概率 * 故障可感知 * 预案可靠性

但随着实践经验的增长，再对上述公式因子进行正交分析后，我发现稳定性其实可以简化为：

稳定性 = 系统风险(概率) * 风险应对能力

我们进一步拆分这一关系：

系统风险(概率) = 固有风险(概率) + 变更风险(概率)

其中固有风险对应稳定性概念的内部变化，工程上可以定义为网络、服务器等运行环境变化。而变更风险，则是包括发布、配置变更在内的，由人为发起的系统变化。一般固有风险会由运维团队进行关注，因此我们主要展开变更风险：

变更风险 = 变更频率 * 变更复杂度 * 变更爆炸半径

其中：

变更频率：代表变更的发生次数，它一般和业务的需求有关。

变更复杂度：这不仅限于代码的可理解性和可修改性，还包括配置的复杂性。一般来说，复杂度越高，单次变更出问题的概率也越大。

变更爆炸半径：表示发生问题后的影响面，直接影响实际的损失。这个爆炸半径也有很多的衡量因子，如QPS、场景重要性、强弱依赖关系等等。

接下来我们对风险处理能力进行展开：

风险处理能力 = 风险前置发现概率 * 前置风险处理 * 后置风险发现时长 * 应急效果

其中，风险前置发现可以定义为在测试阶段发现问题的场景，由于线下的风险总会有手段可以处理，因此前置风险处理并不会成为瓶颈；后置风险则可定义为上线之后暴露的问题，由于生产问题总会暴露，其关键影响点为发现时长，以及完成应急后最终的影响面，即应急效果。

如果认可这些稳定性公式的拆解推导步骤，我们最终可以将稳定性拉成一个庞大的公式：

稳定性 =（固有风险 + 变更频率 * 变更复杂度 * 变更爆炸半径）

（风险前置发现概率 * 前置风险处理）（后置风险发现时长 * 应急效果）

而这个公式，涵盖了影响稳定性的一系列关键因素，这些关键因素，也将为后续的稳定性建设定下基础。

1.2 为什么要进行稳定性建设？

在进行如何建设稳定性的探讨之前。我们先来讨论一个问题：为什么我们如此重视稳定性？这可以从两个重要方面来理解：

1.失去稳定性的损失：

直接经济与业务损失：想象一下，系统故障导致下单链路出现异常，订单急剧下降；营销逻辑错误，导致优惠券被滥发，直接造成公司的资损。

信任度与隐形资产损失：故障不可用或大规模的技术问题可能引发舆论危机，给品牌形象带来巨大损害。尤其对云服务厂商而言，稳定性故障更可能导致客户的大量流失。

2.具备稳定性的好处：

提高业务迭代效率，使得团队能迅速应对市场变化。

节约值班等额外的投入，减少资源浪费。

此时，大家一定会疑惑，稳定性差的损失容易理解，但良好稳定性与业务迭代的高效又有何关系呢？回到我们的变更风险公式，你会发现，变更复杂度与业务迭代效率之间存在着显著的负相关关系，容易的变更交付的快，复杂的变更交付的慢，这很好理解。因此：良好的稳定性 -> 低变更风险 -> 低变更复杂度 -> 高迭代效率，形成了一个合理的逻辑链。