大规模的技术升级或迁移在开始的时候迅速推进，但随着时间的推移往往会陷入泥沼，终导致大部分系统即使成功迁移，也还是会留下一些老版本的尾巴。大约一年半前，Spotify团队也注意到了这个问题并开始正视它，终找到一个较优策略。近，公众号“高可用架构（ID：ArchNotes）”翻译了Spotify的技术升级思路和方法，供你参考。
Spotify工程团队有三百多人，他们分布在全球各地。开始的技术升级方法是发送电子邮件，给出完成升级的截止时间。但是如此大量的电子邮件让内部用户不知所措，而且尝试去跟踪这类事情的进展就是浪费时间。此外，这些邮件有时候缺少必要信息，例如什么需要升级和应该如何升级。这时候，他们意识到需要重新审视这个问题。
经过一些实验后，他们制定了一个用来提高迁移效率的“三步走”策略。
步：确定优先次序
首先要确保在公司内有正确的优先级排序流程。这个过程的关键部分是，将全公司的系统迁移“绘制”成一个大地图，并与技术架构小组协商确定优先级。这份迁移地图有助于工程师之间形成契约。另外，在将某项目放到迁移地图上之前对成本进行评估，确定受影响的人员，并设定截止日期。
所有这些措施都有助于防止基础架构组织因非必要的工作而使工程团队不堪重负，从而为团队节省了更多时间来迭代业务功能。对于异地沟通问题，Spotify开发了一款工具，用来取代邮件形式，在简化沟通的同时，便于工程师们查看当前和未来有哪些迁移计划，这极大地提升了技术升级的推进速度。
第二步：产品化迁移
Spotify认为，他们需要在技术迁移方面采取产品思维。在实践中，怎么贯彻这一思维呢：
责任人制度：Spotify有专门负责推动迁移的产品经理，每次技术迁移都由一个产品经理负责。包括对迁移的成功负责，并跟踪迁移进度。
测试先行：将迁移计划添加到迁移地图之前，需要进行Alpha和Beta测试。这是为了保持内部用户的信任度，重要的是让他们觉得不会因产品有问题或半成品而在迁移上浪费时间。通过控制“爆炸半径”并在推广服务之前对内部服务或工具进行迭代，就能提高内部产品的质量，终提高整个生态系统的生产力并加快迁移速度。
迁移培训：比如迁移涉及到的新编程语言、服务框架等，对于使用多年的旧系统或旧工具的工程师来说，这会让他们在面对迁移时不那么恐惧。
价值导向：从一开始，迁移团队就与内部产品营销经理合作，确保他们从生产力、成本和扩展性的角度传达了迁移的好处。开发人员容易陷入一个误区或者自顾自的假设，就是说大家都知道并认可某一语言或工具的某个版本比另一个版本更好，这是错误的。通过付出额外的努力来解释为什么某项技术值得采用，不仅是对工程师解释，也要对工程经理和领导层解释，这样才能让大家对技术健康保持一致的认知。
了解用户：负责迁移的产品经理们了解他们的服务对象。他们提供针对性的计划来帮助不同团队，而不是一刀切管理方法。
可视化/游戏化：Spotify后台有一个插件，允许工程师查看迁移进度。
后，或许也是重要的一点，在迁移完成前，Spotify不会停止推进迁移。
第三步：尽量自动化
Spotify的技术迁移策略的目标是实现大程度的自动化，让团队无需知道基础架构组件已经发生了变化，做到无缝衔接与体验。而在无法做到无缝体验的地方，技术迁移团队会主动给其他相关团队发送文件，以供审核和合并。
Spotify技术迁移团队的目标是让工程团队无需关注99%的基础组件迁移。可以通过在平台中提供更多的工具来实现这一目标，这些工具在技术栈中处于较高的位置，底层基础设施组件不会直接暴露在内部用户面前。
技术升级是一个漫长的旅程，希望Spotify的技术迁移策略能够给你带来新的启发。
