基于系统稳定性建设，你做了哪些事情？（上）-一一网

这是我经常问的一个问题，无论是在面试一些高P的时候，还是在晋升答辩当评委的时候。绝大多数啊的答案是：限流、降级、熔断。但是，成体系性的答案，基本上很少有人说出来。

首先，什么是系统可靠性（Reliability）和可用性（Availability）？而什么又是系统稳定性（Stability）？

系统可靠性：高可靠的系统，故障次数少，频率低，在较长的时间内无故障地持续运行。

系统可用性：高可用的系统，故障时间少，止损快，在任何给定的时刻都可以及时地工作。

举个“分布式系统原理与范型”书的第八章的例子：

如果系统在每小时崩溃1ms，那么它的可用性就超过99.9999%，但它还是高度不可靠的。

如果系统从来不崩溃，但要在每年八月中停机两个星期，那么它是高度可靠的，但是系统的可用性只有96%。

系统稳定性，则是在系统可靠性和可用性之上，即降低故障频次和提升止损速度的情况下，要求系统的性能稳定，不要时快时慢。

换言之，我不但需要系统尽可能地随时可以给我提供服务，并且，我希望系统能给我提供有质量保障的服务。

那么，回到最初的问题，基于系统稳定性建设，我们可以做哪些事情？

1、提升系统可靠性，减少故障次数

代码规范：

Java工程师，我认为阿里那套代码规范，应该足可以了。当然，我个人会根据多年的踩坑经验，多增加几条红线的规范。

mybatis select查询语句，必须加limit，且limit不超过100；没加limit，查出来100w条记录，可以把网卡全部打满。
mybatis select查询语句，where后面的条件项，必须有一列是必选项，且该列是加了索引的；几亿数据的大表，因为没走索引而导致全表扫描，数据库直接干挂。
mybatis update、delete语句，单场景单写SQL，不允许出现动态拼接SQL，且where后面的条件项，必须有一列走索引，且该索引的区分度要高；update、delete为动态拼接SQL，且漏传了条件项，会导致全表被修改或删除。
java工程的循环语句中，不允许进行rpc和db操作；过多的循环，可以把下游和db直接干挂，索性一刀切。

上线规范：

重要等级高的服务，必须TL review过后，才能上线。
重要等级高的服务，必须有灰度策略，才能上线。
重要等级高的服务，如果代码改动量大，影响范围大，必须选择不影响业务的时间上线。（如果没有，那就选择业务低峰期上线）

故障复盘：

有句话，成年人最好的学习方式就是复盘，用在系统工程上，一样是真理。既然我们已经出故障交了昂贵的学费，那么我们就希望这个学费交得足够值得。

5 whys，由点及面，深挖问题根因，在复盘过程中，杜绝出现这种“忘了”，“没有仔细”，“没有及时”，“时间太紧”等敷衍、流于形式的字眼，从而避免同样的、同一类型的故障反复出现。
根据“重要紧急”、“重要不紧急”两个维度，制定短期和中期todo，明确执行人以及完成时间，并持续地监督跟进，直到完成所有的todo。且，todo要是真实可落地的，避免出现“下次认真点儿”，“下次高度重视”，“下次提高警惕”等比较务虚的片儿汤话。
明确故障责任人。有错就要认，挨打要立正，出了问题一定要站出来担责，不要担心会产生“多做多错”的问题，因为我们要制定“奖惩规则”，多做属于奖励范畴，多错属于惩罚范畴，其实这是不矛盾的。

压测限流：

通过把系统峰值流量，进行流量回放的方式在生产环境进行压测，已经成了通用的解决方案，我们可以用逐渐加压的方式，1倍、1.5倍、2倍、2.5倍、3倍等，最终压测出，当前系统可以承载线上峰值流量的几倍，然后根据此，设置出来限流的阈值（通常会比可承载的线上峰值流量低一些，以避免误差），起到避免系统过载而挂掉的作用。