按数据敏感度分层决定上云范围：计算和缓存先行，核心数据留守私有云

决定”要上公有云”之后，紧接着要回答的是”整个系统的哪些部分该上云”，而不是把整套系统一股脑地全部迁移。微博的做法是按数据敏感度和公有云技术成熟度做分层判断：现阶段只把计算节点和缓存节点放到公有云，核心数据继续留在私有云——计算节点本身通常是无状态或弱状态的，即使跑在公有云上出问题，也不涉及数据永久丢失或泄露的风险；缓存节点虽然承载数据，但缓存本身的定位就是可丢失、可重建的临时存储，即使公有云的可靠性或安全性还没有完全被验证，缓存层出问题的代价也相对可控。真正涉及业务核心资产、一旦泄露或损坏后果严重的核心数据，则被明确排除在这次上云范围之外，继续放在私有云里。这个分层判断同时也考虑了公有云本身技术成熟度还在发展中这个现实：既然公有云的稳定性、安全性还没有达到完全放心的程度，就先让影响面可控的部分（计算、缓存）去验证和积累经验，而不是让最重要、最难承受风险的部分（核心数据）直接去趟这条还不够成熟的路。这个思路给出了一条评估”新技术/新基础设施该在多大范围内采用”的通用原则：面对一项还在发展、尚未被完全验证的技术方案，不必在”全面采用”和”完全不用”之间二选一，而是可以按业务组件承担的风险等级做分层，先让风险可控、代价可承受的部分去当”先锋”，用实践积累经验和信心，再逐步扩大到风险更高的核心部分，而不是一步到位地把所有身家都押上去。