安全开发与发布的基本准则

遵循一套用于安全开发和发布的准则，为开发活动编织一张质量安全网，尽可能降低出问题的概率。

影响面评估准则

确保代码安全的第一准则是：代码的影响面评估。在核心流程里的一行代码的影响面，胜于在非核心流程里的百行代码的影响面。
新手工程师，往往容易见树不见林，着眼于眼前的功能，而未察觉对现有或全局的负面影响。

1. 在核心流程或通用方法里加代码时，要谨慎。哪怕是一行，都可能会出问题。
2. 尽量避免修改原有方法的签名。使用重载方法或拷贝方法来解决。如果原有方法只有一个调用方，可以这么做，但要回归影响的功能；如果有两个调用方，谨慎这么做；如果有三个调用方，避免这么做【因为回归量可能很大，超出所能预料】。
3. 实现眼前的功能时，要同时关注会被影响的功能。
4. 修改的方法有很多调用方时，要考虑兼容，评估每个被影响到的方法及风险。
5. 新增而不修改原有代码，通常不会出问题。努力做到开闭原则：“对修改关闭，对扩展开放”。
6. 新增配置而不修改原有配置，通常不会出问题。但是“老配置+新应用”会导致问题。
7. 当用新做法替换原有做法时，尤其要回归所有影响到的点。
8. 对可能产生风险的代码敏感。
9. 勿存侥幸心理；勿对代码过于自信。
   
   

健壮性准则

很多线上问题出在代码的不健壮性上。即使引发的是小问题，未导致故障，但修复时也要重新测试和发布，耗时耗力。

1. 在核心流程里解析不可靠的数据（尤其是 JSON 数据）时，加 try-catch 。
2. 在整体流程中流经的确定很可能会抛出异常的代码，如果不期望影响整体的执行完成，加 try-catch 。
3. 在整体流程中流经的不确定是否有场景会导致抛出异常的代码，加 try-catch。
4. 避免链式地获取嵌套对象的属性，很容易导致 NPE 。
5. 对 API 返回结果判空。
6. 对不太确定是否为空的对象或容器判空。
7. 考虑对原有情况的兼容。
   
   

不可变准则

修改入参，使用全局变量，往往使得程序行为更难推测，错误潜藏非常隐秘，出问题后排查也会非常耗时。

1. 避免修改方法入参（对象或容器）。
2. 使用 stream.filter 替代删除列表中的元素。
3. 当需要修改入参来实现时，总是考虑通过返回对象来替代。
4. 提供 merge 操作优化修改入参。
5. 避免使用全局变量。
   
   

快速失败准则

快速失败是避免产生大量脏数据的法宝之一。

1. 如果一项功能需要多个前置条件同时具备才能正确运行，错误运行会导致不可确定的结果时，在任一条件不具备时，及时抛出异常终止。
   
   

重大重构准则

1. 尽可能新增接口/链路而非修改原来的。
2. 使用策略模式分离新链路和旧链路。
3. 增加开关，能够快速切回原来的服务。
4. 确保可快速回滚【应用及配置】。
5. 通过逐步分流来切入新流量，冷却老流量。
6. 用次要的影响面小的业务进行线上试点。
   
   

并发安全准则

1. 单例组件类尽可能只引用不含有实例成员的单例组件。
2. 组件类避免含有可变的实例成员；这种设计容易潜藏难以觉察的并发风险。
3. 如果组件类含有可变的实例成员，则要么确保不在并发环境使用，要么添加组件的原型声明。
4. 生产环境里使用全局配置良好的线程池，而不是简陋配置的线程池。
5. 避免在方法里动态创建线程池。除非这是一个小流量应用，且方法调用很少。
   
   

大流量准则

1. 应对流量大的长耗时任务，限制指定时间段的处理数量。
2. 应对流量大的工具需要加限速能力；限速可动态调整。
3. 降级非核心服务和数据，可配置。
4. 数据存储冗余或优化，减少为了取少量次要数据而导致的外部服务调用。
5. 实时性要求不高的场景，采用延时队列或非实时接口来处理。
   
   

关键日志准则

1. 核心链路和关键数据必须打日志；方便排查问题。
2. 已预估的出错或致命问题的打错误日志；发布时要尤其关注此类日志。
3. 不影响系统运行的错误打警告日志；避免干扰发布是否OK的判断。
   
   

提前预知准则

1. 对于预发上报出的任何问题保持敏感。因为那可能是老天爷在提醒你。
2. 对于返回大量数据的查询服务类，可以使用对比引擎来比较线上和预发的返回结果。
   
   

严格测试准则

1. 单测全部通过；不可绕开原有单测。
2. 无论改动大小，均要自测。
3. QA 和预发测试，自测通过。
4. 已有测试用例全部通过。
   
   

安全发布准则

1. 一个项目涉及多个应用和配置时【应用+配置 > 3 时】，一定要制定发布文档，指明配置与应用的发布顺序，以及不遵循该发布顺序时会导致的风险。
2. 发布文档的细节必须非常具体明确，每一个操作和命令都毫无歧义。即使换另一个人来发布，只要按步骤执行，就不会出问题。
   
3. 发布 4 个以上应用时，应找团队其他小伙伴协助，减少因发布压力过大可能导致的误操作或长耗时。
4. 发布多个应用时，在代码实现考虑兼容，确保部分可以提前发布或者并行发布。
5. 发布时要专注，不允许被打断；发布后一小时内应持续观察，尽量不要离开。
6. 节前非重要紧急问题避免发布；与产品同学协商好，改日发布。
7. 由于配置切换导致线上容易产生大量脏数据，或者需要修复很多数据时，最好凌晨发布。 尽量一次性解决，而不要累积起来多次解决【捞数据和修复数据的成本有时很大】。
8. 涉及很多配置和 DDL 的大项目发布，最好凌晨发布。有充足的时间测试回归。
9. 开发与发布前，确保 QA 和预发、线上的配置是一致的。配置不一致，可能会导致 QA 和预发的测试OK，但是到线上就会出问题。
10. 使用灰度发布或蓝绿发布；白名单验证；分流发布；分批发布；