一、日常问题

1)页面卡死

  QA 将一个页面放在客户端中访问,进行功能测试的时候,发现运行在 iOS 16.7 系统中时,网页会卡死。

  将页面地址复制到 Safari 浏览器中,访问也会卡死。而据 QA 描述,测试环境没有问题,其他 iOS 版本的系统以及安卓手机也没有问题。

  有问题的手机,其测试和线上的客户端版本都是相同的,初步断定和 iOS 系统有关。

  摇上 iOS 的人,让他们帮忙调试,发现卡在接口通信,接口通信中的响应一直在 loading,没有显示。

  让客户端排查,他们什么头绪也没有,说可能页面渲染被阻塞了。

  将接口换个路径,响应内容相同,但依然会被卡死。以为是接口请求时机的问题,那就加个延迟,依然有问题。

  将接口响应置空,这时,页面不会卡死,看来与响应内容有关。

  接下来将响应内容中的数组只返回一个,页面仍然不会卡死,尝试二分查找的思路,再返回 10 个,依旧正常,返回 15 个,出现卡死。

  那看来问题出在这 5 条记录中,一个一个排查,发现一个 emoji 的蘑菇表情会让页面异常,过滤后就正常了。

  又去摇客户端的人,他们排查半天也没发现问题,因为不是所有的 emoji 表情都异常,目前就一个,也找不出规律。

  此时,一名客户端的人说用相同系统的手机访问管理后台,可以正常显示这个表情,活动页面和后台的区别就是用了不同的框架。

  前者是 React 后者是 Vue,既然如此,那就查一下这个表情在 Vue 中输出的写法。

  使用的是模板语法,将其替换成 v-html 的写法后,一切恢复了正常,特地查了这个属性的原理。

  它会将变量内容赋给元素的 innerHTML 属性,而模板语法会经过很多复杂步骤,可能是某一步操作发生了死循环导致了卡死。

  遇到此类难以马上解决的问题,需要抽丝剥茧的分析自己获取到的线索,然后一步一步推导,最后得出结论,这有点像探案推理。

  总结上述这套过程就是寻线索,找差异,缩范围,给结论,如此递归反复,直到解决问题为止。

2)协作问题

  我们组的重点是活动和管理后台,版本涉及的都是比较边缘的需求,有时候都没有直接需求。

  最近就遇到,QA 在测版本需求时,临时找我们修改 BUG,这让我们很被动,安排的计划也被打乱了。

  剖析了下这个问题,发现来源于两个方面。第一是产品在设计文档时,缺失了我们要修改的那部分业务。

  但是人总归有盲区,漏掉点需求很正常。第二是技术评审不够详细,现在的评审流于形式,其他组我也控制不了。

  目前就是比较粗的过,然后经常在开发时,遇到问题再和产品测试等人讨论,这个流程目前破不了。

  想来想去,想到了 QA,是他们告诉我们有 BUG,那只需要求他们在设计测试用例时,涉及到我们这块的,就提前通知。

  即使在版本中,我们没有要修改的需求,也要同步给我们,这样就不至于在测试过程中那么被动,被赶着改 BUG。

  最近在做一个 Electron 客户端的项目,也遇到了两个协作问题。第一个就是协作团队的文档缺失,让我们吃了不少苦头。

  我们的任务是将客户端的一个功能,搬到 Electron 项目中,但是在开发过程中,没有技术文档,遇到问题只能口头讨论,很费时间。

  第二个就是第三方服务文档缺失,虽然他们会提供示例,但是每次都要过一点时间才能给到,无法第一时间拿到。

  这就会延缓我们的开发进度,很多时候只能干等。总结下来,就是不同团队的技术文档缺失影响了我们的开发。

  这也提醒我们自己组,技术文档要补充完善,以免影响他人。

二、工作优化

1)缺失的性能测试

  最近上了一个大活动,其中会调用服务端的一个内部接口,这个接口是这次活动新写的。

  刚上线的时候,发现了少量的慢响应,当时并没在意。正好赶上双休日,这两天慢响应一下子就上升了。

  周末在家排查,发现是服务端的那个新接口问题,但想到页面还能打开,只是响应慢点,也就没有组织人力去修复了。

  毕竟周末时间找人也比较困难,就这么拖到周一,他埋了日志,周二才做了一版修复,上线。

  结果周三零点,整个活动页面的接口都超时,被电话打醒,赶紧排查,马上摇人服务端。

  他说有个服务一直在告警,那你们居然没点反应,我真是醉了,运维我也摇了,过了半小时才来。

  他说那个服务的 CPU 一直居高不下,服务端也没找出问题,还是我点醒他重启下服务,才恢复,额。

  这么一折腾,运营都要跳起来了,在群里狂抱怨,我也很无奈。

  其实我这边的日志显示从周二的 21 点开始,慢响应持续上升,我也大意了。

  改了接口居然没关注,以为一切顺利,其实不然,今晚的日志一定要仔细关注了。

  服务器的配置也会让运维升级,其实这个接口也是让 QA 测试过的,并没有功能问题。

  但是却存在严重的性能问题,QA 之前自己也说以后得增加这块,这次的问题是三方都有责任,既有客观也有主观原因。

  公司在经历裁员之后,服务端有经验的员工都离职了,这个留下的小伙来了才 1 年,模块也刚接手,开发经验也缺乏。

  以后得完善测试流程,以及自己要多留心眼,就好像常说的不要完全信任用户的输入,协作时也有这点意思。

2)OKR

  公司要求我们每个双月要制订自己的 OKR,然后还要对齐上级的 OKR。

  我对齐了上级的双月高等级业务需求,不过我总觉得这个并不算 OKR,因为这些都是我们本月排进日程的任务。

  第二个 O 是质量相关,将线上因代码问题导致的高等级 BUG 或事故降低至 0,之前写的 KR 不够具体,无法明确 KR 与 O 之间的联系。

  那么这次又修改了一下,分析以往发生重大线上事故的原因,发现很多时候是因为慢 SQL 和数据库表太大撑满了整个数据库的容量。

  由此就马上将其作为一个 KR,组织排查与优化,保持数据库健康。还真找到不少潜在问题,例如已没有记录的一张表,还占用 29.12GB 容量,立刻释放掉。

  然后通过下面的 SQL 语句找到排名靠前的数据库表,清理不再需要的数据库表。

select
        table_schema as '数据库',
        table_name as '表名',
        table_rows as '记录数',
        truncate(data_length/1024/1024, 2) as '数据容量(MB)',
        truncate(index_length/1024/1024, 2) as '索引容量(MB)'
from information_schema.tables
where table_schema='backend'
order by data_length desc, index_length desc;

  另一个在使用的数据库是 MongoDB,用代码列出容量占用比较高的集合,发现可以释放掉 100G,每个月能减少 50 元的费用。

  第二个 KR 是定期 Code Review,包含细节、安全、边界等内容,保障代码健壮性。Code Review 在执行时,安全性往往会被忽略,仅仅是复查逻辑的合理性是不够的。

  还有些细节也应该放上台面,隔壁组服务端前段时间出现了非常严重的线上紧急 BUG,发生在 2 月 29 日那天,他们有段计算年龄的代码。

  会将当天推算到 18 年前的当天,但是 18 年前的 2 月没有 29 号,导致计算异常发生了 BUG。但其实算年龄,完全不必如此计算,若在 Code Review 中就将此问题抛出。

  那么就不会发生此类线上问题,关键发生在凌晨,都很难及时修正。

  对三个 KR 分析飞书告警,修复会对业务造成影响的潜在问题。我们会将线上的页面错误和接口错误实时通过飞书发出告警。

  这些告警可能不是最为紧急严重的,可能就是偶尔发生的,但是将它们修复,有助于避免潜在的风险。

 

 posted on 2024-04-22 10:19  咖啡机(K.F.J)  阅读(888)  评论(0编辑  收藏  举报