一半以上的新项目，都始于交接。交接期有长有短，交接形式多种多样。不管怎样，从客户关系、团队工作方式等各方面，交接期都奠定了项目进入稳定交付或维护期的基调。
2020年10月，Thoughtworks的C团队从客户团队交接了一个有近20年历史的支付网关系统。这个支付网关主要向英语系地区的企业提供信用卡支付，储蓄卡支付等支付相关的功能，每个月的交易额过亿。
2021年1月起，C团队正式接手该项目的日常运维工作。不仅需要保证系统稳定运行，提供7×24小时On Call支持，还要响应日常业务的需求，同时保证整个支付网关符合支付卡行业数据安全标准(Payment Card Industry Data Security Standard，缩写为 PCI-DSS)。
在交接的过程中，团队面临很多的挑战，尝试了很多办法，同时沉淀了一些经验。我们将通过这篇文章将经验和实践分享出来，希望帮助到更多人。
挑战
作为一个历史悠久的“大龄”支付网关，在交接过程中我们遇到了一系列的挑战，大致可以分为下面两类：
1. 业务复杂度高
业务上，这个支付网关光是在卡支付的场景下就同时支持8种技术，还有信用卡相关的安全功能，数不清的报表和各种增值服务。
技术上，总共有100多个服务和300多个代码库，部署在超过200个EC2上;服务之间耦合严重;许多服务没有部署流水线、没有测试环境甚至没有源代码;经常需要手工操作生产环境数据库来解决问题;操作系统和软件包版本非常陈旧等。
项目管理上，没有总结和沉淀出完整而清晰的业务和技术文档。
2. 交接内容多、时间短、范围不明确
交接开始前，团队接受到的信息只有100多个服务的名字，内容非常有限;交接的时间周期比较紧张(初步计划只有30个工作日)，没有足够的时间去了解到系统的所有功能。
实践
1. 分阶段制定目标、建立重点
我们一般如何衡量一个遗留项目维护的质量呢?
- 短期：至少做到跟前团队一样。也就是说，在客户团队成员离开时，团队能具备足够的知识和技能来处理线上事故和日常业务工作。
- 长期：体现Thoughtworks不一样的地方。对项目的业务、技术和发展历史有足够了解，足以给出一个改进计划，在未来一个比较长的时间里落地、给客户带来更大价值。
鉴于项目的复杂度，在有限的交接期内达到这个目标基本是不可能的。但是如果将时间轴拉长，分阶段来实施，就比较容易做出一个切实可行的计划;同时，也能最大化交接期的价值，让团队从第一天起就朝着一个方向努力。
基于此，团队从实际情况出发，将项目分为三阶段：
通过对项目不同阶段目标的一致认识，减少了一些团队在交接期的焦虑与慌乱，从而想出更多创造性的点子，并勇敢的尝试、反馈、迭代，达到各个阶段的目标。
2. 利用C4模型梳理系统架构
通常处理的问题都是业务问题，如果不能把一个个服务放在业务流程中去理解就没有意义。因此，我们在交接完一个独立服务或者若干个有关联的服务后，都会试图用C4模型画出他们的C1(System Context Diagram)和 C2(Container Diagram)两个高级别的图，以可视化的方式展示出系统输入、输出和各服务的依赖关系。
实践证明，画图的过程可以帮助大家更好地吸收碎片化知识，有利于整个团队将知识汇总和沉淀。同时，相比于反复的解释说明，图是一种更有效的语言。
有些比较独立的模块相对比较容易画，但是涉及到不同版本API的支付流程，就需要不断地获取更多的信息来完善，反复跟客户确认。有些环节甚至在交接结束后依旧没能打通或者没时间梳理，只能在交接后，作为深入理解期的目标继续完善。
支付系统C1简化图(简化版)
3. 通过结对在团队内部分享上下文
在第一阶段交接的过程中，我们和客户团队是“1+1”的模式进行知识交接，业务知识是像孤岛一样分散在各个成员那里。另外，我们团队又因为每个人加入项目的时间和技能背景的不同，对一些背景信息、业务上下文、技术实现的掌握有一些差距。
因此，在进入项目交接的第二阶段开始，对于大部分的工作内容，我们都通过结对的方式来进行。根据不同的业务和优先级，我们划分了几个重要的主题，比如：日常需求相关的任务，PCI 相关的任务和生产环境的变更等。我们会通过专长和对服务的熟悉程度分工结对，让这两个人可以成为团队内相应领域的专家。
这样的好处有主要有：保证对应的知识能在团队中传播开来，消除知识孤岛;避免某个成员因为请假导致重要的任务不能进行;重要的线上操作可以多一个人帮忙检查。
在安排 Primary On Call 和 Secondary On Call 的时候，采取“Dev + DevOps”的组合，保证有足够的技能应对线上事故。在线上事故发生的时候，两个人一起结对配合处理。
虽然结对在前期会影响效率，但能确保团队中至少两个人熟悉特定的业务，最终可以让整个团队拥有响应事故的能力。从现在的结果来看，正是这种结对的形式，保证了整个团队的“高可用”。
4. 通过线上事故演练提升团队On Call的信心
7 × 24 小时 On Call 对团队来说，无疑会是一个非常大的挑战。在正式接手系统之前，团队感受到了比较大的压力。这些压力一方面是因为大部分项目成员缺少 On Call 的实战经验，另外一方面因为在交接的第一阶段里，我们缺少对业务实现细节和系统的深入了解。
On Call工程师不仅要参照标准处理流程，还需要在短时间内评估线上问题造成的影响并精准地解决，那么用以前发生过的事故来演练就成了我们在深入理解期的最好的学习方式。
在正式承担On Call的职责前，我们每个迭代都会有一个模拟线上事故处理的活动，主要流程为：
- 组织者会去从过去的线上故障里挑选一个有代表性的事故来模拟，比如是某一个与其他网关集成服务的事故;
- 团队约定2个小时来模拟线上事故，组织者还原当时场景，其他成员在不知情的情况下按照自己的理解进行适当的追问;
- 分成两个小组，根据现有的情况定位问题，并给出解决方案;
- 组织者进行复盘，梳理相关知识点。
通过以上方式，我们得以快速适应On Call的节奏。到现在为止，我们团队的每个成员都有作为Primary On Call的经验了。
结语
在交接的三个月里，我们持续地改进交接方式，最终将项目成功地从客户团队手中接过。无论是交付主管，还是和我们合作的客户团队都对我们的工作提出了称赞。在摸索交接的过程中，我们尝试了不同的方式让我们的交接平滑顺利，并将对交接有帮助的实践分享出来，希望对大家有所帮助。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
