https://jiajia.fun/qa/7effa0f7-%E7%9B%AE%E5%89%8D%E6%98%AF%E6%8A%8A%E4%B8%80%E4%B8%AA%E5%88%9D%E4%B8%8A%E7%BA%BF%E7%9A%84%E5%AD%90%E7%B3%BB%E7%BB%9F%E5%88%AB%E4%BA%BA%E5%81%9A%E5%A5%BD%E7%BB%99%E6%88%91%E7%BB%B4%E6%8A%A4

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

回复 群友 716： 那这其实是实习里最好的起点之一，比“参与大项目”强。别人做过、已经上线、现在归你维护，意味着你手上有一个真实系统，有日志、有用户、有历史包袱，而且没有人跟你抢。 关键是要把“维护”翻译成有产出的东西。维护本身不算产出，维护时发现的问题和沉淀的方法才是。 先做三件事，第一周就能做完。 第一，把系统的“体检表”列出来。它跑在几台机器、哪些接口被调用、哪些任务定时跑、错误日志长什么样、慢在哪。很多人维护半年都不知道自己系统有几个定时任务。你把它画成一张图或一张表，这就是第一份产出，而且可以直接给 mentor 看，说“我梳理了一遍，有个定时任务好像没人知道是谁加的”。 第二，装监控和告警。如果它还没有像样的可观测性，你就去接上：接口耗时、错误率、关键任务的成败。这件事没人愿意做，但做完之后全组都要看你的面板。你之前在 Issue RAG 那边摸过链路，这块上手不慢。有了数据，后面所有“优化”才有依据，否则你只有体感。 第三，攒 badcase 和事故记录。每次出问题，记下时间、现象、根因、修复、怎么防复发，做成一个文档。三个月后这份东西就是你的判断力证据，也是最容易在面试里讲的东西——“我维护的这个系统出过 N 次问题，我把它们归成三类，第三类是设计层面的，我提了改法”。 然后从中赚出“优化”。维护者天然拥有别人没有的东西：真实调用数据。挑一个指标，比如某个接口 P99 高、某次查询慢、某类报错多，做一次定位加改进，量化前后对比：从 800ms 到 120ms，报错从每天 40 次到 3 次。这种数字在简历上比“参与 XX 大项目”有说服力得多。 再往上，是把“别人做的”接手成“你的”。通读一遍代码和设计文档，找三五个你解释不清的地方，去问当初写的人，然后补成文档。补文档这件事成本低、可见度高，而且逼你真正理解系统。等你成了组里唯一能解释这块的人，下一件核心事自然就落到你头上了。 要注意的坑有两个。一是别当纯粹的人肉值班，只接报障、只点重跑，那就真成了打杂。二是别急着大改别人写的东西，先观察两周，很多“看着不合理”的地方背后有历史原因，改之前先问清楚。 你这子系统是干什么的、什么技术栈、现在有没有监控？说一下我可以给更具体的切入点。