代码上线的一些思考

• 前提概要
• 先说分支
• 上线之前的准备
• 上线中要谨慎
• 上线完毕做好善后
• 监控要做全
• 日志很重要
• 重要的事情说三遍
• 一些要养成习惯的的东东

前提概要

根据个人经验, 服务中的大多问题, 都是由于上线引起的, 自己总结了一些关于上线的一些经验, 分享给大家, 希望对你有所帮助。

先说分支

master作为上线的主干分支, 要保证稳定性和可靠性。 开发和测试建议使用develop分支, 测试通过后提交至master分支。

上线之前的准备

• 上线前做好code review

• 评估影响范围, 想清楚最重要的是什么, 是否要通知上下游对接方, 如果有依赖方, 一定要注意上线顺序。

• 是否有需要申请的资源, 如: DB, redis等。

• 服务是否需要重启, 如: nginx。

• 如果遇到错误, 要有完善的回滚方案。

上线中要谨慎

• 有预发布机制, 与QA的同学协助完成。

• 灰度发布, 多台服务器, 可先上一台机器观察线上情况, 然后50%发布, 直到100%完成整个上线。

• 个人经验, 尽量避免在晚上或者周末上线, 如果有紧急时间, 则需经过上级审批。

上线完毕做好善后

• 如遇问题, 应及时按照事先指定的回滚方案回滚。

• 对于某些故障, 要有适当的降级方案, 如: 丢弃某些请求或者写死一些value。

监控要做全

• 系统资源: cpu、内存、网卡、sockets、磁盘

• 自身稳定性: QPS、状态码、耗时

• 下游依赖: QPS，耗时，返回值

• 资源依赖: QPS，耗时！performance！

• 慢查询：slow log，php，mysql 等

日志很重要

• 请求下游/第三方服务，必须有log，记录耗时、返回值（可记录关键信息）等信息；

• 日志分级记录，fatal，error，notice，trace；

• 日志分级报警，fatal一个就需要报警，error 可能的逻辑错误等，可配置报警策略；

• 完整日志可查，notice，trace 。在不影响性能的前提下，越全越好！

• 上下游日志打通可回溯跟进。

• 日志规范简版：

  1. 发生故障会“死人”的，必须任何时候都报 fatal ，这个日志不许关闭；

  2. 发生故障需要人为跟进解决处理的，需要报 error，这个日志不许关闭；

  3. 进程重启，派单成功/失败等，与第三方交互的所有api 交互必须都加 notice ，这个日志不许关闭；
5.4 进程运行的各层controller、model、data 层等中间数据，可以加trace。线上系统稳定的时候，可以视情况关闭或抽样记录

重要的事情说三遍

线上无小事, 线上无小事, 线上无小事

• 线上bug优先级最高，要快速响应！
• 快速评估影响，并需要快速给出解决时间点！
• 线上bug 进展随时通报！快速响应，随时通报进度！
• 对服务状态了如指掌，知道发生了什么，关键的日志要完整！
• 面对问题不要害怕，早出问题总比晚出问题好！

分批上线：尽量不要一次上线大型迭代，尽量分批次上线; 注意总结：每一次事故或问题，尽量都要在wiki 上留下分析; 优化流程：如果流程不合理，一定要随时提出一起讨论

一些要养成习惯的的东东

• 需要清楚业务主流程和上下游、关键资源；直接负责人需要清楚细节！
• 有完善的wiki, 方便以后的查看和后来的人接手。
• 解决任何问题都要有一个时间点，要有关键节点的时间点！

要对自己的代码负责，像对待孩子一样，对自己服务的生命负责！

服务好别人，别人会更放心信赖你、依赖你！——决定你和团队的口碑和前途和发展。