技术升级易烂尾
根据我们的经验，大规模的技术升级或迁移往往在开始的时候迅速推进，但随着时间的推移往往会陷入泥沼，最终导致大部分系统即使成功迁移，也还是会留下一些老版本的尾巴。就好比无人看管时花园里的杂草便会发芽长大，也是技术基础架构碎片化的原因之一。
大约一年半前，我们开始在spotify正视这个问题。在这篇文章中，我们将分享我们的思路和方法，以及下一步将怎么做。
多吃萝卜少挨揍
在深入探讨之前，我们应该承认，一家公司的工程文化会对人们如何看待以及如何处理这个问题起到很大的作用。在Spotify，我们的工程团队有三百多人（或我们称之为 “小队”），他们分布在全球各地，我们倾向于激励而非惩罚。我们已经看到了很多成功的案例，以创造性的方式解释了为什么技术升级很重要，以及技术升级有助于提升效率，而不是任务加倍。这一直是我们的风格，接下来的很多内容都将反映出我们在工程自主性和健康的技术环境之间取得平衡的愿望。
往日情景再浮现
首先我想先带你回到2017年。那时，我们的基础设施团队和开发工具团队会向整个公司的工程师发送电子邮件，比如“必读：某组件将被弃用或淘汰”，给出完成升级的截止时间。负责内部工具或服务的所有团队可能会发送电子邮件，通知内部用户需要从一个版本迁移到另一个版本或需要使用完全不同的解决方案。这种情况是不是听起来有点耳熟？
可以想象，这会造成一大堆麻烦。如此大量的电子邮件让内部用户不知所措，而且尝试去跟踪这类事情的进展就是浪费时间。此外，这些邮件有时候缺少必要信息，例如什么需要升级和应该如何升级。这时候，我们意识到需要重新审视这个问题。
三步断长尾
经过一些实验后，我们制定了一个用来提高迁移效率的「三步走」策略。
1. 确定优先次序
第一部分是确保在公司内有有正确的优先级排序流程（注意：当你在一个工程文化是强调高度自主性的团队中工作时，能够确保和协调出优先级可是说起来容易做起来难）。此过程的关键部分是，将全公司的系统迁移「绘制」成一个大地图，并与TAG(Technical Architecture Group)协商确定优先级。这份迁移地图将帮助工程师之间形成契约：我们在将某项目放到迁移地图上之前会对成本进行评估，确定受影响的人员，并设定截止日期(时间表尤为重要)。
所有这些措施都有助于防止我们的基础架构组织因非必要的工作而使工程团队不堪重负，从而为团队节省了更多时间来迭代业务功能。那么上文提到的那些对迁移没什么帮助的通知邮件哪里去了呢？答案是我们取消了这些邮件并把相关的沟通简化了。我们自己开发了一个工具（已开源），工程师们可以查看当前和未来有哪些迁移计划。
协调45+基础设施产品经理和数百位工程师，需要大量的时间和耐心。我们通过这个工具有效的组织数据带给了我们推进的全景，本来几周就可以完成的升级被延宕到数月或者更长时间。所有这些都是因为内部用户（需要进行迁移的团队）被之前海量的信息「淹没」而导致瘫痪或者无所适从。
2. 产品化迁移
在我们的平台部门中，我们相信要建立强大的产品管理功能，而且我们已经聘请了一些出色的产品经理，他们帮助我们制定战略并按照这一愿景执行。我们意识到我们需要在技术迁移方面采取相同的产品思维。在实践中，怎么贯彻这一思维呢：
责任人制度：每次技术迁移都由一个产品经理负责。他/她对迁移的成功负责，并跟踪迁移进度。是的，没错——我们有专门负责推动迁移的产品经理，他们的工作帮助我们成功的进行技术迁移。
测试先行：我们在将迁移计划添加到迁移地图之前，需要进行alpha和beta测试。尽管这似乎不是必须的，但为了保持内部用户的信任度，重要的是让他们觉得不会因产品有问题或半成品而在迁移上浪费时间。我们并非总能做到正确-这就是软件的本质。但是，通过控制「爆炸半径」并在推广服务之前对内部服务或工具进行迭代，我们就能提高内部产品的质量，最终提高整个生态系统的生产力并加快迁移速度。
培训：我们与内部技术学习部门合作一起开发所需的培训计划（例如，如果我们要从一种编码语言迁移到另一种编码语言，或者迁移到另一种服务框架）。虽然不是每次技术迁移都如此，但我们倾向于为知识库中较新的技术提供这样的培训。对于使用多年的旧系统或旧工具的工程师来说，这让他们面对迁移时感到不那么恐惧。
价值导向：从一开始，我们就与内部产品营销经理PMMs合作，确保我们从生产力、成本和扩展性的角度传达了迁移的好处。作为一个基础设施和开发人员工具团队，容易陷入一个误区或者自顾自的假设，即某一种语言或者工具的某个版本比另一个版本更好的原因大家都是知道并都认可的。这是错误的。通过付出额外的努力来解释为什么某项技术值得投入时间去采用,不仅是对工程师解释，而且也对工程经理和高级领导层解释，这样才能让技术健康相关的工作出现在每个人的sprint里。
了解你的用户：负责迁移的产品经理们了解他们的服务对象。他们提供针对性的计划来帮助不同团队，而不是一刀切管理方法。
可视化/游戏化：在后台我们构建了一个允许工程师查看迁移进度的插件，将其命名为Tech Insights。我们以tribes（部落）和Squad（小队）来分类，方便大家清楚地知道和其他团队相比，自己的迁移进度处于什么位置。以下是以tribes（部落）为单位的关于一个技术迁移进度的图示说明：
最后，或许也是最重要的一点，在迁移100%完成前，我们不会停止推进迁移。确保100%完成迁移意味着我们可以降低文章开头提到的碎片化的问题。这可能真的很乏味，但从长远来看，这是值得的。
3. 尽量自动化
我们策略的最后一部分是关于自动化。我们的目标是实现最大程度的自动化，以使技术迁移成为无缝的体验。有时候，我们能够做到这一点，让团队无需知道基础架构组件（例如Puppet版本）已经发生了变化。在无法使体验完全无缝的地方，我们将自动PRs发送给对应团队以便review和merge。
雄关漫道真如铁，而今迈步从头越
我们的目标是让我们的工程团队无需关注99%的基础组件迁移。可以通过在平台中提供更多的工具来实现这一目标，这些工具在技术栈中处于较高的位置，底层基础设施组件不会直接暴露在内部用户面前。
这是一个漫长的旅程，我们在这个过程中学到了很多。我们希望我们的失败和学习能激励你消除一些长期的技术债务。愿您安然迁移!
译者注：Tribes（部落）和Squad（小队）是Spotify团队比较独特的组织架构，Spotify的技术团队由多个小于百人的部落组成，而每个部落又拥有多个小队。
原文链接：https://engineering.atspotify.com/2020/06/25/tech-migrations-the-spotify-way/