实习日记

第一周：工牌还没捂热，需求已经拍脸上​

新人培训刚结束，我抱着领来的笔记本和工牌往工位走，工牌上的照片还带着点拘谨。刚到电梯口，飞书就弹出消息 ——LD 把我拉进了一个需求评审群，消息里直接 @我：“xx这是你的第一个需求，下午一起聊聊吧。”​

身后的 MT 看到这场景，笑着拍了拍我肩膀：“这速度可以啊，比预想中快多了。” 中午去食堂吃饭，他端着餐盘坐在我对面，边吃边跟我聊这个需求的细节，问了我对需求的理解和想法。那时候才反应过来，这部门的节奏，好像比想象中要快得多，连喘口气的功夫都省了。​

第二周：新服务开荒，光权限配置就够喝一壶​

这周正式开始接需求，因为是新服务，所有工作都得从零开始。光是各种权限点配置，就列了一长串清单，每个都要找不同的人审批，来来回回沟通了好几天。​

更麻烦的是下游组件接入，之前完全没接触过，不仅要搞定接入流程，还得算清楚下游的限流规则和能支撑的 QPS。每天不是在拉 oncall 沟通，就是在等沟通的路上。偏偏对接的同事在其他 base，有时差，每天能正经合作的时间没几个小时，进度卡得让人着急。​

还有因为合规问题我们没法本地调试，全靠日志来查问题，这时候我终于知道打印出一个好的日志非常的难，但是又非常的重要，如果打印太多会有很多重复的消息，排查问题耽误时间，如果打印不够仔细会导致丢失很多上下午信息，查不出问题。

第三周：一个需求刚自测完，又来一个加急的​

第一周接的需求优先级不高，自测没问题后就先放着没上线。结果刚闲下来，LD 又丢过来一个新需求，跟第一个类似，也是在新服务上做开发，但得接触新的组件。​

这个需求有强卡点，必须在周五前上线。为了赶进度，晚上天天加班。过程中遇到不少问题，只能自己一点点排查解决。那几天下班时，公司大楼的灯都暗得差不多了，才发现原来急需求的压力，比开荒时还让人上头。

忙碌三周，收获比加班时长更实在

回头看这三周，每天都像被按了快进键，从第一周手忙脚乱参加需求评审，到第二周在权限配置和跨时区协作中摸爬滚打，再到第三周独立排查问题、赶加急需求，虽然每天都感觉时间不够用，但实实在在的成长看得见。​

• 各种发布单的发布流程
• 如何高效的沟通，简洁明了的留言
• 如何预估上下游的流量，如果做好系统的保护
• 如何给自己排期，考虑到因为权限等问题导致的卡点如何去安排任务
• ..........

所以对于实习来说，什么样的部门是值得去的部门呢？

什么是实习值得去的部门？

这三周踩的坑让我想明白：实习选部门，别光看「名气大不大」，得看「敢不敢让你真上手」。

我现在的部门就是典型的「野蛮生长型」：没有现成的流程手册，甚至连前辈都在边做边摸索。但正因为这样，我才敢在第二周就去跟安全组 argue 权限范围，在第三周主动提对系统做优化，接入mq来解偶组件提高稳定性和可扩展性。

被 PM 临时改需求时，从第一周的慌到「这咋搞」，到现在会提前问「最晚变更时间是哪天？我留两天缓冲」；独自 owner 需求时，从怕「搞砸了怎么办」，到现在每天发日报时附「风险点 + 应对方案」。这些成长，可比在成熟部门里「按部就班写 CRUD」来得猛多了。

所以对实习生来说，好部门未必是「轻松稳定」的，而是那种能让你在三周里，从「怕犯错」变成「会解决错」的地方 —— 毕竟，谁实习不是想多踩点坑，好让正式工作时少摔点跤呢？#牛客AI配图神器#