这篇文章不谈人物履历，只从阿里云产品和服务的角度，说说企业上云该怎么想、怎么走。
先想清楚上云要解决什么
不少企业上云，是因为同行都在用。结果上了云，账单没降，运维反倒更乱。动手之前，先把三件事问清楚：业务高峰出现在什么时候，哪些数据有合规要求必须留在特定范围内，团队有没有能力管理新的架构。三个问题答不上来，迁移方案很容易变成跟风。
设想一个常见的情形：某区域性零售连锁企业的线下门店系统，大促时经常卡顿甚至宕机，而本地服务器是按最高峰配置的，平时大部分时间闲着。这类企业比较稳妥的路子，一般是先把订单查询、会员服务这些高并发模块拆出来，放到弹性计算资源上，财务核心系统暂时留在本地。拆分之后，哪一块出了问题也更容易定位。
迁移时的三条经验
- 先拆分，再迁移：优先把最需要弹性的模块搬上去。一次性整体迁移，出问题时很难判断是哪一层的原因。
- 按业务价值排序：先处理直接影响营收和客户体验的系统，而不是技术上最好迁的系统。后者迁得快，但对业务的帮助可能有限。
- 监控和成本分析同步上线：资源一开，就要配好告警和用量看板。没有这些，云上的账单和故障往往要事后才发现。
产品能力要落到具体场景
云服务好不好用，最终要看试错成本够不够低。对中小企业来说，按需付费的计算资源、托管数据库和现成的安全组件，意味着不必为了一次活动提前买整套硬件。大型企业关心的往往是多云管理、数据治理，以及和既有系统怎么对接。两类客户的诉求差得很远，只讲参数，很难说服任何一方。
还有一个容易踩的坑，是把上云当成一次性项目。验收完就不管了，云上的资源配置和存储策略会慢慢和业务脱节。比较实际的做法，是每个季度看一次资源利用率和费用构成，闲置实例降配或关掉，新增的业务模块单独评估。
上云前可以先问自己的几个问题
如果你正在评估，可以先回答下面几点，答案会决定迁移的节奏：
- 哪些系统一停就会影响收入？这些系统最好放到最后迁移，或者先备好回滚方案。
- 数据出境或跨地区存储有没有限制？先和法务或合规同事确认，再定架构。
- 现有团队会不会运维云资源？如果不会，要预留培训时间，或者考虑托管服务。
上云本身不会自动带来收益。它的作用是让资源跟着业务走。问题想清楚了，选哪条路往往就不难了。
