飘（在云端）

2018 年到目前为止最大的一件事，终于落停：周四凌晨，我们（Tubi TV）把所有的服务和数据从一个 region 迁移到另一个 region。工程团队内部给项目起了一个响亮的名字：Move to Oregon。对于技术公司来说，这种迁移，是单向的，不成功，就成仁 —— 一旦我们解决不了迁移中发现的所有严重问题而不得不回滚的话，不光意味着工程团队半年多的努力白费，而整个公司服务能力的未来也变得黯淡无光。

这事年前就在铺垫，甚至，最初的很多工作可以上溯到去年最后一个季度。我们用 terraform 重塑我们的 infrastructure（infrastructure as code），来打造一个 code review driven 的生产和测试环境，希望籍此能够将环境的无记录的，变化无常的变更管理地更加科学和透明。我们后端团队（是的我们没有专职的 devOps）花了不少时间撰写脚本，并构建 staging 环境，以及 production 环境。一切准备妥当后，我们要做的，就是按下按钮，切换流量，静待一切好的坏的事情发生。就像淝水之战的谢安：心里打着鼓（墨菲定理啊，千万不要发生），表面上泰然自若（我们已经做足了万全的准备）。

很多历史事件，站在后来者的角度，可以说的风轻云淡；然而只有亲历者身涉其中，才知道过程的艰辛。数种形态各异的数据库服务，几十个 service，几百台机器，以及长长的，望不到边际的 action list，由约莫十个后端工程师在流量相对低峰的几个小时内迁移完毕，并且要尽可能降低对用户的影响和广告收入的影响，不啻于在一架正在飞行的飞机上进行外科手术般的引擎升级换代。几个月的努力，毕其功于一役，每个人所经受的压力非同寻常。

我从我的前老板 AK 在 Juniper 的沉浮中学到三件事：1) 人无完人，这个世界不是非黑即白 —— 不论你是否喜欢一个人，只要那个人身上有值得学习的地方，就学习之，即便你再看不上对方；2) 人一生中难得遇到一些一辈子可能也遇不到第二回的重要项目，面对这样的机会要勇敢地站出来抓住它而非逃避；3) 人要向前看，过去的功绩荣辱过去了就过去了，不要老挂在口中，让它们羁绊自己继续成长，要平常心 —— 「举世而誉之而不加劝，举世而非之而不加沮」。

对我和我的团队而言，这次 region to region 的迁移，就是一辈子很难遇到的重大项目，是天赐的机遇。

所以我想趁着记忆还未冷却，写点文字将其持久化，算是给自己一个交代。

《礼记 中庸》里曰：凡事豫则立，不豫则废。言前定，则不跲；事前定，则不困；行前定，则不疚；道前定，则不穷。我们做事前如果先有详尽的计划和准备，发生让自己追悔莫及，走投无路的事情的概率就大大降低。Data Center 的迁移，是个苦活累活，考究的是事无巨细均考虑周全。我们都有哪些 service，哪些对外，哪些对内，哪些第三方，哪些自研，谁来负责，目前状态是什么，ETA 是哪天，这样的 responsibility matrix 要构建好。迁移时分几个阶段，迁移前几个小时干什么，迁移时 DNS 切换的先后顺序，迁移后都要验证些什么，如果出现问题，预案是什么。就跟下棋一样，一步步要先尽可能考虑清楚了，省得到时候焦头烂额，急中生错。

由于我们没有专门的 devOps，所有的 terraform / ansible 脚本，都是后端团队完成。这样有好有坏。好处有二：

• 后端团队真正对所做的服务有端到端的责任（ownership），整个反馈环（feedback loop）高效运作。一个服务如果开发的是一拨人，上线的另一拨人，维护的是第三波人，那么一定是有问题的：互相推诿避免不了，且反馈的闭环是撕裂和低效的。
• 高性能的服务是由承载服务所用的资源，第三方工具以及服务代码共同协作而成。开发者是最有机会将三者揉在一起，达到最佳状态。

所以我们基本的准则是谁开发谁上线，谁就要肩负起全责。

这样做的坏处是，遇到这种大型的 devOps 项目，开发者的时间难以保证。后端团队手里有各自的项目，很难全心投入。

因此，这个项目的截止日期一拖再拖，似乎永无完结的一天 —— 即便我们大部分脚本工作完成，staging 运行稳定，我们还是无法达成一个一致的上线迁移时间表。眼看 2018 年的第一季度就要这样拖过去了，三月初，在得到项目核心成员的支持下，我定了个 deadline：3/22 凌晨两三点正式切换流量上线。

之后的日子，就是撕资源，或者说撕优先级。虽然 staging ready，但我们还是要把所有服务在 shadow production 环境里建立起来，并且测试通过。建立的过程并不困难，就是运行准备好的脚本，然而，有几个服务还是出了差池，费了不少功夫问题才得以解决。

虽然 shadow production 趋于稳定，主要问题都得到解决，我却有个担心：新的 Data Center 使用新域名 abc.com，所有的 client 使用 tubitv.com，即便 abc.com 一切服务无误，我们却很难保证当 tubitv.com 指向 abc.com 对应的服务上去时不出错。Tubi TV 整个 business 的麻烦之处是，客户端太多太多，有些历史遗留的，工程上不再维护的客户端对于我们自己来说都是黑盒。因而，我们不得已想出了一个非常 hack 的方式来测试 —— 把公司 HQ 的 DNS 服务器切换到了自己用 bind9 搭的 DNS 服务器上。这个 DNS 服务器会劫持 tubitv.com 的所有子域名，指向新的 data center，同时 forward 其它 DNS 请求。这个方法帮助我们测试出了一些严重的，我们完全没有预料到的 bug。

到了决战的那一天，美国团队的大部分工程师都半夜待命，而中国工程师也在地球的另一半磨刀霍霍。对外的服务整体下线，服务一个个被切换到新的区域，数据库的增量备份的恢复等等，里面的种种细节恕商业机密不能对外。虽然我们已经尽可能准备周全，还是遇上了三四个严重的问题，在得到解决之后，我们撰写了事后分析（post mortem），一个一个问题从 root cause 谈到 solution，到 lessons learned。当一切忙活完，已经是 3/22 早上 7 点多，是我差不多到公司的时间。

（本文未发布在公众号，2020 年 1 月解密，细节全部删减）