上一篇<系统稳定性方法论 - 序篇>中提到了系统稳定性的4大抓手，今天就先说说其中的第一个 降发生
降发生指的是，从设计阶段开始，开发阶段、测试阶段、上线前的准备阶段、上线阶段到最后上线后的回归测试阶段，在这整个过程中，对所有阶段进行把控，将能出现异常的可能性消除。
这一阶段需要考虑的主要问题：除了最基本的"实现功能性需求"之外，更要设计和思考"如何实现非功能性需求"，而对于系统稳定性方向来说，就是如何设计系统防止被别人搞死。
举几个常见的"非功能性需求"
以上这些都是需要在设计阶段就决定好的，不能急于实现”功能性需求“去交差，而忽略这些”非功能性需求“…
不写bug是对所有开发者的最基本要求，也就是别被自己搞死…
开发阶段还需要考虑，代码的性能、维护性、可复用性…
首先要落地落实code review，很多时候code review都成了走过场，失去了code review的意义… 不仅做不到提前发现问题，更做不到知识共享。
那如何做好code review呢？说说理想情况下的code review：
这里也吐槽一下，正确使用GIT也是code review的一大前提，发现很多开发者只做commit、merge… 怎么简单怎么来… 有时间也出一篇如何正确使用GIT的分享…
测试是上线前的重要环节，可以提前发现问题，也是上线前投入精力最多的一个阶段。
单元测试不能省，好的单元测试可以覆盖大部分场景，test coverage甚至可以作为RD的OKR。
很多团队都不做压力测试的，更别提全链路压力测试，其中有主观原因也有客观原因…
做好全链路压力测试不简单，涉及链路梳理、入口压测标识改造、系统间以及系统内部压测标识传递、中间件改造、影子库、流量回放等众多难点…
给自己再挖个坑，找机会出一篇全链路压测的分享
上线过程需要制定上线SOP，滚动发布、灰度发布，每发布一点就做一次检查，不要一次性的全量上线。上线后也要做线上的回归测试。
总结一下：
