大家好，我是树哥。说到系统稳定性，你怎么看？我想大多数人会觉得这个词很空洞，不知道系统稳定性指的是什么。一年前看到这个词的时候，我也有类似的感觉。大概只知道消除单点，做好监控告警，没有系统的方法论。经过一段时间的摸索，对系统的稳定性有了更系统的认识，迫不及待的分享给大家。那么今天，就系统稳定性建设这个话题，和大家简单聊聊吧！什么是稳定性？系统稳定性，从字面上看，就是让系统尽可能的稳定，不出问题。但是业务在变，系统也要不断变。有可能是增加了新的功能导致系统挂了，或者业务流量突然增加导致系统挂了。因此，很难保证系统的稳定性。但是再难，还是要做，但是怎么做呢？如果我们要保证系统的稳定性，我们需要知道哪些因素可能会导致系统不稳定。我灵机一动，把所有可能导致系统不稳定的因素都整理了出来。以下是我整理的一些可能导致系统不稳定的因素：未经测试直接上线的需求。错误经常被发布。需求被释放。紧急需求未在线验证。系统设计方案存在缺陷。系统代码实现存在缺陷。启动某个功能时，出现运行错误。下游服务挂了。应用服务器内存溢出OOM应用服务器CPU100%数据库主从延迟数据库主库挂起Kafka消息挤压Redis响应慢第三方服务商挂起潜在黑客攻击有点晕？不要害怕，其实我们可以把所有的不稳定因素按照时间维度分为三类：上线前、上线中、上线后。上线前的不稳定因素。这部分是指需求上线前的所有内容，包括需求评审、技术方案设计、代码编写、功能测试等。上线时的不稳定因素。该部分是指上线时可能出现的不稳定因素，包括操作失误、某项功能出现问题导致上线问题等。上线后的不稳定因素。这部分是指需求上线后可能出现的各种问题，比如中间件宕机，网络宕机等等。知道了可能是哪个环节出了问题，接下来就是针对每个环境做一些具体的动作来提高系统的稳定性了！上线前很多时候，我们认为系统的稳定性只是稳定上线运行的问题，但实际上，所需要的研发流程是否规范也会极大地影响系统的稳定性。试想，如果任何人都可以随意提出需求，如果不设计功能，任何人都可以直接操作在线服务器，这样的系统服务能稳定吗？因此，需求上线前的流程也是影响系统稳定性的一大因素。在我看来，在上线前的这个阶段，主要有三个非常重要的稳定性建设内容，分别是：开发流程规范，发布流程规范，高可用设计，稳定性建设，研发流程规范，上线前研发流程规范.这就是需求的整个过程应该如何从提议到完成。需求开发的一般流程包括：产品需求、技术预研、需求评审、技术方案设计、测试用例评审、技术方案评审、测试用例评审、需求开发、CodeReview、需求测试。不同的公司会根据情况进行调整，但差别不大。在这个过程中，与研发相关的几个重要节点是：技术方案设计与评审、测试用例评审与评审、需求开发、代码测试覆盖率、CodeReview。我们上面提到的几个影响稳定性的因素都是因为没有做好这些节点的工作造成的，包括：未经测试直接上线的需求。产品不知道上线的新需求有bug。验证系统设计方案存在缺陷，系统代码实现存在缺陷。如果以上几个节点处理好，研发过程中出现的问题就可以大大减少。这里的每个节点都有很深的学问，这里就不多说了，主要说一个思路。发布流程规范发布流程规范主要是控制发布权限和频率。项目初期，为了快速响应业务，一般权限控制很松，很多人可以发布在线服务。但是，随着业务越来越多，流量越来越大，对应的故障也越来越多，到了一定的时候，就需要控制权限，控制需求的发布频率。对于需求发布流程，一般有几种发布方式，即：ReleaseTrain方式和分散发布方式。ReleaseTrain是指固定时间窗口发布，比如每周四一次。如果赶不上这个发布时间，就需要等到下一个发布窗口了。零星释放法是指必要时释放，释放时间不受控制。不过这种方法一般只在工程前期有效，后期一般会收紧。另外在发布过程中会有一个紧急发布流程，即如果某个需求特别重要，或者有一个紧急的漏洞需要修复，那么就可以使用这个流程来紧急修复，所以以免时间窗失效对业务造成影响。影响。但一般来说，紧急发布流程比较麻烦，除非万不得已，否则不要批准，否则ReleaseTrain方式可能会退化为零星发布方式。高可用性设计高可用性设计是指使系统在各种异常情况下都能正常工作，从而使系统更加稳定。其实这块应该属于研发流程规范中的技术方案设计，只是研发流程规范更注重规范，而高可用设计更注重高可用。另外因为高可用的设计很重要，所以作为一个块单独拿出来。对于高可用设计，一般可以分为服务治理和容灾设计两部分。服务治理包括限流、降级、熔断、底线、隔离等，这些考虑都是为了让系统在某些特殊情况下稳定工作。比如限流是为了防止上游请求量过大时系统被巨大的流量压垮，仍然可以正常提供服务。容灾设计应该说是比较高端的设计。指的是在下游系统、第三方、中间件宕机的情况下，如何保证系统还能正常运行？可以说，容灾设计面临着比服务治理更糟糕的局面。比如支付系统最后通过服务商A支付，如果服务商A突然挂了，我们的支付系统会不会挂了？那么有什么办法可以让我们的系统在这种情况（灾难）发生的时候能够正常提供服务呢？这就是容灾设计需要做的。上线阶段，这个阶段的主要目的是保证功能按照原来的设计方案进行部署。这个阶段主要是保证操作规范，避免出错。因此，可以制定相关的CheckLists和变更审批。其次，为了避免可能存在的未被发现的功能缺陷，有时可以采用灰度发布的方式来降低风险。这个阶段可以做的一些稳定性建设如下图所示。上线时的稳定性建设系统上线成功后，很多小伙伴都认为工作结束了，但实际上我们还有很多工作要做。根据我的经验，上线后我们可以做的稳定性建设包括：监控告警、故障管理、应急预案、灾备演练案例、全链路压测、监控告警，也就是说我们需要收集应用程序的运行数据，监控系统的运行状态。当系统状态异常时，我们需要及时发现并报警，以便研发人员快速解决问题。一般来说，监控告警分为系统级监控告警和业务级监控告警。系统级监控告警包括对CPU、内存、磁盘等服务器资源的监控，而业务级告警需要根据业务情况定义。故障管理是发生故障时我们需要遵循的一套处理规范。团队小的时候可能无所谓，但是当团队大的时候，我们需要统一大家的故障处理流程，这样才能更快的解决故障。另外，故障解决后，还需要进行复核，生成相应的故障报告。CaseStudy机制是指定期学习其他团队的高可用或线上故障，以提升团队的系统设计能力，避免踩坑。灾备演练其实就是模拟一些中间件或者服务出现故障，然后看看系统能否按照之前设计好的高可用方案来实现。灾备演练是提升系统稳定性的利器。在很多情况下，即使我们设计得很完美，它们实际上也不起作用。原因是我们根本没有实践过。是驴还是马，拉出来走走就知道了。应急预案简单来说就是把所有可能发现的情况想一想，然后制定预案。之后结合灾备演练，不断优化，形成良好的处置方案。这样当线上出现类似的故障时，就可以轻松处理了。全链路压测是指对整个链路进行压测。不同的公司可能采用不同的方案，有的会直接在线进行压测，然后通过流量标记来识别测试流量。有的是做流量记录，然后重建一个和线上系统很像的系统做压测。一般来说，第一次效果肯定会更好，成本也会更低，但对研发人员的要求也更高，风险也更大。小结今天我们从上线前、上线中、上线后简单讨论了如何构建稳定性，每一个都可以展开讲很多内容。比如在监控告警方面，我们应该监控系统的哪些指标？其实这些都是一些比较成熟的解决方案，比如监控TP90，响应延迟，调用延迟，消息处理延迟等等。但是由于篇幅原因，今天我们只是触及皮毛，以后会继续慢慢完善。后续行动。有兴趣的可以关注夏树兄，后面慢慢写。最后，抛出一张思维导图作为今天文章的结尾。如何打造高可用？好了，今天的分享就到这里。
