第一个bug: 登陆模块的扫码登录出现遗漏一段逻辑,和正常的登录不一致导致一小部分用户利用这个漏洞做一些事情。 这个bug隐藏的优点深,是因为这个逻辑涉及到的范围非常小,不是大规模的。
这个bug是清明节放假期间的晚上9点找到的,我翻了很多遍代码发现扫码登录这一块遗漏了一小部分逻辑, 问题的起因是有用户发现登录失败,问题开始上报到客服,客服上报到研发,然后解决问题。 首先可以肯定的一点是用户体验是绝对有问题的,理论上用户在登录失败的时候就应该知道问题出在哪里了,至少用户收到的不应该是失败这种消息 因为当用户收到 失败 这种结果第一想法必然会是你的程序有问题。 再者问题是,这种bug真要去测试的话,是百分百重现的,问题的关键是居然没有产品知道这段逻辑,因为问题爆发的时候并没有传达到产品经理,也没有相应的产品人员作出回应 所以这就直接把问题抛到了开发。 我觉得研发人员作为编码人员应该是解决问题的最后一道防线,如果这种问题大量的直接抛到研发,那可以说明的是第一,逻辑不清晰过于复杂,第二,用户体验极差,第三,产品经理不作为或者不熟悉业务。 这个问题值得思考,一个需求下来是不是做完了就完事了,研发编码完毕,测试通过,产品试用下没问题,生产上线,然后就进入下一个流水线重复开头的动作。 我觉得一个团队一起去做一个应用,研发本身要对业务熟悉,同时产品经理也应该是熟悉业务的,也应该全程跟踪这个过程,体验,后续负责,而不应该是为了做这个需求而做这个需求,做完了就完事了。 如果仅仅是做完了需求就完事了这就太可怕了,铁打的营盘流水的兵,谁还会记得做过什么,有过什么呢?这样做出来的应用没有灵魂,生硬,毫无体验可言。
第二个bug:分布式锁的问题
这个是放假前一天的晚上发现的分布式锁的一个问题,在某后台系统的修改配置的接口出现了一段分布式锁的代码, 这段代码是利用redis来实现的分布式锁,但是这把锁有一个很神奇的地方就是,没有给这把锁加上一个超时时间, 这意味着当在拿到锁的时候开始处理逻辑,在处理逻辑的过程中机器如果宕机了,这就会引发死锁。
这种bug要重现也是有点难度的,但是写分布式锁的时候理应该想到这种问题,我觉得这是很基本的。 如果有codeReview机制的话,可能也许可以避免这种问题发生,即使不能避免也可以减少这类事情发生。 这也暴露出了一个问题,技术团队本身的技术上的良莠不齐(这种问题无法避免),对于一些基本功能组件没有做相应的封装提供公共使用,遇到什么问题都是直接造轮子, 导致解决1+1=?的项目代码比老太太的裹脚布还长且臭。 当然我反对过度封装,大道至简,以至于我现在看到项目里对redisTemplate再包装一层的行为很排斥,虽然这并不一定是错的。
第三个bug:权限控制问题
a项目本来是一个后台管理系统,但是因为一些原因,开发了b系统来替代a系统。 但是遗憾的是,因为很多原因,b系统的开发完成并没有像当初理想的那样替代a系统,反而导致了a和b同时存在的局面。 a系统是个老项目,它的项目名字和它本身的功能就是雷锋和雷峰塔的关系,以至于新人都会问为啥叫xx名。 回到正题,因为a项目比较老,所以在权限控制这一块做的不够完善,可以说a项目作为一个非常重要的后台管理系统。 它的权限控制可以说形同虚设,只要复制链接或者抓取接口,什么权限都能访问,虽然只有内网才能访问,其实这是一件很恐怖的事情。 这说的只是权限控制,还有比如csrf这种漏洞是否存在也没有真正去看过(我也没去看是否存在这种漏洞,0.0),以前在做一些面向用户的应用的时候是非常注重这个的,感觉这不仅仅是对公司的产品负责或者对用户负责,这也是对自己的负责。
产生这种问题的原因是啥,我们可以细想一下,如果大家都要求高一点,要做就努力做好,节奏慢一点,多想一点,这种问题是否能避免。 现在的情况是来一个人都能搞它(这个项目)一下,没人当它是个东西,久而久之,破罐子破摔,食之无味弃之可惜,甚至有的使用者(提需求的人员)对a系统某功能在哪里都忘却了。
我一直在思考,软件研发和软件工程之间到底应该是个什么关系,在追求效率的同时,你会发现,有时速度快了,做出来的东西差了,甚至连灵魂都没有,就像一具尸体躺在哪里, 对于流水线似的开发我觉得是很恐怖的,并不是说重复做一件事情的恐怖,而是我觉得软件工程本身并不是一件流水线的事,而是一件需要精雕细琢,慢慢打磨的过程, 而软件研发应该是这打磨过程中的技术的体现,一个应用的成长过程,不应该是做完了一个功能就可以不管了做下一个功能,这种事情应该是掌舵者要有一个大的方向,大家为之去鼓足干劲。 不管是研发也好,产品经理也好,测试运维等等也罢,都不应该置身事外,只是守着自己的那一亩三分地来搞。 如果是为了规范化,也不应该把线划的太死,因为水至清则无鱼,在问题来临的时候,如果人人都做到‘不属于我的管辖范围我不管’,那么问题很可能变成一个死结,我经常看历史,抗日战争日本人打中国人,中国人又分北方人和南方人,真要打了北方,南方不管,唇亡齿寒啊,哪来的中国。一个整体在某些时候可以拆分,但是在某些时候他们理应该是一起的。
还有一个想说的就是微服务,其实对于微服务,这里的第二个bug,分布式锁,就是解决多机器部署的时候的一些问题,我们目前的很多微服务并不能称之为微服务,
微服务在我的理解是,小巧,功能规划整齐,最重要的是可以横向扩展!现在我们的应用没有做到小巧,光是启动过程就得一分钟,部署的包大小100m+。
横向扩展更是无处谈起,当你横向扩展一台机器的时候,你需要开通机器的防火墙,安全策略,数据访问权限等等,这些流程走下来,24小时能扩展一台机器就谢天谢地。如真正的流量洪峰来了,我们拿什么来扛?拿离职申请?
总而言之,这些问题都是可以解决的,脚踏实地一点,把起服务的脚本准备好,演练好,这些应该是最实在的吧,邮件能规范化,流程化,它本身没有错,但是邮件本身并不能马上解决生产问题。