一、稳定性及其意义
什么是稳定性？
我们先来探讨一个核心概念：稳定性 。想象一下，一个系统、一个物体或一个过程在受到外部干扰或内部变化时，能否如一面坚实的墙壁，屹立不倒？在信息系统的世界里，稳定性的定义就如同这面的墙壁，它确保在各种干扰面前，我们服务依旧保持可用。
然而，尽管这个定义听上去很清晰，若要用它来推动我们的稳定性建设，却显得有些模糊。因此，我们需要深入探讨如何将这一概念转化为切实可行的方法论。
我们将方法论定义为影响结果的公式，并为稳定性写下了如下公式：
稳定性 = 全局风险可见性 * 风险转化概率 * 故障可感知 * 预案可靠性
但随着实践经验的增长，再对上述公式因子进行正交分析后，我发现稳定性其实可以简化为：
稳定性 = 系统风险(概率) * 风险应对能力
我们进一步拆分这一关系：
系统风险(概率) = 固有风险(概率) + 变更风险(概率)
其中固有风险对应稳定性概念的内部变化，工程上可以定义为网络、服务器等运行环境变化。而变更风险，则是包括发布、配置变更在内的，由人为发起的系统变化。一般固有风险会由运维团队进行关注，因此我们主要展开变更风险：
变更风险 = 变更频率 * 变更复杂度 * 变更爆炸半径
其中：
变更频率： 代表变更的发生次数，它一般和业务的需求有关。
变更复杂度： 这不仅限于代码的可理解性和可修改性，还包括配置的复杂性。一般来说，复杂度越高，单次变更出问题的概率也越大。
变更爆炸半径： 表示发生问题后的影响面，直接影响实际的损失。这个爆炸半径也有很多的衡量因子，如QPS、场景重要性、强弱依赖关系等等。
接下来我们对风险处理能力进行展开：
风险处理能力 = 风险前置发现概率 * 前置风险处理 * 后置风险发现时长 * 应急效果
其中，风险前置发现 可以定义为在测试阶段发现问题的场景，由于线下的风险总会有手段可以处理，因此前置风险处理 并不会成为瓶颈；后置风险 则可定义为上线之后暴露的问题，由于生产问题总会暴露，其关键影响点为发现时长 ，以及完成应急后最终的影响面 ，即应急效果。
如果认可这些稳定性公式的拆解推导步骤，我们最终可以将稳定性拉成一个庞大的公式：
稳定性 =（固有风险 + 变更频率 * 变更复杂度 * 变更爆炸半径）
（风险前置发现概率 * 前置风险处理） （后置风险发现时长 * 应急效果）
而这个公式，涵盖了影响稳定性的一系列关键因素，这些关键因素，也将为后续的稳定性建设定下基础。
为什么要进行稳定性建设？
在进行如何建设稳定性的探讨之前。我们先来讨论一个问题：为什么我们如此重视稳定性？这可以从两个重要方面来理解：
1.失去稳定性的损失 ：
-
直接经济与业务损失 ： 想象一下，系统故障导致下单链路出现异常，订单急剧下降；营销逻辑错误，导致优惠券被滥发，直接造成公司的资损。
-
信任度与隐形资产损失 ： 故障不可用或大规模的技术问题可能引发舆论危机，给品牌形象带来巨大损害。尤其对云服务厂商而言，稳定性故障更可能导致客户的大量流失。
2.具备稳定性的好处 ：
-
提高业务迭代效率，使得团队能迅速应对市场变化。
-
节约值班等额外的投入，减少资源浪费。
此时，大家一定会疑惑，稳定性差的损失容易理解，但良好稳定性与业务迭代的高效又有何关系呢？回到我们的变更风险公式，你会发现，变更复杂度与业务迭代效率之间存在着显著的负相关关系，容易的变更交付的快，复杂的变更交付的慢，这很好理解。因此：良好的稳定性 -> 低变更风险 -> 低变更复杂度 -> 高迭代效率，形成了一个合理的逻辑链。
稳定性建设究竟要建什么？
在推导出稳定性公式之前，这个命题简直宽泛地让人无从下手。但推导出公式之后，所有的关键点都已经成竹在胸！（这也是方法论的魅力所在）
1.1中，我们已经给出了稳定性的公式，并标红了关键因子。当我们应用上这个方法论时，问题就变得清晰起来：稳定性建设的目标应该聚焦于之前提及的关键因素，借此我们可以制定出实用的治理项如下：
当然，每个治理项都能进一步拆分成若干举措。由于每个团队、每个应用的生命周期阶段不同、实际特性不同，因此各团队在需要重点治理的方向和举措上均有所不同。但总归跳不出这个框架。
二、稳定性建设面临什么困难？
稳定性建设在当今技术驱动的时代至关重要，但它常常被视为"重要但不紧急"的任务，导致在排期过程中得不到必要的优先级支持。许多时候，团队甚至不得不依赖于故障的驱动才能艰难推进稳定性建设。这一现象的根源，可以归结为以下几个方面。
稳定性建设缺少立竿见影的短期价值
其一：量化价值不明确，收益评估困难
我们可以从上文提到的稳定性公式中找到一些线索，尤其是两个非常重要的因子：变更复杂度和风险前置发现概率。变更复杂度实际上对应的是研发引入的单次变更中携带风险的概率，而风险前置发现概率是经过研发和测试团队的努力后，变更风险仍被遗漏到生产环境中的可能性。
正是因为在稳定性的衡量公式计算中，带入了这2个概率因子，稳定性建设的量化价值的不确定性就显而易见了。概率常常需要经过大量的样本统计才能形成有效的量化指标，但在实操时聚焦到某个团队、某个应用或某个具体的治理需求中时，它提升的概率影响往往不足以成为一个可以衡量的量化指标。甚至运气不好的时候，可能会出现治理越多故障越多的离谱事件。
其二：业务压力重，稳定性任务排不上优先级
我们不妨再回到稳定性的关键因子，尤其是变更频率这个有意思的指标。我们很容易通过公式推导得出：变更频率越高的功能，其稳定性治理的收益也越大。然而，正如你所想的，这类功能往往是在业务高速发展时诞生的，此时需求繁多且时间紧迫，在这样的情况下，稳定性治理的优先级与业务的迭代需求相较，无疑排不上号。
而当业务进入稳定期，变更频率下降，终于有时间投入稳定性治理了，但变更频率的下降又同样带来了稳定性风险的减小，治理优先级随之降低。此时的稳定性治理就变成了"食之无味，弃之可惜"的鸡肋工程，仍旧排不上优先级。
稳定性建设存在极大的复杂性和风险
与上文所述的不确定收益相对的，却是稳定性建设确定性的复杂度和风险。无论是风险识别、风险治理，还是风险预防，均需要投入大量的精力。
存量风险识别的难度
在解决问题的第一步中，发现问题是重中之重。稳定性建设的第一步同样是识别其中的稳定性问题。但问题是，我们该如何发现这些问题呢？依靠故障或者TS工单吗？这种方式确实可以帮助我们发现问题，并在后续解决问题。但这种亡羊补牢的操作，对于稳定性的建设而言，实在是太过滞后，根本达不到预期的效果。
为了有效地防范问题发生，我们需要从整体上排除风险------它大到一个域，几十个应用，成千上万条调用链路；小到一个git仓库，数万甚至数十万代码------要准确评估整个域的稳定性并识别其中的风险，这无疑是一项巨大的挑战。
风险治理的难度
风险识别已经足够困难，风险治理的复杂性同样不容忽视。虽然理论上，技术同学从不畏惧已知问题，但不同问题背后的复杂性，也往往会带来不同的治理难度。
首当其冲的自然是技术同学最头疼的排期问题，"世上无难事，只要有排期"。但正如2.1中提到的，稳定性建设由于价值的不确定性，往往难以取得足够的排期。即便是再高瞻远瞩的管理者，也不得不严格控制技术投入的占比，将更多的资源用于服务业务，创造更多的增长。
其次，稳定性治理本身带来的变更风险也不容小觑。 这里贴上技术人员非常喜欢的一张图，来贴切地表示这个难题。
上图的这个房屋，毫无疑问是个风吹就塌的危房。但谁又真敢动手对这样的危房进行稳定性治理呢？如果就是个普通房屋，推倒重建就完了，但业务系统可无法停机。在这种情况下进行代码改动，就如同需要持续地挪动木头、泥土和石块，试图将其替换为坚固的建筑材料，却很可能无意中移走某个重要支撑，导致整个系统崩溃。
这在稳定性建设中是不可接受的。为了预防可能发生的故障，反而引入了变更故障，这实属本末倒置。
至于另外一种治理方案......新建一个系统，然后把流量切过去。如果面对类似图片这种治理难度地狱级的项目，确实是个最佳选择，并且该方法也确实大量应用在架构治理上（如服务拆分）。但大部分应用，使用该方案又着实奢侈了。叠加上文提及的排期问题，也限制了这种方案成为稳定性治理银弹的可能性。
如果继续深入探讨变更风险的问题，我们必然会碰到"代码债务"的概念。每一位技术开发者都对代码债务耳熟能详，深有感触。它通常定义为低代码质量和不合理架构设计等一系列技术负担，而这些问题并非立刻显现出危害。一个重的代码债务，只要在生产环境中能够正常运行，就意味着它是能被接受的。即如图中的房子再怎么危房，没塌之前，住人防风挡雨都是没问题的。
然而，代码债务阻碍了变更，无论是业务的迭代还是技术的治理，都会提升变更的风险。因此，最后的风险治理难度来到了稳定性风险因子中的变更复杂度问题。
命名为变更复杂度，而非代码复杂度这种客观描述，也是意味着变更难度是包含主观含义，是因人而异的。 例如某个应用由一位同学贯穿始终地维护，代码再复杂，变更复杂度也高不到哪里去。因为这份代码从始至终，都是由同一个人，以他的思维框架，解读业务链路后，再抽象建设而成的，这份代码从头到脚都是这位同学的形状。他知道这些代码从何而来，又应当往哪里去。但实际生产过程中，一个应用往往要经历多人维护，就必然出现信息传递的损失。最终，我们在面对这种代码时，大概率会遇到理解困难以及对变更后果的无能为力。因此，变更复杂度的本质，是由不同人员的思维方式、设计理念、编码习惯，以及业务知识在传递过程中的信息偏差交织在一起，构成的一种现象。
至此，排期、变更复杂度、变更风险三者，构成了整个稳定性风险治理的难度。
增量风险预防的难度
在此前的讨论中，我们已经探讨了存量风险的识别和治理。而本节将重点关注每次变更引入的增量风险。这是一个不可忽视的领域，因为风险的根源在于变更，而变更又是业务发展的必然过程。那么，如何有效控制这些因变更而来的风险呢？
变更可见性
首先，最重要的是确保变更的可见性和可感知性 。这里所说的可见性，不仅仅是变更执行者本人的知晓，更是整个团队乃至所有相关方共同的认知。毕竟，执行变更的同事自然会清楚自己做了什么，但真正的问题在于，执行变更的同事是否知道这些变更意味着什么，这个认知和其他相关人员------比如PM和测试人员------是否是一致的？
这就是为什么变更可见性如此重要。做过业务负责人的都知道，最担心的事情就是业务/产品和技术说要改个什么一句话功能，或者是刷数等操作，技术同学顺手就给做了；因为功能点太小，甚至都没通知测试和PM，直接自测完就上线了，真就映着一句话：天知地知，你知我知。但这个却是风险最高的行为，因为没有任何人帮助变更同学进行二次确认，不出问题都是侥幸。
那么难点来了，对一个域少则几十，多则数百的同学，每个迭代也是几十个需求，上百种不同类型的变更，怎么保证每个微小的变更，都能让变更的所有相关方都感知到，并且进行有效的二次确认呢？
方案可控性
在确认了变更共识后，下一步便是对变更方案本身进行评估，从而确保每项调整都符合预期。但此时，又出现了一个障碍：如何保证这个变更是符合预期的呢？
对于一项代码的变更，它不仅会对这行代码的所有上游场景产生影响，更会影响所有使用到这行代码结果的下游场景。若是数据的变更，更是牵一发而动全身，所有读取和写入到这行数据的场景都要受到影响。由于整体链路的复杂性和不可控性，对于变更方案的风险可控性评估就显得异常困难。
人员可靠性
最后，涉及到的还有变更执行人员本身的可靠性 ，人是同时具备高上限和低下限的特性的。即便是一个优秀的同学，即有高瞻远瞩，防范未然的时候；也有马失前蹄，被"!"和"NullPointException"搞得焦头烂额的时候。
那么怎样在各种各样的变更中，去保障人员的下限，不要让这种人员的波动性影响到系统的稳定性；甚至尽可能让人员保持他们的高上限，将更多的稳定性风险扼杀在摇篮之中？这便是稳定性建设中最后一个需要重点考虑的问题。
三、如何进行稳定性建设？
经过前面的铺垫，我们已经明确了稳定性建设的重要性，以及在实施过程中面临的种种挑战。那么，问题的关键就在于如何克服这些困难，顺利进行稳定性的建设。实际操作中，很多治理建设的思路和策略都已经隐含在前文的分析中，现在我们只需将它们整合提炼出来。
建立稳定性共识
从上文知，困难中排在第一点的，即是稳定性治理的优先级和的资源排期问题。因此，在解决稳定性建设的客观困难之前，首先需要业务团队内部从主观层面建立对稳定性的一致认知：即业务团队需要针对本团队业务的重要性、发展阶段、风险情况进行综合评估，确定好稳定性建设在本团队中的重要程度。
直白点说，这个共识就是业务团队确定好稳定性建设将在团队总投入中的时间占比。
这个占比可以在迭代维度进行波动，但周期拉长到季度、年维度的时候，是需要保持在一个符合预期的比例的。它可以是5%或者更低，也可以是10%甚至更高，具体的数值需要和团队目前的业务和技术现状相匹配。
明确稳定性建设目标
当确定了资源比例后，接下来就是明确具体的目标。在此过程中，我们需制定可执行的方案，将大方向细化为明确的阶段目标。
回到1.3脑图中提供的三个大方向：
-
风险前置发现 ： 侧重于人和流程的管理；
-
变更风险控制 ： 关注系统性架构建设；
-
风险后置处理 ： 着眼于应急响应，同时关注人的应急流程和系统的预案建设；
因此，归根结底，稳定性的目标收敛成是练人、建系统两种。我们通常建议先从练人中的强化意识和流程入手，再优化系统，最后持续性地提高人员的综合能力。
这是因为加强团队意识和规范团队流程的投入相对较低，通过制定规范、流程，进行宣导培训甚至考试等形式，不需要投入过多资源就能取得良好效果。这种意识的培养，虽然不会立即影响故障率，但有助于营造稳定性的文化氛围，为长期的治理打下基础。其次，在这一过程中，无需直接修改代码，在初期可以尽量避免"越治理越故障"的困境。最后，加强团队意识和规范团队流程，有助于后续保护好稳定性治理结果。避免一边堵漏，一边挖坑的迷惑行为。
需要注意的是，稳定性建设是一个动态变化的过程。随着时间的推移，人可能会逐渐懈怠，系统架构也可能因为业务迭代而腐化。因此，稳定性建设必须是一个周期性的工作，并且建议每一个季度都专注于1-2项关键点，使得整个系统的稳定性可以在螺旋中上升。
落地稳定性建设任务
为了有效实施稳定性建设，我们将其任务进一步细分为五个核心部分：意识培养、 安全生产规范、应急响应、日常巡检和架构治理 。接下来，我们将逐一阐述这五个部分的重要性及其具体实现方案，并表述清楚这些部分应对的是上述的那些困难点。
意识培养
意识培养是提升团队成员在稳定性建设中能动性的关键环节。它主要涵盖三个方面：认知、意愿和能力。换句话说，我们要弄清楚团队成员对于稳定性的认知程度、愿意投入的程度以及他们的能力如何。
认知 ：团队成员是否充分了解稳定性的重要性。
针对这一点，我们可以定期举办"谨慎编码"宣讲，以提高大家的意识。虽然这看似简单，但不可忽视。因为如果长期不提及稳定性，其重要性就会在潜意识中随时间弱化。
意愿 ：团队成员是否愿意花费时间和精力去评估并解决稳定性风险。
评估稳定性风险往往需要深入细致的工作，还需要克服习惯、自信、侥幸、嫌麻烦等心理障碍。为了提升意愿度，可从奖、惩两方面入手。如可以通过设置稳定性红线或进行故障复盘来进行必要的惩罚，同时引入激励机制，比如对表现突出的团队成员进行表彰或绩效激励。此外权责到人也是激发意愿的手段之一，当同学有了固定负责的应用，并有权限进行完全控制时，会更愿意吃透其业务，保证其代码整洁和稳定。
能力 ：团队成员能否识别风险，并设计有效的解决方案。
这块可提升点就很多了：如一是案例分享可以扩展同学眼界，通过举一反三可以避免同类问题的发生；二是沉淀组内/域内的稳定性知识库，将团队的能力沉淀下来，将团队的智慧变成个人的智慧，提高同学能力上限；三是寻求组内同学的帮助也是一种方法，这适合于发现了问题后，在设计方案时进行组内交流，查缺补漏，共同设计完备的解决方案。
当然，意识培养，或者说人的培养，同样是一个庞大复杂的体系，这里仅针对三个关键因素进行粗浅的解读，更多内容可以关注一些专业书籍。
安全生产规范
安全生产规范，我们定义为为了保证变更风险可控而制定的一系列流程规范。但很多人对于这些流程规范可能不以为然，认为繁琐的过程除了降低效率外并没有什么实际的益处。但其实，这些环节的存在是对变更方案及其风险进行二次确认的重要保障。
在一个典型的需求变更流程中，一般会有需求评审、技术方案评审、用例评审、自测/测试环节、CR、验收等多个环节。为什么需要有这么多环节呢？
-
需求评审： 针对业务变化带来的功能变化，在产品、研发、测试之间达成一致，进行多方确认。
-
技术方案评审： 针对功能变化对应的技术变化，在产品、研发、测试之间达成一致，进行多方确认。
-
用例评审： 针对功能变化/技术变化带来的用例变化，在产品、研发、测试之间达成一致，进行多方确认。
-
自测/测试环节： 针对技术变化的正确性和完备性，在研发、测试之间达成一致，进行二次确认。
-
CR： 针对技术变化对应的代码变化，在研发团队内部进行风险确认，属于二次确认。
-
验收： 针对功能变化的最终效果，在产品、研发、测试之间达成一致，属于多方确认。
可以看到，通过这些环节，变更的可见性将得以显著提升：几乎所有的相关方，都能够准确知道变更内容、变更方案和变更时间，并共同确认过变更风险。正因为这些环节在现有的需求流程中多半能够充分落实，因此需求变更带来风险的概率是相对较低的。
与需求变更的多方确认相反的是，技改需求、curl、数据订正、Ark变更等操作，在技术部多次管控加码之前，这些变更操作发生问题的概率远高于需求变更。其原因正是由于这些变更可能就是某个研发顺手操作了，其可见范围极小。根本没有相关方进行多轮有效的二次确认操作，容易出问题也就不足为奇了。其他类似的案例还有业务方突然执行了大量的业务变更操作，突然进行了某项营销活动导致引入远超预期的流量等等，这同样也是由于变更的可见性并未被技术团队感知，而导致的变更风险。
因此，安全生产规范，就是用来约定当任意变更产生时，需要通过何种流程将该变更通知到所有相关方，并通过何种方式进行多方确认，共同确保变更风险可控的共识方案。 了解了安全生产的本质后，各团队就完全可以针对自己的业务特性和所有的变更场景，制定专属的安全生产规范。其完备性取决于变更场景的完备性，其有效性取决于多方确认的有效性。 这样，也同时回答了"如何制定一个好的安全生产规范"这个问题。
应急响应
应急响应主要分三个部分：发现 、响应 和处理 ；关键的标准则是及时性 和有效性 。及时性确保了问题的影响不被放大，有效性则确保了已经发生的影响能被控制和修复。
发现： 发现的关键点是及时。若不考虑及时性，客户进线、结算错误这种后置发现手段，是可以发现所有的问题的。但这种通过实际的业务损失来发现问题的方案，显然不符合预期。因此，必须通过系统的手段，做好监控、告警布防，不论是系统资源使用率、服务可用性情况，还是业务数据正确性、波动值，均要做好完善的布控，方可及时发现。
响应： 响应的要点同样也是及时，它关系到已经出现的异常事件是否有人立即进行跟进处理，它一方面和意识培养直接相关，对应人的责任意识。另一方面对应的工具的正确使用，诸如手机、电脑、飞书等通知配置，也是关系到值班同学是否能第一时间获取到紧急事件通知的关键。
处理： 问题处理是应急响应的最后一环，它需要兼顾及时性和有效性：是否能够快速定位根因？是否能够有效止血？这就不仅和个人的能力有关，也和系统的完备性有关。
个人能力这块基本和3.3.1提及的内容一致。但系统能力的完备性，则同样可以展开大量的建设任务，如：为了定位问题根因： 告警信息的重要性（是否提供关键信息快速定位），日志信息的完备性和串联性（是否能够提供足够的信息定位问题，是否提供的信息均是重要的关联信息，减少不必要的噪声），都是非常重要的基础建设。
为了快速止血：除了通过个人的能力快速找到止血方案外，更重要的在于系统是否预设过相应的故障，并提供了止血预案。如果有，往往可以快速解决问题。但如果没有，要在短时间内解决问题，往往难度极高。如果操作不当，容易引入额外的风险。
最后，团队中关于应急问题处理的知识库也是非常重要的知识沉淀，有助于不熟悉该业务的同学，也能够快速定位和处理问题。
日常巡检
"防患于未然"是我们维护稳定性的重要目标。通过日常巡检，团队能够识别潜在的风险苗头。或是慢SQL、或是慢接口，或是cpu突刺。包括业务数据量是否逐步增长到了危险的范围，各项活动/配置是否临近过期，上下游的调用量是否接近容量上限......等等，这些风险，均可以在相应的巡检中发现问题，避免潜在风险逐步积累引发的灾难性后果。
架构治理
如果之前的部分主要关注人员层面的提升，那么架构治理则是从代码层面提升系统稳定性的一项重要措施，能够真正提升系统抗风险的硬实力。
从稳定性共识中可知，架构治理的能影响的关键因子为变更风险 ，而变更风险主要包括变更频率 、变更复杂度 和变更爆炸半径。
对应的领域建模、高内聚低耦合、OO等的架构原则，反映到变更风险中，就是控制了变更复杂度。因为内聚性，变更多可以聚焦在单一应用中，爆炸半径也同时得到控制。
资源隔离的架构设计，则是专门用于控制爆炸半径，不论是容器资源、线程池，还是DB、redis，甚至是P0/PN链路拆分等，均为控制爆炸半径，避免相互影响。
还有一种特殊的称作B/C流量拆分，这种看似是爆炸半径，但实际上也控制了变更频次。或者更精确的说法，是运营/B/C三端拆分，它的逻辑除了流量来源不同之外，更在于场景和变更频次不同。一般可以认为B端/运营端的供给侧，相较于C端的消费侧，会有更复杂的模型，更高的变更频次。进行这几端的拆分，更多在于减少C端（往往更核心）的变更频次，减少变更时的相互影响。
关于架构治理还有一个关键点，那就是抓住主要矛盾，先从最核心的业务场景开始治理。如果没有考虑好治理优先级，那么茫茫多的场景和链路就会成为一个交织在一起的毛线球，是无法进行抽丝剥茧逐一治理的。
资损防控
最后还有一个特殊的稳定性场景，资损防控。它在稳定性建设中比较特殊，是一个强业务相关的防控方案。一般可以在事前、事中、事后三个环节进行防控。
事前环节： 一般考虑防呆拦截/提醒、二次确认、审批流等多轮操作确认；更深入的可以增加结果预计算、影响面提示、前后对比等重提示，给到使用方对于执行后果的直观展示，减少误操作可能性。
事中环节： 一般会有资金上限熔断、实时/准实时Dcheck预警、相关资金指标波动预警等策略，在出现资损风险的时候进行预警，或业务熔断。
事后环节： 一般会采取T+1对账，确认多方资金数据一致。并辅以货款抵扣、调账等工具，在发生资金差额的情况下，进行金额补偿。
稳定性建设的困难是否都被解决了？
最后，让我们回过头来复盘一下第2节中提到的困难，看看这些拦路虎是否在本节中被逐一击破。
首先是短期价值不明确带来的争议，这块我们通过建立团队的稳定性共识得到彻底的解决。
其次稳定性建设的复杂性和风险性：
-
先说相对明确的增量风险预防：3.3.2中的安全生产规范整个存在的意义就是为了通过流程来控制增量风险。
-
然后是风险治理的难度：该问题先可以通过架构治理 进行分而治之，将大问题拆解成若干个小问题；再通过安全生产规范，控制每次解决小问题引入风险的概率。
-
最后是存量风险识别的难度：日常巡检 有助于发现存量风险的苗头，意识培养 则有助于对单应用风险的摸排，架构治理则对应了对于应用间、甚至整个域内的依赖链路风险评估和治理。
至此，所有的核心困难点都有了解决的方案，稳定性治理不再是一座不可逾越的高山，剩下的无非是根据具体问题，照着公式，逢山开路，遇水搭桥了。
四、稳定性建设全景图
通过以上的探讨，我们不仅分析了稳定性建设的重要性，还从理论角度，揭示了稳定性建设的核心要素与挑战，提供了具体的解决方案和建设任务。简单统合一下，就生成了下面的稳定性建设全景图，希望能为正在努力追求系统稳定性的小伙伴们提供启发与帮助。
当然，其中的支撑事项仅是抛砖引玉，每个团队都可以因地制宜，设计有团队特色的支撑事项。只要是能够服务于上层的建设目标，就具备落地的价值。
往期回顾
2.基于ANTLR4的大数据SQL编辑器解析引擎实践｜得物技术
4.一个Rust小白发布生产级Rust应用的进阶之路 ｜ 得物技术
文 / 裁衣(Joker)
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。