工作总结

时间:2026-03-29 作者:工作汇报网

[实用]按照信息技术培训个人总结。

这次培训报名的时候，我其实没抱太大期望。干我们这行的，听过太多“架构师讲方法论”的课，台上讲得天花乱坠，回去一写代码还是该崩崩。但这次不一样，三天下来笔记本记了半本，都是能直接落地的玩意。我挑几个让我印象最深的点，说说我怎么用的，以及用完之后系统到底怎么样了。

先说那个批处理的事。我们有个对账任务，每天凌晨跑，处理几十万条订单。之前一直好好的，四十来分钟跑完。从上个月开始，慢慢拖到一个半小时，前天直接干到两小时十五分，眼看就要影响早晨的业务高峰。我一开始按老套路排查：先看数据库，慢查询日志翻了个遍，索引该建的都建了；再看网络，也没抖动；又把服务器CPU、内存、磁盘IO扫了一圈，都正常。说实话，那两天我有点毛了，领导每天早会问一嘴，脸上挂不住。

培训第二天讲性能剖析，老师演示了arthas的trace命令怎么抓方法耗时。晚上回去我就用在生产灰度环境上跑了一把。命令敲下去，等了几秒，火焰图出来，我盯着看了一分钟，差点骂自己傻——耗时的根本不是数据库，是一行日志打印：log.info(“处理结果：” + JSONObject.toJSONString(bigObject))。这个bigObject里嵌套了十几层，每次循环都序列化一次，数据量上来之后，序列化开销直接爆炸。

改法很简单：把日志级别从INFO改成DEBUG，再套一个if(log.isDebugEnabled())。上线之后，批处理缩到了四十五分钟。就一行日志的事，折腾了我两天。这事给我的教训是：别猜，用工具看。你觉得是A，往往是B。

再说一个线上故障。那天下午发版，半小时后监控跳黄，订单接口成功率从99.99%掉到99.2%。别看只掉了不到一个点，每秒就有几十单失败。我第一反应是自己代码有问题，赶紧回滚，但回滚之后故障还在。那就不是我的事了。拉网关日志一看，是一个供应商的回调接口大面积超时。对方服务挂了，但我们的代码还在傻乎乎地重试，每次重试等三秒，三秒超时再重试，三次之后才失败。相当于每个失败请求堵了九秒，把线程池全拖满了。

当时我在群里吼了一句“供应商挂了，先熔断”，然后手写了三段代码：设置超时两秒、重试一次且退避策略、失败后直接落失败表异步补偿。十分钟后紧急上线，成功率回到99.98%。事后我写了篇复盘，不是流水账，是把“外部依赖故障的标准处理流程”固化下来：所有同步调用必须配超时、重试（带退避）、熔断，缺一不可。这成了我们模块的硬性验收标准。

还有一个例子特别丢人，但我觉得值得说。上个月有个慢查询，SQL很简单：select * from order where order_no = ?，order_no字段建了唯一索引，但查询就是慢，走了全表扫描。我折腾了一下午，加hint、重建索引、分析统计信息，都没用。最后同事过来看了一眼，说“order_no字段类型是varchar，你传的参数是不是数字？”我一看代码，传的是Long类型。MySQL隐式转换把索引干掉了。改成一圈引号，瞬间毫秒级。

这种低级错误，培训里不会讲，但实际工作中比比皆是。我现在给自己定了个规矩：每次写完SQL，先把参数类型和字段类型对一遍。 gsi8.CoM

培训里还有一个概念我觉得特别实用，叫“架构腐化”。代码刚写出来的时候都是清爽的，经过十几个人、几十次修改，慢慢就成了一坨。说白了就是欠的技术债。我的做法是，把代码维护当成设备保养，不能等坏了再修。我在CI流水线里加了几条自定义规则：循环里不能调RPC、BigDecimal不能用double构造器、所有对外接口必须有TraceID。每周跑一次静态扫描，看到“坏味道”就顺手清掉。上个月清了一个数据库连接没关闭的bug，藏在一个异常分支里，要不是扫出来，上线两周连接池就得爆。

下一步我给自己定了三个具体目标，不玩虚的。

工作汇报网黑话解析: