【T】点击发布按钮前的思考
写在前面
本来想叫一个 “上线八大问” 之类的名字，感觉一来不太雅，二来不能体现主动性。
最近一阵比较有感触。首先是线上无小事，要有一颗敬畏执行，特别是对于流量大，数据多的系统。而上线是否有问题，绝对是一个
九十八分在人，两分在天的事情。自己关于这点也的确算是思考过，不能算是方法论，但也能算一个上线自检的规则。
思考点
自问一：自测了吗？
没有什么比自测更可靠。每一个单测，都是一份保障。多跑一个单测，就多一分把握。
自测绝对是对付问题性价比最高的一种方式。所以，他应该排在首位。
自问二：Review了吗？
Revive 又分为 自Revive 与 他人Review, 如自测一样，自Review 的作用绝对高于他人Review。因为没有谁比你更懂这次你写了什么，为什么要这么写。没有谁比你更懂这三行代码和之前的四行区别不只有代码量的大小。
Review 是一种以全局的视角看待此次代码的行为，开发时沉浸在细节里，想的是为什么是这样写而不是那样写，Review 是对之前
细节的总体把握与检验。
自问三：发布顺序有影响吗？接口先后兼容吗？
如果有系统依赖，双方都要上线，那么发布先后顺序有没有依赖？
如果是同一个接口，接口前后逻辑兼容吗？
本次上线是否会影响旧的逻辑？
自问四：灰度发布有影响吗？
灰度发布时降低问题影响率的有效手段。但是灰度也有自身的负面效果，或者说怎样控制这种负面效果的发生。
比如之前遇到过的情况，同学A迁移数据需要双读双写，更新操作是通过单机任务发生的，写是全机器发生，怎样上线才能控制到不会产生双
数据源的不一致情形？灰度发布时应该是怎样的发布策略？
自问五：有问题怎么办？
真的产生了问题，有没有比回滚更优雅的方式？比如加个开关逻辑。
如果有问题，是否会影响数据？如果影响了，有没有快速修复方案？
上线后怎么验证效果是否是预期的？什么情况下需要切回旧逻辑？
自问六：有监控吗？有复盘吗？
监控与复盘是预期效果与真正效果的对比，没有监控自然就没法知道效果，没有复盘自然就没有对比。
关键位置有打点吗？效果符合预期吗？不符合问题出在哪了？
荣誉感
这个怎么描述都感觉太虚了。但是我认为这绝对是最厚重的保障。