目前是把一个初上线的子系统别人做好给我维护

提问

目前是把一个初上线的子系统别人做好给我维护

回答

那这其实是实习里最好的起点之一，比“参与大项目”强。别人做过、已经上线、现在归你维护，意味着你手上有一个真实系统，有日志、有用户、有历史包袱，而且没有人跟你抢。

关键是要把“维护”翻译成有产出的东西。维护本身不算产出，维护时发现的问题和沉淀的方法才是。

先做三件事，第一周就能做完。

第一，把系统的“体检表”列出来。它跑在几台机器、哪些接口被调用、哪些任务定时跑、错误日志长什么样、慢在哪。很多人维护半年都不知道自己系统有几个定时任务。你把它画成一张图或一张表，这就是第一份产出，而且可以直接给 mentor 看，说“我梳理了一遍，有个定时任务好像没人知道是谁加的”。

第二，装监控和告警。如果它还没有像样的可观测性，你就去接上：接口耗时、错误率、关键任务的成败。这件事没人愿意做，但做完之后全组都要看你的面板。你之前在 Issue RAG 那边摸过链路，这块上手不慢。有了数据，后面所有“优化”才有依据，否则你只有体感。

第三，攒 badcase 和事故记录。每次出问题，记下时间、现象、根因、修复、怎么防复发，做成一个文档。三个月后这份东西就是你的判断力证据，也是最容易在面试里讲的东西——“我维护的这个系统出过 N 次问题，我把它们归成三类，第三类是设计层面的，我提了改法”。

然后从中赚出“优化”。维护者天然拥有别人没有的东西：真实调用数据。挑一个指标，比如某个接口 P99 高、某次查询慢、某类报错多，做一次定位加改进，量化前后对比：从 800ms 到 120ms，报错从每天 40 次到 3 次。这种数字在简历上比“参与 XX 大项目”有说服力得多。

再往上，是把“别人做的”接手成“你的”。通读一遍代码和设计文档，找三五个你解释不清的地方，去问当初写的人，然后补成文档。补文档这件事成本低、可见度高，而且逼你真正理解系统。等你成了组里唯一能解释这块的人，下一件核心事自然就落到你头上了。

要注意的坑有两个。一是别当纯粹的人肉值班，只接报障、只点重跑，那就真成了打杂。二是别急着大改别人写的东西，先观察两周，很多“看着不合理”的地方背后有历史原因，改之前先问清楚。

你这子系统是干什么的、什么技术栈、现在有没有监控？说一下我可以给更具体的切入点。