这里谈谈一些在实际开发中遇到的几个问题。
2.3.监控告警
- 【强制】线上服务机器必须有基础监控报警，包含CPU、IO、内存、磁盘、coredump、端口
- 【强制】线上服务必须有基础的服务监控，包括接口qps、fatal数量、耗时
基础监控报警，目前可能未配置报警。服务超时、异常等报警有配置。
2.4.变更管理
- 【强制】任何一级服务变更，均需要走灰度发布机制
- 【强制】任何一级服务变更，包括服务变更、配置变更，均需要有相应的回滚预案，保证变更异常时可以快速回退
- 上线中都需要单点部署后，再全量部署（每个节点有部署间隔）
- 上线要检查变更列表，如jar包发布，配置变更，服务调用增加等等是否已完成。 多个服务上线，制定上线顺序以及相应的回滚方案。
反模式3.1.9 没有对非核心流程弱依赖化
【实例】
没有对流程进行弱依赖化，导致系统整体上比较脆弱，每个依赖单元故障都会导致整个业务瘫痪
【解决方案】
定期对系统的流程进行梳理，最小系统化，非必须流程尽量弱依赖化。
在项目中，某个流程会调用二方或三方接口，如果该接口出现了异常，也不会影响主流程的结果。例如：不能影响库存服务异常，而导致整个订单查询异常。
反模式3.4.1 代码搭车上线
【实例】
由于缺乏有效的代码修改管理机制，某产品线由于代码搭车上线，出现过多次线上故障
并且由于变更时涉及的修改比较多，导致问题定位和追查时非常困难
【解决方案】
建立严格的代码管理机制，严禁代码搭车上线，保证任何时刻主干没有未上线验证的代码
这一点其实还蛮多人用的（笑）。个人认为修复一些简单的线上Bug还是可以搭车上线的。
反模式3.4.7 变更没有经过严格的测试
【实例】
变更较小，感觉没有必要进行测试，结果出现低级错误，导致故障
【解决方案】
任何变更都要测试、double check，修改一行代码，也可能导致线上的稳定性故障
目前上线流程，都要经过冒烟测试、QA测试、沙箱测试才能上线，且上线后第一时间验证。