Google Cloud 解决方案架构输出模板详解基于 skills29 仓库编写标准化架构报告指南【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文围绕 google-cloud-solution-architecture 技能中的 output-template.md 模板展开系统讲解如何基于该模板将「需求收集—产品选型—架构设计—部署验证」全流程的产出汇编成一份结构统一、可审计、可复用的 Google Cloud 解决方案架构报告。读者完成本文后将掌握模板八个章节的定位、填写要点、Mermaid 架构图画法、Well-Architected 支柱设计建议的组织方式以及部署与验证计划的编写规范并了解模板与技能四阶段工作流的对应关系。一、模板在技能工作流中的定位在skills29/skills仓库中google-cloud-solution-architecture 是一个面向复杂负载的端到端云架构设计技能它交互式地收集需求设计跨多个产品的整体系统架构、解决方案蓝图与部署建议。该技能在工作流的最后阶段Phase 4Solution packing and presentation要求把所有阶段产生的文本与代码工件合并为一份名为solution-architecture-guide.md的 Markdown 报告合并所依据的标准骨架正是assets/output-template.md。模板头部有一段说明性注释点明其用途基于SKILL.md中的指令使用此模板来汇编所生成的内容。因此模板不是一份「文档」而是一张结构化的内容编排清单——它规定了报告必须包含哪些章节、每章节必须回答哪些问题、哪些内容必须使用表格或图表呈现从而保证不同架构师、不同负载产出的报告在结构上一致便于评审、审计与后续维护。要正确使用模板需要先理解驱动它的四阶段工作流详见 SKILL.md阶段名称产出物与模板章节的对应关系Phase 1Requirements discovery需求发现功能/非功能需求、当前状态、依赖清单、技术分解technical decomposition第 2、3 章Phase 2Solution architecture方案设计产品映射、Mermaid 架构图、架构描述、设计建议、部署指引第 4、5、6 章Phase 3Solution validation方案验证静态 dry-run 验证计划、运行时验证命令第 7 章Phase 4Solution packaging打包呈现基于模板合并成solution-architecture-guide.md全文该工作流还强调三个重要约束直接决定模板各章节能否被正确填写严格分阶段Phase 1 期间只允许提问澄清需求禁止提前给出架构设计、技术分解或产品建议以避免锚定偏差confirmation bias——这保证了模板第 4 章的产品选择真正由需求驱动。迭代审批技术分解、产品推荐、图表、架构描述、部署脚本等每个交付物都要显式呈现给用户审批批准后才进入下一任务因此模板的每一章都对应一次「已获批准的中间产物」。禁止擅自执行代码除非获得用户明确许可不得运行生成的任何脚本或代码避免意外开通云资源产生费用或改动线上基础设施应始终提供让用户手动执行命令的选项。这对应模板第 6 章的部署指引以「供用户执行」的方式交付以及第 7 章验证计划必须先征得许可再执行 dry-run。二、模板整体结构与文档目录对照模板共八个顶层章节结构如下Executive summary and workload overview执行摘要与负载概览Requirements and current state需求与现状Technical decomposition of the workload负载技术分解Proposed solution architecture拟议解决方案架构Design and configuration recommendations设计与配置建议Deployment guidance部署指引Validation plan验证计划References参考资料这八章构成了从「为什么做」摘要、需求到「做什么」分解、架构、再到「怎么做」设计建议、部署、验证的完整叙事链。模板在仓库中位于 assets/output-template.md而驱动内容生成的三份 Grounding 资料分别位于references/architecture-guides.md按技术类别组织的官方参考架构与设计指南索引基础、AI/ML、应用开发、安全合规、可靠性容灾、数据与分析、数据库、迁移、网络、混合多云、金融、监控、存储等 13 个类别用于支撑第 4 章产品选择与第 5 章设计建议的「引用官方文档」要求。references/best-practices-guides.md按产品组织的最佳实践文档索引BigQuery、Cloud Run、GKE、Compute Engine、IAM、Spanner、Cloud SQL、Cloud Storage 等 24 类用于填充第 5 章各支柱的最佳实践细节。references/decision-making-guides.md面向「二选一/多选一」场景的决策指南表如 Cloud Run 适用性清单、GKE vs Cloud Run、负载均衡选型、数据库选型、Pub/Sub 家族对比等用于第 4.1 节中「替代方案及优劣势」的论证。模板还要求内容 Grounding生成任何建议都必须引用官方 Google Cloud 文档且不得推荐已弃用、退役或不受支持的产品/特性。三、第 1 章执行摘要与负载概览Executive summary模板第 1 章要求用一段简短文字描述负载Workload、其业务目标以及所提出的高层级解决方案架构。它位于报告最前面是评审者架构委员会、安全团队、财务最先阅读的部分。填写要点负载是什么一句话说清业务系统定位例如「面向零售的多租户电商平台」「面向保险理赔的生成式 AI 文档处理系统」。业务目标负载要解决的核心业务问题以及成功度量维度吞吐、用户规模、合规要求等。高层级方案概述采用的部署形态区域性/多区域/全局/混合/多云与核心 Google Cloud 服务组合但不展开细节——细节属于第 4 章。由于模板第 1 章的输入来自 Phase 1 的需求收集结果此章节应当在需求获批后再撰写避免描述与最终选型不一致。仓库中的同族技能例如 google-cloud-solution-n-tier-serverless-web-app也要求基于output-template.md输出标准化报告结构印证了该模板在整个 solution 技能族中的通用地位。四、第 2 章需求与现状Requirements and current state第 2 章是四阶段工作流 Phase 1 产物的归档包含四个子节2.1 功能需求Functional requirements模板要求覆盖业务流程Business processes负载支撑的业务流程细节活动与用例Activities and use cases关键活动与用例。2.2 非功能需求Non-functional requirements模板明确列出六大非功能维度每一项都必须显式填写维度模板要求的细节Security安全合规、加密、访问控制要求Reliability可靠性SLA、RTO/RPO、备份、冗余要求Cost成本成本约束与计费模式Operations运维监控、日志、部署、维护要求Performance性能延迟、吞吐、扩缩容要求Sustainability可持续性碳足迹、资源优化要求依据 SKILL.md若非功能需求缺失或不完整技能必须向用户追问并显式解释其重要性——它们直接决定运维 SLA、可用性等级、扩缩容配置、成本预算、资源类型与安全态势。这意味着 2.2 节不能留空每个维度都要有可度量的表述例如「RPO ≤ 1 小时」「P99 延迟 200 ms」。2.3 当前状态Current state模板标注「如适用」用于描述负载当前的本地数据中心on-premises或其它云上架构现有基础设施Current infrastructure现有部署细节迁移/重设计的痛点与动因Pain points and drivers驱动迁移或重设计的原因。2.4 依赖Dependencies内部依赖Internal dependencies与其它负载、内部服务的依赖外部依赖External dependencies第三方产品、本地工具等外部依赖。模板整体以「问题填写占位提示」的方式组织例如[Details of ...]形式在最终交付的solution-architecture-guide.md中这些占位符必须全部替换为真实内容。仓库同族技能甚至明确要求「不得输出字面模板占位注释」参见 google-cloud-solution-n-tier-serverless-web-app/SKILL.md 中关于 No Unpopulated Placeholders 的约定这一约定对本模板同样适用。五、第 3 章负载技术分解Technical decomposition第 3 章要求将负载的技术组件分解为逻辑服务或层。它是 Phase 1 的收尾产物且必须先经用户批准才能进入 Phase 2——SKILL.md 明确指出技术分解与用户需求不一致会使后续所有阶段产出失效。填写要点按职责拆分入口/网关、应用层、数据处理、存储层、消息中间件、批处理任务等每个逻辑组件应能映射到后续第 4.1 节的某一行「产品映射」即分解是产品选型的输入不在此章推荐具体产品——产品选择属于 Phase 2。六、第 4 章拟议解决方案架构Proposed solution architecture第 4 章是报告核心由三个子节构成分别对应 Phase 2 的 Task 2.12.3。4.1 Google Cloud 产品与特性映射表模板要求以表格形式完成「组件 → 推荐产品 → 选型依据与引用 → 考虑的替代方案 → 替代方案优劣势」的映射。表格列结构如下列内容Component组件名应来自第 3 章技术分解Recommended Google Cloud product/feature推荐产品/特性Justification and citations选型理由引用官方文档Alternatives considered考虑的替代产品Pros and cons of alternatives替代方案优点Pros与缺点Cons用br分隔依据 SKILL.md 的 Task 2.1 规则不得推荐已弃用/退役/不受支持的产品或特性可通过developerknowledge:answer_query或search_documents以「{product_name} release status」之类的查询核实产品状态当多个产品可服务同一组件时推荐最合适者同时列出替代方案并说明各自优缺点选型论证应优先参考 decision-making-guides.md 中与负载相关的决策主题以及 architecture-guides.md 中对应技术类别的参考架构。4.2 架构图Mermaid模板要求使用Mermaid 格式绘制架构图展示组件之间的关系与流转并给出了示例骨架填写要点节点语义与 4.1 的产品映射保持一致图例/标注建议与 4.3 的架构描述呼应方向建议使用graph TDTop-Down用户节点用([User])、负载均衡用方框、数据库用[(...)]圆柱形保持可读性依据 Task 2.2生成的图必须先向用户展示并获得批准再进入架构描述撰写。4.3 架构描述Architecture description模板要求详细描述架构并明确从两个视角展开数据流Data flow数据如何在组件间流转任务/控制流Tasks/control flow任务或控制如何流转。依据 Task 2.3此描述要解释每个组件的用途、组件间关系、任务流与数据流同样需要用户批准后再进入下一步。七、第 5 章设计与配置建议Design and configuration recommendations第 5 章按Google Cloud Architecture Framework 的六大支柱组织最佳实践与配置建议每个支柱给出模板列出的具体切入点支柱模板给出的切入点5.1 Security, privacy, and compliance访问控制IAM 角色、最小权限、数据保护静态/传输加密、Cloud KMS、网络安全VPC、防火墙、Cloud Armor、Private Service Connect5.2 Reliability冗余部署多区域/区域部署、负载均衡、备份与容灾备份、故障切换流程、RTO/RPO 策略5.3 Operational excellence监控与日志Cloud Logging、Cloud Monitoring、Dashboards、基础设施即代码Terraform、Deployment Manager5.4 Cost optimization规模与伸缩自动扩缩容配置、资源合理配比、计费模式承诺折扣、Spot VM、固定费率定价5.5 Performance efficiency缓存与 CDNCloud CDN、Memorystore、数据库与查询优化分区、索引、缓存5.6 Sustainability无服务器采用、资源利用率、碳足迹这一章对应 Phase 2 的 Task 2.4。依据 SKILL.md生成非功能需求对应的建议时应优先使用仓库内现成的六个 Well-Architected FrameworkWAF专项技能google-cloud-waf-securitygoogle-cloud-waf-reliabilitygoogle-cloud-waf-cost-optimizationgoogle-cloud-waf-operational-excellencegoogle-cloud-waf-performance-optimizationgoogle-cloud-waf-sustainability若工作区中没有上述任一 WAF 技能则直接依据 best-practices-guides.md 中的文档索引推导设计建议。因此第 5 章每一条建议都应能溯源到「WAF 技能或官方最佳实践文档」这与模板「Ground all generated content」的要求一致。八、第 6 章部署指引Deployment guidance第 6 章对应 Phase 2 的 Task 2.5要求给出部署架构的指令与代码通常包含基础设施即代码并包含两个固定子节。6.1 部署前置条件Deployment prerequisites模板给出的示例条目类型包括启用 APIEnabling APIs安装 SDK/工具Installing SDK/tools其它必备条件。前置条件应可执行、可核对例如gcloud auth login、gcloud config set project、启用对应产品的 API、安装 Terraform 并验证版本等。6.2 逐步部署指令Step-by-step deployment instructions模板给出的步骤示例使用 Google Cloud 进行认证初始化 Terraform如terraform init应用 Terraform 配置如terraform apply。填写要点结合仓库同族技能约定若在报告中内嵌代码或脚本必须内联完整真实的 Terraform 代码、gcloud 命令与验证脚本不得输出字面模板占位注释部署顺序建议遵循「自底向上」的依赖顺序先 VPC/子网再数据层再内部微服务最后公共网关与负载均衡跨服务传递参数如从gcloud run services describe提取status.url时应通过 shell 变量显式传递。模板第 6 章还隐含了 Task 2.5 的审批要求部署指引完成后需向用户展示并获批准才能进入 Phase 3。九、第 7 章验证计划Validation plan第 7 章对应 Phase 3要求给出验证生成方案是否满足负载需求的步骤并包含对任何已生成验证脚本的引用。依据 SKILL.md验证计划分两个层次Task 3.1 部署前静态验证Pre-deployment validation部署 dry-run使用terraform plan或支持--dry-run的gcloud ... --dry-run命令校验基础设施语法并预览将开通的资源架构与策略分析对网络路由拓扑、防火墙规则、IAM 实施情况做静态核查对照最佳实践静态验证计划必须先呈现给用户并获得执行 dry-run 的明确许可若用户不同意或希望自行执行则提供可由用户手动运行的精确命令对 dry-run 检查发现的错误或策略不一致进行排查修复直至验证通过。Task 3.2 运行时验证Runtime validation, post-deployment询问用户是现在部署基础设施进行真实运行时验证还是直接跳到 Phase 4若用户选择部署则生成运行时验证命令如curl、ping、gcloud交给用户执行测试在线端点可达性、网络路径与负载均衡路由排查部署或运行时路由问题直至检查通过。因此第 7 章在报告中应明确区分「静态验证」不需要真实资源与「运行时验证」需要已部署资源并把两部分的验证命令、预期结果、以及验证脚本的文件引用都记录在案形成可回溯的验证证据链。十、第 8 章参考资料References模板第 8 章用于汇总报告引用的官方文档模板示例给出了两条参考格式横向可扩展性、区域托管实例组。结合前文 Grounding 要求参考资料应来源于architecture-guides.md 中与负载技术类别匹配的参考架构例如部署原型对比、区域性部署、灾难恢复场景等decision-making-guides.md 中用于支持选型决策的主题文档best-practices-guides.md 中对应推荐产品的最佳实践文档。引用应精确到具体页面作为第 4.1 节选型依据与第 5 章设计建议的可验证支撑。十一、模板的使用流程与质量自检清单综合模板与 SKILL.md 的 Phase 4 收尾要求使用该模板的标准流程如下完成并批准Phase 13 的全部中间产物需求、分解、产品映射、架构图、架构描述、设计建议、部署指引、验证计划合并将 Phase 2 与 Phase 3 生成的文本工件合并为单个 Markdown 文件solution-architecture-guide.md结构严格遵循assets/output-template.md请求许可向用户申请在工作区写入代码文件的权限写文件获准后将代码文件写入用户工作区。提交报告前的质量自检清单占位符清零[Details of ...]、[Component Name]等模板占位全部替换为真实内容不输出字面模板注释引用完整每个产品选型与设计建议都有对应官方文档引用且未推荐任何已弃用产品图与文一致Mermaid 架构图中的节点与 4.1 产品映射、4.3 架构描述中的组件名称保持一致验证可执行第 7 章的 dry-run 与运行时验证命令完整、可复制且已标注哪些需要真实资源审批记录齐全各章节对应的审批节点分解、产品、图、描述、建议、部署均有明确结论。十二、总结assets/output-template.md是google-cloud-solution-architecture技能交付环节的结构基石它将四阶段工作流的全部产出压缩为一份八个章节的标准化架构报告以执行摘要开篇以需求与现状为设计输入以技术分解衔接以产品映射、Mermaid 架构图与架构描述构成方案主体以六大 WAF 支柱组织设计建议以部署指引和验证计划确保方案可落地、可验收最终以参考资料保证每条结论可溯源。对架构师而言这份模板既是「内容清单」也是「质量门」——严格按章节填写并执行审批与验证流程就能稳定产出结构一致、证据充分、可直接进入评审与实施阶段的 Google Cloud 解决方案架构指南。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Google Cloud 解决方案架构输出模板详解：基于 skills29 仓库编写标准化架构报告指南
Google Cloud 解决方案架构输出模板详解基于 skills29 仓库编写标准化架构报告指南【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文围绕 google-cloud-solution-architecture 技能中的 output-template.md 模板展开系统讲解如何基于该模板将「需求收集—产品选型—架构设计—部署验证」全流程的产出汇编成一份结构统一、可审计、可复用的 Google Cloud 解决方案架构报告。读者完成本文后将掌握模板八个章节的定位、填写要点、Mermaid 架构图画法、Well-Architected 支柱设计建议的组织方式以及部署与验证计划的编写规范并了解模板与技能四阶段工作流的对应关系。一、模板在技能工作流中的定位在skills29/skills仓库中google-cloud-solution-architecture 是一个面向复杂负载的端到端云架构设计技能它交互式地收集需求设计跨多个产品的整体系统架构、解决方案蓝图与部署建议。该技能在工作流的最后阶段Phase 4Solution packing and presentation要求把所有阶段产生的文本与代码工件合并为一份名为solution-architecture-guide.md的 Markdown 报告合并所依据的标准骨架正是assets/output-template.md。模板头部有一段说明性注释点明其用途基于SKILL.md中的指令使用此模板来汇编所生成的内容。因此模板不是一份「文档」而是一张结构化的内容编排清单——它规定了报告必须包含哪些章节、每章节必须回答哪些问题、哪些内容必须使用表格或图表呈现从而保证不同架构师、不同负载产出的报告在结构上一致便于评审、审计与后续维护。要正确使用模板需要先理解驱动它的四阶段工作流详见 SKILL.md阶段名称产出物与模板章节的对应关系Phase 1Requirements discovery需求发现功能/非功能需求、当前状态、依赖清单、技术分解technical decomposition第 2、3 章Phase 2Solution architecture方案设计产品映射、Mermaid 架构图、架构描述、设计建议、部署指引第 4、5、6 章Phase 3Solution validation方案验证静态 dry-run 验证计划、运行时验证命令第 7 章Phase 4Solution packaging打包呈现基于模板合并成solution-architecture-guide.md全文该工作流还强调三个重要约束直接决定模板各章节能否被正确填写严格分阶段Phase 1 期间只允许提问澄清需求禁止提前给出架构设计、技术分解或产品建议以避免锚定偏差confirmation bias——这保证了模板第 4 章的产品选择真正由需求驱动。迭代审批技术分解、产品推荐、图表、架构描述、部署脚本等每个交付物都要显式呈现给用户审批批准后才进入下一任务因此模板的每一章都对应一次「已获批准的中间产物」。禁止擅自执行代码除非获得用户明确许可不得运行生成的任何脚本或代码避免意外开通云资源产生费用或改动线上基础设施应始终提供让用户手动执行命令的选项。这对应模板第 6 章的部署指引以「供用户执行」的方式交付以及第 7 章验证计划必须先征得许可再执行 dry-run。二、模板整体结构与文档目录对照模板共八个顶层章节结构如下Executive summary and workload overview执行摘要与负载概览Requirements and current state需求与现状Technical decomposition of the workload负载技术分解Proposed solution architecture拟议解决方案架构Design and configuration recommendations设计与配置建议Deployment guidance部署指引Validation plan验证计划References参考资料这八章构成了从「为什么做」摘要、需求到「做什么」分解、架构、再到「怎么做」设计建议、部署、验证的完整叙事链。模板在仓库中位于 assets/output-template.md而驱动内容生成的三份 Grounding 资料分别位于references/architecture-guides.md按技术类别组织的官方参考架构与设计指南索引基础、AI/ML、应用开发、安全合规、可靠性容灾、数据与分析、数据库、迁移、网络、混合多云、金融、监控、存储等 13 个类别用于支撑第 4 章产品选择与第 5 章设计建议的「引用官方文档」要求。references/best-practices-guides.md按产品组织的最佳实践文档索引BigQuery、Cloud Run、GKE、Compute Engine、IAM、Spanner、Cloud SQL、Cloud Storage 等 24 类用于填充第 5 章各支柱的最佳实践细节。references/decision-making-guides.md面向「二选一/多选一」场景的决策指南表如 Cloud Run 适用性清单、GKE vs Cloud Run、负载均衡选型、数据库选型、Pub/Sub 家族对比等用于第 4.1 节中「替代方案及优劣势」的论证。模板还要求内容 Grounding生成任何建议都必须引用官方 Google Cloud 文档且不得推荐已弃用、退役或不受支持的产品/特性。三、第 1 章执行摘要与负载概览Executive summary模板第 1 章要求用一段简短文字描述负载Workload、其业务目标以及所提出的高层级解决方案架构。它位于报告最前面是评审者架构委员会、安全团队、财务最先阅读的部分。填写要点负载是什么一句话说清业务系统定位例如「面向零售的多租户电商平台」「面向保险理赔的生成式 AI 文档处理系统」。业务目标负载要解决的核心业务问题以及成功度量维度吞吐、用户规模、合规要求等。高层级方案概述采用的部署形态区域性/多区域/全局/混合/多云与核心 Google Cloud 服务组合但不展开细节——细节属于第 4 章。由于模板第 1 章的输入来自 Phase 1 的需求收集结果此章节应当在需求获批后再撰写避免描述与最终选型不一致。仓库中的同族技能例如 google-cloud-solution-n-tier-serverless-web-app也要求基于output-template.md输出标准化报告结构印证了该模板在整个 solution 技能族中的通用地位。四、第 2 章需求与现状Requirements and current state第 2 章是四阶段工作流 Phase 1 产物的归档包含四个子节2.1 功能需求Functional requirements模板要求覆盖业务流程Business processes负载支撑的业务流程细节活动与用例Activities and use cases关键活动与用例。2.2 非功能需求Non-functional requirements模板明确列出六大非功能维度每一项都必须显式填写维度模板要求的细节Security安全合规、加密、访问控制要求Reliability可靠性SLA、RTO/RPO、备份、冗余要求Cost成本成本约束与计费模式Operations运维监控、日志、部署、维护要求Performance性能延迟、吞吐、扩缩容要求Sustainability可持续性碳足迹、资源优化要求依据 SKILL.md若非功能需求缺失或不完整技能必须向用户追问并显式解释其重要性——它们直接决定运维 SLA、可用性等级、扩缩容配置、成本预算、资源类型与安全态势。这意味着 2.2 节不能留空每个维度都要有可度量的表述例如「RPO ≤ 1 小时」「P99 延迟 200 ms」。2.3 当前状态Current state模板标注「如适用」用于描述负载当前的本地数据中心on-premises或其它云上架构现有基础设施Current infrastructure现有部署细节迁移/重设计的痛点与动因Pain points and drivers驱动迁移或重设计的原因。2.4 依赖Dependencies内部依赖Internal dependencies与其它负载、内部服务的依赖外部依赖External dependencies第三方产品、本地工具等外部依赖。模板整体以「问题填写占位提示」的方式组织例如[Details of ...]形式在最终交付的solution-architecture-guide.md中这些占位符必须全部替换为真实内容。仓库同族技能甚至明确要求「不得输出字面模板占位注释」参见 google-cloud-solution-n-tier-serverless-web-app/SKILL.md 中关于 No Unpopulated Placeholders 的约定这一约定对本模板同样适用。五、第 3 章负载技术分解Technical decomposition第 3 章要求将负载的技术组件分解为逻辑服务或层。它是 Phase 1 的收尾产物且必须先经用户批准才能进入 Phase 2——SKILL.md 明确指出技术分解与用户需求不一致会使后续所有阶段产出失效。填写要点按职责拆分入口/网关、应用层、数据处理、存储层、消息中间件、批处理任务等每个逻辑组件应能映射到后续第 4.1 节的某一行「产品映射」即分解是产品选型的输入不在此章推荐具体产品——产品选择属于 Phase 2。六、第 4 章拟议解决方案架构Proposed solution architecture第 4 章是报告核心由三个子节构成分别对应 Phase 2 的 Task 2.12.3。4.1 Google Cloud 产品与特性映射表模板要求以表格形式完成「组件 → 推荐产品 → 选型依据与引用 → 考虑的替代方案 → 替代方案优劣势」的映射。表格列结构如下列内容Component组件名应来自第 3 章技术分解Recommended Google Cloud product/feature推荐产品/特性Justification and citations选型理由引用官方文档Alternatives considered考虑的替代产品Pros and cons of alternatives替代方案优点Pros与缺点Cons用br分隔依据 SKILL.md 的 Task 2.1 规则不得推荐已弃用/退役/不受支持的产品或特性可通过developerknowledge:answer_query或search_documents以「{product_name} release status」之类的查询核实产品状态当多个产品可服务同一组件时推荐最合适者同时列出替代方案并说明各自优缺点选型论证应优先参考 decision-making-guides.md 中与负载相关的决策主题以及 architecture-guides.md 中对应技术类别的参考架构。4.2 架构图Mermaid模板要求使用Mermaid 格式绘制架构图展示组件之间的关系与流转并给出了示例骨架填写要点节点语义与 4.1 的产品映射保持一致图例/标注建议与 4.3 的架构描述呼应方向建议使用graph TDTop-Down用户节点用([User])、负载均衡用方框、数据库用[(...)]圆柱形保持可读性依据 Task 2.2生成的图必须先向用户展示并获得批准再进入架构描述撰写。4.3 架构描述Architecture description模板要求详细描述架构并明确从两个视角展开数据流Data flow数据如何在组件间流转任务/控制流Tasks/control flow任务或控制如何流转。依据 Task 2.3此描述要解释每个组件的用途、组件间关系、任务流与数据流同样需要用户批准后再进入下一步。七、第 5 章设计与配置建议Design and configuration recommendations第 5 章按Google Cloud Architecture Framework 的六大支柱组织最佳实践与配置建议每个支柱给出模板列出的具体切入点支柱模板给出的切入点5.1 Security, privacy, and compliance访问控制IAM 角色、最小权限、数据保护静态/传输加密、Cloud KMS、网络安全VPC、防火墙、Cloud Armor、Private Service Connect5.2 Reliability冗余部署多区域/区域部署、负载均衡、备份与容灾备份、故障切换流程、RTO/RPO 策略5.3 Operational excellence监控与日志Cloud Logging、Cloud Monitoring、Dashboards、基础设施即代码Terraform、Deployment Manager5.4 Cost optimization规模与伸缩自动扩缩容配置、资源合理配比、计费模式承诺折扣、Spot VM、固定费率定价5.5 Performance efficiency缓存与 CDNCloud CDN、Memorystore、数据库与查询优化分区、索引、缓存5.6 Sustainability无服务器采用、资源利用率、碳足迹这一章对应 Phase 2 的 Task 2.4。依据 SKILL.md生成非功能需求对应的建议时应优先使用仓库内现成的六个 Well-Architected FrameworkWAF专项技能google-cloud-waf-securitygoogle-cloud-waf-reliabilitygoogle-cloud-waf-cost-optimizationgoogle-cloud-waf-operational-excellencegoogle-cloud-waf-performance-optimizationgoogle-cloud-waf-sustainability若工作区中没有上述任一 WAF 技能则直接依据 best-practices-guides.md 中的文档索引推导设计建议。因此第 5 章每一条建议都应能溯源到「WAF 技能或官方最佳实践文档」这与模板「Ground all generated content」的要求一致。八、第 6 章部署指引Deployment guidance第 6 章对应 Phase 2 的 Task 2.5要求给出部署架构的指令与代码通常包含基础设施即代码并包含两个固定子节。6.1 部署前置条件Deployment prerequisites模板给出的示例条目类型包括启用 APIEnabling APIs安装 SDK/工具Installing SDK/tools其它必备条件。前置条件应可执行、可核对例如gcloud auth login、gcloud config set project、启用对应产品的 API、安装 Terraform 并验证版本等。6.2 逐步部署指令Step-by-step deployment instructions模板给出的步骤示例使用 Google Cloud 进行认证初始化 Terraform如terraform init应用 Terraform 配置如terraform apply。填写要点结合仓库同族技能约定若在报告中内嵌代码或脚本必须内联完整真实的 Terraform 代码、gcloud 命令与验证脚本不得输出字面模板占位注释部署顺序建议遵循「自底向上」的依赖顺序先 VPC/子网再数据层再内部微服务最后公共网关与负载均衡跨服务传递参数如从gcloud run services describe提取status.url时应通过 shell 变量显式传递。模板第 6 章还隐含了 Task 2.5 的审批要求部署指引完成后需向用户展示并获批准才能进入 Phase 3。九、第 7 章验证计划Validation plan第 7 章对应 Phase 3要求给出验证生成方案是否满足负载需求的步骤并包含对任何已生成验证脚本的引用。依据 SKILL.md验证计划分两个层次Task 3.1 部署前静态验证Pre-deployment validation部署 dry-run使用terraform plan或支持--dry-run的gcloud ... --dry-run命令校验基础设施语法并预览将开通的资源架构与策略分析对网络路由拓扑、防火墙规则、IAM 实施情况做静态核查对照最佳实践静态验证计划必须先呈现给用户并获得执行 dry-run 的明确许可若用户不同意或希望自行执行则提供可由用户手动运行的精确命令对 dry-run 检查发现的错误或策略不一致进行排查修复直至验证通过。Task 3.2 运行时验证Runtime validation, post-deployment询问用户是现在部署基础设施进行真实运行时验证还是直接跳到 Phase 4若用户选择部署则生成运行时验证命令如curl、ping、gcloud交给用户执行测试在线端点可达性、网络路径与负载均衡路由排查部署或运行时路由问题直至检查通过。因此第 7 章在报告中应明确区分「静态验证」不需要真实资源与「运行时验证」需要已部署资源并把两部分的验证命令、预期结果、以及验证脚本的文件引用都记录在案形成可回溯的验证证据链。十、第 8 章参考资料References模板第 8 章用于汇总报告引用的官方文档模板示例给出了两条参考格式横向可扩展性、区域托管实例组。结合前文 Grounding 要求参考资料应来源于architecture-guides.md 中与负载技术类别匹配的参考架构例如部署原型对比、区域性部署、灾难恢复场景等decision-making-guides.md 中用于支持选型决策的主题文档best-practices-guides.md 中对应推荐产品的最佳实践文档。引用应精确到具体页面作为第 4.1 节选型依据与第 5 章设计建议的可验证支撑。十一、模板的使用流程与质量自检清单综合模板与 SKILL.md 的 Phase 4 收尾要求使用该模板的标准流程如下完成并批准Phase 13 的全部中间产物需求、分解、产品映射、架构图、架构描述、设计建议、部署指引、验证计划合并将 Phase 2 与 Phase 3 生成的文本工件合并为单个 Markdown 文件solution-architecture-guide.md结构严格遵循assets/output-template.md请求许可向用户申请在工作区写入代码文件的权限写文件获准后将代码文件写入用户工作区。提交报告前的质量自检清单占位符清零[Details of ...]、[Component Name]等模板占位全部替换为真实内容不输出字面模板注释引用完整每个产品选型与设计建议都有对应官方文档引用且未推荐任何已弃用产品图与文一致Mermaid 架构图中的节点与 4.1 产品映射、4.3 架构描述中的组件名称保持一致验证可执行第 7 章的 dry-run 与运行时验证命令完整、可复制且已标注哪些需要真实资源审批记录齐全各章节对应的审批节点分解、产品、图、描述、建议、部署均有明确结论。十二、总结assets/output-template.md是google-cloud-solution-architecture技能交付环节的结构基石它将四阶段工作流的全部产出压缩为一份八个章节的标准化架构报告以执行摘要开篇以需求与现状为设计输入以技术分解衔接以产品映射、Mermaid 架构图与架构描述构成方案主体以六大 WAF 支柱组织设计建议以部署指引和验证计划确保方案可落地、可验收最终以参考资料保证每条结论可溯源。对架构师而言这份模板既是「内容清单」也是「质量门」——严格按章节填写并执行审批与验证流程就能稳定产出结构一致、证据充分、可直接进入评审与实施阶段的 Google Cloud 解决方案架构指南。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
