SRE Production Rediness Review 指南（From GitLab.com）

原文地址

个人认为这篇写的特别好，列出了 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 管道中针对此功能自动运行哪些测试？