Back to Details

cloud-architecture

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Cloud Architecture

云架构

Use provider Well-Architected guidance, but derive the answer from workload requirements.
参考云服务商的Well-Architected指导原则，但需基于工作负载需求推导答案。

Assessment

评估

  1. Establish workload purpose, criticality, environments, regions, users, traffic, data classes, and regulations.
  2. Quantify SLOs, latency, throughput, growth, RTO, RPO, retention, and cost guardrails.
  3. Inventory identities, accounts/projects/subscriptions, networks, DNS, certificates, compute, data, integrations, and deployment paths.
  4. Identify trust boundaries, failure domains, quotas, single points of failure, manual operations, and vendor dependencies.
  5. Evaluate security, reliability, operational excellence, performance, cost, and sustainability.
  1. 明确工作负载的用途、关键程度、环境、区域、用户、流量、数据类别及合规要求。
  2. 量化服务水平目标（SLOs）、延迟、吞吐量、增长预期、恢复时间目标（RTO）、恢复点目标（RPO）、数据保留期限及成本管控阈值。
  3. 盘点身份标识、账户/项目/订阅、网络、DNS、证书、计算资源、数据、集成组件及部署路径。
  4. 识别信任边界、故障域、配额限制、单点故障、手动操作环节及供应商依赖项。
  5. 评估安全性、可靠性、运营卓越性、性能、成本及可持续性。

Design Defaults

设计默认原则

  • Separate production from non-production using provider isolation boundaries.
  • Prefer workload identity and short-lived credentials over static keys.
  • Use private connectivity where justified, centralized policy, immutable audit logs, and encryption with deliberate key ownership.
  • Select managed services when reduced operations outweigh lock-in and constraints.
  • Design zone failure by default; add multi-region only when business RTO/RPO and failure analysis justify its cost.
  • Make infrastructure reproducible through reviewed IaC and automated policy checks.
  • Define telemetry, ownership, runbooks, backup restoration tests, rollback, and cost allocation before launch.
  • Avoid multi-cloud unless a specific regulatory, acquisition, customer, or resilience requirement repays duplicated complexity.
  • 利用云服务商的隔离边界将生产环境与非生产环境分离。
  • 优先使用工作负载身份标识和短期凭证，而非静态密钥。
  • 在合理情况下使用私有连接，采用集中式策略、不可变审计日志，并明确密钥所有权的加密方式。
  • 当减少运维工作量的收益超过锁定风险和约束限制时，优先选择托管服务。
  • 默认按可用区故障场景设计；仅当业务的RTO/RPO要求及故障分析证明其成本合理时，才添加多区域架构。
  • 通过经过审核的基础设施即代码（IaC）和自动化策略检查，确保基础设施可重现。
  • 在上线前定义遥测方案、职责归属、运行手册、备份恢复测试、回滚机制及成本分配规则。
  • 除非存在特定的合规、收购、客户或弹性需求，且其收益足以抵消重复的复杂性，否则避免采用多云架构。

Deliverable

交付物

Provide assumptions, target architecture, provider mappings, identity and network model, data and DR strategy, deployment model, observability, cost drivers, risks, alternatives, phased roadmap, and acceptance tests. Distinguish facts from estimates and link current official documentation for volatile service limits or pricing.
提供假设条件、目标架构、云服务商映射、身份与网络模型、数据与灾难恢复（DR）策略、部署模型、可观测性方案、成本驱动因素、风险点、替代方案、分阶段路线图及验收测试。区分事实与估算内容，并为易变的服务限制或定价链接当前官方文档。