工作总结

发表时间：2026-03-16

[优质]2026年投资公司技术骨干转正工作总。

半年试用期，说长不长，说短不短。转正述职是个形式，但手里的活儿骗不了人。下面几个数字，算是对这180多天的一个交代：

核心交易系统全年可用性99.99%，这个小数点后两位是硬扛下来的。三季度处理过3次突发性能瓶颈，其中两次是盘中交易量瞬间冲到峰值的CPU满载。另外，配合业务上了三个新模块，“智能对账”上线后，财务部两个人半天的人工核对变成了半小时自动跑完。关于系统卡顿或数据延迟的生产投诉，从上半年的7起降到下半年的2起——这两起还都是因为网络运营商割接，跟我们自己的代码没半毛钱关系。

数字背后，是三场硬仗，也是三次差点翻车的教训。

第一仗：给五年的老代码做“心脏搭桥”

业务部每天晨会必看的持仓分析模块，跑批时间越来越长。最开始三小时，后来四小时，最夸张的一天跑了五个半小时，直接耽误八点半的数据汇总。业务领导在会上拍桌子，我们只能低头。

常规套路都试过：加索引、扩内存、上SSD，效果撑不过两周。我带着两个核心开发蹲了两天，把跑批逻辑从头到尾捋了一遍——不看不知道，一看吓一跳。五年前的老代码，处理两亿条持仓数据用的还是嵌套游标循环，相当于用算盘算导弹轨迹。

问题找到了，但重构风险极高。这模块一天不用，业务就瞎眼。我们只能做“不停跳搭桥”：新写一套基于集合运算的批处理逻辑，在测试环境压了三天三夜，把边界条件全跑烂了。上线那天晚上，我盯着屏幕，手心冒汗。跑批开始，监控曲线从三小时的平台直接掉到四十分钟的斜坡，绿色信号亮起来的时候，旁边同事递过来一瓶水，我才发现后背湿透了。

但第二天就出幺蛾子了。有个小众产品的持仓汇总对不上，财务打电话来问。赶紧回滚查询逻辑，发现是重构时漏了一种特殊分红场景的权重算法。赶紧补丁修复，前后折腾了两小时。这事儿让我明白：再完美的重构，也得留足观察期。后来我们定了个规矩，核心模块重构后必须双轨运行一周，新旧逻辑同时跑，对账一致才能切流量。

第二仗：网关被“挤爆”的四十分钟

八月中旬，市场异动，成交量瞬间放大。下午两点十三分，监控大屏开始飙红——持仓网关的连接数直线上升，紧接着是报错，再接着是风控模块响应超时。群里消息刷屏，老板电话直接打到我手机上。

我当时在机房调试设备，手机一响就知道出事了。第一反应不是接电话，是切到跳板机，一把拉下网关对风控的强依赖开关，改成异步降级。这动作保证了即使网关挂掉，核心交易的风控底线还在。然后才回老板电话：“正在处理，预计二十分钟。”

排查过程其实挺笨的。先用top看负载，不高；再看日志，全是连接超时。最后用lsof查进程限制，才发现文件句柄数跑满了——系统默认1024，当天并发连接数冲到2000多，直接捅破窗户纸。改配置、重启服务，全程四十分钟。恢复后业务正常，但复盘时后背发凉：如果当时没第一时间切断依赖，风控模块一瘫，交易就可能被熔断，那损失就不是四十分钟能填回来的。

这件事暴露了两个漏洞：一是服务器初始化脚本里没调大文件句柄数，这是历史欠账；二是限流熔断机制只在核心链路上有，网关这种边缘服务没覆盖。后来我们把所有中间件、网关、缓存服务的初始化配置全过了一遍，新增了自动告警和限流策略。现在每次新服务上线，第一件事就是检查内核参数。

第三仗：把财务大姐的Excel“翻译”成代码

“智能对账”这个需求，最开始产品经理给的需求文档写了十几页，什么“提升效率”“优化体验”，全是虚的。我拉着他直接去找财务部负责对账的王姐，让她打开电脑，当着我们的面操作一遍。

结果发现，她每天要打开五个Excel文件，复制粘贴数据到第六个文件里，再用VLOOKUP比对差异。最费眼睛的一步，是手动标记那些对不上的账，经常看到眼花。我们问：哪一步最烦？她说：“每次复制粘贴完，还得数一数条数对不对，生怕漏了。”

这就对了。我们把她的操作拆成十几个步骤，用代码一个个实现。开发过程中，每做完一个小功能，就请她来测试环境点两下。第一次原型出来，她把界面上的按钮位置调了个个儿，说“我习惯右手点，放左边别扭”。改。第二次，她说“你们这个差异标红太刺眼，能不能改成淡黄色”。改。第三次，她试了半个小时，抬头说：“行了，这个比我那个Excel强。”

⬬读书笔记吧DsBJ1.coM深度干货: