12.2 检查清单

这些检查清单是实用的、即取即用的快速参考。可以把任意一份检查清单复制到拉取请求模板、Wiki 页面、工单，或者评审会议的议程中，并根据你的具体情境调整其中的条目。把每一条都当作一个人可以核实、并能以“是/否”来回答的事项。检查清单是一种记忆辅助工具和共享标准，而不是判断力的替代品；请删除不适用的条目，并补充你所在领域需要的条目。

有效使用这些清单的一些指导原则：

• 让检查清单保持足够短，使人们真的会去完成它。如果一份检查清单经常被跳过，那说明它太长了，或者太笼统了。
• 把任何机器能够核实的条目（格式化、测试、扫描）自动化，好让人力专注在需要判断力的条目上。
• 为你的检查清单打上版本号，并定期审查它们。一份从不改变的检查清单，很可能根本没有被使用。
• 当这种区分对你的流程有意义时，要区分阻断性条目和建议性条目。

代码评审检查清单

用于评审他人改动的评审者。

• 该改动实现了其描述和关联工单所声明的内容。
• 范围聚焦于单一的逻辑关注点；不相关的改动已被拆分出去。
• 设计契合现有架构，没有引入本可以更简单地避免的耦合。
• 边界情况、错误路径和失败模式都得到了处理，而不只是理想路径。
• 测试存在，有意义，并且在行为出现回归时会失败。
• 命名、结构和注释让未来的读者能够理解这段代码。
• 没有提交任何机密信息、凭据、令牌或个人数据。
• 安全敏感的输入得到了恰当的校验、编码或参数化处理。
• 公共接口、契约和向后兼容性得到了保留，或者是有意进行了版本化。
• 日志、指标和错误报告足以支撑在生产环境中运行这项改动。
• 文档、操作手册和配置已更新，与这项改动保持一致。
• 反馈被区分为阻断性问题和建议，并且措辞针对的是代码本身。

拉取请求作者检查清单

用于作者在请求评审之前自查。

• 这个 PR 足够小、足够聚焦，可以在一次坐下阅读中被仔细评审。
• 描述说明了改动的内容、原因，以及是如何验证的。
• 关联的工单、议题或设计文档为评审者提供了必要的上下文。
• 所有自动化检查在本地或 CI 中都已通过（构建、代码规范检查、格式化、测试、扫描）。
• 新增和变更的行为都有测试覆盖。
• 机械性的重构与行为变更已被分开。
• 已完成自我评审：你已经逐行读过自己的 diff。
• 没有残留调试代码、被注释掉的代码块、机密信息或多余的文件。
• 数据库迁移、功能开关和配置变更已有文档记录，并且是可回退的。
• 破坏性变更已明确指出，并附有迁移路径。
• 在有助于评审的地方，附上了截图、录屏或示例输出。
• 已请求合适的评审者以及任何按角色要求的必需审批人。

完成的定义（Definition of Done）

一个工作项被视为完成之前必须满足的共享标准。

• 工单中的验收标准全部已满足，且可以被演示证明。
• 代码已经过必需评审者的同行评审并获得批准。
• 自动化测试已编写、通过，并与该改动一并合入。
• 代码已合入主干，并通过流水线顺利部署。
• 没有已达到约定严重程度阈值、仍处于开放状态的已知缺陷。
• 文档、帮助文本和操作手册已更新。
• 可观测性已就位：相关的日志、指标和告警均已存在。
• 已考虑并处理了安全和隐私方面的影响。
• 该改动在面向用户的部分满足无障碍要求。
• 功能开关已配置完毕，发布计划已获一致同意。
• 产品负责人或利益相关者已认可这一成果。
• 任何后续工作都已记录为被追踪的工单，而不是隐含未说明的事项。

生产环境上线 / 就绪评估

在向生产环境发布重大改动或新服务之前。

• 发布计划已有文档记录，包括分阶段或金丝雀发布的步骤以及成功标准。
• 回滚计划已有文档记录、经过测试，并且能够被快速执行。
• 容量和负载测试表明系统能够满足预期需求和峰值需求。
• 监控、仪表盘和告警在上线前已经上线并经过验证。
• 待命排班已经安排妥当，响应人员熟悉该系统。
• 针对最有可能发生的故障和运维场景，已准备好操作手册。
• 依赖项、集成方和第三方均已确认就绪，速率限制已被理解。
• 安全评审和所需的签核均已完成。
• 如果涉及数据迁移，已进行端到端测试，并有经过验证的回退方案。
• 功能开关允许在不重新部署的情况下禁用该改动。
• 在需要的地方，已获得法务、隐私和合规方面的批准。
• 沟通计划覆盖了利益相关者、支持团队和客户。
• 由指定负责人依据明确标准做出了“是否发布”的决定。

安全评审 / 威胁建模检查清单

用于评估一项改动或一个系统的安全态势。

• 信任边界和数据流已被识别并有文档记录。
• 每一个需要身份验证的入口点都强制执行了身份验证。
• 授权检查为每一个操作和资源强制执行了最小权限原则。
• 所有外部输入都经过校验，输出也针对其去向进行了编码。
• 机密信息存储在受管理的机密库中，绝不出现在代码或配置里，并且是可轮换的。
• 数据按照分类要求，在传输中和静态存储时都进行了加密。
• 依赖项已被扫描已知漏洞，并保持在最新版本。
• 针对不可信输入的注入、反序列化和 SSRF 风险已得到缓解。
• 与安全相关的事件被记录下来，且不会记录敏感数据。
• 速率限制、配额和滥用防护措施保护着对外暴露的端点。
• 错误消息不会泄露堆栈跟踪、内部实现细节或敏感信息。
• 通过 STRIDE 或类似方法识别出的威胁，已连同其缓解措施或被接受的风险一并记录。
• 安全测试（SAST、DAST 或渗透测试）已经计划好或已经完成。

隐私与数据保护（DPIA 风格）检查清单

用于涉及个人数据或敏感数据的处理活动。

• 所收集的个人数据已被清点、分类，并被最小化到实际所需的范围。
• 每一个处理目的所依据的合法基础或权限均已有文档记录。
• 目的限制得到强制执行：数据仅被用于所声明的目的。
• 保留期限已被明确定义，删除或匿名化已实现自动化。
• 数据主体权利（访问、更正、删除、可携带性）能够被切实履行。
• 在依赖同意的情况下，该同意是自由给出的、具体明确的，并且是可撤销的。
• 第三方和数据处理方受到充分数据保护条款的约束。
• 跨境传输具有适当的合法传输机制。
• 对个人数据的访问受到限制、被记录，并会被审查。
• 对个人的隐私风险已被评估，并得到缓解或上报。
• 数据泄露的检测和通知流程已被明确定义。
• 该功能的隐私优先设计和默认选项均已有文档记录。
• 在需要的地方，数据保护官或隐私评审人员已经签核。

无障碍（WCAG）检查清单

用于面向用户的界面，依据 WCAG 原则。

• 所有内容都可以仅通过键盘到达并操作。
• 焦点顺序符合逻辑，并且存在可见的焦点指示器。
• 文本颜色对比度达到目标比例（正文文本通常为 4.5:1）。
• 图片和非文本内容都有有意义的替代文本。
• 表单字段都有关联的标签和清晰的错误提示信息。
• 标题、地标和结构都以语义化的方式进行了标记。
• 交互组件向辅助技术暴露了正确的名称、角色和状态。
• 内容在 200% 缩放以及小屏幕上仍能重排并保持可用。
• 时间限制是可调整的，动画或自动播放的内容是可以暂停的。
• 颜色不是传达信息的唯一手段。
• 媒体带有字幕，并在需要时提供文字稿或音频描述。
• 该界面已使用屏幕阅读器和自动化无障碍工具进行了测试。

API 设计评审检查清单

在发布或变更一个 API 之前。

• 资源和操作的命名一致且可预测。
• 契约已在一份机器可读的模式（例如 OpenAPI）中定义。
• 版本策略已被明确定义，向后兼容性得到保留或有序管理。
• 分页、过滤和排序遵循一致的约定。
• 错误响应使用一致的结构、代码和可据以采取行动的消息。
• 每一个操作都指定了身份验证和授权方式。
• 输入校验和大小限制均已定义并强制执行。
• 对于预期会被重试的操作，幂等性已被明确定义。
• 速率限制、配额和节流行为均已有文档记录。
• 超时、重试和失败语义对客户端而言是清晰的。
• 响应中敏感数据的暴露已被最小化，并有合理理由。
• 文档为每个操作和每种错误情形都提供了示例。
• 废弃策略和下线时间表均已被明确定义。

架构决策记录（ADR）评审检查清单

用于评审一份拟议的架构决策记录。

• 所要解决的背景和问题被清晰地陈述。
• 决策被明确无歧义地表述为单一选择。
• 至少考虑并比较了两个现实可行的备选方案。
• 后果，无论正面还是负面，均已被记录。
• 非功能性影响（性能、安全、成本、可运维性）均已得到处理。
• 该决策与现有原则以及先前的 ADR 保持一致，或者明确地取代了它们。
• 受影响的团队和利益相关者已被征询意见。
• 该决策的可逆性和变更成本已被评估。
• 假设条件和约束条件均已被明确说明。
• 状态（拟议中、已采纳、已被取代）已被设置并注明日期。
• 该决策是可被发现的，并从相关系统中被链接到。
• 任何后续行动或迁移工作都已作为被追踪的工作项记录下来。

事件响应检查清单

在生产环境事件发生期间使用。

• 宣布事件成立，并指定一位单一的事件指挥官。
• 评估并对外沟通严重程度、影响范围和客户影响。
• 开设一个专用的沟通渠道和事件记录。
• 分配清晰的角色：指挥官、沟通负责人和运维负责人。
• 优先进行缓解和恢复服务，而不是根因分析。
• 按固定节奏向利益相关者发布常规状态更新。
• 实时记录事件、行动和决策的时间线。
• 在需要时上报给更多响应人员或供应商。
• 如果涉及数据或法规问题，通知法务、安全和合规团队。
• 验证修复方案，并确认系统已完全恢复。
• 正式关闭该事件，并对外沟通处理结果。
• 在人员分散之前，安排好无责事后总结会议。

事后总结检查清单

用于事件发生后的回顾性评审。

• 这次评审是无责的，聚焦于系统和促成因素。
• 事件的真实、带时间戳的时间线已被记录。
• 客户和业务影响已被量化（持续时间、影响范围、成本）。
• 检测过程已被分析：问题是如何被发现的、又是何时被发现的。
• 响应过程已被分析：哪些举措有帮助，哪些拖慢了恢复。
• 促成因素已被识别，而不只是单一的根本原因。
• 做得好的地方与出问题的地方一样，都被记录了下来。
• 行动项是具体的，被分配了负责人，并设有截止日期。
• 行动项覆盖了预防、检测和缓解三个方面。
• 后续事项被纳入常规待办事项列表中追踪至完成。
• 该事后总结被广泛分享，以便其他人从中学习。
• 跨事件的系统性模式会被定期审查。

待命就绪检查清单

在有人开始一次待命轮班之前。

• 响应人员拥有他们所需的所有系统、仪表盘和工具的访问权限。
• 告警能够可靠地到达响应人员，且已经过测试。
• 上报路径和次要待命联系人是已知且最新的。
• 针对最常见和最严重的告警，已准备好操作手册。
• 响应人员已针对这些系统完成了入职培训或跟岗学习。
• 最近的变更、正在进行中的事件和已知问题均已完成交接。
• 告警阈值已经过调优，以最大限度地减少噪音和误报。
• 响应人员知道如何宣布一起事件，以及如何联系到指挥官。
• 响应人员能够从其工作环境中访问生产环境。
• 沟通渠道和利益相关者联系方式均已有文档记录。
• 待命排班表已发布，覆盖范围没有空缺。
• 待命的报酬、期望和工作量上限均已明确。

SLO 定义检查清单

在定义一个服务水平目标（SLO）时使用。

• 该 SLO 所保护的用户旅程或能力已被清晰识别。
• 服务水平指标（SLI）被定义为清晰、可衡量的数量。
• SLI 尽可能从用户的视角进行度量。
• 目标值被设定在用户实际所需的水平，而不是 100%。
• 度量窗口（例如滚动 28 天）已被明确指定。
• 由目标值推导出的错误预算已被计算并被理解。
• 一项策略明确定义了错误预算耗尽时会发生什么。
• 用于 SLI 的数据来源是可靠的，并已完成埋点。
• 告警与消耗速率挂钩，而不仅仅是阈值突破。
• 负责人和利益相关者一致认为该 SLO 是现实且有意义的。
• 该 SLO 已有文档记录，并在仪表盘上可见。
• 存在一份日程，用以随服务演进定期审查和修订 SLO。

CI/CD 流水线检查清单

用于一条持续集成与持续交付流水线。

• 每一次提交都会触发自动化构建和测试运行。
• 流水线能够快速失败，并向作者清晰地报告结果。
• 代码规范检查、格式化和静态分析会自动运行。
• 单元测试、集成测试以及相关的端到端测试都会在流水线中运行。
• 每次构建都会运行安全和依赖项扫描。
• 构建产物是有版本、不可变的，并存放在一个制品仓库中。
• 机密信息以安全的方式注入，绝不会打印在日志中。
• 部署是自动化的，并且在各环境之间是可重复的。
• 部署策略（金丝雀、蓝绿、滚动）已被定义并被使用。
• 回滚是自动化的，或者是一个有文档记录的单一操作。
• 流水线权限遵循最小权限原则，并且是可审计的。
• 流水线配置以代码形式存储在版本控制中。
• 在需要的地方，会生成构建溯源信息和软件物料清单。

基础设施即代码评审检查清单

用于评审以代码形式定义的基础设施。

• 变更完全以代码形式表达，并通过流水线应用。
• 在应用变更之前，会评审一份执行计划或试运行输出。
• 状态被安全地存储，并带有锁机制以防止并发变更。
• 资源遵循命名、标记和归属方面的约定。
• 使用最小权限的 IAM 角色和策略，能避免的地方不使用通配符。
• 网络暴露被最小化；不存在非预期的公开访问。
• 机密信息和敏感值从一个机密库中引用，而不是硬编码。
• 存储、数据库和传输过程均已启用加密。
• 变更是幂等的，可以安全地重复应用。
• 影响范围已被理解；破坏性变更已被明确指出。
• 已考虑该变更的成本影响。
• 模块是可复用的、有版本的，并且经过测试。
• 已配置漂移检测，用以捕捉带外变更。

AI/ML 模型发布检查清单

在将一个机器学习模型发布到生产环境之前。

• 该模型的预期用途、适用范围和局限性均已有文档记录。
• 训练和评估数据的来源、许可和同意情况均已核实。
• 数据和模型都有版本，并且是可复现的。
• 性能已在具有代表性的、留出的测试数据上得到评估。
• 已针对相关子群体评估了公平性和偏见问题。
• 该模型已与现有模型或一个基线进行了对比评估。
• 失败模式、边界情况和分布外行为均已被理解。
• 安全性、滥用风险和有害输出风险均已被评估并缓解。
• 针对漂移、数据质量和性能退化的监控均已就位。
• 存在回退或降级到先前模型或基于规则路径的方案。
• 对于有重大后果的决策，提供了人工监督或申诉渠道。
• 隐私评审覆盖了训练数据以及推理的输入和输出。
• 一份模型卡片或等效文档已向利益相关者发布。

数据流水线质量检查清单

用于为分析或产品提供数据的数据流水线。

• 源数据的模式已被校验，模式变更能够被检测到。
• 数据摄取能够正确处理延迟到达、重复和乱序的记录。
• 数据质量检查（完整性、唯一性、取值范围）会自动运行。
• 失败的记录会被隔离并呈现出来，而不是被悄悄丢弃。
• 转换逻辑已用具有代表性的输入和边界情况输入进行了测试。
• 该流水线是幂等的，失败后可以安全地重新运行。
• 输出的新鲜度和延迟会与预期进行对比监控。
• 数据血缘已有文档记录，以便消费方了解数据来自何处。
• 个人数据和敏感数据已被恰当地分类、脱敏或加以限制。
• 支持回填和重新处理，并且均有文档记录。
• 告警会在失败和质量问题发生时通知负责人。
• 存储数据的保留和删除策略得到了强制执行。
• 下游消费方和 SLA 均已有文档记录。

开源引入与许可证审查检查清单

在采用一个开源组件之前。

• 该组件的许可证已被识别，并且在已批准的清单之列。
• 许可证义务（署名、著佐权/copyleft、声明）均已被理解并被满足。
• 许可证与你们的分发模式之间的兼容性已被确认。
• 该项目正被积极维护，拥有健康的社区。
• 已检查已知漏洞，版本保持最新。
• 该依赖项及其传递依赖均已被纳入清单。
• 安全态势和过往事件历史均已被评审。
• 该组件填补了一个真实的需求，且没有明显的重复建设。
• 已考虑该组件的退出成本和可替代性。
• 该组件已被记录在软件物料清单中。
• 有指定负责人负责追踪更新和安全公告。
• 如果对其进行了修改，遵循了回馈贡献和内部分支相关的政策。

供应商 / 第三方风险检查清单

在引入一个外部供应商或服务之前。

• 业务需求以及供应商将访问的数据均已被明确定义。
• 供应商的安全态势已被评估（认证、审计、调查问卷）。
• 数据处理条款、所有权，以及退出时的数据删除，在合同中都已明确。
• 供应商的次级处理方和数据存放地点均已披露，且可被接受。
• 已核实其符合相关法规要求。
• 正常运行时间、支持和 SLA 承诺均已有文档记录。
• 数据泄露通知义务和时限均已写入合同。
• 访问权限被限定在最小权限范围内，并且是可撤销的。
• 已评估业务连续性以及供应商失效所带来的影响。
• 存在退出和数据迁移计划，以避免被锁定。
• 成本、续约条款和价格变动条款均已被理解。
• 该供应商已被加入风险登记册，并设有复审日期。

政府合规（ATO / FedRAMP 风格）就绪检查清单

用于需要正式运营授权（ATO）的系统。

• 系统边界和数据流已被定义并绘制成图。
• 数据已按影响等级和敏感程度进行分类。
• 适用的控制基线已被选定并加以裁剪。
• 一份系统安全计划记录了每一项控制措施是如何被实施的。
• 控制措施已被实施、留有证据，并与该计划相对应。
• 持续监控和漏洞扫描处于运行状态。
• 一份行动与里程碑计划正在追踪未结项发现事项直至整改完成。
• 访问控制、审计日志记录和身份管理均满足要求。
• 加密使用经批准的算法和经过验证的模块。
• 一份事件响应计划已有文档记录并经过测试。
• 一份应急与灾难恢复计划已有文档记录并经过测试。
• 已完成对各项控制措施的独立评估或审计。
• 授权官员已拥有授予授权所需的风险评估结果。
• 重新授权的触发条件和持续性授权的节奏均已被明确定义。