一、日常问题
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 分析飞书告警，修复会对业务造成影响的潜在问题。我们会将线上的页面错误和接口错误实时通过飞书发出告警。
这些告警可能不是最为紧急严重的，可能就是偶尔发生的，但是将它们修复，有助于避免潜在的风险。