企业官网建设流程全解析

很多人的简历上只有业务功能：做了什么模块、上了什么需求。搭流水线、补单测、配监控这些事，要么不写，要么写成一句「负责项目的 CI/CD 配置」。

这类经历值得写，但要写对。判断标准是一句话：它有没有改变团队的行为。

改变了团队行为的，值得展开

搭建 CI 流水线（GitLab CI + 自建 Runner）： 提交触发单测与静态检查，合并前强制通过； 上线后主干构建失败率从每周 5-8 次降到 1 次以内， 回滚次数由每月 3 次降为 0。

这段描述说明的是：你让团队的交付方式变了，而且有可测量的结果。

同理，补单测如果只是把覆盖率从 20% 提到 35%，意义有限；但如果你同时引入了「新增代码必须带测试」的门禁，那就是行为改变。

没有改变行为的，一行带过

按文档把监控接上、按模板配好告警、跟着规范写了测试，这类工作是必要的，但它只说明你能按要求做事。

写法上放在某段经历的最后一条，一行即可：

参与服务的可观测性接入（Prometheus 指标、日志采集、基础告警规则）

不要展开成三行，也不要写成「负责公司监控体系建设」，后者面试时会被问到体系设计，答不上来反而扣分。

三类特别值钱的

第一类，把重复劳动自动化掉的。每次发版要人工执行十几步，你写了脚本或者做了平台，把它压到一条命令。写清楚原来多久、现在多久、涉及多少人。

第二类，定位过难查问题的。加了链路追踪之后定位到一个跨服务的偶发问题，这类经历在面试里能讲很久，含金量高。

第三类，做过取舍的。比如「没有引入服务网格，因为团队规模和运维能力不匹配，改为在网关层做统一治理」，能说清为什么不做某件事，往往比做了更能体现判断力。

从零搭和在已有基础上改，价值不同

面试官会问一句：这套流水线是你从零搭的，还是在已有的上面改的？

两种都有价值，但要如实区分：

从零：团队此前无 CI，提交后靠人工跑测试。 调研并落地 GitLab CI，定义三阶段流水线（lint / test / build）， 推动 9 个仓库接入，两周完成迁移。 改进：在已有流水线基础上做提速， 将单元测试改为按模块并行 + 依赖缓存， 单次构建从 14 分钟降到 4 分钟，日均构建 60 次。

第二种看起来不如第一种「大」，但它的可信度和技术含量往往更高，在别人的系统上做优化，需要先读懂它。

写这类经历时的两个坑

一是术语堆砌。把 Jenkins、GitLab CI、ArgoCD、Helm、Prometheus、Grafana、ELK 全列上，但每个只用过一次。面试官会挑一个深问，堆得越多越危险。

二是把团队的成果写成自己的。「主导公司 DevOps 转型」这种表述，在一个二十人团队里可能是真的，在一个两百人公司里一问就露。写清楚范围：哪个团队、几个服务、覆盖多少人。

最后

业务功能证明你能完成需求，工程能力证明你能让团队跑得更快。三年以上的简历上如果一条工程类内容都没有，面试官会默认你只做过被安排的事。

这类经历在什么岗位上权重最高

一是基础架构、平台、效能工程这类岗位，它本身就是主业。

二是小团队的全栈或者后端岗。团队只有五六个人时，没有专职运维，能自己搞定部署和监控的人价值很高，招聘方也知道这一点。

三是资深岗位。三年以内的岗位主要看编码能力，五年以上的岗位一定会考察你对工程效率的贡献。

反过来，大厂的螺丝钉型岗位上，这类经历的权重会低一些，因为基础设施由专门团队负责。投这类岗位时，把它压到一行即可。

一个判断标准

写之前问自己：如果我离职了，我做的这件事还在被人用吗？

答案是「还在用」的，值得展开写；答案是「大概没人维护了」的，说明它当初可能就没解决真问题，一行带过即可。

自查时按「有没有改变行为、有没有可测量的结果」这两条筛一遍就行。