system stability

从前leader那边学得，分享给更多的小伙伴

一、异常可预警：

一个基本要求是，SDE应该在业务方感知到问题之前发现系统异常，而不是被动等待用户的投诉再层层传导到SDE。
基于此要求，我们目前的有了各种层次维度的预警机制和系统、
如监控CPU、Memory、IO、Network的zabbix，falcon系统；业务指标监控；监控异常的ELK。
业务异常比较容易忽略，这类异常一定是业务强相关的，顶多有系统工具帮助发出报警，但是逻辑却需要自己来写。一般导致大面积问题的原因是我们认为不合理的情况，是小概率事件。类似的这类监控非常重要，需要业务积累的人的意识。

二、快速可恢复：

假设第一点我们做到了，系统遇到了问题，SDE在业务方之前就得到了预警，系统有故障但是由于发现及时从时间上看还未对大面积用户造成很坏的影响；就需要我们具备系统快速可恢复的能力，当前阶段最重要的服务快速恢复可用状态，而不是找到具体原因或者追究责任。

对应的预警分类我们有如扩容，回滚，降级等等方式，按照级别类型分而治之。

前期系统建设以及压力情况还不涉及到扩容和降级的问题，但是回滚却是常见的，不要认为回滚很容易，一团队要有这个意识，一定需要培养；二技术层面依然有坑。如何做到系统的可回滚是我们进行大规模重构升级时必须考虑的。当然回滚可退出的意识一定要贯彻整个研发过程中。

三、事后可分析：

假设问题发现了，服务马上恢复了，接下了就是找到具体的原因，并且FIX掉；
这就要求系统层面要能够尽可能的保留当时发生问题的环境，要有历史记录，如CPU、Memory、IO、Network等各种技术LOG数据，业务LOG数据等；常见的问题如忘记Dump出来当时的Java内存快照，导致很难查找原因；最好开发出可以一键snapshot的脚本帮助解决重复劳动的事情。

参考：系统一键备份脚本