程序世界里的不信任原则

正文

请到「今天看啥」查看全文

变更的影响一般体现在输出，有时候输出的结果并不能简单的判断是否正常，如输出是加密信息，或者输出的内容过于复杂。

所以，对于每次变更

1. 修改代码时，采用不信任编码，正确的不一定是“对”的，再小的修改也应确认其对后续逻辑的影响，有些修正可能改变原来错误时的输出，而输出的改变，就会影响到依赖该改变字段的业务。

2. 发布前，应该对涉及到的场景进行测试和验证，测试可以有效的发现潜在的问题，这是众所周知的。

3. 发布过程，应该采用灰度发布策略，因为测试并非总是能发现问题，灰度发布，可以减少事故影响的范围。常见灰度发布的策略有机器灰度、IP灰度、用户灰度、按比例灰度等，各有优缺点，需要根据具体场景选择，甚至可以同时采用多种的组合。

4. 发布后，全面监控是有效发现问题的一种方法。因为测试环境和正式环境可能存在不一致的地方，也可能测试不够完整，导致上线后有问题，所以需采取措施补救：

1. 如使用Monitor监控请求量、成功量、失败量、关键节点等

2. 使用DLP告警监控成功率、

3. 发布完，在正式环境测试一遍

【案例】 oauth系统某次修改后编译时，发现有个修改不相关的局部变量未初始化的告警，出于习惯对变量进行了初始化（初始化值和编译器默认赋值不一样），而包头某个字段采用了该未初始化的变量，但在测试用例中未能体现，监控也没细化到每个字段的值，导致测试正常，监控正常；但前端业务齐齐互动使用了该包头字段，导致发布后影响该业务。

2

服务程序的世界里防不胜防

一般的系统，都会有上下游的存在，正如下图所示：

而上下游的整个链路中，每个点都是不能保证绝对可靠的，任何一个点都可能随时发生故障，让你措手不及。

因此，不能信任整个链路中的任何一个点，需进行设防。

01

对服务本身的不信任

主要措施如下：

（1）服务监控

前面所述的请求量、成功量、失败量、关键节点、成功率的监控，都是对服务环节的单点监控。

在此基础上，可以加上自动化测试，自动化测试可以模拟应用场景，实现对于流程的监控。

（2）进程秒起

人可能在程序世界里是不可靠的因素（大牛除外），前面的措施，多是依赖人来保证的；所以，coredump还是有可能发生的，这时，进程秒起的实现，就可以有效减少coredump的影响，继续对外提供服务 。

02

请到「今天看啥」查看全文