〔标准〕疫情防控排查工作总结。
那是一个三十四度的下午，机房空调又报故障，服务器风扇嘶吼着，监控大屏上三台应用服务器的CPU全红了。我蹲在机柜前面，手背贴在机箱上烫得缩回来——重启刚过半小时，又卡死了。街道办电话追过来，问下午三点的报表什么时候能出，社区那边一百多条新排查的数据还没录进去。
当时我们这套排查系统是春节后突击上线的，只想着赶紧能把纸质的表变成电子档，根本没考虑并发。每天两个高峰：早上八点到十点，社工入户回来集中录入；下午两点到四点，街道和社区核对数据、补录遗漏。两个波峰一叠，数据库连接池直接打满，后面的人只能干等着转圈。更头疼的是市里每天下发的重点人员名单，格式五花八门，身份证号有带X小写的，有带空格的，电话号码有86开头也有加横杠的。我们三个人手工清洗，每天耗三个小时，还经常漏掉重复数据。
第一个改动是从格式标准下刀。我跟市里对接的同事商量，能不能统一下发格式，答复是各区县系统不一样，没法改。那就自己消化。我在前置机上写了个清洗服务，每天凌晨自动拉取名单，把身份证统一转大写、去空格，电话只保留数字。反过来，我们自己的录入页面也做了限制，身份证最后一位强制大写，电话分段显示，输错格式当场弹提示。上线第一天，数据合并时间就从三小时掉到五十分钟。那个月手底下两个实习生不用再熬夜盯清洗了，能早点回去。
但数据库撑不住的问题还在。周末全员核酸演练，同时在线录入人数冲到两千，系统直接瘫了半小时。事后查日志，全是写操作锁表。我翻了三天的慢查询日志，发现90%的查询是统计报表，只有10%是真正的填表。那就读写分离——填表走主库，查询走从库，主从之间用消息队列异步同步。第一版部署完，第二天早高峰，有个社工打电话说，我刚填完老张家的信息，回头查怎么没有？我才反应过来，主从同步有延迟，查从库读到的是旧数据。后来加了个策略：刚写完主库五分钟内的查询，强制走主库读；超过五分钟的才走从库。延迟投诉再没出现过。
离线缓存那部分是真被逼出来的。有次去虹桥社区培训，那个社区在地下室，手机信号一格都不到。社工把数据记在纸上，出来再重新敲，一天多敲三小时。回来之后我拉着前端同事做了个本地缓存模块：入户时数据先存在浏览器IndexedDB里，有网的时候自动往后台推。但多设备同时录入同一个人怎么办？我们在每条记录里加了设备ID和更新时间戳，后台发现冲突时，以时间戳最新的为准，并在第二天生成冲突报告让社区核对。这个机制到现在用了四个月，总共发现三十几条冲突，都在可接受范围。
和人打交道才是最磨人的。自助解锁功能上线前，每天半夜有社工打电话说账号锁了，等第二天管理员上班才能解。我们加了手机验证码自助解锁，结果第一周，有个五十多岁的老周还是天天打电话。后来发现他不是不会用，是记不住密码，每次试错三次就锁。我们干脆加了个人脸登录，用手机前置摄像头一扫就能进。老周后来见到我，拍了肩膀说，你们那玩意儿总算不欺负老头了。
记得项目冲刺那周，周五晚上十一点，系统报警磁盘快满了。我远程连上去一看，日志文件一天就写了20G——某个查询没加索引，全表扫描了上百万条数据。临时加索引，清日志，搞到凌晨两点。第二天复盘，发现是上周更新版本时，有个索引被误删了。从那以后，我们每次上线前多了一道工序：用自动化脚本比对生产库和测试库的表结构，索引、字段类型必须完全一致才能发版。
-
工作总结之家（dG15.COm）PC端置顶专题:
- 常态开展疫情防控排查工作总结 | 疫情防控 | 新冠肺炎疫情防控工作排查表 | 疫情防控工作 | 疫情防控排查工作总结 | 疫情防控排查工作总结
那周之后，那个社工再没打过电话。后来我想，技术这东西，说到底就是别给人添乱。你让它跑快点，它就跑快点；你让它少出错，它就少出错。能让人觉得这系统“还挺好用”的时候，它就成功了。
现在这套系统还撑着全区的排查任务，日均处理数据两万多条，最近一次区域核酸，一小时峰值两万七千人录入，CPU稳定在30%。复盘会上一圈人问怎么做到的，我说没别的，就是一点点抠细节，哪卡了通哪，哪烦了改哪。干技术的，不就是干这个的么。
-
欲了解工作总结网的更多内容，可以访问：工作总结
