引导式演练 · 8 分钟
探索软件生命周期
跟随一项导出功能，从要求走到运维。检查各阶段的负责人、证据和决定。
当前情况
你负责一个客户管理服务。经理要求导出一份文件，包含其所属组织的活跃客户数据。跟随这项虚构功能，从请求走到运维。
场景：导出客户数据
证据是支持决定的文档或检查结果。下面每个阶段都提供示例。可以按顺序学习，也可以直接选择阶段。
阶段 1 / 7
需求
经理需要导出自己组织的活跃客户数据。
- 负责人
- 产品负责人
- 证据
- 已接受的目标结果与允许字段
经理每周花一小时收集活跃客户数据。已接受需求：将自己组织的客户名称和客户 ID 导出为 CSV。
阶段 2 / 7
规格说明
定义允许的用户、数据、故障行为和验收标准。
- 负责人
- 产品与安全负责人
- 证据
- 数据流与授权要求
验收标准：即使修改请求标识符，组织 A 的经理也不能取得组织 B 的记录。
阶段 3 / 7
实现
智能体在功能分支中准备小型变更。
- 负责人
- 开发团队
- 证据
- 关联到要求的 diff
PR 为数据库查询添加组织筛选，并添加请求另一组织数据的测试。登录和计费保持不变。
阶段 4 / 7
验证
检查实际授权和被禁止的请求。
- 负责人
- 独立审查者
- 证据
- 针对最终提交的测试与审查
最终提交上的测试表明，组织 A 的用户无法取得 B 的记录。审查者检查授权链。
阶段 5 / 7
发布
用获准部署角色，部署已接受的制品。
- 负责人
- 发布负责人
- 证据
- 制品标识符、批准和恢复计划
发布负责人核对制品对应提交与已审查提交是否一致。恢复说明指定先前版本，以及能启动回滚的人。
阶段 6 / 7
运维
监控导出失败、访问控制和服务行为。
- 负责人
- 服务负责人
- 证据
- 指标、范围受限的审计日志和事件处理说明
导出失败告警发送给值班工程师。范围受限的审计日志记录操作人和组织，不复制完整客户列表。
阶段 7 / 7
学习
下一次变更前，评估使用情况和观察到的问题。
- 负责人
- 产品负责人和团队
- 证据
- 反馈与更新后的工作队列
支持请求报告，大型客户列表导出失败。团队为下一次变更添加性能要求和测试。
这一过程可以重复。新证据可能让工作回到规格说明或实现阶段。
完成前
代码可以运行。团队为什么不能在“实现”阶段就停下？
将你的答案与解释比较
能运行的代码不能说明谁可访问记录，或谁处理故障。验证阶段检查数据边界。发布阶段将证据关联到已部署版本。运维阶段明确运行中服务的职责。学习阶段把观察到的问题转化为下一次变更。
应用到工作中
为团队的一项功能，指定发布负责人和接收故障告警的人。
选择其他练习