原文地址
个人认为这篇写的特别好，列出了 Production Rediness Review 需要注意的各个潜在风险点。
下面是全文内容，对极少部分无关紧要的地方做了删减。
Production Readiness生产准备
对于生产中的功能或服务的任何新的或更改，本指南中的问题将有助于使这些更改在 GitLab.com 上启用时更加健壮。 在开始之前，请查看手册中的生产准备审查文件。 此问题作为跟踪问题来指导您完成准备情况审查。这不是生产准备文件本身！
准备文件将通过合并请求添加到项目中，不同的相关方可以在其中进行协作。
Readiness MR
创建准备 MR 时添加链接
审核人
清单的步骤之一。如果“必填”部分的审稿人未被分配，请在姓名旁边注明原因。
如果您不确定应该指定谁作为审阅者，请联系任何基础设施工程经理寻求帮助。
要从 InfraSec 团队指派审阅者，请在专用于“一切照旧”(BAU) 的问题跟踪器中创建一个问题。这将帮助团队对审查进行分类并开始处理。团队手册页面上提供了更多信息。创建问题后，在下面的 Infrasec 审阅者项目旁边放置一个指向该问题的链接，并在分配一个审阅者后添加审阅者姓名。
审阅完成后，审阅者将选中其姓名旁边的框
强制的
- 可靠性：审稿人姓名
- 交付：审稿人姓名
- 安全：审稿人姓名
可选的
如果不适用，请删除这些审稿人
- 开发：审稿人姓名
- 可扩展性：审稿人姓名
- 数据库：审稿人姓名
Readiness Checklist
启动准备审查的人员应完成以下项目：
- 创建此问题并将其分配给自己。为您认为准备工作完成的时间设置截止日期（如有必要，可以稍后更新）。
- 查看生产准备审查手册页面。
- 在上面的“审稿人”部分中，添加审稿人姓名。将通过联系相应团队的工程经理来分配名称。
- 通过复制下面的模板并提交 MR 创建准备审查的初稿，添加标签工作流程基础设施进行中到这个问题。
- 在本期顶部的“Readiness MR”部分添加指向 MR 的链接
- 将初始集审阅者分配给 MR。如果需要，MR 可以有多次迭代，通常让同一团队中的团队成员审阅初稿会很有帮助。MR 的批准并不意味着就绪文件得到批准，稍后将在这个问题上进行批准。
- 当 MR 的最后一次审查完成后，如果他们对审查感到满意并且没有更多问题或疑虑，请要求上面“审查者”部分中的审查者选中他们姓名旁边的框。
- （可选）如果后来决定不继续执行此提案，请添加工作流程基础设施取消并关闭这个问题
在“审阅者”部分选中所有框后，添加工作流程基础设施完毕标记并关闭问题。
生产准备MR 模板【下面这些都是重点部分】
使用以下内容创建 <name>/index.md 作为新的合并请求，其中对所提议的更改进行简短描述
概要
- 提供此新产品功能的高级摘要。解释这一变化将如何使 GitLab 客户受益。列举客户用例。
- 应监控哪些指标（包括业务指标）以确保此功能的发布会取得成功？
架构
- 在本期功能组件中添加架构图，以及它们如何与现有的 GitLab 组件交互。确保包括以下内容：内部依赖项、端口、加密、协议、安全策略等。
- 描述新功能的每个组件并列举它为支持客户用例所做的工作。
- 对于每个组件和依赖项，故障的爆炸半径是多少？功能设计中有什么可以降低这种风险的吗？
- 如果适用，请解释此新功能将如何扩展以及设计中任何潜在的单点故障。
操作风险评估
- 此更改可能导致哪些潜在的可伸缩性或性能问题？
- 列出此功能对应用程序（例如：redis、postgres 等）的外部和内部依赖项，以及服务将如何受到该依赖项故障的影响。
- 是否有任何功能削减或妥协以启动该功能？
- 列出此功能上线时的前三大运营风险。
- 有哪些操作问题不会在发布时出现，但可能会在以后出现？
- 新产品功能上线后是否可以安全回滚，是否可以使用功能标志将其禁用？
- 记录客户与此新功能交互的每一种方式，以及每次交互失败对客户的影响。
- 作为一个思想实验，想想这个产品功能最坏的故障场景，如何隔离故障的爆炸半径？
数据库
- 如果我们使用数据库，数据库团队是否验证和审查了数据结构？
- 我们是否有存储数据的近似增长率（用于容量规划）？
- 我们可以老化数据并删除特定年龄的数据吗？
安全和合规
我们是否添加了以下类型的任何新资源？（如果是，请在此处列出它们或链接到列出它们的地方）
- AWS 账户/GCP 项目
- 新的子网
- VPC/对等网络
- DNS名称
- 暴露于 Internet 的入口点（公共 IP、负载均衡器、存储桶等...）
- 其它
安全软件开发生命周期 (SSDLC)
- 配置是否遵循安全标准？（例如，CIS 是一个很好的基准）
- 所有云基础设施资源都根据基础设施标签和标签指南进行标记
- 此功能是否遵循GitLab 安全开发指南？
- 我们是否有一个自动程序来更新基础设施（操作系统、容器镜像、包等...）
- 我们是否将 IaC (Terraform) 用于与此功能相关的所有基础设施？如果不是，什么样的资源没有被涵盖？
- 我们是否有涵盖此功能地形的安全静态代码分析工具（kics或checkov ）？
- 如果有一个新的terraform状态：
- terraform 状态存储在哪里，谁可以访问它？
- 此功能是否为 Terraform 状态添加了秘密？如果是，它们可以存储在机密管理器中吗？
- 如果我们正在创建新容器：
- 我们使用的是 distroless 基础镜像吗？**
- 我们有覆盖这些容器的安全扫描器吗？
kics或者checkov例如 Dockerfiles- GitLab 的容器漏洞扫描器
身份和访问管理
- 我们是否添加了任何新形式的身份验证（新服务帐户、用于存储的用户/密码、OIDC 等...）？
- 它是否遵循最小特权原则？
如果我们要添加任何新的数据存储（数据库、桶等...）
- 每个系统上存储了什么样的数据？（秘密、客户数据、审计等...）
- 根据我们的数据分类标准如何对数据进行评级（客户数据为红色）
- 静态数据是否加密？（如果存储由 GCP 服务提供，答案很可能是肯定的）
- 我们有关于数据访问的审计日志吗？
网络安全（加密和端口在上面的架构图中要清楚）
- 防火墙遵循最小特权原则（使用 Kubernetes 中的网络策略或云提供商的防火墙）
- 该服务是否包含在任何 DDoS 保护解决方案中（GCP/AWS 负载均衡器或 Cloudflare 通常包含此内容）
- 服务是否受 WAF（Web 应用程序防火墙）的保护
日志和审计
- 是否已努力在日志中隐藏或删除敏感的客户数据?
遵守
- 该服务是否符合任何监管/合规标准？如果是，请详细说明并提供有关适用控制、管理流程、额外监控和缓解因素的详细信息。
性能
- 解释根据 GitLab 的性能指南进行了哪些验证。请解释使用了哪些工具并链接到下面的结果。
- 在 GitLab.com 规模上启用此功能时，是否会对数据库产生任何潜在的性能影响？
- 此功能是否有任何限制？如果有，他们是如何管理的？
- 如果有节流限制，达到限制的客户体验是什么？
- 对于应用程序外部和内部的所有依赖项，是否有针对它们的重试和退避策略？
- 该功能是否考虑了至少比预期 TPS 高出 2 倍的短暂流量高峰？
备份和还原
- 除了现有备份之外，是否还有任何其他客户数据需要为此产品功能进行备份？
- 是否监控备份？
- 是否测试了从备份恢复？
监控和告警
- 服务是否以 JSON 格式记录并且日志是否转发到 logstash？
- 服务是否向 Prometheus 报告指标？
- 如何衡量端到端的客户体验？
- 我们是否为此服务制定了目标 SLA？
- 我们知道映射到目标 SLA 的指标 (SLI) 是什么吗？
- 我们是否有在未满足 SLI（以及 SLA）时触发的警报？
- 我们是否有与这些警报相关联的故障排除操作手册？
- 对于与此功能相关的中断，发布推文或发布官方客户通知的门槛是多少？
- 负责此服务的 oncall 轮换是否可以使用此服务？**
责任
- 哪些人是主题专家并且最了解此功能？
- 一旦功能投入生产，哪个团队或一组人将对该功能的可靠性负责？
- 团队中是否有人在发布时oncall？如果不是，为什么？
测试
- 描述用于此功能的负载测试计划。验证了哪些断点？
- 对于根据该功能理论化的组件故障，是否对其进行了测试？如果是这样，请包括这些失败测试的结果。
- 简要概述一下在 GitLab 的 CI/CD 管道中针对此功能自动运行哪些测试？
