返回首页

云

关于跨平台云治理的一些实践与思考。

本页使用的云术语
CAF
Cloud Adoption Framework,云采用框架,指导组织的上云与持续运营。
WAF
本页指 Well-Architected Framework,良好架构框架,而不是 Web 应用防火墙;用于工作负载设计与运营。
着陆区
账号、身份、网络与治理等共享云平台基础。
SLO / RTO / RPO
服务水平目标、恢复时间目标、恢复点目标,分别约定服务质量、恢复时间与可接受的数据丢失。

我的云治理实践

从平台选型延伸到持续运营,而不只是把工作负载搬上云。

我在 GCP、AWS、Azure、阿里云和 OpenStack 的治理中积累了成熟的实践。面对不同云平台,我更关注一套可落地、可持续调整的治理方式:明确业务目标与责任边界,建立平台基线,再用策略、安全、成本和运营反馈持续改进。

Cloud Adoption Framework (Microsoft Learn,在新标签页打开)

借鉴其 Strategy、Plan、Ready 到 Govern、Secure、Manage 的路径,把业务目标、平台准备和治理运营连成闭环;方法论用于指导多云实践,而不是照搬 Azure 的实现细节。

Azure Well-Architected Framework (Microsoft Learn,在新标签页打开)

以可靠性、安全性、成本优化、卓越运营和性能效率五个支柱审视工作负载,在取舍中平衡风险、体验与投入。

这些框架提供检查问题的视角;实际治理仍需结合各平台能力、组织约束与工作负载特点。

组织如何采用云

以 Cloud Adoption Framework(Microsoft Learn,在新标签页打开) 为参照。它是 Azure 指南,其中的组织决策思路也可用于 AWS、GCP、阿里云与私有云的采用实践。

CAF 连接业务目标、组织准备与云交付。战略、规划、就绪与采用构成初始路径;治理、安全与管理需要提前规划,并贯穿采用与运营全程。需求变化时应重新审视之前的决策。以下以假设的客户门户为例。

Microsoft 云采用框架:战略、规划、就绪与采用依次推进,治理、安全与管理持续开展;Azure 架构中心与良好架构框架为实现和工作负载设计提供指导。 查看完整尺寸图(在新标签页打开)
Microsoft 云采用框架概览。来源:Microsoft Learn(在新标签页打开)。查看完整尺寸图(英文,在新标签页打开)。
查看图解的中文说明

云采用 · 依次推进

  1. 01Strategy 战略
  2. 02Plan 规划
  3. 03Ready 就绪
  4. 04Adopt 采用

运营 · 并行持续

  • Govern 治理
  • Secure 安全
  • Manage 管理

Azure 架构中心提供实现指导,良好架构框架提供工作负载设计原则,两者共同支持云就绪、采用与持续运营。

  1. Strategy · 战略

    先把云投入与业务成果关联,再选择服务。让业务、财务、IT 与安全负责人共同确定上云动机、范围、风险容忍度与可衡量的成功标准。

    预期成果
    具备明确负责人的业务论证、投资优先级与成效指标。
    示例
    以客户门户为例,优先解决发布速度与季节性容量问题,以上云前的数据为基线,衡量部署交付时间与客户请求成功率。
  2. Plan · 规划

    把战略转化为可执行的路线图。盘点应用、数据与依赖关系,评估云就绪程度和技能缺口,估算成本,并明确平台团队与工作负载团队的职责。

    预期成果
    按优先级排序的待办、迁移批次、预算、培训计划与职责分工。
    示例
    梳理门户的数据库、身份提供方与支付依赖,先试点低风险环境,再根据业务约束安排生产迁移。
  3. Ready · 就绪

    在部署业务前搭建可重复交付的着陆区。区分共享平台服务与工作负载环境,通过基础设施即代码建立身份、网络连接、账号结构、策略、日志与计费基线。

    预期成果
    经过验证、可供业务团队在约定护栏内使用的云平台基础。
    示例
    用可复用的 Terraform 模板提供独立的生产与非生产订阅、数据库私有连接、集中日志,以及负责人和成本中心标签。
  4. Adopt · 采用

    根据业务价值与技术约束迁移、现代化或新建工作负载。逐个应用选择路径,验证功能与性能,规划数据传输、切换、回退与运营交接,并随需求变化重复推进。

    预期成果
    符合验收标准、具备明确运营团队的生产工作负载。
    示例
    为门户演练数据库切换与回退,再完成迁移;当收益足以覆盖改造成本时,把后台任务现代化为托管队列。
  5. Govern · 治理

    把业务风险与合规要求转化为可执行策略。规定允许的区域、资源归属、支出控制与例外处理方式,并随云规模增长持续检查合规状态。

    预期成果
    成文的策略、合规证据,以及有期限的例外审批流程。
    示例
    强制负责人标签,限制资源部署到批准区域,禁止存储公开访问,并把预算告警发送给业务负责人;预算告警本身不会限制支出。
  6. Secure · 安全

    以零信任贯穿整个生命周期:明确验证、最小权限、假设已被入侵。结合身份控制、网络隔离、数据保护、漏洞管理、威胁检测与事件响应。

    预期成果
    安全基线、按风险排序的整改任务,以及经过演练的响应流程。
    示例
    管理员使用多因素认证,应用使用托管身份代替内嵌密钥,数据库保持私有访问,并通过集中安全监控调查异常登录。
  7. Manage · 管理

    上线后持续维护服务健康。约定服务与恢复目标,监控用户体验和平台状态,维护备份与补丁,明确值班责任、操作手册与持续改进机制。

    预期成果
    运营仪表盘、恢复验证记录、事件处理流程与持续改进待办。
    示例
    对门户请求失败建立告警,按恢复目标演练数据库还原,并结合事件复盘与利用率数据改进操作手册和资源规格。

在多云环境中,每个平台各有着陆区实现,但战略、治理、安全与运营标准应当统一,避免各云各管一套。

围绕五大支柱优化工作负载

以 Well-Architected Framework(Microsoft Learn,在新标签页打开) 为参照。CAF 确立组织方向与平台标准;WAF 指导工作负载在这些标准内的设计与运营。

五个支柱之间存在取舍:没有工作负载能在每一项都做到极致。组织应根据业务关键程度、合规要求和上线时间,决定每个支柱投入多少。示例沿用 CAF 阶段中的假设客户门户;数字目标仅用于说明,实际目标需与业务共同约定。

工作负载在取舍中平衡可靠性安全性成本优化卓越运营性能效率
每个支柱都提供设计原则、检查清单与取舍;工作负载位于这些决策的交汇处。

可靠性 Reliability

保证关键用户流程可用,并在约定范围内恢复。用 SLO 定义服务质量、RTO 定义恢复时间、RPO 定义可接受的数据丢失;分析依赖故障,消除单点并验证恢复能力。

示例
让门户跨可用区运行,对短暂依赖故障采用有上限的重试,并演练数据库还原,确认整个服务达到恢复目标。
取舍
额外副本与备用区域会增加成本和运营复杂度,应依据停机对业务的影响决定投入。

安全性 Security

根据工作负载风险保护机密性、完整性与可用性。进行数据分级和威胁建模,落实最小权限、隔离、敏感数据加密与攻击监测,并规划事件遏制与恢复方式。

示例
只给门户的托管身份必要的数据库权限;把密钥放入保管库,保持数据访问私有,脱敏日志,并对异常访问建立告警。
取舍
更强的隔离与访问控制增加配置和支持工作,需要让团队能够方便地采用安全路径。

成本优化 Cost Optimization

在可持续预算内交付业务价值。把计算、存储、网络传输、许可与运营纳入总成本模型,明确费用负责人,跟踪每笔有效业务交易的成本,并按实测需求调整容量和计费方式。

示例
关闭闲置开发环境,压测后缩小低利用率数据库,只为稳定的基础负载预留容量,并跟踪门户每次成功客户请求的成本。
取舍
预留容量降低灵活性,过度缩容可能损害可靠性或响应速度,每次节省后都要复核服务目标。

卓越运营 Operational Excellence

让开发与运营可重复、可观测且变更安全。采用版本化基础设施、自动化测试与部署、清晰的职责、可行动的监控信号和事件手册,把生产反馈转化为改进。

示例
通过流水线检查基础设施并灰度发布门户;监控错误率与延迟,超出阈值时回退,并让值班团队演练响应过程。
取舍
自动化与可观测性需要前期投入和持续维护,应先覆盖高频或高风险任务,以及能指导行动的信号。

性能效率 Performance Efficiency

随需求变化持续满足用户体验。为关键流程设定延迟与吞吐目标,测量完整请求路径,模拟真实负载进行压测,并针对实际瓶颈选择伸缩和数据访问方案。

示例
示例目标:在预期峰值负载下,95% 的门户请求在 300 毫秒内完成。追踪慢查询,缓存合适的读取结果,并根据队列深度扩展后台处理实例。
取舍
缓存需要权衡数据新鲜度,预留容量改善响应但增加成本,自动伸缩面对突增流量也需要反应时间。

落地方法:先理解各支柱设计原则,再按业务优先级处理检查清单,明确记录取舍,并用成熟度模型分阶段改进,把评估当作随工作负载演进的动态分数。