后端简历怎么写系统规模和故障处理证据

后端招聘公告要确认你在哪个流量级别管理过哪些指标,规模要写成吞吐量、数据量和延迟百分位这类可测量的单位,故障经历要按检测、缓解、恢复、预防四个阶段来写。把这些语句和目标公告的要求逐条对照,才能决定哪段经历放在最前面。

我们在 refresh.cv 上做的事情,是把一份招聘公告拆成要求和 ATS 关键词,再检查这些关键词是否出现在简历的表述和真实经验证据里。后端简历最常卡住的地方,不是技术栈罗列不够,而是缺少描述规模和故障的单位。定好单位之后,同一段经历也可以为不同公告写出不同版本的简历。

规模要写成数字,不要写成形容词

"大流量""高并发""稳定的服务"都是无法验证的说法。运维可靠性领域早就有一套通用单位。Google SRE Book 把请求延迟列为核心服务水平指标(SLI),并把错误率(占总请求的比例)和吞吐量(每秒请求数)作为常用的补充指标。

简历里能写进一句话的规模单位大致如下表:

很多简历只写平均响应时间。同一本 Google SRE Book 的监控章节 指出,用百分位数可以看到分布的形状,第 99 或第 99.9 百分位反映的是接近最坏情况的真实体验。书中的例子更直接:一个平均延迟 100ms 的网络服务,仍可能有 1% 的请求耗时 5 秒,某个后端的 p99 有时正好等于前端看到的中位数。面试官追问 p99 的原因就在这里,手上有数字的人不如一开始就用百分位来写。

不知道具体数字时不要编。只写内部仪表盘能查到的值,查不到就换成区间或架构描述。"4 个分片、2 个副本"这类结构描述,同样能证明规模。

故障经历拆成四个阶段

把故障经历写成"解决了一次服务故障"留不下任何可判断的信息。借用事故复盘的标准格式,四个空格自然就能填满。Google SRE Book 的事后总结章节 把"无责事后总结"定义为查明导致事故的原因,而不指向具体某个人或某个团队。简历里也需要同样的态度,把原因归到组织或前任身上的句子,证明不了任何技术判断力。

四个空格这样填:

1. 检测:怎么发现的。是告警规则、指标异常,还是客户反馈,写清楚渠道。
2. 缓解:先降低用户影响的措施,例如回滚、限流、绕过缓存。
3. 恢复:根本原因和修复方法,例如连接池耗尽、索引缺失、重试风暴等具体原因。
4. 预防:后续改动了什么,例如告警阈值、压测流程、熔断器、运维手册整理。

四项里最常空着的是预防。补上这一句,才能把经历过故障的人和故障之后改变了系统的人区分开来。

公告里真正扫描的可靠性术语

后端公告里和运维相关的要求,常常用的是行业通用词汇。DORA 把软件交付表现定义为部署频率、变更前置时间、变更失败率、故障恢复时间这几项指标,这些词就藏在公告里"故障处理""发布稳定性""SLO 运维"这类句子背后。

所以简历表述需要对齐公告的用词。同一段经历,公告要求"基于 SLO/SLI 的运维"时,就把延迟目标和统计窗口一起写;公告要求"发布稳定性"时,就把回滚流程和故障恢复时间放在前面。公告里没出现的术语,不必硬凑,反而在核实环节容易站不住。

同一段经历,按公告分成三类整理

我们建议的顺序是:先贴一份公告,提取要求和 ATS 关键词,再把简历现有表述和真实经验证据分成三类。

• 关键词和经验证据都有的部分:把句子改成公告用词,放到最前面。例如把"提升了消息处理吞吐量"改成公告用词"降低事件管道延迟(以 p99 为准)"。
• 有经验证据但缺关键词的部分:只换表述。"凌晨值班处理过故障"这类经历,写成"on-call 轮值和一线故障排查(triage)经验",同一个事实就变得可检索。
• 关键词和经验证据都没有的部分:留空。把没做过的 Kafka 运维或不存在的恢复时间填进去,即使通过简历筛选,也过不了技术面试。

在 refresh.cv 上,这个对照过程是先输入招聘公告,再和简历比对完成的。简历本身的质量评分(具体性、成果、表述、语法)和某份公告的关键词匹配度是两个不同的结果:分数高不代表匹配某份具体公告,反过来也一样。这两个结果都不等于录用概率,也不是某家公司真实 ATS 系统的判定结果。

Free 方案每月提供 5 次 AI 撰写修改和 5 次简历评分分析,按公告定制修改与 ATS 关键词分析改进建议包含在 Pro 方案($14.99/月) 里。如果近期要投的公告只有三四个,先在免费额度内验证一遍方法,再决定是否升级,是比较合理的顺序。

如果还想先确认工具本身值不值得用,可以参考《AI简历工具怎么选?6款产品按经验证据对照标准评测》。

FAQ

内部指标可以直接写进对外简历吗?

如果绝对值敏感,可以换成能公开的量级。把"日入库 1.2TB"换成"TB 级日入库量",把"4200 RPS"换成"数千级 RPS",保留数量级,规模的信息量基本不会丢。也可以只写改善的比例,不写绝对值。

没有主导解决故障,只是参与过,该怎么写?

如实写自己的角色。日志收集和时间线整理、复现测试、事后记录撰写,把负责的具体范围写清楚更稳妥。查明原因这类记录工作本身,也算作运维经验。

应届生没有线上故障处理经验怎么办?

用压测结果和失败场景设计替代。哪怕是练习项目,用 k6 或 JMeter 测出的 RPS 和 p95 延迟,以及超时和重试策略的设定依据,写出来同样能证明你能用指标说话。

简历和更详细的经历描述里可以写重复内容吗?

简历放带指标的一句话总结,更详细的经历描述里再展开检测到预防的四个阶段。同一件事,篇幅和深度分开处理。

选一份具体的招聘公告,按上面这三类对照自己的简历。可以直接在 refresh.cv 上开始。