提到阿里云杨名，很多人先想到的是公开资料里的职务和业务线。这些信息可以作为起点，但做云计算的人更关心的是：这条业务线在看什么，客户为什么愿意买单。这篇不谈人物履历，只从业务角度拆出三个指标，你可以拿来对照自己手里的项目。
先把人物信息和业务信息分开
搜“阿里云杨名”时，很容易把个人动向、团队调整和产品发布揉在一起。职务变化、组织调整这类内容，以官方发布和权威媒体原文为准，二手摘要不要直接当结论。业务层面的判断则看产品文档、客户案例和发布会材料。两边对得上，再下判断，比较稳。
指标一：资源利用率与峰值的差距
上云后最容易被高估的是“省钱”。假设一家零售企业大促时流量是平时的十几倍，如果还按峰值常年预留机器，平时的利用率可能很低。这时候更该看的是平均利用率和峰值之间的距离。差距越大，弹性伸缩越有价值；差距很小，上了云也只是把闲置资源换了个地方放。
具体做法：迁移前至少采集两到四周的CPU、内存和请求量曲线，大促周期要包含在内。没有这组数据，任何“能省多少”的说法都只能靠猜。
指标二：单位业务量的成本
总费用会随规模一起涨，只看总额很难判断效率。更有用的是每千次订单、每万次请求或每个活跃用户对应的资源成本。这个数字如果在业务增长时反而变高，通常说明扩容规则过于保守，或者有服务一直在空跑。
计费方式也会影响这个指标。按量计费适合波动大的服务，长期稳定的负载买包年包月可能更划算。别只盯单价，要把整体用量和折扣算在一起。
指标三：扩容响应与恢复时间
弹性能力好不好，要看真实跑起来时的表现：从触发扩容到新实例接住流量要多久，出问题时回滚要多久。这两个时间如果超过业务能容忍的范围，弹性就只是摆设。
可以在压测环境里模拟一次流量突增，记录从告警触发、扩容完成到错误率回落的完整时间线。第一次测出来的数字大概率不好看，这很正常，找到瓶颈再改就行。
一个假设的迁移过程
以下是一个假设的场景，用来说明步骤，并非某个真实团队的数据。一支十人左右的电商技术团队，订单系统原本跑在固定规格的虚拟机上，大促前靠人工提前加机器。他们的推进顺序大致如下：
- 先把无状态的商品查询服务迁到容器平台，用它验证弹性伸缩规则是否可靠。
- 再拆分订单、库存等有状态服务，引入消息队列削峰，减轻数据库的瞬时压力。这一步改动大，要保留旧链路以便切换回去。
- 最后建立压测和演练机制，大促前完整演练至少两轮，每轮都记录指标变化。
这个团队最后得到的变化，主要是扩容从一次紧张的人工操作，变成了有脚本、有负责人、能复盘的流程。这一点比某个具体产品功能更值得借鉴。
落地前的三件小事
- 先定基线。把现有资源的平均利用率、峰值和单位成本记下来。没有基线，迁移后省没省钱说不清。
- 先迁边界清晰的服务。选影响范围小、依赖少的服务试点，确认监控、告警和回滚都能用，再推进核心业务。
- 把演练写进排期。大促、版本发布、故障切换都要有脚本和责任人，别只依赖某个老员工的经验。
关注官方更新，别只看二手解读
云产品迭代快，今天的配置方式半年后可能就变了。定期看官方文档的更新日志，留意产品变更说明，通常比看几篇总结文章更靠谱。自己团队的踩坑记录也值得沉淀下来，它往往比外部资料更贴近你的实际情况。
评价一个人或一条业务线之前，先看它的指标能不能在你自己的系统里复现。
