深夜生产事故，人工多线程来救场！

有一个读者问我：你认为一个程序员具备什么样的能力，才算得上是厉害的程序员?

我答：拥有解决问题的能力的程序员。

这个回答貌似有点抽象，不要紧看下面的文章你会慢慢有所了解。

一、解决问题的能力

很多年前，当我还是一个小菜鸟的时候，我的领导经常告诉我，解决问题的时候，不要局限于技术本身，并且形象的给我举了一个例子。

有一次两个程序员一直讨论，如何判断两台服务器之间是否网络正常，争争吵吵了很久。旁边的一个测试说，Ping 一下不就知道了吗?就这样他们用 Java 代码实现了 Ping 操作解决了这个问题。

多年以后，虽然我知道有更优雅的方式来解决这个问题，但是我仍然觉得之前的那个测试人员很聪明。后面我们持续打过一年交道，她能力真的很强，在小公司相当于产品经理+测试的职能。

需要给大家说明的是：解决问题的能力和技术能力是两个能力区间，我见过很多程序员源码玩得一溜，生产出现问题的时候仍然不知道如何去解决问题。

生产出现问题的时候，是考验一个程序员的最高水准，在面对高强度高压力下，动作不变形，能够冷静思考、分析、解决问题，能达到这个水平的程序员，这在古代可以拜为上将军。

我一直非常喜欢能够快速解决问题的程序员，我也乐于在各种生产出现问题的时候，第一时间去研究去分析。说一句不厚道的话，好程序员都是在解决问题中锻炼出来的，特别是生产环境出现问题时，能够站出来的程序员。

二、给大家分享一个深夜技术故事

01. 老平台和新平台

公司有一个老系统，一个新系统。

老系统使用了很多年，早已经超出了它能支持的极限，最早在2013年上线这套系统的时候，预估每天的交易量在一两个亿，实际上现在每天已经跑出了 40 亿的交易量。

从2013-2017年，技术团队做了很多努力，老系统使用的是 Oracle 数据库，为支持最大的交易量，读写分离分库分表+各种最强硬件搞上；系统拆分、重构、优化了很多次，仍然满足不了公司日益增长的交易量。

说实话，团队能把一个老系统整成这个样子，也确实不易。最初的架构设计不合理，缝缝补补终究解决不了大问题。研发新平台成为公司发展必须要做的一件事情，新平台一期设计可以支撑日百亿的交易量，最重要的是支持后期日千亿的扩展。

经过兄弟们的艰苦奋站，新平台终于上线了。新平台上线是成功的一小半，后面的数据迁移才是最最重点的事情。

运行了好几年的老系统，使用的是传统的垂直架构，(架构演进可以参考这篇文章：从架构演进的角度聊聊Spring Cloud都做了些什么?)，各种业务、政策、活动、风控都揉在了一起。

新平台使用的微服务架构，光微服务就搞了上百个，数据库 MySQL HA。两个系统在架构设计上隔了一代，在设计时为了兼容老系统的部分功能，还做了部分沉余设计，反正这两个系统就不是一个时代的产物。

迁移的要求是，从老平台迁移到新平台的时候，不能影响到商户的正常交易。打个比喻就相当于，你开着车在高速公路上跑，在行驶的过程中换掉车轮，而这个过程还得让坐车的你还不能有任何感觉。

于是我们研发了一套迁移系统，本来计划着一批一批的迁移，给新平台一次切一两个亿的交易量，慢慢看看效果再根据节奏来走，但是突然来的一次政策(活动)打乱了这个节奏。

02. 新政策带来的变化

对于第三方支付公司来讲，经常会随着市场环境推出一些新政策(活动)，有些政策比较简单，但大多数政策很复杂，往往需要很大的开发量。

当时新平台已经切换了一段时间，大家慢慢对新平台有了一定的信心，就决定在这个新政策在新平台实施。计划在执行政策的当天晚上，把其中一个老平台上剩余的商户全部迁移到新平台。

方案定下来之后，各部门开始各司其职，运营中心对外发通知，我们要在元旦的时候搞个大动作，可能会有什么样的变化；营销中心负责联系各代理进行分批培训；商务部门开始出公司的红头文件，下发各分公司。

我们提前和客服、运营部门做好沟通，可能会面临哪些问题提前做预案;公众号、公司官网、App、邮件对外通知政策变化，公布开始执行日期;产品中心负责政策落地需求梳理，研发中心开发新政策确定的方案。

最最最重要的是，要确保元旦晚上可以把剩余几百万的商户，一次性平稳的迁移到新平台。

03. 半夜开始迁移