五环小胖子的博客

代码上线的一些思考

2016-07-09
Ryan

前提概要

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

先说分支

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, 方便以后的查看和后来的人接手。
  • 解决任何问题都要有一个时间点,要有关键节点的时间点!

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

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


上一篇 SSO设计与实现

下一篇 2016云南行

Outline