大型核心系统的升级或迁移

1. 前言

.　　一般来说公司的发展是一个快速迭代到逐渐成熟的过程，公司的技术能力也是同样的一个发展过程。对于一个强力依靠技术的互联网公司，这一点就更加明显和深刻了。接下来我们就来讨论一下这些技术演进过程中最为重要的一个环节：核心功能升级或迁移。

.　　在一个公司的技术发展过程中，核心系统的功能演进是非常缓慢的。究其原因我认为有l两个：
- 业务需要核心功能稳定、初期就应基本定型。
- 因为第一个原因核心业务会慢慢变得复杂，升级风险也不停增大，直到你害怕； 甚至可能危及公司存亡（这个并不危言耸听，我就曾经历过失败的核心系统升级项目，且影响深远，看这里的同学可能是以前同事就不再继续展开了）。

.　　基于以上，这种场景在公司发展中出现的次数和频率都是少之又少的。自然经历的人也就很少。如果你有幸经历了这样的事，请一定要好好珍惜，不要退缩。怕什么真理无穷,进一寸有一寸的欢喜！

2. 准备

.　　言归正传，如果真的需要做我们从什么上手？基于一次成功但不太完美的经历（一下简称Xplan）总结如下。

2.1 现状整理

2.1.1 现有业务梳理

.　　万事开头难，要想切换或升级系统，第一步必须要充分理解现有系统的全部业务逻辑，包括坑。 这个说起来难，但其实可以细分。最简单直接的方式是根据基础流程和业务梳理。这一招对大多数系统都是有用的，当然也包Xplan。
.　　采用以上方式Xplan梳理出系统的1条主流程和7(左右)条业务流程。这里必须强调一点，整理出的这些业务流程必须是闭环的（说白了为了完美不能漏掉任何旁枝末节）这一点和普通的功能开发时很不一样的。这样是Xplan开始做的不太好的地方。
.　　此阶段产出是系统业务流程图、注意事项、坑位等。

2.1.2. 回归Case整理

.　　有了完美的业务梳理，接下来一项繁重的事情必须要做。那就是回归Case整理。根据您的业务进度需要可采用两种方式

- 地毯式
- 自顶向下，由核心到边界 多次完善

.　　什么情况采用设么方式，相信各位老手一定心知肚明。
.　　此阶段产出尽可能多的重要的、全的回归Case，这个事无巨细。

2.2 新系统方案

2.2.1 新方案设计

.　　新方案的设计的理由、合理性不在本篇文章范围内，这个应有对应的设计、决策者保证。但是新方案必须要保证对原有系统的兼容

2.2.2. 新方案对现有周边生态的影响

.　　新方案的设计设计完毕之后一定要从新再次梳理一下新引入的概念、模型、角色对现有生态系统的影响，并补全周边方案。
.　　此