【软件工程】应对故障最佳实践

背景

最近上线改动的东西都很多，而且都是跨系统改动，同时修改3个以上系统的东西，并且很容易出现错误，出现生产事故，所以打算总结一下可以规避的问题。一般来说我们上线功能都需要在不同的阶段进行提前设计规划好。
需求评审阶段，需要和产品方进行合理的据理力争，那么实现不了，哪些改动较多，那么可能影响现有流程，都是需要一一核对的。而开发人员的职责不仅仅是一个需求的接收者，更有义务和产品方一起去构想可能出现的任何情况并在代码层面进行兜底处理。
技术设计阶段, 当产品方案确认之后，大方向其实就确定好了，剩下就是实现细节，需要和各个上下游系统对接方进行确定，改动的范围，比如一个功能改动可能设计上下游同时改动、多方的参与。那么在设计阶段需要考虑可能出现的所有情况。当然这个情况不仅仅是业务流程，以及需要从系统资源、中间件多角度考虑。
开发阶段，当进入开发阶段，工程师也就清楚改动点大概是什么了，当然可能涉及到一些细节点，那么就需要工程师多去评估可能的影响，这里有一个点就是我们不能仅仅构想没有异常的场景，也需要为异常场景从代码层面去控制。也就是fail for design。遇到不确定的点，及时和相关利益人进行沟通，确认。而这个时候修改成本是最低的。
测试阶段 测试阶段，一般来说为自测和提测，工程师开发完毕之后，需要将自己修改的功能单元测试，然后全流程走通。有经验的工程师和小白的差距，就在于对于异常情况代码的把控力以及设计能力。新手可能只考虑正常情况下流程，而高手会各种条件都考虑齐全。以及在功能实现上更加的具备灵活性和可拓展性等。这样也可以减少不必要的BUG。
上线阶段 一般来说，我们需要把基础工作做好，SQL、配置等。然后上线后，其实观察错误日志，出现情况的话，及时采取回滚措施，或者及时修复。

故障发生时

一般来说，发生故障的时候，大多数都是系统上线新或者是依赖三方服务、系统层面、数据库等出现异常，首先是定位故障原因是什么。这个时候需要看监控报警、日志等。

• 重启和限流 ： 主要解决的系统的可用性，不是功能性问题，限流操作需要具备一定的流控中间件。
• 回滚操作 ： 回滚一般针对的是新代码的bug，将代码回滚到之前的版本。
• 降级操作 ：降级操作是不能回滚操作的时候，不要将失态扩大，挂一个停止服务的故障公告
• 紧急更新 ： 紧急更新，一般是出现异常情况，需要针对特殊情况处理，马上code和上线，需要具备强大的自动化系统，自动化测试和自动化发布系统。如果是3台机器，你可以手动一台发布，但是如果是1000台，就需要自动话处理。

出现故障时，最重要的不是debug故障，而是尽可能减少故障的影响范围，并尽快的修复问题。

故障前的准备工作

• 具备一个调用链图，请求经过的系统。
• 设定故障登记，比如影响多少用户，宕机多久，损失多少钱等。
• 故障演练，之前看过字节的混沌工程，随机在生产环境搞，看出现问题能否及时修复。但是对于中小公司来说一般都没有资源和能力做这个事情。
• 灰度发布系统 要减少线上故障采用灰度发布，一般来说有些场景在测试环境很难复线，但是进行恢复发布可以比较好的观察，如果有问题可以及时回滚，不至于影响全部用户。