从一行代码，
到一次可靠交付。

面向有约 3 年服务端开发经验、准备应聘研发效能平台后端研发岗位的读者。

推荐使用单页 HTML 完整版阅读：包含完整正文、流程图、目录、全文搜索和阅读进度，单独保存这一份 HTML 即可离线打开。

这套指南用一个功能的交付过程回答三个问题：功能经过哪些阶段；每个阶段做什么、谁负责、依赖什么技术；平台工程师需要把哪些事情做成可复用的能力。

资料核对日期：2026-10-16。岗位分工是本文的教学模型，工具定位以各章官方参考资料为依据。实际公司的流程、权限和产品版本可能不同；阅读 JD 和面试交流时需要对应确认。

先抓住岗位的工作对象#

过去写业务服务，主要面对订单、账户、支付等业务对象。开发研发效能平台，主要面对应用、代码仓库、构建任务、制品、环境、发布单和运行事件。

你已有的接口设计、数据库、异步任务、权限、并发控制和故障排查经验都能迁移。需要补齐的是软件交付过程，以及这些对象之间的状态、约束和失败处理。

本文会分别讨论：

• 业务开发怎样借助平台交付功能。
• 平台后端怎样实现流水线、发布编排、环境管理和运行反馈。
• 平台依赖的 Jenkins、Kubernetes 等系统各自负责什么。

阅读目录#

建议怎样读#

第一次先读 01 和 11，建立流程与岗位的整体认识。随后按 04 → 05 → 06 → 07 → 08 → 09 理解交付主链。最后用 12 制定学习安排，用 13 完成一次练习。

阅读一章后，试着不看原文回答：

1. 这一阶段接收什么，产出什么？
2. 谁对结果负责，平台提供什么支持？
3. 正常路径怎样走，失败后怎样判断和处理？
4. 如果由我写平台后端，接口、数据和异步任务怎样设计？

能用自己的话讲清楚这些，比记住工具名称更接近岗位要求。

全文共用案例#

给已有的 order-service 新增“查询当前用户已支付订单”的接口：

GET /orders?status=paid&limit=20

请求的用户身份来自认证上下文。接口需要做权限校验、访问订单数据库，并在生产流量下满足团队约定的性能与可靠性目标。后续各章跟踪同一个功能的代码、测试结果、镜像、部署记录和运行反馈。

文中的性能数值、时间、标识符、状态机和平台表结构都是教学示例。实操章提供任务、配置思路和验收方法，完成练习时使用自己熟悉的语言另建业务项目。

技能深度的约定#

初期目标是掌握主链的“理解＋使用”，再对流水线或发布平台中的一个模块达到“开发平台”。无需在应聘前精通所有开源项目。

工具选择原则#

各章列出的是代表性项目，方便认识不同能力的实现方式。相邻阶段可能由同一个平台覆盖，也可能由几个系统组合完成。

开源软件、商业增强版本和托管服务会明确区分。实操优先选一套能完成闭环的组合，产品的功能与版本边界通过官方资料确认，资料入口统一收录在第 14 章。

返回阅读入口 · 下一章：需求与设计

1. 看完整交付链，而不只看代码#

本指南把功能交付拆成十个阶段，便于建立知识地图。实际工作会循环、并行：测试参与需求设计，运行要求会影响代码，生产问题也会触发新的需求。

flowchart LR
    A["需求承接"] --> B["技术设计"]
    B --> C["开发与协作"]
    C --> D["CI 验证"]
    D --> E["制品管理"]
    E --> F["测试与验收"]
    F --> G["CD 交付与部署"]
    G --> H["生产发布与验证"]
    H --> I["运行态保障"]
    I --> J["反馈与效能改进"]
    J --> A
    F -->|发现缺陷| C
    I -->|发布异常| H

CI 内也包含测试；图中的“测试与验收”侧重需要完整环境、跨服务协作或业务确认的验证。“CD”可以覆盖生产部署，“生产发布”单独展开，是为了看清流量、风险和结果判断。

2. 阶段、重点、角色与交接#

下面是中等规模团队的一种常见分工。主责人负责推动结果，协作人提供专业判断或公共能力；平台接入并不转移业务团队对功能正确性的责任。

每次发布都应该能找到业务负责人、发布负责人和异常升级路径；这些职责可能由同一个人承担，但需要明确。

3. 技术栈与代表性开源项目#

项目名后的资料入口用于确认其定位，不代表必须全部安装。具体能力边界在各阶段章节继续解释。

GitLab 的开源部分与商业功能、Grafana OSS 与云服务、Plane 开源版与商业版本需要分别看待。GitHub Actions 可作为工作中常见的托管 CI/CD 对照，本表不把 GitHub 的整体托管平台当作开源平台。

4. 四个容易混淆的边界#

CI 是持续集成。 核心是频繁集成变更，并用自动化验证尽快暴露问题。有一个构建按钮不等于团队已经形成良好的持续集成实践。

CD 可能指两件事。 持续交付强调变更保持可发布，进入生产可保留人工决策；持续部署进一步让满足规则的变更自动进入生产。具体公司说“CD”时，需要确认指哪一种。本文的交付流程采用可保留人工生产决策的模型，工具实现参见 Jenkins Pipeline 和 GitLab CI/CD。

部署、发布、功能开放是三个可分别控制的动作。 部署把软件放进环境并运行；发布让目标用户或流量使用新版本；功能开放还可能受功能开关控制。公司内部可能把它们都叫“上线”，平台研发需要把实际动作和成功条件拆清楚。生产策略的实现边界见 Argo Rollouts 流量管理。

运行态持续存在。 流水线结束后，还要知道用户能否成功访问、延迟是否异常、服务容量是否足够。相关方法见 Google SRE：服务目标。

5. 贯穿各阶段的“证据链”#

平台需要能回答：线上这个版本从哪里来、为什么能发布、谁发布的、上线后怎样。

需求 REQ-123
  → MR-42 / Git commit
  → PipelineRun / 测试报告
  → Artifact digest / 扫描结果
  → Deployment / 环境配置版本
  → Release / 审批 / 流量变化
  → 指标 / 日志 / 事件 / 复盘

这是本文建议的平台领域模型，不是某款产品的统一标准。关键是使用可关联的稳定标识，避免只在页面里写一段无法追溯的文本。

6. 对转岗读者的优先级#

最先需要解释清楚的是：一次代码提交怎样变成生产中的某个版本；每一步怎样判断成功；失败时怎样恢复。

接着学习 CI、制品、CD、发布和运行态的实际操作。最后选择一个平台模块深入设计，例如“发布单状态机＋同环境互斥＋回调幂等＋超时对账”。

自测：如果测试通过了，但生产接口一直超时，可能是哪几个阶段的哪些假设没有得到验证？阅读后续章节时持续带着这个问题。

返回阅读入口 · 下一章：开发协作

1. 阶段一：需求承接#

输入、产出与重点#

输入是业务目标，例如“用户想快速找到已经支付的订单”；产出是可验收的功能范围、优先级、依赖和交付安排。

需求中应该说明正常行为，也应该约定空结果、非法参数、权限不足和失败反馈。对平台研发而言，需求还需要关联服务、代码仓库、负责人及预期发布批次，便于后续追踪。

谁负责#

产品或业务负责人确认用户价值、范围和验收标准。业务开发评估实现与依赖，测试提前发现边界条件，技术负责人协调风险和拆分。研发效能平台团队负责需求系统与研发流程的连接能力。

共用案例的需求记录#

这里的 300ms 只用于练习。正式目标要由业务体验、已有基线、访问规模和成本共同决定。

技术栈与代表性项目#

需要理解 Issue、看板、工作流、权限、Webhook 和系统间 API。可以查看 OpenProject、Plane 开源版 和 Gitea Issues 如何表达任务、状态和协作。

核心技能#

典型开发任务：接收任务系统事件，建立需求与服务、提交和发布的关联；支持补偿同步，并保留外部系统的原始 ID，便于对账。

2. 阶段二：技术设计#

输入、产出与重点#

输入是明确的需求；产出是团队能够实现、测试、部署和维护的方案。

设计范围包括 API 契约、数据访问、依赖行为、兼容性、运行观测和发布方案。对一个查询接口，除了 Controller 和 SQL，还要考虑超时、分页、索引、用户隔离和失败码。

谁负责#

业务开发或技术负责人主导方案。测试参与可验证性设计；安全团队按风险参与鉴权、数据和供应链评审；SRE 或基础设施团队协助容量与运行约束；平台团队提供标准模板和自动检查。

本案例需要做的设计判断#

1. API 契约：字段、状态码、错误结构和分页语义是什么？客户端是否能识别错误？
2. 数据访问：SQL 是否包含用户条件？扫描量是否随数据增大失控？需要新增什么索引？
3. 兼容性：新旧代码共存时，响应和数据库结构是否都可用？
4. 依赖与资源：数据库超时、连接池和并发上限怎样约束？请求取消后是否停止无用工作？
5. 可观测性：请求数、失败率、延迟、慢查询和版本信息怎样关联？
6. 发布：先部署到哪里，如何验证，小流量怎样放，什么情况下暂停？
7. 恢复：旧版本能否读取新结构？已执行的数据变更是否需要前向修复？

设计记录可以采用简短 ADR：问题、可选方案、选择、理由、代价和回退条件。无需为小功能写冗长文档，但需要保留影响交付与运行的关键决策。

技术栈与代表性项目#

基础是 HTTP、SQL、索引、事务、认证授权、缓存及超时处理。使用 OpenAPI 描述 HTTP API 契约，使用 Mermaid 表达依赖和时序；跨服务行为验证可以进一步了解 Pact。

OpenAPI 是规范，Mermaid 是图示工具，Pact 是契约测试工具。它们分别解决表达和验证的一部分问题，设计判断仍需要开发者完成。

核心技能#

典型开发任务：生成标准服务骨架，把接口契约差异检查接入 MR，并让发布单显式记录数据库变更和恢复方案。

3. 交接到开发前，应该能回答#

• 谁确认业务验收，哪些情况必须阻断交付？
• 新旧版本会共存多久，数据库变更怎样兼容？
• 怎样知道功能在生产上工作正常？
• 哪些规则由平台自动验证，哪些仍需人工判断？

只有排期、没有可验证目标，会让后续流水线把一份“能够编译的代码”误当成“能够交付的功能”。

官方资料#

• OpenProject：需求与项目协作工具定位。
• OpenAPI Initiative：API 契约及其生命周期作用。
• Pact Introduction：跨应用契约测试。
• Mermaid Introduction：用文本维护图示。

返回阅读入口 · 下一章：CI

1. 输入、产出与重点#

输入是设计与验收标准，产出是可评审的代码、自动化测试和可复现的开发说明。

对业务开发，重点是正确实现、小批次提交和有效评审。对平台开发，重点是把仓库、身份、代码事件和后续任务可靠地连接起来。

2. 谁负责#

业务开发提交实现与测试，评审人检查正确性、兼容性、可维护性及风险。测试参与场景补充。平台团队维护仓库接入、保护规则、模板和事件处理能力。

代码平台的管理员不天然拥有每个应用的业务评审权限，平台管理员与生产发布权限也应分别表达。

3. 分支和评审要解决什么#

本文建议练习采用“短分支＋PR／MR＋主干保护”的简单模型：

main
  → feature/order-query
  → 提交代码与测试
  → PR/MR 自动检查与人工评审
  → 合并
  → 对合并后的确定提交生成交付候选

PR 和 MR 都是提议合并代码的协作对象，名称取决于产品。团队也可能采用其他分支策略；面试时应解释为什么选择某个流程，以及长分支、合并冲突、紧急修复怎样处理。

评审通过和自动检查通过是两类证据。平台应把“检查针对哪个提交”绑定清楚：评审后又推送新提交，旧结果是否仍有效，需要由规则决定。

GitLab 官方资料区分普通 MR 流水线和验证合并结果的流水线。不能看到“MR 检查通过”就假设目标分支合并后的组合已被测试；还要确认执行对象以及版本功能。

4. 本地环境要能复现#

团队至少应约定：

• 语言运行时、构建工具与依赖版本的管理方式。
• 一条明确的构建、测试和启动命令。
• 本地数据库、缓存等依赖的准备方式。
• 示例配置与密钥注入入口。
• 初始化测试数据的方法。

容器可以统一部分环境，但硬件架构、操作系统、外部依赖和运行权限仍可能不同。复现问题时要记录差异。

本案例在本地完成参数、权限、空数据和数据库查询测试；集成测试可以通过 Testcontainers 启动临时依赖，再把同一测试入口交给 CI。

5. 平台收到代码事件后要做什么#

下面是教学设计：

1. 校验事件来源和签名，解析仓库、提交、分支、事件类型和事件 ID。
2. 以外部事件 ID 去重，保存接收记录。
3. 判断是否需要创建流水线；同一次变更可能同时产生 push 和 MR 事件。
4. 创建内部任务并投递队列，尽快返回事件接收结果。
5. 异步执行后，将检查结果回写对应的提交和 MR。
6. 回写失败时保留重试和对账记录。

“代码事件至少送达一次”是一个有用的设计假设：平台要能接受重复、迟到和漏回调，不能靠“Webhook 应该只来一次”保证正确性。

如果外部系统没有稳定事件 ID，可以用仓库、事件类型、提交、目标分支等组成业务去重键，并说明哪些重新执行应被允许。

6. 技术栈与开源项目#

7. 核心技能#

已有服务端经验的迁移点非常直接：Webhook 就是一个有认证与幂等要求的接入 API；流水线触发是异步业务流程；检查回写是外部系统集成。

8. 本阶段的交付证据#

本案例进入后续阶段时，至少能定位需求、MR、具体 commit、评审结果和自动检查结果。出现“本地通过，CI 失败”时，应能比较依赖、运行时、环境变量和测试数据。

自测：同一个 MR 的旧提交测试通过，新提交还没测，平台应该显示什么？为什么不能只在 MR 表里保存一个 success=true？

官方资料#

• Gitea Documentation：仓库、评审、Webhook 和保护规则入口。
• GitLab MR Pipelines：MR 流水线实际执行对象。
• GitLab FOSS 说明：开源部分与上游开发仓库的关系。
• Testcontainers：测试依赖生命周期。

返回阅读入口 · 下一章：CD

1. 输入、产出与重点#

输入是明确的代码或制品版本、测试范围、测试数据和环境；产出是可复查的验证证据、缺陷及剩余风险。

测试贯穿开发和交付。单元测试可以在本地和 CI 执行；集成测试可以在 CI 启动临时数据库；完整系统验证可能需要把候选制品部署到集成环境。本文单列这一章，是为了说明环境验证和业务验收怎样连接 CI 与 CD。

2. 谁负责#

业务开发对实现及基础自动化测试负责。测试人员补充系统场景、组织质量验证并推动风险闭环。产品或业务代表确认业务验收。平台团队提供环境、执行、报告和证据关联能力。

测试团队的确认不替代业务开发的质量责任；平台上的“通过”也需要能追溯到具体测试范围。

3. 各类测试分别验证什么#

测试层次是选择验证手段的思路，不意味着每个项目都要配置相同数量的测试或独立平台。

4. 环境和数据常常比测试脚本更难#

环境可识别#

需要记录运行中的制品摘要、部署配置、依赖版本、数据库结构和测试时间。出现问题时，才能知道测试的是哪套组合。

共享环境上被另一组发布覆盖，是一种环境冲突。可以通过预约、隔离命名空间或临时环境缓解，但隔离同时还要考虑账号、数据、队列和外部服务。

数据可构造#

本案例至少准备两个不同用户、各类订单状态、空结果和分页边界。大数据量验证还要设计合理分布，不能只插几条记录就宣称性能满足生产目标。

测试数据使用合成数据或经过批准的脱敏流程。练习中用合成用户与订单即可。

依赖可控制#

Mock 便于构造失败，但与真实服务行为可能有偏差。对关键依赖应结合契约测试、真实集成和超时场景验证。

使用 Testcontainers 管理测试中的容器依赖时，还要确认执行器具备所需容器运行能力和资源；它并不自动解决所有跨服务环境问题。

5. 验收结果应绑定什么#

建议保存：

TestRun
  - 测试计划 / 用例版本
  - 代码提交或制品完整摘要
  - 环境与配置快照标识
  - 测试数据版本 / 负载参数
  - 执行人或执行器
  - 开始与结束时间
  - 结果、报告、缺陷和例外

同一制品换了数据库结构、关键配置或运行架构，旧测试证据是否仍然足够，需要规则判断。只保留“本周已通过测试”的文字，无法约束实际发布对象。

6. 平台后端的典型开发任务#

• 为 MR 创建临时环境，配置到期回收和异常回收。
• 调度测试，保存报告，并和发布单关联。
• 管理测试数据初始化、隔离和清理流程。
• 把门禁结果回写代码平台或 CD。
• 区分应用失败、测试框架失败、环境不可用和结果未知。
• 统计不稳定测试，保留首次失败证据。

删除临时环境前，要验证所属项目与运行状态；环境回收失败也需要可追踪的任务记录。

7. 技术栈与代表性开源项目#

对平台后端岗位，先掌握 API 和依赖集成测试，再了解跨服务和端到端验证如何接入，不要求先成为所有测试工具的专家。

8. 核心技能与案例验收#

本案例要留下权限、分页、状态过滤和数据库集成测试；部署后验证实际路由；用可复现负载检查延迟与数据库瓶颈。测试通过后明确哪些风险仍未覆盖。

自测：CI 单元测试全绿，生产接口返回了别人的订单，测试设计和需求验收可能缺少哪些内容？

官方资料#

• Testcontainers：容器化测试依赖。
• Pact：契约测试模型。
• k6 Documentation：场景、指标和阈值。
• Playwright Introduction：浏览器测试与执行。

返回阅读入口 · 下一章：平台后端研发

1. 输入、产出与重点#

输入是需求、代码、测试、构建、部署和运行事件，以及开发者反馈；产出是明确的瓶颈、改进任务和效果验证。

平台的价值需要同时看交付速度、质量、使用体验和运行成本。流水线数量增加、页面访问量提高，只能说明活动或采用情况，不能单独证明交付变好。

2. 谁负责#

业务与平台负责人共同确定改进目标。开发、测试和 SRE 解释实际流程与风险。平台研发和数据相关人员建立事件关联、口径和看板。

指标需要对应团队可采取的行动，避免把跨角色的交付结果简单归因到某一个人。

3. DORA：先认识当前五项口径#

截至 2026-10-16 核对的 DORA 官方指南采用五项交付绩效指标。旧材料常讲四项，阅读时注意定义变化。

失败部署恢复时间聚焦部署引发的问题，与把所有故障都混在一起计算的 MTTR 不等同。这组指标适合结合服务上下文观察趋势，不宜作为个人排名或不同业务的简单横向排名。

4. 怎样真正落地数据口径#

下面是本文建议的平台事件设计：

不同组织可以有不同操作口径，但必须公开、稳定、可回算。调整规则时保留版本，避免趋势变化只是计算方式改变。

5. 用过程指标找到具体瓶颈#

DORA 指标展示交付结果，过程指标帮助寻找可改进的环节。可以从以下维度入手：

采用率需要与体验和结果一起看。强制大家接入一个复杂平台，也可能让接入率很高而交付变慢。

6. 一个改进例子#

教学场景：某服务提交到上线耗时很长。

先确认时间口径
  → 拆分评审、CI 排队、执行、环境等待、审批和发布
  → 找出主要等待来自 CI 资源排队
  → 调整队列或资源分配
  → 比较调整前后等待分布与成本

如果主要时间花在等审批，缩短编译几秒不会解决核心问题。改进后还要检查质量、成本和其他租户是否恶化。

不要只看平均值。查看中位数与高分位、样本量和异常分布，并排除业务规模或工作负载变化造成的干扰。

7. 复盘要留下什么#

本文建议用以下结构：

1. 影响：用户、范围、持续时间和可验证的损失。
2. 时间线：告警、发现、决策、操作和恢复。
3. 证据：日志、指标、变更与关键判断。
4. 促成因素：代码、设计、测试、环境、流程和监控的共同作用。
5. 改进项：负责人、期限、验收方法和优先级。

把“加强意识”改成可以验证的动作。例如“新增数据库慢查询对照，并在预发验证指定数据规模”，比“以后发布仔细一点”更能落地。

8. 技术栈与代表性开源项目#

DevLake 等工具的内置口径与当前 DORA 定义可能存在版本差异，使用前逐项核对。平台建设可以先覆盖少量可信事件，再逐步扩大，不必先做一个完整数据仓库。

9. 核心技能与平台任务#

本案例要能够关联需求、提交、构建、部署和一次故障演练，按同一时间线解释交付过程。

自测：部署频率提高了一倍，但紧急修复变多、开发者更焦虑，能否直接宣称研发效能提升？

官方资料#

• DORA Software Delivery Performance Metrics：当前五项定义与使用边界，页面标注更新于 2026-01-05。
• DORA Metrics History：历史口径的变化。
• Apache DevLake：项目能力与集成入口。

返回阅读入口 · 下一章：案例与实操

1. 先保持已有优势#

对有 3 年服务端经验的读者，先用熟悉的语言完成交付闭环。目标岗位如果主要使用 Go，可以再补 Go；无需为了“做 DevOps”同时重学全部技术。

下面的安排是学习建议。实际用时取决于已有基础与投入，不表示完成后就能覆盖所有公司面试。

2. 能力分层#

已有能力不是默认全部达标。例如过去只写业务接口，也需要检查事务、消息重复、并发控制和故障恢复的实践深度。

3. 六个学习单元#

可以按每周一个单元安排；每个单元有可复查的成果，遇到不熟悉的基础可以延长。

详细任务见第 13 章。先把主链跑通，再决定是否增加 GitOps、自动分析或更复杂的环境管理。

4. 八道场景题及回答要点#

题一：从一次代码提交讲到生产运行#

应覆盖触发、验证、可信制品、测试、环境配置、部署、流量、业务验证和运行反馈。每一步说清输入、成功条件和失败处理。

追问：同一个提交为什么可能产生不同制品？回答需要涉及依赖、基础镜像、构建工具和环境。

题二：CI 为什么有时很慢#

先分解排队、环境准备、依赖下载、编译、测试和报告时间，再看资源、缓存、并行和测试范围。不能直接回答“增加机器”。

追问：缓存加速后怎样防止污染与版本差异？

题三：Webhook 重复，为什么没有重复构建#

解释验签、事件 ID、业务去重键、数据库唯一约束、队列重复及执行幂等。还要允许用户显式重新运行，而不被去重逻辑永久阻止。

追问：同一 MR 的 push 与 MR 事件要合并处理吗？依据是什么？

题四：测试通过了，生产却失败了#

考虑制品与配置不同、真实数据量、路由与权限、依赖差异、资源、并发、数据库兼容，以及测试覆盖不足。先看事实再形成假设。

追问：怎样证明测试与生产使用同一内容？要说出完整摘要和配置证据。

题五：发布接口超时了，该怎么办#

先区分用户请求超时、平台任务超时和外部执行超时。查询已有任务与外部状态，利用幂等键和预先保存的关联标识对账。创建响应丢失时不能只依赖尚未取得的外部 ID；无法可靠定位时保留未知并人工核对，不能简单创建另一次发布。

追问：原 Worker 还在运行，新 Worker 接手后怎样防止双方同时推进？

题六：Pod Ready，能否判定发布成功#

还要检查目标版本、实例分布、入口路由、业务冒烟、依赖和生产指标。说明探针验证的范围，以及没有流量或指标缺失时怎样处理。

追问：把数据库是否可用放进 Liveness，可能有什么副作用？

题七：为什么不能一键回滚所有变更#

镜像、配置、数据库、消息和用户数据的恢复方式不同；新旧代码还需要兼容。解释暂停、流量切回、关闭功能、应用回退和前向修复。

追问：启用 GitOps 自动同步时，手工改集群会怎样？

题八：平台效能怎样评估#

用交付结果、稳定性、过程等待、开发体验和成本共同判断。讲清当前 DORA 定义，再根据瓶颈选择行动，不把提交数当个人产出排名。

追问：改进前后样本、服务范围和口径怎样保持可比？

5. 怎样讲已有项目#

选择自己真实做过的项目，用以下顺序：

背景与约束
  → 自己负责什么
  → 为什么采用该设计
  → 怎样验证与发布
  → 出过什么问题，怎样判断和处理
  → 结果与局限

如果以前没有开发过发布平台，可以诚实说明：“业务开发里使用过相关流程，最近完成了交付闭环练习，并针对幂等、状态对账和回退做了设计。”再用实际练习证据展开。

不要把练习描述成公司生产经验，也不要编造降本、提效或大规模并发数据。

6. 一段练习项目介绍模板#

完成相应内容后，可以据实填写：

我用熟悉的语言实现了一个订单查询练习服务，接入了一条包含构建、测试和镜像生成的流水线，使用固定摘要部署到练习环境。随后加入了业务冒烟、基础指标与一次失败演练。平台设计部分，我重点处理发布请求幂等、同环境互斥和外部执行超时后的状态对账。还没有实践的部分是……。

面试中比这段文字更重要的是展示流水线、报告、部署配置和故障时间线，并解释每个选择。

7. 拿到 JD 后重点确认#

• 平台主要服务哪些团队，当前最需要解决什么问题？
• 这个岗位负责哪几个模块，日常代码开发、集成和运维分别占什么范围？
• 是基于现有工具扩展，还是自研控制面与执行引擎？
• 技术栈是 Java／Go／Python 中的哪一种，Kubernetes 要求多深？
• 谁负责基础设施和生产值班，平台自身的可用性目标是什么？
• 平台接入和使用效果怎样衡量，有没有真实开发者反馈？
• 入职前三个月预期交付什么？

这些回答能帮助判断机会是否匹配“平台后端研发”，也能决定接下来把时间投在哪个模块。

8. 完成学习后的自测#

给自己做一次 20 分钟演示：

1. 用 3 分钟讲完整流程。
2. 用 5 分钟展示一次成功 CI 与一次失败阻断。
3. 用 5 分钟说明指定制品怎样部署、验证和恢复。
4. 用 5 分钟解释一个平台后端模块及异常路径。
5. 用 2 分钟说明没有覆盖的风险和下一步。

如果只能讲工具名字，回到相关章节补概念；如果正常路径能跑通但失败后无从下手，优先补失败、幂等和对账。

工具的官方学习入口见第 14 章。

返回阅读入口 · 下一章：术语与资料

1. 练习目标与范围#

另建一个 delivery-lab 练习仓库，用自己熟悉的语言，实现“当前用户查询已支付订单”，再完成 CI、制品、部署、发布验证和基础监控。

本文是一份任务书，包含设计、配置示例、检查方法和验收要求。需要在练习仓库中实现应用、测试和环境接入；本目录本身是学习文档，不是一套已经部署的实验环境。

依次完成三个层次：

资源有限时分层完成，不必把代码托管、CI、仓库、集群和监控全部装在同一台电脑。所有演练都在个人或授权的测试环境中进行。

2. 推荐的一套练习组合#

选择熟悉的工具即可，下面只提供一套参考：

• 代码：已有的 Git 托管服务。
• CI：Jenkins；已有 GitLab CI 时可以直接使用。
• 应用：熟悉的 Java、Go 或 Python 框架。
• 制品：一个支持 OCI 镜像的仓库；有条件时用 Harbor。
• 部署：本地 Kubernetes，例如 kind；先完成普通滚动更新。
• 观测：Prometheus＋Grafana，日志先用容器标准输出。
• 进阶：Argo CD、Argo Rollouts、链路后端和发布任务 API。

CI 执行器需要明确的构建方式。容器镜像构建权限、仓库访问和集群访问分别配置，避免把个人管理员凭据直接塞进流水线。

官方参考：Jenkins、kind、Harbor、Prometheus。

3. 练习仓库应包含什么#

delivery-lab/
  README.md               # 环境、构建、测试、运行和恢复说明
  app/                    # 业务实现
  tests/                  # 自动化测试与合成数据
  Dockerfile              # 镜像构建定义
  .dockerignore           # 排除密钥、临时文件等
  Jenkinsfile             # 或选用工具的 CI 定义
  deploy/                 # 部署定义和环境配置
  observability/          # 指标说明、告警或看板配置
  evidence/
    traceability.md       # 提交→构建→摘要→部署
    failure-drill.md      # 故障时间线与恢复证据
    decisions.md          # 关键设计选择与剩余问题

这是建议结构，按语言习惯调整即可。不要把真实令牌、个人订单或未脱敏日志提交进仓库。

4. 第一阶段：定义需求并实现接口#

任务#

实现：

GET /orders?status=paid&limit=20
GET /healthz
GET /readyz
GET /version
GET /metrics

认证由所选框架的认证层处理，业务从身份上下文取当前用户。测试中构造合成身份，不接受用户随意指定一个 userId 就读取对应订单。

准备两个用户、多种状态和足够的分页边界数据。初步可以用内存或轻量数据库，随后用真实数据库完成集成测试。

/version 返回构建时注入的非敏感版本标识，帮助检查实例。镜像完整摘要由部署平台或容器运行元数据核对，不要求应用在镜像构建前知道自身最终摘要。

验收#

• 合法身份只能获得自己的已支付订单。
• 未认证、非法状态、过大 limit 均有明确行为。
• 空数据、排序和分页测试通过。
• healthz 与 readyz 的判断范围有文字说明。
• 有统一的构建、测试和启动命令。

5. 第二阶段：接入 CI，并演练失败阻断#

任务#

按第 04 章配置流水线：

提交触发 → 固定 commit → 构建与测试 → 报告 → 结果回写

先完成验证，合并到主干后再对确定提交生成可信候选制品。使用独立的练习分支故意破坏一项权限测试，确认失败不会生成可晋级版本。

记录排队、执行、依赖下载和测试耗时。触发一次重复事件或手动重跑，说明两者分别应该产生什么记录。

验收#

• 流水线能定位到确切提交。
• 失败日志指出具体任务与测试。
• 报告缺失不会被展示成测试全通过。
• 有一条成功运行和一条被阻断的运行记录。
• 能解释主干候选与普通分支产物的区别。

6. 第三阶段：生成、保存并固定制品#

任务#

在练习项目已提供 Dockerfile 的前提下，可以用以下命令表达打包与上传。仓库地址、标签及登录凭据需要按自己的环境配置：

docker build -t registry.example.com/lab/order-service:lab-v1 .
docker push registry.example.com/lab/order-service:lab-v1

从仓库或推送结果取得完整摘要，登记它与 commit、CI 运行的关系。配置不可变标签或采用不会覆盖的标签策略；生产式部署记录使用完整摘要。

多架构场景明确选定目标平台。如果使用 kind 的本地镜像导入路径，则它只是本地替代；另外练习一次真实仓库推拉，才能验证凭据和仓库链路。

验收#

• 能解释标签和摘要的区别。
• 能从摘要找到来源 commit 与测试报告。
• 拉取同一摘要后可以运行并验证版本。
• 仓库凭据不会出现在日志或提交内容中。

7. 第四阶段：部署并区分“请求成功”与“业务成功”#

部署定义示例#

下面是 Kubernetes 核心结构示例。应用需要监听 8080 并实现对应探针。<完整摘要> 是替换标记，需要替换为真实摘要；示例没有包含数据库配置、镜像凭据和外部路由。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: delivery-lab
spec:
  replicas: 2
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: app
          image: registry.example.com/lab/order-service@sha256:<完整摘要>
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          startupProbe:
            httpGet:
              path: /healthz
              port: http
            periodSeconds: 2
            failureThreshold: 30
          readinessProbe:
            httpGet:
              path: /readyz
              port: http
          livenessProbe:
            httpGet:
              path: /healthz
              port: http
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
  namespace: delivery-lab
spec:
  selector:
    app: order-service
  ports:
    - port: 80
      targetPort: http

资源值和探针时长仅用于说明字段，按语言启动特性与实测内存调整。命名空间需提前创建或写入独立配置。

检查方法#

在自己已经创建的练习集群中：

kubectl config current-context
kubectl get deployment,pods,service -n delivery-lab
kubectl rollout status deployment/order-service -n delivery-lab --timeout=120s
kubectl describe deployment/order-service -n delivery-lab
kubectl logs -l app=order-service -n delivery-lab --all-containers=true --tail=100

检查目标环境后再执行变更。使用 port-forward 可以从本机验证 Service：

kubectl port-forward service/order-service 8080:80 -n delivery-lab

另开终端访问版本、探针和业务接口。业务接口需要测试身份；本地端口转发通过后，还应在配置了正式入口时单独验证路由和认证。

验收#

• 实际运行镜像与目标摘要一致，配置版本可查。
• 能解释 Pod、Service、探针和实际入口各自验证什么。
• 故意配置错误镜像地址，能从事件判断原因。
• 部署成功后业务冒烟通过。

8. 第五阶段：运行观测与失败演练#

任务#

让应用输出结构化日志，并通过 Prometheus 采集请求数和耗时等指标。指标名、标签和单位在仓库中写明；如采用第 09 章查询，先匹配它要求的直方图定义。

通过已认证的合成请求产生负载，记录负载参数和时间窗口。k6 的脚本需要同时检查 HTTP 和响应内容，并定义明确阈值；具体写法见 k6 Thresholds。

选择一项受控故障：

故障注入仅存在于练习版本或受控测试配置中，普通调用者不应有切换故障的权限。

验收#

• 看板能展示流量、失败和延迟。
• 指标、日志、版本与发布时间能互相定位。
• 能解释故障影响和至少一个备选假设。
• 恢复后从业务入口和指标确认结果。

9. 第六阶段：做一次发布与恢复#

基础练习#

先用普通滚动更新发布第二个版本，观察新旧实例共存和状态变化。保留旧制品、配置与回退记录。

用前一阶段的故障版本演练暂停与恢复。直接部署的练习模式下可以把部署定义恢复到先前的明确摘要；GitOps 模式则通过恢复期望配置并同步实现。

只执行 rollout undo 不能证明数据、配置、业务和 GitOps 期望状态已经恢复。记录实际动作与验证结果。

进阶练习#

选择 Argo Rollouts，配置分阶段推进与指标分析。如果没有可控制权重的路由底座，明确说明实际采用的分流方式，不声称已经精确控制请求比例。

验收#

• 有目标版本、发布策略、观察条件和恢复方案。
• 失败时停止继续扩大。
• 指标缺失时不自动判定通过。
• 恢复后确认流量、实例和业务均符合目标。

10. 第七阶段：选择一个平台后端模块#

在交付主链完成后，任选一项深入：

先设计领域对象、状态与允许操作，再实现接口。可用假的外部适配器演练超时和乱序，但要说明哪些场景已接入真实系统。

11. 最终成果与复盘#

完成练习后，把证据整理成：

需求与设计
  → MR 与提交
  → 成功 / 失败 CI 运行
  → 测试报告与制品摘要
  → 环境配置和部署记录
  → 发布与恢复
  → 指标、日志和故障时间线

每个箭头至少有可点击记录、文件或可复现命令。最后写清：

• 做成了什么，哪些仍是设计或模拟。
• 哪一步最难，怎样得到证据。
• 哪项平台能力可以减少业务开发的重复劳动。
• 如果成为团队共享平台，下一步要补哪些权限、隔离、可靠性和体验。

这些成果可以支撑第 12 章的面试演示。

返回阅读入口

资料核对日期：2026-10-16。下面以官方规范、产品文档和项目仓库为入口。使用 stable、latest 或 main 的页面会随时间变化，实际操作时切换到已安装版本。

1. 术语速查#

2. 按阶段查官方资料#

需求、设计与代码协作#

• OpenProject：项目与工作管理。
• Plane Open Source：开源项目管理版本及功能边界。
• OpenAPI Initiative：API 契约规范与定位。
• Mermaid：文本图示。
• Gitea：代码托管、协作与集成。
• GitLab FOSS：GitLab 开源部分说明。
• GitLab MR Pipelines：MR 验证对象与相关能力。

CI 与制品#

• Jenkins Pipeline：概念。
• Jenkins Pipeline Syntax：配置语法。
• GitLab Pipelines：任务、执行器与类型。
• GitLab Pipeline Security：代码信任与凭据。
• Tekton：云原生流水线。
• Harbor：OCI 仓库与策略。
• Harbor 不可变标签。
• Gitea Packages：包管理。
• OCI Image Specification：摘要与内容描述。
• Dependency-Track：SBOM 与组件风险。
• SLSA Provenance：构建来源证明规范。
• Sigstore Cosign：签名与验证。

测试#

• Testcontainers：测试依赖。
• Pact：契约测试。
• k6：负载与性能验证。
• k6 Thresholds：阈值判断。
• Playwright：浏览器端到端测试。

部署与生产发布#

• Kubernetes Deployment：更新与状态。
• Kubernetes Probes：探针。
• Kubernetes Secrets：敏感配置。
• Kustomize：配置覆盖。
• Helm Charts：应用打包与参数。
• Argo CD Auto Sync：GitOps 同步。
• Argo Rollouts Analysis：渐进发布分析。
• Argo Rollouts Traffic Management：流量管理。
• Apache APISIX：网关。
• Unleash：功能开关。
• Ansible：主机与系统自动化。
• OpenTofu：基础设施即代码。
• kind Quick Start：本地 Kubernetes 练习。

运行态、平台与效能#

• Google SRE：Service Level Objectives：服务目标。
• OpenTelemetry：可观测数据的生成与传递。
• Prometheus Overview：指标系统。
• Prometheus Instrumentation：插桩原则。
• Prometheus Histograms：延迟分布与统计。
• Alertmanager：告警通知。
• Grafana OSS：可视化与开源产品入口。
• Jaeger：链路后端。
• Backstage Software Catalog：服务目录。
• DORA Metrics：五项交付绩效指标及使用建议。
• DORA Metrics History：指标演变。
• Apache DevLake：研发数据集成与度量。

3. 选择项目时怎样核对#

先看项目承担的能力，再检查：

1. 使用的版本、开源许可证和商业功能边界。
2. 身份、权限、执行隔离和凭据管理。
3. 外部 API、事件、状态和恢复机制。
4. 自己团队的环境、规模、维护成本与升级路径。
5. 是否需要整个平台，还是只需接入其中一个模块。

本文优先介绍能力与概念，没有指定“所有团队都应该使用”的统一工具栈。正式选型还应根据实际约束单独评估。