1. 课程导入与全景认知
在 Azure 上运行生产系统，性能与成本从来不是两个独立的问题。一个响应变慢的 API，可能同时意味着实例规格选大了、缓存命中率下降了、数据库 DTU 被无谓消耗；一次月末账单的异常上涨，背后往往也藏着低效查询、闲置资源或错误的存储分层策略。本课程的目标，是帮助你把"性能"和"成本"放在同一张图上思考：在满足业务 SLO 的前提下，用尽可能少的资源消耗，稳定地交付可预期的用户体验。
核心目标：三个可度量的方向
我们把课程目标拆成三个可度量方向，避免停留在"优化一下"这种模糊表述：
- 性能达标：以 P95/P99 延迟、吞吐量（RPS）、错误率作为验收指标，而不是平均值。例如一个订单查询接口，目标可定义为 P95 < 300ms、错误率 < 0.1%。
- 成本可控：以单位业务量的成本（如每万次请求成本、每 GB 处理成本）衡量，而非只看总账单。总账单下降但业务量下降更多，其实是效率恶化。
- 可持续治理：优化不是一次性动作，而是通过监控、预算、标签、定期评审形成闭环，让系统在业务增长时不会悄悄失控。
关键挑战：为什么"优化"经常失效
生产环境的性能与成本问题，通常不是单点故障，而是几类典型挑战叠加：
- 可观测性不足：只有 CPU 和内存曲线，没有依赖调用链、数据库等待类型、缓存命中率，导致定位靠猜。
- 性能与成本割裂：性能团队加机器，财务团队砍预算，缺少共同的指标语言。
- 环境差异：测试环境数据量小、缓存热、网络近，压测结果无法代表生产。
- 责任边界模糊：不清楚哪些由 Azure 负责、哪些由自己负责，导致问题互相推诿。
- 缺乏基线：没有优化前的数据，无法判断改动是否真的有效。
Azure 责任共担模型：先分清"谁负责什么"
责任共担模型是理解云上治理的起点。它的核心思想是：云安全、可靠性、性能与成本，始终由云厂商和客户共同承担，但分担比例随服务模型变化。
以 IaaS（虚拟机）为例，Azure 负责物理主机、网络、数据中心和虚拟化层；操作系统补丁、运行时、应用代码、数据、身份配置、扩缩容策略都由你负责。到了 PaaS（如 Azure App Service、Azure SQL Database），Azure 接管了操作系统和部分运行时，你负责应用配置、查询效率、连接池、索引和容量层级选择。到了 SaaS，你主要负责数据、身份和使用方式。
这个模型对性能与成本治理的直接含义是：越往上走，Azure 承担越多底层运维，但你的优化杠杆越集中在配置、查询、架构和使用习惯上。例如 Azure SQL Database 不会替你优化一条全表扫描的查询；App Service 不会替你决定实例数和自动缩放规则。因此，课程后续会反复强调：先确认责任边界，再决定优化动作。
FinOps 原则：让成本成为工程决策的一部分
FinOps 不是"省钱运动"，而是一套让工程、财务、业务协同管理云成本的操作框架。结合本课程，我们提炼出四条最实用的原则：
- 成本可见：通过资源标签（如 env、app、owner、costcenter）和成本管理视图，把账单分摊到具体应用和团队。
- 业务对齐：用单位成本指标衡量效率，而不是单纯压缩绝对值。
- 持续优化：把 rightsizing、预留实例、自动缩放、存储分层纳入常规迭代，而不是季度末突击。
- 责任到人：每个工作负载有明确的成本负责人，预算超限有告警和处置流程。
本课程学习路径与实战项目
课程围绕一条主线展开：观测 → 定位 → 优化 → 验证 → 固化。前半部分建立可观测性、性能剖析、数据库与缓存优化、自动缩放等能力；后半部分进入成本分析、标签与预算、存储与计算优化、预留与混合权益、治理闭环。每一节都尽量给出可操作的参数、命令或判断依据。
实战项目贯穿全程：一个部署在 Azure 上的订单处理系统，包含 App Service 前端 API、Azure SQL Database、Redis Cache、Service Bus 队列和 Blob 存储。你会先建立基线与监控，再逐步定位慢查询、缓存击穿、实例规格过大、存储冗余等问题，最后用单位请求成本和 P95 延迟共同验证优化效果。项目中的参数和结果均为教学示例，用于说明方法，不代表真实生产实测值。
从这张全景图可以看到：责任共担模型决定了你能动哪些杠杆，FinOps 闭环决定了这些杠杆如何被持续使用，而实战项目把两者串成一条可执行的主线。接下来每一节，我们都会围绕这条主线，给出具体的观测方法、定位依据、优化参数和验证标准。