填坑那些事

人的成长的过程其实就是填坑的过程,技术如此,管理如此,生活也如此。十多年来作为团队首席填坑官,在此分享些技术方面的填坑经验。

指导思想 - 相信科学

  • 有时候会有些不好重现或者比较意外的问题出现,请减少无意义的解释说明,相信科学,抓紧时间收集信息、分析问题,这种情况往往是真的有问题,而且有时候是一些非常低级的错误。对于填坑人员来说,需要牢记墨菲定律:
    1. 任何事都没有表面看起来那么简单;
    2. 所有的事都会比你预计的时间长;
    3. 会出错的事总会出错;
    4. 如果你担心某种情况发生,那么它就更有可能发生。

发现问题

  • 问题一般来源于监控报警、客服反馈等,为减少损失和尽量在用户反馈之前发现问题,除传统的系统环境监控报警外,通过日志分析进行业务监控报警是很有必要的。

定位问题

  • 常用方法有排除法、分治法、对称法、替代法等,逐步缩小范围,对系统各模块的边界及关键节点要事先了解。
  • 日志是定位常规问题比较快的方法,因此需要有日志规范,以Java为例:要求使用自定义异常;对于关键路径或节点需要记录日志,通过记录TraceID、SpanID能做到全链路跟踪;如果是分布式系统,需要搭建类似ELK这样的集中分析平台。
  • 网络问题抓包分析会比较快,特别是涉及第三方调用时。
  • 性能问题是比较复杂的,一般需要对调用链上各节点逐个排查来找到性能瓶颈。

  • 在混乱中找到线索犹如在大海中发现灯塔一样令人开心。

解决问题

  • 问题定位到以后就是解决了,这时候需要全盘考虑优先级和影响范围,不能改出新问题来,解决问题怕的是代码盘根错节,很容易拔出萝卜带出泥,此时模块化(不一定要微服务)的优势就显现出来了。
  • 功能模块设计时可以加上一些开关,一旦有问题可以及时止损。
  • 尽量考虑扩展而不是替换,修复后跑一遍单元测试和自动化测试。

事后复盘

  • 团队需要规范化的管理,事后需要组织团队对问题进行复盘并记录到知识库,避免类似问题再次出现。

未雨绸缪

  • 预防问题出现其实比解决问题更重要,但问题少了碰到有些老板会觉得技术人员没事干,这就尴尬了。
  • 规则越严谨,效率可能更高。
  • 对团队的要求-职业度
    1. 态度 遵守设计和操作规范,少挖坑
    2. 责任心 挖坑要填坑
    3. 团队精神 队友挖的坑也要帮忙填
  • 对团队的要求-专业度
    1. 保持学习精神 团队内外定期分享
    2. 提高PRD质量 能把产品描述清楚,为什么用户解决什么问题,所有可能的场景
    3. 提升代码质量及设计文档(类图、时序图)质量 遵守设计原则和规范,高内聚低耦合,提高单元测试覆盖度,持续重构优化代码(可参考SonarQube反馈)
    4. 提升工作效率 自动化测试、自动化运维


blog comments powered by Disqus
—  原创作品许可 — 署名-非商业性使用-禁止演绎 3.0 未本地化版本 — CC BY-NC-ND 3.0   —