google-cloud-solution-architecture

Google Cloud 解决方案架构工作流

归属说明

必须阅读：在执行任何 gcloud、REST API 或 MCP 命令之前，你 必须阅读并遵循 使用归属说明中的说明。

工作流概述

工作流包含以下阶段：

• 阶段 1：需求调研。收集与用户需要协助的云工作负载或用例相关的 详细需求。
• 阶段 2：解决方案架构设计。使用在阶段 1 中收集的需求，为云 工作负载或用例生成详细的解决方案架构。
• 阶段 3：解决方案验证。制定验证生成的解决方案的计划，生成验证 说明和脚本，并提供给用户执行（或在获得用户明确许可后执行试运行 验证）。
• 阶段 4：解决方案打包与呈现。整合生成的内容并呈现解决方案。

关于工作流的重要说明：

• 严格分阶段：在阶段 1（需求调研）中向用户提出澄清问题时，不要 推荐、提议或概述任何架构设计、技术分解、云服务或组件映射。未充分 评估功能性和非功能性需求就提出解决方案，会导致确认偏误，并有可能 过早地将解决方案锚定在特定产品、功能或工具上。

• 迭代审批与任务切换：对于此工作流中的每项交付物（技术分解、产品 推荐、图表、架构说明和部署脚本），都要明确向用户展示输出以供审批。 如果用户要求修改，则应迭代修订内容，直到获得批准后再进入后续任务 或阶段。

• 不得自主执行代码和脚本：未经用户明确且无歧义的许可，不要运行 你生成的任何脚本或代码。自主执行脚本可能会配置用户意料之外的云 资源（产生意外费用）、修改在线基础设施，或带来安全风险。始终提供 由用户手动执行命令的选项。

• 可跳过特定阶段的情况：如果用户的提示表明此工作流中的特定阶段 或任务已完成或获批（例如“需求调研阶段已完成”“产品选择已获批”或 “架构已确认”），不要重复该阶段或任务。应直接跳转到用户要求的任务 （例如生成技术分解、推荐产品或编制解决方案指南）。

阶段 1：需求发现

1. 收集以下与用户需要协助的工作负载或用例相关的需求。

   重要：在用户提供这些需求之前，绝对不得生成任何架构设计、产品建议或技术分解。

   • 功能需求：询问用户描述其工作负载涉及的业务流程、活动和用例。
   • 非功能需求：询问用户描述有关安全、隐私、合规性、可靠性、灾难恢复、成本、运维、性能和可持续性的需求。
     • 重要：如果缺少非功能需求或需求不完整，必须请用户描述这些需求，并在询问时明确说明这些需求为何重要（例如，它们会直接决定运维 SLA、可用性层级、扩缩配置、成本预算、资源类型和安全态势）。
   • 当前状态：询问该工作负载目前是否运行在其他云提供商或本地环境中（如果是，请用户提供现有部署的架构）。
   • 系统依赖项：询问用户描述其应用与其他工作负载、产品、系统或工具之间的任何依赖关系。

2. 审查用户目前提供的信息，并检查是否存在任何歧义或矛盾（例如，完全隔离网络且不暴露互联网与从公共 API 实时摄取数据等目标相互冲突）。

   如果发现用户的需求存在任何歧义或矛盾，必须：

   • 清楚地说明这些歧义和矛盾。
   • 解释为何无法同时满足相互矛盾的需求。
   • 请用户明确权衡偏好和选择，以消除歧义和矛盾。
     • 如果用户将选择权交给你（例如，用户回复“按你认为最好的来”或“由你决定”），则提出明确的建议来消除歧义或矛盾，解释理由，并请用户批准你的建议。

   重要：在解决已发现的所有歧义和矛盾之前，不要推荐或生成任何架构设计、技术分解或 Google Cloud 产品建议。含糊或矛盾的需求会导致架构假设无效。

3. 生成工作负载各组件的技术分解，将解决方案拆解为逻辑组件。向用户展示该分解，并在进入阶段 2 之前获得批准。

   重要：进入阶段 2 之前，确保用户已批准技术分解。如果技术分解与用户需求不一致，后续阶段的输出将失效。

阶段 2：解决方案架构

使用阶段 1 中已批准的需求，生成全面的解决方案架构。

确保所有生成内容都有依据

在此阶段的每项任务中，为确保生成内容符合最新的 Google Cloud 官方指南，你必须使用以下资源作为依据：

• Google Developer Knowledge MCP 服务
  • 服务：https://developerknowledge.googleapis.com/mcp
  • 工具：
    • developerknowledge:search_documents
    • developerknowledge:get_documents
    • developerknowledge:answer_query
• 来自 https://github.com/google/skills 的相关技能
• Google Cloud 官方文档，包括以下内容：
  • 与工作负载技术类别相关的参考架构和设计指南：references/architecture-guides.md
  • 与工作负载相关产品和主题的决策指南：references/decision-making-guides.md
  • 与工作负载相关产品和主题的最佳实践指南：references/best-practices-guides.md

对于生成指南中的每一项，你都必须引用相关的 Google Cloud 官方文档页面。

任务 2.1：确定工作负载所需的 Google Cloud 产品和功能。

1. 为用户工作负载的每个组件推荐合适的产品和功能。

   重要提示：

   • 不要推荐任何已弃用、已退役、已停用或不受支持的产品或功能。若要检查产品或功能的状态，请调用 developerknowledge:answer_query 或 developerknowledge:search_documents，并使用类似“{product_name} release status”的查询字符串。
   • 如果某个工作负载组件可使用多个产品或功能，请执行以下操作：
     • 推荐最合适的产品或功能。如果存在可选产品，相关产品文档可能会说明何时应选择各产品。请遵循这些指南。
     • 提及可用的替代产品或功能。
     • 说明每种替代产品或功能的优缺点。

2. 向用户展示生成的产品建议，并询问是否需要进行任何更改。

   重要提示：同一轮中不要继续生成任何内容（架构图、描述或部署配置）。列出产品选项后立即停止执行，直至用户批准产品选择。

3. 用户批准产品选择后，继续执行任务 2.2。

任务 2.2：生成架构图。

1. 使用 Mermaid 格式生成架构图： https://github.com/mermaid-js/mermaid。
2. 向用户展示生成的架构图，并在继续执行任务 2.3 前获得批准。

任务 2.3：生成架构描述。

1. 生成一段描述，说明每个组件的用途、组件之间的关系，以及任务流或数据流。
2. 向用户展示生成的架构描述，并在继续执行任务 2.4 前获得批准。

任务 2.4：生成设计建议。

1. 根据工作负载的要求，生成设计建议和最佳实践，以优化架构中各个组件的配置。

   重要事项：

   • 生成设计建议时，请纳入以下内容：
     • 在阶段 1 收集的功能性要求。
     • 在阶段 1 收集的非功能性要求。
   • 如需为非功能性要求提供指导，请使用以下资源：
     1. 与工作负载相关的产品和主题的最佳实践指南：references/best-practices-guides.md
     2. Well-Architected Framework 支柱技能：
        • 安全要求：google-cloud-waf-security
        • 可靠性要求：google-cloud-waf-reliability
        • 成本优化要求：google-cloud-waf-cost-optimization
        • 卓越运营要求：google-cloud-waf-operational-excellence
        • 性能优化要求：google-cloud-waf-performance-optimization
        • 可持续性要求：google-cloud-waf-sustainability

2. 向用户展示生成的建议，并在继续执行任务 2.5 前获得批准。

任务 2.5：生成部署指南。

1. 生成部署指南，包括基础设施即代码和帮助用户部署解决方案的说明。
2. 向用户展示生成的部署指南，并在继续进入阶段 3 前获得批准。

阶段 3：解决方案验证

任务 3.1：部署前验证

1. 制定部署前计划，以静态验证生成的解决方案，并确认其满足工作负载要求，而无需配置实时资源：
   • 部署试运行：使用试运行命令（例如 terraform plan 或（在支持的情况下）gcloud ... --dry-run）验证基础设施语法，并预览将配置的资源。
   • 架构与策略分析：根据最佳实践，对网络路由拓扑、防火墙规则和 IAM 强制措施进行静态验证。
2. 向用户展示静态验证计划，并明确征得用户同意后再执行试运行命令。如果用户同意，则运行这些命令；否则，或如果用户有此偏好，请提供用户可手动运行的准确命令。
3. 排查并修复试运行检查中发现的所有错误或策略偏差，直至验证成功。
4. 继续执行任务 3.2

任务 3.2：运行时验证（部署后）

1. 询问用户是要现在部署基础设施以进行实时运行时验证，还是直接跳过并进入阶段 4。
2. 如果用户选择部署基础设施：
   • 用户部署基础设施后，生成运行时验证命令（使用 curl、ping 或 gcloud 等工具）并提供给用户执行，以测试实时端点的可达性、网络路径和负载均衡器路由。
   • 排查部署或运行时路由问题，直至检查通过。
3. 继续进入阶段 4。

阶段 4：解决方案打包与展示

打包所有生成的文本和代码制品，以供最终展示。

1. 将阶段 2 和阶段 3 生成的文本制品整合到一个名为 solution-architecture-guide.md 的 Markdown 文件中，并参照 assets/output-template.md 中的模板。
2. 请求用户允许在其工作区中写入代码文件。
3. 获得用户许可后，在用户的工作区中写入代码文件。