Atlassian data migrate 数据迁移

数据迁移 在 Atlassian 的用户来看，都是让人觉得充满风险及工程艰巨的任务，但其实这个工作，在运维期间的各种场景会发现，数据迁移其实是一个很需要时常被执行的例行性任务，但用户端总是到了 应用程序 本体在出现重大问题，无法维持正常运作的这个时刻，才体会到数据迁移工作的重要性。

Atlassian data migrate 数据迁移
排除单点故障SPoFSingle Point of Failure
版本的升级VCSApplication Upgrade
- Test Environment 測試環境
- Test Group 测试团队
灾难恢复Recovery TimePoint Objective
- Root Cause意外的真正原因
兼容性测试 Compatibility Test
- Backward Compatible 向后兼容
- Forward Compatible 向前兼容
数据迁移 Data Migration
结语

排除单点故障(SPoF,Single Point of Failure)：

如果您工作的 jira/confluence 环境就只有那么一座主机在运行着，那么一定是随时处在担心害怕的日子当中，不管AP是座落在拟虚或是实体机上，只有单一节点来维持AP的运作，是非常高风险的，这样高风险的构架，我们称之为SPoF，要消除这种风险只有改变构架，节点逢一就变二，这样才可能避免当唯一的节点故障时，所有的用户都只能等待你把节点恢复正常后才可以开始工作，试想！这样的成本会有多高。这还是要能够顺利把问题排除才算，但问题通常是陷入胶着的，连个方向都还不明朗，到底要花多久的时间才可以把问题分析出来，甚至找到故障排除的方法。

在问题还无法排除时，应该让生产环境尽快进入正常运作，如图显示：

版本的升级(VCS，Application Upgrade)

不管是AP应用程序或是插件的版本，原厂都有非常详尽的升级备注（release note），但是如果没有好好的记录版本异动的历史资料，在问题来临时，你很难掌握当下的问题到底跟之前升级的哪一个版本是有关联的。

(Test Environment) 測試環境

在AP应用程序执行了部份的升级后，发生了一些周边功能不正常（side effect）的运作，比如单一插件的升级，如果升级过程都留下记录，也许是可以追朔，但也因为数据大都已输入了一段时间，恢复回旧有的版本，也许是另一个数据移失的灾难，这突显在生产环境上应用的插件或是AP本身，前期的测试阶段是不可省略的。
商用的应用程序及插件，都有一定的质量，生产环境上所要作的测试不是软件本身，而是不同客户自家数据的搭配测试。

保留独立的测试环境，可以避免不可靠的组合进入生产环境如图示：

(Test Group) 测试团队

前期的测试工作到底落到谁的身上才是适当的？事实上测试的结果大家都关心，运维团队会担心不可靠的组合，造成日后维护的困扰。开发团队会担心项目进行一段时间后，所有输入的数据是有问题的。因此前期的测试，大家都不可以缺席，但是要分工才是重点，运维团队再怎么测试也都只是针对构架面及功能运作是否有明显立即性的问题，其他进一步的测试，还是需要开发或管理团队本身来进行，因为他们的测试涵盖率较广，能不能通过测试，他们的点头较俱代表性。

运维团队的测试范围尽止于构架面及功能性 :

研发团队的测试涵盖率较广，较俱代表性：

灾难恢复(Recovery Time/Point Objective)

只要有可能，它就一定会发生。意外是我们一定要面对的，运气不会永远站在我们这一边。我们虽然无法保证意外永远不会发生，但我们可以确保当意外来临时，生产环境可以在最短的时间内恢复正常。

(Root Cause)意外的真正原因

大家都不愿意当发生意外的凶手，但其实意外的发生跟大家都有关系，事后分析的结果也告诉我们，意外通常是可以避免的，因此意外的真正原因时常被团队刻意模糊掉，这里指的意外通常是指带来的灾难无法让大家承受及处理的，试想！如果有一个容灾构架让意外发生时，可以让灾难降低到一个大家可以处理的程度，那么意外的真正原因是不是就可以开诚布公的拿到台面上来，认真的检讨及分工想出下次如何避免的方法，而不是找个代罪羔羊然后模糊掉意外的原因，如果不面对意外的真正原因那么定时炸弹还是永远的躺在那里，等着下一个代罪羔羊。

有了容灾的构架，意外才有避免的可能：

兼容性测试 (Compatibility Test)

需求是无止尽的，前端的开发团队或是管理团队，需要更进一步的功能来完成他们艰巨的任务，而此刻您发现有个插件是可以满足这样的需求时，你应该怎么开始进行？
我们理解，新插件的安装或是旧插件的升级，都需要承担相当程度的风险，唯有独立的兼容性测试平台，才可以降底这样的风险，把不兼容的组合排除在生产环境之外。
>

(Backward Compatible) 向后兼容

一个全新应用程序的版本，代表着一个新的方向，所有的插件都要朝向此一方向来兼容，这就是向后兼容，在升级的进行当下，代表着一个版本的世代交替，在旧版本的主应用程序里所有的插件，如果还没有支持未来的版本，那么兼容性就有待确认。
打个比方，新版本的jira/confluece新版本都有支持Data Center那原有的旧插件未必都有支持Data Center，所以需要进一步确认未支持Data Center的插件，是否可以在有支持Data Center的新版jira/confluence下运作正常，这个必须先要先确认才可以决定后续要怎么进行。

(Forward Compatible) 向前兼容

许多插件在应用程序中协同运作良好，如果因为有错误修正的小版本升级需求，就必需要考察到与之前旧版本的兼容，如果因为升级后，造成旧版本除了需要修正的部份以外，其他功能的不正常，那升级的必要性就需要重新评价。

数据迁移 (Data Migration)

Atlassin 系列的应用程序在执行数据迁移的步骤及过程，每一种应用程序都有他们不同的步骤及方法，但是整体而言备份及还原的数据资料，基本上都没有跟构架纠节在一起，怎么说呢？
如下图示例，在我们平日排程备份出之zip格式档案，在我们复原（recovery）回另一座底层完全不一样的数据库构架，是不会影响整个数据的完整性，甚至不同jira版本之间的 备份/还原 也是如此，于是数据迁移就这么轻易完成了。
正因为如此，全新安装的应用程序平台可以接受旧版本的备份文件，所以原厂建议全新安装的切换式升级，在线升级是不得已的作法，但由于情况紧急，小版本的修正确定是在线团队所必需要排除的问题时，在线升级小版本的运维团队大有人在。切换式的升级虽然较为可靠，但眼前的资源条件仍然不允许的情况下，在线升级虽然充满风险，但仍然是一般的作法。

例行备份出来的 zip 档是不包括底层结构的改变

结语：

虽然数据迁移的步骤看似容易，但在生产环境上很少有运维敢大胆的在线进行，主要的因素是缺乏该有的构架，比如双机热备（High Available）也就是HA，这个主要的构架缺乏的话，上述所有重要的议题如：故障排除/版本升级/灾难恢复/兼容性测试/数据迁移….等等，这些都只能担心，不能作什么。
企业在成本的考察下，要多申请一座，不管是虚机或是实体机的节点，总是百般考虑，迟迟不肯放行，在这里建议一些应用程序的维运团队可以考虑在即有的资源下，以 docker 的构架，容器化（containerize）您手头上的 Atlassian 应用程序，这样的方向，也许可以帮助您脱离出维运的困境。