从流程、认知上做稳定的系统演进

从需求提出到设计、研发以及线上运行和维护等是一个需求全流程的生命周期，基于个人的思考，总结和概况从研发接入到线上设计等各个流程环节中的工作推进以及质量、风险保障上的考量，最终是保质、保量、平稳有效的进行系统演进，持续输出一个稳定、安全的线上系统环境。

接口设计篇

1、设计接口文档，交付端上相对完整的接口文档，包括接口地址、调用方式（如 HTTP GET/POST/PUT/DELETE等）、传入参数数据类型和释义等、接口响应参数类型释义等，最后附加调用示例演示，示例演示更加直观（也可借助相关 API 开发工具）

2、接口文档交付后，协调端上做接口文档宣讲，与端上对接，沟通设计思路、使用场景。对于存在App历史包袱的或其他情况下，可适当适配端上实现做后端逻辑调整等支持。

3、开发中途，适当跟进端上开发情况，收集接口接入情况以及可能存在的问题，以及时解决。

4、接口变更时，对于变更部分应标明其生效版本或者引入版本。

5、重大版本设计或逻辑调整，可升级接口版本，做全新实现，避免各个版本兼容和逻辑变更造成代码混乱，也降低对历史版本的影响和风险

6、应尽量保证逻辑是约束在后端逻辑中的，保障线上各端上实现的简单性，便于逻辑统一

7、针对存在第三方依赖的功能点或者其他可能存在特定风险、需要控制的地方甚至产品特殊需求点，增加开关选项，支持端上呈现或者功能的输出控制，更灵活的控制端上业务交互，减少发版或受影响用户

研发设计篇

1、功能设计中，尤其是大的功能演进上线，做到灰度控制，可以有效避免新版本上线、系统变更等潜在的风险

灰度规则：

a、用户id尾号范围(00~99、000～999等)

b、限制特定id尾号(00、10、11、14等)

c、满足特定条件的具体用户

i、产品根据特定规则遴选配置或设定其他系统规则自动识别（如月均交易量达10笔的用户等）

ii、大数据识别（特征筛选、用户行为分析识别）

iii、地理区域等其他条件

d、特定移动端设备、设备号等

灰度实现：

a、业务系统实现逻辑切分和路由。

优势：规则灵活可控制，无需额外部署集群

缺点：是切入代码，引入新策略，还有考虑后续弃用策略下线

b、网关层面路由。

优势：对代码无切入，简单高效

不足之处：可能无法实现部分规则，只能依赖简单的特性来识别，如ip、请求参数、header头、cookie、session等，同时需要部署灰度集群作为灰度代码发布环境

实际应用中，可以网关 + 业务的方式混合使用

2、系统或需求存在的问题点、方案点应做更加充分的考虑，不要预留后续做变更的打算。

a、系统变更往往需要测试等资源配合，建议在实现时，做的更加彻底。

如果在需求实现过程中，方案一是直接对堆砌代码，方案二是思考和进行更多的设计，以“对修改关闭，对拓展开放”为准则。方案二可能在本次设计中，耗费更多的时间，做更多的考量，但是却能更好的应对未来的变更。

b、在系统稳定运行中，进行系统变更，可能造成线上问题，而线上系统稳定是首位。而人员本身存在风险厌恶性，为保持线上稳定，后续可能会较少变更，所以差的设计可能会比想象中存在的要久，也可能造成系统债务。

3、使用sonar等质量工具，辅助代码检查、优化问题排查，规范代码

4、研发过程中综合考虑异常捕获，设定对应的日志以及报警级别（执行相关补偿逻辑和修复是正常操作）

日志篇

1、系统需要在关键节点输入输出点增加必备的日志输出，以便于在问题和系统排查时，了解其执行情况

尤其对于部分逻辑算法或节点，针对同一输入在不同时期不同的历史执行情况下，会产出不同的输出。类似交易时，不同时间商品价格不同，使用同样的价格，可购买的数量是不同的。

2、日志信息应该在保证精准、有效的情况下，尽量简介，同时也要避免无意义的日志输出，防止数据干扰，也有利于日志的跨系统、跨网络消费等。

监控篇

1、硬件级别的监控。硬件级别包括cpu、内存、磁盘io、网络等监控和报警

2、业务级别监控，尤其核心业务的监控。

例如异常订单占比或异常订单产生速度等参数，可感知下单系统的异常；

验证码请求和发送比，用于感知验证码发送是否正常，否则可能影响用户系统的正常使用，如登录、支付等（验证码是用户相当敏感的操作，系统核心环节）

3、指标报警。报警要防止误报，同时又要预留适当的冗余度，以便于有足够的时间跟踪和处理问题



以上

To Be Continued...