软件平台系统稳定性规范

目录

1 什么是系统稳定性？

2 上线前

2.1 研发流程规范

2.2 发布流程规范

2.3 ⾼可用设计

3 上线时

4 上线后

5 总结

---

1 什么是系统稳定性？

        系统稳定性，从字面上来看，就是让系统尽可能稳定，不要出问题。 但业务是变化的，系统肯定也是一直变化的，有可能新加了个功能就把系统搞挂了，也有可能突然业务流量暴增把系统搞挂了。所以，要保障系统稳定性可谓非常之难。但即使再难，也还是得去做，但到底怎么做呢？

        要保障系统稳定性，那就需要知道哪些因素可能会造成系统不稳定。先来个头脑风暴，把所有可能造成系统不稳定的因素整理⼀下，下⾯是梳理的会造成系统不稳定的部分因素：

        是不是感觉特别多，看起来有点晕了？别怕，其实可以将所有的不稳定因素根据时间维度，将其分为三⼤类：上线前、上线时、上线后。

1. 上线前的不稳定因素。 这块指的是需求上线前的所有内容，包括需求评审、技术⽅案设计、代码编写、功能测试等等。

2. 上线时的不稳定因素。 这块指的是上线时可能的不稳定因素，包括操作失误、某个功能有问题导致线上出问题等等。

3. 上线后的不稳定因素。 这块指的是需求上线后，有可能出现的各种各样的问题，例如中间件挂了、⽹络挂了等等。

        现在已经知道哪个环节可能会出什么问题，那么接下来就是针对每个环境做⼀些特定的动作，从⽽提⾼系统稳定性了！

2 上线前

        很多时候都以为系统稳定只是线上运⾏稳定就好了，但事实上需求研发流程是否规范，也会极⼤地影响到系统的稳定性。

        试想⼀下，如果谁都可以随便提需求、做的功能没有做⽅案设计、谁都可以直接操作线上服务器，那么这样的系统服务能够稳定得了吗？所以说，需求上线前的过程也是影响系统稳定性的重⼤因素。

        在上线前这个阶段，主要有三⼤块⾮常重要的稳定性建设内容，分别是：

1. 开发流程规范

2. 发布流程规范

3. ⾼可⽤设计

上线前的稳定性建设

2.1 研发流程规范

        研发流程规范，指的是⼀个需求从提出到完成的整个过程应该是怎样流转的。⼀般的需求研发流程包括：产品提出需求、技术预研、需求评审、技术⽅案设计、测试⽤例评审、技术⽅案评审、测试⽤例评审、需求开发、CodeReview、需求测试。不同公司根据情况会有所调整，但⼤差不差。

        在这个流程中，与研发相关的⼏个⽐较重要的节点是：技术⽅案设计及评审、测试⽤例设计及评审、需求开发、代码测试覆盖率、CodeReview。 上⾯提到的⼏个影响稳定性的因素，就是因为没有做好这⼏个节点的⼯作导致的，包括：

1. 未测试需求直接上线

2. 上线的需求产品不知道

3. 上线的新需求有 bug

4. 上线后没有线上验证

5. 系统设计⽅案存在缺陷

6. 系统代码实现存在缺陷

        如果能够处理好上述⼏个节点，那么就能够极⼤地降低研发流程导致的问题。这⾥每个节点都有很深的学问，这⾥就不展开讲了，主要说个思路。

2.2 发布流程规范

        发布流程规范主要是为了控制发布权限以及频率的问题。

        在项⽬初始，为了快速响应业务，⼀般权限控制都很松，很多⼈都可以进⾏线上服务的发布。但随着业务越来越多、流量越来越⼤，相对应的故障也越来越多，到了某个时候就需要对权限做管控，并且需要对需求的发布频率做控制。

        对于需求发布流程来说，⼀般有⼏种发布⽅式，分别是：Release Train ⽅式、零散发布⽅式。

        Release Train 意思是固定时间窗⼝发布，例如每周四发布⼀次。如果⽆法赶上这次发布时间，那么就需要等到下次发布窗口。

        零散发布⽅式，指的是有需要就发布，不做发布时间控制。但这种⽅式⼀般只在项⽬初期发挥作⽤，后期⼀般都会收紧。

        除此之外，发布流程中都会设有紧急发布流程，即如果某个需求特别重要，或者有紧急漏洞需要修复，那么可以通过该流程来紧急修复，从⽽避免因未到时间窗⼝⽽对业务产⽣影响。

        但⼀般来说，紧急发布流程都⽐较⿇烦，除⾮迫不得已不然不要审批通过，不然 Release Train ⽅式可能会退化成零散发布⽅式。

2.3 ⾼可用设计

        ⾼可⽤设计指的是为了让系统在各种异常情况下都能正常⼯作，从⽽使得系统更加稳定。 其实这块应该是属于研发流程规范中的技术⽅案设计的，但研发流程规范更加注重于规范，⾼可⽤设计更加注重⾼可⽤。

        另外，也由于⾼可⽤设计是⾮常重要，因此独⽴拿出来作为⼀块来说说。对于⾼可⽤设计来说，⼀般可分为两⼤块，分别是：服务治理和容灾设计。

        服务治理就包括了限流、降级、熔断、兜底、隔离等，这⼀些考虑点都是为了让系统在某些特殊情况下，都能稳定⼯作。 例如限流是为了在上游请求量太⼤的时候，系统不至于被巨⼤的流量击垮，还可以正常提供服务。

        容灾设计应该说是更加⾼端点的设计了，指的是当下游、第三⽅、中间件挂了，如何保证系统还能正常运⾏？ 可以说容灾设计比起服务治理，其⾯临的情况更加糟糕。

        例如⽀付系统最终是通过 A 服务商进⾏⽀付的，如果 A 服务商突然挂了，那⽀付系统是不是就挂了？那有什么办法可以在这种情况（灾难）发⽣的时候，让系统还能够正常提供服务呢？这就是容灾设计需要做的事情了。

3 上线时

        上线时这个阶段，主要是确保功能按照原先设计的⽅案进⾏部署，这个阶段主要是确保规范操作，避免失误，因此可以制定相关的 CheckList 以及变更审批。

        其次，为了避免还可能存在未发现的功能缺陷，有时候还可以使⽤灰度发布降低⻛险。在这个阶段能做的⼀些稳定性建设如下图所⽰。

上线时的稳定性建设

4 上线后

        当系统成功上线后，很多⼩伙伴以为⼯作就结束了，但实际上还有不少⼯作可以做。根据经验，在上线后能做的稳定性建设包括：

1. 监控报警

2. 故障管理

3. 紧急处理预案

4. 容灾演练

5. 案例学习

6. 全链路压测

        监控报警，指的是需要对应用做好运行数据的收集，监控好系统的运⾏状态。当系统状态异常时，需要及时地发现并报警，从⽽让研发⼈员快速地解决问题。

        ⼀般来说，监控报警分为系统级别的监控报警和业务级别的监控报警。系统级别的监控报警包括CPU、内存、磁盘等服务器资源的监控，⽽业务级别的报警则需要根据业务情况⾃⾏定义。

        故障管理，就是当发⽣故障时，需要遵循的整套处理规范。 团队⼩的时候可能⽆所谓，但是当团队⼤了的时候，就需要统⼀⼤家的故障处理流程，从⽽可以更快速地解决故障。此外，在故障解决完成之后还需要进⾏复盘，产出对应的故障报告。

        Case Study 机制指的是定期学习其他团队的⾼可⽤或者线上故障进⾏学习，从⽽提⾼团队的系统设计能⼒，避免踩坑。

        容灾演练，其实就是模拟某些中间件或者服务故障，然后看看系统是否能按照之前设计的⾼可⽤⽅案实施。

        容灾演练是提升系统稳定性的⼀把利器，很多时候即使设计得很完美，但实际上却没发挥作⽤，究其根本就是没有实践过。是驴是⻢，得拉出来溜溜才知道。

        紧急处理预案，简单就是要想到各种可能发现的情况，然后做好预案。 之后结合容灾演练不断进⾏优化，从⽽形成⼀套很好的处理预案。这样当线上发⽣类似故障时，就可以轻松应对了。

        全链路压测，指的是对整个链路进⾏压测。 不同公司可能会采⽤不同的⽅案，有些会直接在线上进⾏压测，然后⽤流量标记的⽅式识别测试流量。

        有些则是进⾏流量录制，之后重新搭建⼀套与线上⾮常类似的系统进⾏压测。⼀般来说，第⼀种效果肯定会更好，成本也更低，但是对研发⼈员要求也更⾼，⻛险也更⼤。

5 总结

        简单地从上线前、上线时、上线后去探讨了如何做稳定性建设，其中每⼀块都可以展开来讲很多内容。

        例如监控报警这块，那应该监控系统的哪些指标？其实这些都是有⼀些成熟的⽅案了，例如要监控TP90、响应延迟、调⽤延时、消息处理延时等