一份DevOps或平台工程简历，若能突出可靠性、值班责任、基础设施迁移，以及其他团队所依赖的工具，往往比一般软件工程师简历常用的"功能交付"式条目更有说服力。这两类简历在大多数结构上是相通的：按时间倒序排列的经历、一段简短的个人简介、一个技能部分，以及描述结果而非职责的条目。真正不同的是，在这类岗位上哪些结果才算真正令人印象深刻，因为基础设施工作的受益者通常是其他工程师而非终端用户，而且当一切运行良好时，这项工作本身往往是不可见的。
为什么重点会转移
软件工程师交付的功能通常有明显的前后对比：一个此前不存在的界面，一个从五步简化为两步的流程。基础设施和平台工作很少能带来这种可见的成果，因为最好的结果往往是从用户角度看什么都没变，一次原本会在凌晨两点把人叫醒的部署，如今不再这样；一个原本会在高负载下崩溃的服务，如今不再崩溃。面向这类岗位的简历，需要让从未从事过基础设施工作的读者也能理解这种不可见的可靠性，方法是说明哪些事情依赖这项工作，以及若没有它会出什么问题，而不是假设读者已经明白一次迁移或一次监控改动为何重要。
诚实地描述可靠性与正常运行时间
可靠性方面的描述容易落入在简历中量化工程影响，而不是编造数字一文提到的陷阱：写下一个诱人但无法核实的数字，比如"正常运行时间提升了40%"，而实际上从未真正追踪过这样的数字。如果确实存在一个当前仍可查证的指标，来自仪表盘或事故报告，就应如实写入简历。如果没有，用范围和前后状态描述同样有分量，且没有风险：这次改动背后涉及多少服务，之前哪些会失败、之后不再失败，哪个团队不再需要手动绕过这个问题。
把值班与事故响应写进简历
值班责任值得直接点明，而不是笼统地写成"支持生产系统"，因为它体现了一种纯功能岗位所没有的运维责任程度。写得好的方式是描述责任的具体形态：你为哪个或哪些系统承担值班，轮值大致是怎样安排的，以及因你处理过的某次事故而实际发生的一项具体变化，比如事后新增的一份操作手册，或某类此前反复出现、在根因修复后不再触发的告警。
值得单独写出的迁移与基础设施变更
一次迁移、平台变更或工具切换，如果属于其他工程师必须随之调整的那种项目，而不是团队之外无人察觉的纯内部改动，就值得单独写成一条。说明改动了什么、为什么改动，通常比只写目标技术的名称提供更多信息。
其他团队依赖的工具
内部工具应当得到与面向客户的功能同样的对待：它做什么，谁在使用，取代了什么。在软件工程师简历中展示业余项目一文讲述了同样的结构，用于正式工作之外的作品，这一结构同样适用于在正式工作中构建的内部工具。
示例：围绕基础设施所有权重写的一条条目
之前，笼统且偏功能导向："负责后端团队的基础设施和部署工作。"之后，围绕所有权、范围和描述清楚的前后状态重写："负责后端团队十一个服务的部署流水线；此前每个服务上线前都需要一次人工审批，重写之后，测试套件通过即可自动部署，把发布时需要在场的工程师人数从三人减少到一人。"第二个版本中没有任何一处是编造的统计数字。
整理一份冗长的工具与平台清单
平台工程岗位的技能部分往往比一般开发者更长，同时涵盖云服务商、编排工具、监控系统和编程语言，这正是那种冗长、混杂、适合按类别分组而不是排成一行的清单。
开始创建
CVBuilderKit的Developer模板围绕以项目和所有权为主线的条目构建，既适合应用代码，也同样适合基础设施和平台工作。可以从它开始，也可以从空白文档开始，在编辑器中把关于可靠性、值班和迁移的条目，围绕实际依赖这项工作的内容重写，而不是急于用一个你目前无法证明的数字。