接手 GCP 项目与故障演练
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
接手已有 Project 时，先确认项目身份、运行责任和当前健康状态，再安排变更。一个业务系统可能跨多个 Project；每个 Project 分别盘点，并记录跨项目依赖。初次盘点使用获批的只读权限，未知项标记为待确认。
接手顺序#
| 要回答的问题 | 查看位置或命令 |
|---|---|
| 谁付费、项目归谁、有哪些环境？ | Billing、Resource Manager、组织/文件夹层级 |
| 人和程序分别是谁？ | IAM、Groups、SA、WIF provider、审计日志 |
| 请求从哪里进来？ | DNS → LB / IAP → Cloud Run / GKE / VM |
| 数据存在哪里、如何恢复？ | SQL、Storage、Pub/Sub、BigQuery、备份与保留策略 |
| 如何发布与回滚？ | 仓库、Cloud Build/GitHub、镜像 digest、Terraform state |
| 如何知道业务坏了？ | SLO、告警接收人、日志关联字段、值班手册 |
快速盘点#
| 要完成的检查 | 留下的证据 |
|---|---|
| 核对当前身份、Project ID / Number、Organization / Folder、环境、业务与技术负责人 | 明确正在接手哪个 Project，以及关联的其他 Project |
| 查看 Asset Inventory、已启用 API 和各服务资源列表 | 找到入口、计算、数据库、存储、消息与定时任务 |
| 找代码与 Terraform 仓库、CI/CD、制品、部署身份、最近一次发布 | 能说清发布审批与回滚入口 |
| 看监控面板、未关闭告警、近期错误日志和值班通知渠道 | 判断当前健康状态，知道故障找谁 |
| 看 Project、Folder、Organization 与关键资源的 IAM，确认运行 SA 和部署身份 | 列出高权限主体及授权来源 |
| 核对 Billing account、近 30 天成本趋势、预算及告警接收人 | 知道谁承担费用、谁处理异常 |
先向原负责人索取架构图、值班手册、部署和回滚说明、备份恢复记录、近期事故与重大变更。凭据只记录保管位置和负责人，不通过交接记录传递口令或私钥。
下面是只读盘点示例。显式指定 Project，避免复用其他项目的 CLI 默认值；部分资源命令还需指定实际 Region。没有相应权限时记录缺口，请管理员提供清单，不为盘点申请 Owner。
PROJECT_ID='REPLACE_PROJECT_ID'
REGION='REPLACE_REGION'
gcloud auth list
gcloud config list
gcloud projects describe "$PROJECT_ID"
gcloud services list --enabled --project="$PROJECT_ID"
gcloud asset search-all-resources --scope="projects/$PROJECT_ID"
gcloud projects get-iam-policy "$PROJECT_ID" --format=json
gcloud run services list --project="$PROJECT_ID" --region="$REGION"
gcloud compute instances list --project="$PROJECT_ID"
gcloud sql instances list --project="$PROJECT_ID"
gcloud pubsub subscriptions list --project="$PROJECT_ID"
gcloud artifacts repositories list --project="$PROJECT_ID" --location="$REGION"Project 的 IAM 输出不是完整有效权限清单。 还要检查 Folder / Organization 继承、各资源 policy 和 Group 授权。Asset Inventory 也不覆盖所有资源类型；查询不到不能证明资源不存在。先完成盘点再变更。
第一天：确认能否运营#
- 沿“DNS → 入口 → 应用 → 数据/消息 → 外部依赖”画出实际请求路径，标明 Region、Project、负责人和故障时的联系人。
- 核对发布审批、流水线、运行身份、制品来源与回滚手册。找最近一次成功发布的记录；真实回滚演练应约定维护窗口。
- 核对关键告警的通知接收人、值班升级路径和未关闭事件。检查日志位置、保留期及 Data Access 审计日志是否按需启用。
- 列出关键数据、备份状态、RPO / RTO、最近恢复演练及其业务核对证据。只有“备份成功”不足以证明可恢复。
- 检查账单趋势、预算通知和成本归属；告警型预算不会自动阻止消费。发现风险时记录负责人和处理期限，不直接删除未知资源或授权。
第一周：完成正式交接#
- 与原负责人核对架构图、跨项目依赖、关键 SA、权限申请与撤销渠道。
- 跟班处理一次常见告警，并走查发布、回滚及恢复步骤；记录实际入口和卡点。
- 补齐无人接收的告警、无负责人的资源和未验证的恢复流程，分别建立跟进项。
- 请业务和技术负责人确认交接记录、值班渠道与未关闭风险。
交接记录模板#
每个 Project 复制一份；敏感信息只填写管理入口或保管位置。
| 项目 | 记录 |
|---|---|
| 日期、记录人、Project ID / Number、环境、Organization / Folder | |
| 业务负责人、技术负责人、值班与升级渠道 | |
| 架构图、代码 / IaC 仓库、关键服务与跨项目依赖 | |
| 发布审批、部署身份、最近发布、回滚手册 | |
| 监控面板、告警接收人、未关闭事件、日志位置与保留期 | |
| 关键数据、备份状态、RPO / RTO、最近恢复演练 | |
| Billing account、费用负责人、近 30 天趋势、预算告警 | |
| 高权限组、关键 SA、权限申请与撤销渠道 | |
| 未确认事项 / 风险 / 负责人 / 完成期限 | |
| 原负责人确认日期 |
初步接手完成时，应能回答：系统现在是否健康、故障找谁、如何发布与回滚、关键数据如何恢复、费用由谁处理。尚未验证的控制保留为待办。权限与成本的进一步盘点见 资源治理；日志和告警见 Logging 与 Monitoring。
综合项目故障表#
| 注入 | 预期信号 | 恢复与验收 |
|---|---|---|
| 撤销 API SA 的 topic publisher | POST 返回 5xx，日志 PermissionDenied | 恢复 topic binding，重新提交同一订单 ID |
| 撤销 worker 的 Bucket objectCreator | SQL 已存在订单，push 返回 5xx，重投增加 | 恢复权限；对象补齐；SQL 仍只有一行 |
| 禁用 DB Secret 后发布新 worker revision | 新实例不能读取密码，部署/启动失败 | 启用版本，恢复已知健康 revision |
| 删除 NAT（仅网络实验） | 无公网 IP VM 不能访问普通互联网 | 重建 NAT，验证公网 HTTPS |
| 发布坏镜像 | 新 revision 不健康或错误率升高 | 将流量切回旧 revision |
| 删除 SQL 测试行 | 业务结果缺失 | 在独立恢复实例/实验实例恢复备份，核对记录 |
每次只注入一个故障，记录开始时间、发现时间、根因、恢复时间。云 IAM 有传播延迟，恢复后重复验证。
运维交付检查#
- 一张包含身份和网络路径的架构图。
- 可复建的命令或 IaC、镜像 digest、配置清单。
- 至少一次拒绝访问、消息重投、告警、发布回滚、数据恢复证据。
- 资源费用清单和清理结果。
把“服务健康”与“业务完成”分开：HTTP 202 只代表接受，订单在 SQL 和归档对象中出现才算本项目处理完成。
新项目还要检查#
- DNS：父域委派、公共/私有视图、TTL、DNSSEC；证书：到期、自动续期与验证记录。
- 入口：CDN 是否误缓存私有内容，WAF 是否能绕过，员工登录与机器调用是否共用错误入口。
- 异步：Scheduler 重复运行、Tasks 重试上限、Eventarc 过滤范围、消息积压和死信补偿。
- 数据：SQL 恢复与对象/缓存/查询投影是否一致，KMS 旧版本是否仍被数据使用。
- 治理：区域与服务配额、账单导出、无人认领资源、清理后的保留数据费用。