互联网生产问题分类

最近参加面试,被产研大佬问到了一个以前自己并没有深入总结思考过的问题,如题[互联网生产问题分类],自己临场发挥,结合自己的工作经历说出来了若干场景,面试结束后,自己开始反思大佬问这个问题的出发点,嗯~,大佬已经在系统性思考问题了,不亏是大佬&高手。

首先感谢网友文章[互联网生产环境问题规避与排查]的启发,接下来结合自己的工作经历再继续发散、总结。

导致生产问题原因及解决列表

1、产品同学需求对接问题[接口、字段使用场景不对]

答:这类问题主要出现在新业务开展上,避免的办法就是需求宣讲、概设、详设阶段多跟产品确认、二次确认、再确认,因为有些情况下,由于业务压力大,开发周期短,很多需求做的并不够详细,如果在评审期间发现了若干不清晰不明确的地方,一定要追着产品同学把不清晰的地方梳理清除,不可得过且过,否则越晚发现问题,修复的成本就越高。

2、产品同学对接上游解决方案时不符合业界通用解决方案进而导致的下游系统过于复杂,导致生产问题的情况。

答:这类问题大都比较隐蔽,或上游不愿意配合改动新增支撑性联动功能开发,针对工作中遇到的这类问题,一定不能妥协,否则后患无穷,一定要据理力争,坚持自己团队的底线。站在一个整体全局的角度,考虑系统设计,不能因兄弟团队的种种客观理由,自己就默默承接不合理的需求,既不利于系统的维护,也不利于自己团队的后续设计与开发。

3、概设、详设阶段需求频繁变更导致设计反复修改,进而导致后续开发阶段出现[漏洞]

答:严格把控需求变更,尤其是已经在概设和详设后续阶段的时候,因事物发展的连贯性,很多时候都是一环套一环的,可能概设阶段考虑的很全面,但是一个需求变更或者方案变更,就会打乱很多原本默认的设计基础,进而撼动整个设计方案,如果草草修改,到了后续测试、上线等环节,就有可能出现各种考虑不周全的场景。

4、设计阶段[库表索引、联合唯一主键、接口幂等设计、缓存生效失效、内部消峰队列]

答:设计一定要基于业务特点保证数据准确、灵活运维、系统稳定,良好的设计习惯,与产品需求业务充分讨论后的设计方案,考虑到业务特点、数据量等细节的设计原则,都是避免生产出现问题的基础,对于新老业务重构,初始化数据、数据清洗、数据迁移等一定要考虑,并做好测试环境的充分测试,否则就会在发版期间手忙脚乱,甚至导致发版失败。

5、编码阶段[非空判断、类型转换、异常捕获、字段传值、常量定义]

答:编码阶段要严格安装编码规范来写,不要随意硬编码、不加设计的扩展老业务接口,久而久之代码的可维护性就会大大下降,进而为后续发生生产问题埋下大量隐患。

6、测试阶段[单元测试、功能测试、集成测试、回归测试]

答:自测是必须要做的,方便后续生产发现问题,及时复现。其他测试都需要充分评估测试案例的覆盖度和有效性,避免漏测和走过场测试,测试同学发现的任何可以现象都要细心分析。

7、sonar代码检测

答:sonar检测出来的问题一定要及时修复并通知测试复测。

8、上下发布

答:接口权限、初始化数据、sql脚本等各类部署物一定要全面实施完毕。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值