正文
【真实案例】：接手oauth系统后运行数月表现良好，突然有一天，发生了coredump，经查，是某个业务不按规定请求包中填写了超长长度，导致memcpy时发生段错误，根本原因，还是没有做好长度检查。
（3）对数据内容的检查
某些场景下，没有对数据内容做检查就直接使用，可能导致意想不到的结果。
【案例】：sql注入和xss攻击都是利用了服务端没有对数据内容做检查的漏洞。
2、对输出（变更）的不信任
变更的影响一般体现在输出，有时候输出的结果并不能简单的判断是否正常，如输出是加密信息，或者输出的内容过于复杂。
所以，对于每次变更
（1）修改代码时，采用不信任编码，正确的不一定是“对”的，再小的修改也应确认其对后续逻辑的影响，有些修正可能改变原来错误时的输出，而输出的改变，就会影响到依赖该改变字段的业务。
（2）发布前，应该对涉及到的场景进行测试和验证，测试可以有效的发现潜在的问题，这是众所周知的。
（3）发布过程，应该采用灰度发布策略，因为测试并非总是能发现问题，灰度发布，可以减少事故影响的范围。常见灰度发布的策略有机器灰度、IP灰度、用户灰度、按比例灰度等，各有优缺点，需要根据具体场景选择，甚至可以同时采用多种的组合。
（4）发布后，全面监控是有效发现问题的一种方法。因为测试环境和正式环境可能存在不一致的地方，也可能测试不够完整，导致上线后有问题，所以需采取措施补救。
A：如使用Monitor监控请求量、成功量、失败量、关键节点等
B：使用DLP告警监控成功率
C：发布完，在正式环境测试一遍
【案例】oauth系统某次修改后编译时，发现有个修改不相关的局部变量未初始化的告警，出于习惯对变量进行了初始化（初始化值和编译器默认赋值不一样），而包头某个字段采用了该未初始化的变量，但在测试用例中未能体现，监控也没细化到每个字段的值，导致测试正常，监控正常；但前端业务齐齐互动使用了该包头字段，导致发布后影响该业务。
一般的系统，都会有上下游的存在，正如下图所示
而上下游的整个链路中，每个点都是不能保证绝对可靠的，任何一个点都可能随时发生故障，让你措手不及。
因此，不能信任整个链路中的任何一个点，需进行设防。
1、对服务本身的不信任
主要措施如下：
（1）服务监控
