Back to Details

google-cloud-solution-architecture

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Google Cloud solution-architecture workflow

Google Cloud 解决方案架构工作流

Overview of the workflow

工作流概述

The workflow consists of the following phases:
  • Phase 1: Requirements discovery. Gather detailed requirements related to the cloud workload or use case that the user needs assistance for.
  • Phase 2: Solution architecture. Use the requirements that were gathered in Phase 1 to generate a detailed solution architecture for the cloud workload or use case.
  • Phase 3: Solution validation. Create a plan to validate the generated solution, generate validation instructions and scripts, and run the validation.
  • Phase 4: Solution packing and presentation. Consolidate the generated content and present the solution.
Important notes about the workflow:
  • Strict phase separation: During Phase 1 (Requirements discovery), when you ask the user clarifying questions, don't recommend, propose, or outline any architectural designs, technical decompositions, cloud services, or component mappings. Proposing solutions before functional and non-functional requirements are thoroughly assessed causes confirmation bias and risks anchoring the solution on specific products, features, or tools prematurely.
  • Iterative approval & task transitions: For each deliverable in this workflow (technical decompositions, product recommendations, diagrams, architectural descriptions, and deployment scripts), explicitly present your output to the user for approval. If the user requests modifications, iteratively revise the content until approved before progressing to the subsequent task or phase.
  • When you can skip certain phases: If the user's prompt indicates that a specific phase or task in this workflow is already completed or approved (e.g., "requirements discovery stage is completed", "product selection is approved", or "architecture is confirmed"), don't repeat that phase or task. Instead, skip directly to the requested task (such as generating the technical decomposition, recommending products, or compiling the solution guide).
该工作流包含以下阶段：
  • 阶段1：需求发现。收集与用户需要协助的云工作负载或用例相关的详细需求。
  • 阶段2：解决方案架构。利用阶段1收集到的需求，为云工作负载或用例生成详细的解决方案架构。
  • 阶段3：解决方案验证。创建计划以验证生成的解决方案，生成验证说明和脚本，并运行验证。
  • 阶段4：解决方案打包与展示。整合生成的内容并展示解决方案。
工作流重要说明：
  • 严格的阶段分离：在阶段1（需求发现）期间，当您向用户询问澄清问题时，请勿推荐、提议或概述任何架构设计、技术分解、云服务或组件映射。在全面评估功能和非功能需求之前就提出解决方案，会导致确认偏差，并存在过早将解决方案锚定在特定产品、功能或工具上的风险。
  • 迭代审批与任务过渡：对于此工作流中的每个交付物（技术分解、产品建议、图表、架构描述和部署脚本），请明确向用户展示您的输出以获取审批。如果用户要求修改，请迭代修订内容直至获得批准，然后再推进到后续任务或阶段。
  • 何时可跳过某些阶段：如果用户的提示表明此工作流中的特定阶段或任务已完成或获得批准（例如，“需求发现阶段已完成”、“产品选择已获批”或“架构已确认”），请勿重复该阶段或任务。而是直接跳转到请求的任务（例如生成技术分解、推荐产品或编制解决方案指南）。

Phase 1: Requirements discovery

阶段1：需求发现

  1. Gather the following requirements related to the workload or use case for which the user needs assistance.
    CRITICAL: You MUST NOT generate any architecture designs, product recommendations, or technical decompositions until the user provides these requirements.
    • Functional requirements: Ask the user to describe the business processes, activities, and use cases of their workload.
    • Non-functional requirements: Ask the user to describe requirements for security, privacy, compliance, reliability, disaster recovery, cost, operations, performance, and sustainability.
      • CRITICAL: If non-functional requirements are missing or incomplete, you MUST ask the user to describe the requirements and explicitly explain why they are important (e.g., because they directly dictate operational SLAs, availability tiers, scaling configuration, cost budgets, resource types, and the security posture) when asking the user to supply them.
    • Current state: Ask whether the workload currently runs on other cloud providers or on-premises (if yes, prompt for the architecture of the existing deployment).
    • System dependencies: Ask the user to describe any dependencies between their application and other workloads, products, systems, or tools.
  2. Review the input that the user has provided so far, and check whether there are any ambiguities or contradictions (e.g., conflicting goals like complete network isolation with zero internet exposure vs. real-time ingestion from public APIs).
    If you identify any ambiguities or contradictions in the user's requirements, you must:
    • Clearly describe the ambiguities and contradictions.
    • Explain why the contradictory requirements cannot be simultaneously satisfied.
    • Request the user to clarify their trade-off preferences and choices to resolve the ambiguities and contradictions.
    • If the user delegates the choice to you (e.g., the user replies with "do what you think is best" or "you decide"), then provide a clear suggestion to resolve the ambiguity or contradiction, explain your reasoning, and ask the user to approve your suggestion.
    CRITICAL: Until all the ambiguities and contradictions that you identify are resolved, don't recommend or generate any architecture design, technical decomposition, or Google Cloud product recommendations. Ambiguous or contradictory requirements lead to invalid architectural assumptions.
  3. Generate a technical decomposition of the components of the workload that breaks down the solution into logical components. Present it to the user and obtain approval before proceeding to Phase 2.
    CRITICAL: Before proceeding to Phase 2, ensure that the user has approved the technical decomposition. Misalignment of the technical decomposition with the user's requirements will invalidate the outputs of the subsequent phases in this workflow.
  1. 收集与用户需要协助的工作负载或用例相关的以下需求。
    关键要求：在用户提供这些需求之前，您绝对不能生成任何架构设计、产品建议或技术分解。
    • 功能需求：请用户描述其工作负载的业务流程、活动和用例。
    • 非功能需求：请用户描述有关安全性、隐私性、合规性、可靠性、灾难恢复、成本、运维、性能和可持续性的需求。
      • 关键要求：如果非功能需求缺失或不完整，您必须请用户描述这些需求，并在请求时明确解释其重要性（例如，因为它们直接决定了运维SLA、可用性层级、扩展配置、成本预算、资源类型和安全态势）。
    • 当前状态：询问工作负载当前是否在其他云提供商或本地环境运行（如果是，请提示用户提供现有部署的架构）。
    • 系统依赖关系：请用户描述其应用与其他工作负载、产品、系统或工具之间的任何依赖关系。
  2. 回顾用户目前提供的输入，检查是否存在任何模糊或矛盾之处（例如，完全网络隔离且无互联网暴露与从公共API实时摄取数据这类相互冲突的目标）。
    如果您发现用户需求中存在模糊或矛盾之处，必须：
    • 清晰描述这些模糊和矛盾之处。
    • 解释为什么相互矛盾的需求无法同时满足。
    • 请求用户明确其权衡偏好和选择，以解决模糊和矛盾问题。
    • 如果用户将选择权委托给您（例如，用户回复“做你认为最好的”或“你来决定”），则提供明确的建议来解决模糊或矛盾问题，解释您的推理，并请用户批准您的建议。
    关键要求：在您发现的所有模糊和矛盾问题得到解决之前，请勿推荐或生成任何架构设计、技术分解或Google Cloud产品建议。模糊或矛盾的需求会导致无效的架构假设。
  3. 生成工作负载组件的技术分解，将解决方案拆分为逻辑组件。将其展示给用户并获得批准后，再进入阶段2。
    关键要求：在进入阶段2之前，确保用户已批准技术分解。技术分解与用户需求不一致会使后续阶段的输出无效。

Phase 2: Solution architecture

阶段2：解决方案架构

Use the approved requirements from Phase 1 to generate a comprehensive solution architecture.
利用阶段1中获批的需求生成全面的解决方案架构。

Ground all generated content

基于所有生成内容

For each task in this phase, to ensure that the generated content aligns with the latest and official Google Cloud guidance, you must ground the generated content by using the following resources:
  • Google Developer Knowledge MCP server
  • Relevant skills from https://github.com/google/skills
  • Official Google Cloud documentation, including the following:
    • Reference architectures and design guides that are relevant to the technology category of the workload: 
      references/architecture-guides.md
    • Decision-making guides for the products and topics that are relevant to the workload: 
      references/decision-making-guides.md
    • Best-practices guides for the products and topics that are relevant to the workload: 
      references/best-practices-guides.md
For each item in the generated guidance, you must include citations to the relevant official Google Cloud documentation pages.
对于此阶段的每个任务，为确保生成的内容符合最新的官方Google Cloud指南，您必须使用以下资源来支撑生成的内容：
  • Google Developer Knowledge MCP服务器
  • 来自https://github.com/google/skills的相关skill
  • 官方Google Cloud文档，包括以下内容：
    • 与工作负载技术类别相关的参考架构和设计指南：
      references/architecture-guides.md
    • 与工作负载相关的产品和主题的决策指南：
      references/decision-making-guides.md
    • 与工作负载相关的产品和主题的最佳实践指南：
      references/best-practices-guides.md
对于生成的指导中的每个条目，您必须包含相关官方Google Cloud文档页面的引用。

Task 2.1: Identify Google Cloud products and features required for the workload.

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

  1. Recommend the products and features that are appropriate for each component of the user's workload.
    CRITICAL:
    • Don't recommend any products or features that are deprecated, retired, decommissioned, or unsupported. To check the status of a product or feature, call 
      developerknowledge:answer_query
      or 
      developerknowledge:search_documents
      with query strings like: "{product_name} release status".
    • If multiple products or features can be used for a component of the workload, then do the following:
      • Recommend the most appropriate product or feature. When alternative products exist, the relevant product documentation might provide guidance on when to choose each product. Follow that guidance.
      • Mention the available alternative products or features.
      • Explain the pros and cons of each alternative product or feature.
  2. Present the generated product recommendations to the user and ask whether any changes are needed.
    CRITICAL: Don't generate anything further (architecture diagrams, descriptions, or deployment configurations) in the same turn. Halt execution immediately after listing the product choices until the user approves the product selections.
  3. After the user approves the product selections, proceed to Task 2.2.
  1. 为用户工作负载的每个组件推荐合适的产品和功能。
    关键要求：
    • 请勿推荐任何已弃用、停用、退役或不支持的产品或功能。要检查产品或功能的状态，请调用
      developerknowledge:answer_query
      或
      developerknowledge:search_documents
      ，查询字符串如："{product_name} release status"。
    • 如果有多个产品或功能可用于工作负载的某个组件，请执行以下操作：
      • 推荐最合适的产品或功能。当存在替代产品时，相关产品文档可能会提供选择每个产品的指导，请遵循该指导。
      • 提及可用的替代产品或功能。
      • 解释每个替代产品或功能的优缺点。
  2. 将生成的产品建议展示给用户，并询问是否需要任何更改。
    关键要求：在同一轮交互中，请勿进一步生成任何内容（架构图、描述或部署配置）。列出产品选项后立即停止执行，直到用户批准产品选择。
  3. 用户批准产品选择后，进入任务2.2。

Task 2.2: Generate an architecture diagram.

任务2.2：生成架构图。

  1. Generate an architecture diagram in Mermaid format: https://github.com/mermaid-js/mermaid.
  2. Present the generated diagram to the user and obtain approval before proceeding to Task 2.3.
  1. 以Mermaid格式生成架构图：https://github.com/mermaid-js/mermaid。
  2. 将生成的图展示给用户并获得批准后，再进入任务2.3。

Task 2.3: Generate an architecture description.

任务2.3：生成架构描述。

  1. Generate a description that explains the purpose of each component, the relationships between the components, and the task flow or data flow.
  2. Present the generated architecture description to the user and obtain approval before proceeding to Task 2.4.
  1. 生成描述，解释每个组件的用途、组件之间的关系以及任务流或数据流。
  2. 将生成的架构描述展示给用户并获得批准后，再进入任务2.4。

Task 2.4: Generate design recommendations.

任务2.4：生成设计建议。

  1. Generate design recommendations and best practices to optimally configure each component in the architecture based on the workload's requirements. Important:
    • When generating design recommendations, incorporate the following:
      • Functional requirements that were gathered in Phase 1.
      • Non-functional requirements that were gathered in Phase 1.
    • To generate guidance for non-functional requirements, use the following skills, as appropriate: 
      • 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
    If any of the specialized 
    google-cloud-waf-*
    skills are not available in your current workspace, derive design guidance directly from the documentation references in 
    references/best-practices-guides.md
    .
  2. Present the generated recommendations to the user and obtain approval before proceeding to Task 2.5.
  1. 根据工作负载的需求，生成设计建议和最佳实践，以优化配置架构中的每个组件。 重要提示：
    • 生成设计建议时，请整合以下内容：
      • 阶段1中收集的功能需求。
      • 阶段1中收集的非功能需求。
    • 为生成非功能需求的指导，请根据情况使用以下skill： 
      • 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
    如果当前工作区中没有任何专用的
    google-cloud-waf-*
    skill，请直接从
    references/best-practices-guides.md
    中的文档参考中获取设计指导。
  2. 将生成的建议展示给用户并获得批准后，再进入任务2.5。

Task 2.5: Generate deployment guidance.

任务2.5：生成部署指导。

  1. Generate deployment guidance, including infrastructure-as-code and instructions to enable the user to deploy the solution.
  2. Present the generated deployment guidance to the user and obtain approval before proceeding to Phase 3.
  1. 生成部署指导，包括基础设施即代码（infrastructure-as-code）和使用户能够部署解决方案的说明。
  2. 将生成的部署指导展示给用户并获得批准后，再进入阶段3。

Phase 3: Solution validation

阶段3：解决方案验证

Task 3.1: Pre-deployment validation

任务3.1：部署前验证

  1. Create a pre-deployment plan to statically validate the generated solution and verify that it meets the workload's requirements without provisioning live resources:
    • Deployment dry-run: Validate infrastructure syntax and preview the resources that will be provisioned using dry-run commands (e.g., 
      terraform plan
      or (where supported) 
      gcloud ... --dry-run
      ).
    • Architecture & policy analysis: Perform static verification of network routing topologies, firewall rules, and IAM enforcement against best practices.
  2. Present the static validation plan to the user, obtain approval, and execute the dry-run commands.
  3. Troubleshoot and fix any errors or policy discrepancies identified during dry-run checks until validation succeeds.
  4. Proceed to Task 3.2
  1. 创建部署前计划，以静态方式验证生成的解决方案，并在不配置实时资源的情况下验证其是否满足工作负载的需求：
    • 部署预演（Deployment dry-run）：验证基础设施语法，并使用预演命令（例如
      terraform plan
      或（在支持的情况下）
      gcloud ... --dry-run
      ）预览将配置的资源。
    • 架构与策略分析：针对最佳实践，对网络路由拓扑、防火墙规则和IAM实施进行静态验证。
  2. 将静态验证计划展示给用户，获得批准后执行预演命令。
  3. 排查并修复预演检查中发现的任何错误或策略差异，直到验证成功。
  4. 进入任务3.2

Task 3.2: Runtime validation (Post-deployment)

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

  1. Ask the user whether they choose to deploy the infrastructure now to perform live runtime verification, or skip directly to Phase 4.
  2. If the user chooses to deploy the infrastructure:
    • After the user deploys the infrastructure, generate runtime verification commands (using tools like 
      curl
      , 
      ping
      , or 
      gcloud
      ) and provide them to the user to execute, to test live endpoint reachability, networking paths, and load balancer routing.
    • Troubleshoot any deployment or runtime routing issues until checks pass.
  3. Proceed to Phase 4.
  1. 询问用户是否选择立即部署基础设施以执行实时运行时验证，还是直接跳转到阶段4。
  2. 如果用户选择部署基础设施：
    • 用户部署基础设施后，生成运行时验证命令（使用
      curl
      、
      ping
      或
      gcloud
      等工具）并提供给用户执行，以测试实时端点可达性、网络路径和负载均衡器路由。
    • 排查任何部署或运行时路由问题，直到检查通过。
  3. 进入阶段4。

Phase 4: Solution packaging and presentation

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

Package all the generated text and code artifacts for final presentation.
  1. Consolidate the text artifacts that were generated in Phase 2 and Phase 3 into a single Markdown file named 
    solution-architecture-guide.md
    , based on the template in 
    assets/output-template.md
    .
  2. Request the user's permission to write the code files in the user's workspace.
  3. After the user gives permission, write the code files in the user's workspace.
打包所有生成的文本和代码工件以进行最终展示。
  1. 将阶段2和阶段3中生成的文本工件整合到一个名为
    solution-architecture-guide.md
    的Markdown文件中，基于
    assets/output-template.md
    中的模板。
  2. 请求用户允许在其工作区中写入代码文件。
  3. 用户允许后，在其工作区中写入代码文件。