统稳定性，从字面上来看，就是让系统尽可能稳定，不要出问题。 但业务是变化的，系统肯定也是一直变化的，有可能新加了个功能就把系统搞挂了，也有可能突然业务流量暴增把系统搞挂了。所以，要保障系统稳定性可谓非 ...
系统总出故障怎么办，或许你该学学稳定性建设！说到系统稳定性，不知道大家会想起什么？我想大多数人会觉得这个词挺虚的，不知道系统稳定性指的是什么。 一年前的我看到这个词，也是类似于这样的感受，大概只知道要消除单点、做好监控报警，但却并没有一个体系化的方法论。 经过一段时间的摸索，我对系统稳定性有了较为体系化的认识，于是迫不及待地希望和大家一起分享。所以今天，就让我跟大家简单聊聊系统稳定性建设这个话题吧！ 何谓稳定性？系统稳定性，从字面上来看，就是让系统尽可能稳定，不要出问题。 但业务是变化的，系统肯定也是一直变化的，有可能新加了个功能就把系统搞挂了，也有可能突然业务流量暴增把系统搞挂了。所以，要保障系统稳定性可谓非常之难。但即使再难，也还是得去做，但到底怎么做呢？ 我们要保障系统稳定性，那就需要知道哪些因素可能会造成系统不稳定。我自己来了一个头脑风暴，把所有可能造成系统不稳定的因素整理一下，下面是我梳理的会造成系统不稳定的部分因素：
是不是感觉特别多，看起来有点晕了？别怕，其实我们可以将所有的不稳定因素根据时间维度，将其分为三大类：上线前、上线时、上线后。
我们现在已经知道哪个环节可能会出什么问题，那么接下来就是针对每个环境做一些特定的动作，从而提高系统稳定性了！ 上线前很多时候我们都以为系统稳定只是线上运行稳定就好了，但事实上需求研发流程是否规范，也会极大地影响到系统的稳定性。 试想一下，如果谁都可以随便提需求、做的功能没有做方案设计、谁都可以直接操作线上服务器，那么这样的系统服务能够稳定得了吗？所以说，需求上线前的过程也是影响系统稳定性的重大因素。 在我看来，在上线前这个阶段，主要有三大块非常重要的稳定性建设内容，分别是：
研发流程规范研发流程规范，指的是一个需求从提出到完成的整个过程应该是怎样流转的。一般的需求研发流程包括：产品提出需求、技术预研、需求评审、技术方案设计、测试用例评审、技术方案评审、测试用例评审、需求开发、CodeReview、需求测试。不同公司根据情况会有所调整，但大差不差。 在这个流程中，与研发相关的几个比较重要的节点是：技术方案设计及评审、测试用例评审及评审、需求开发、代码测试覆盖率、CodeReview。 我们上面提到的几个影响稳定性的因素，就是因为没有做好这几个节点的工作导致的，包括：
如果能够处理好上述几个节点，那么就能够极大地降低研发流程导致的问题。这里每个节点都有很深的学问，这里就不展开讲了，我们主要说个思路。 发布流程规范发布流程规范主要是为了控制发布权限以及频率的问题。 在项目初始，为了快速响应业务，一般权限控制都很松，很多人都可以进行线上服务的发布。但随着业务越来越多、流量越来越大，相对应的故障也越来越多，到了某个时候就需要对权限做管控，并且需要对需求的发布频率做控制。 对于需求发布流程来说，一般有几种发布方式，分别是：Release Train 方式、零散发布方式。 Release Train 意思是固定时间窗口发布，例如每周四发布一次。如果无法赶上这次发布时间，那么就需要等到下次发布窗口。 零散发布方式，指的是有需要就发布，不做发布时间控制。但这种方式一般只在项目初期发挥作用，后期一般都会收紧。 除此之外，发布流程中都会设有紧急发布流程，即如果某个需求特别重要，或者有紧急漏洞需要修复，那么可以通过该流程来紧急修复，从而避免因未到时间窗口而对业务产生影响。 但一般来说，紧急发布流程都比较麻烦，除非迫不得已不然不要审批通过，不然 Release Train 方式可能会退化成零散发布方式。 高可用设计高可用设计指的是为了让系统在各种异常情况下都能正常工作，从而使得系统更加稳定。 其实这块应该是属于研发流程规范中的技术方案设计的，但研发流程规范更加注重于规范，高可用设计更加注重高可用。 另外，也由于高可用设计是非常重要，因此独立拿出来作为一块来说说。对于高可用设计来说，一般可分为两大块，分别是：服务治理和容灾设计。 服务治理就包括了限流、降级、熔断、兜底、隔离等，这一些考虑点都是为了让系统在某些特殊情况下，都能稳定工作。 例如限流是为了在上游请求量太大的时候，系统不至于被巨大的流量击垮，还可以正常提供服务。 容灾设计应该说是更加高端点的设计了，指的是当下游系、第三方、中间件挂了，如何保证系统还能正常运行？ 可以说容灾设计比起服务治理，其面临的情况更加糟糕。 例如支付系统最终是通过 A 服务商进行支付的，如果 A 服务商突然挂了，那我们的支付系统是不是就挂了？那有什么办法可以在这种情况（灾难）发生的时候，让我们的系统还能够正常提供服务呢？这就是容灾设计需要做的事情了。 上线前上线时这个阶段，主要是确保功能按照原先设计的方案进行部署，这个阶段主要是确保规范操作，避免失误，因此可以制定相关的 CheckList 以及变更审批。 其次，为了避免还可能存在未发现的功能缺陷，有时候还可以使用灰度发布降低风险。在这个阶段能做的一些稳定性建设如下图所示。 上线后当系统成功上线后，很多小伙伴以为工作就结束了，但实际上我们还有不少工作可以做。根据我的经验，在上线后我们能做的稳定性建设包括：
监控报警，指的是我们需要对应用做好运行数据的收集，监控好系统的运行状态。当系统状态异常时，我们需要及时地发现并报警，从而让研发人员快速地解决问题。 一般来说，监控报警分为系统级别的监控报警和业务级别的监控报警。系统级别的监控报警包括 CPU、内存、磁盘等服务器资源的监控，而业务级别的报警则需要根据业务情况自行定义。 故障管理，就是当发生故障时，我们需要遵循的整套处理规范。 团队小的时候可能无所谓，但是当团队大了的时候，我们就需要统一大家的故障处理流程，从而可以更快速地解决故障。此外 |
2022-05-12
2021-10-20
2022-04-28
2022-05-07
2022-05-10
回答
回答
回答
回答
回答
回答
商务合作
0