古人兵法有云：“谋定而后动，知止而有得。”这句话道出了一个深刻的道理——真正的智者，从不贸然出击，而是在行动之前，已经将全局了然于胸，将每一步棋都提前布局妥当。架构重构亦如是。
在之前的文章中，我们探讨了“有的放矢”与“穿针引线”两个思维办法，学会了从纷繁复杂的问题中识别关键的复杂度问题，并有的放矢地通过架构重构来解决。然而，当真正站在重构的门槛上时，你或许会发现一个尴尬的事实：即使你清楚地知道问题所在，却依然无法落地。因为很多条件尚不具备，因为有的问题没解决之前就无法动手术。
这正是第三式心法“谋定后动”的真谛——分段实施的策略艺术。
当我们对系统进行深入分析和思考后，可能从最初的100个问题中筛选出50个需要在架构重构中解决的。其中一些是基础能力建设或准备工作，另一些才是架构重构的核心工作。面对这50个问题，很多人会陷入一个误区：每次挑一个解决，期望最终把所有问题都解决。这种做法操作简单，但效果却很差。
为什么分段实施比“一锅端”更有效？原因有三。
第一，不区分优先级会导致资源分散。所有问题一视同仁，没有集中有限资源去解决最重要或最关键的问题，做了大半年回头一看，好像做了很多事情，却没取得什么阶段性的成果。团队会逐渐失去信心，相关人员对项目的评价也会降低。
第二，不将问题分类会导致效率低下。相似问题没有统筹考虑，方案可能出现反复，徒增工作量。
第三，业务版本的压力会驱使团队专门挑容易的实施。到了稍微难一点的问题，就因为复杂度高、投入大而被搁置，最终达不到重构的真正目的。
以X系统为例。在架构师加入之前，其实也已经整理了系统存在的问题，涵盖可用性、性能、安全、用户体验等多个大项，每个大项又包含十几二十个子项。然而实施时基本是“挑软柿子捏”，觉得哪个好落地、占用资源不太多就做哪个。结果半年过去了，做了很多功能，整体却没什么进展。
后来成立了一个专门的项目组，在原有问题清单的基础上，识别出架构的核心复杂度体现在庞大的系统集成了太多功能、可扩展性不足。但同时，系统的可用性也不高，经常出线上问题，耗费大量人力处理。经过分析发现，如果要做架构重构，系统需要处于一个比较稳定的状态，不能经常出线上问题。而当时可用性不高的原因多种多样：有的是硬件资源不够，有的是系统组件使用不合理，有的是架构本身存在问题。
基于这些分析，制定了总体策略：真正的架构重构在第三阶段，前两个阶段都是为第三阶段做准备。如果没有前两个阶段的铺垫就直接开始第三阶段，架构重构方案需要糅合很多前期事项，会导致方案不聚焦，而且异常复杂。
将明显且比较紧急的事项优先落地，解决目前遇到的主要问题。例如，扩容在多个系统中都是最优先实施的。因为如果不扩容，系统隔三差五就会出现响应超时报警，一会儿是过载报警，一会儿是大面积不可用……这些问题耗费大量的人力和精力，团队根本没空做其他事情。
将问题按照性质分类，每个阶段集中解决一类问题。例如，第二阶段可以将多个底层系统切换到公司统一的公共组件，提升整体可用性。分类的目的在于聚合相似问题，统一制定方案，统一实施，避免方案反复。
这点与很多人的直觉不太一样。有的人认为应该先攻克最难的问题，所谓“擒贼先擒王”，解决最难的问题后其他问题就不在话下。这样看起来很美好，但实际上不可行。
首先，一开始就做最难的部分，会发现想要解决这个最难的问题，要先解决其他容易的问题。其次，最难的问题解决起来耗时都比较长，占用资源比较多，如果一开始做最难的，可能做了一两个月还没有什么进展和成果，会影响相关人员对项目的评价和团队士气。第三，刚开始的分析并不一定全面，所以一开始对最难的或者最关键的事项的判断可能会出错。
采取“先易后难”的策略，能够很大程度上避免这些问题。随着项目推进，一些相对简单的问题逐渐解决，会发现原来看起来很难的问题已经不那么难了，甚至有的问题可能都消失了。先易后难能够比较快地看到成果，虽然成果可能不大，但至少能看到一些成效，对后续的项目推进和提升团队士气有很大好处。随着项目的进行，原来遗漏的点，或者分析和判断错误的点，会逐渐显示出来，及时根据实际情况进行调整，能够有效地保证整个重构的效果。
按照前三个步骤划分了架构重构的实施阶段后，就需要评估每个阶段所需要耗费的时间。很可能会出现有的阶段耗时只需1个月，而有的却需要6个月。虽然这可能确实是客观事实，但通常情况下，按照固定的步骤和节奏更有利于项目推进。经验是每个阶段最少1个月，最长不要超过3个月。如果评估超过3个月的，那就再拆分为更多阶段。
每个阶段又可以细分为任务子集。当任务子集比较小的时候，多个任务子集可以并行；当任务子集比较大的时候，就当成一个独立的里程碑推进。
分段实施将问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源解决一类问题。这种做法有几个显著好处。
每个阶段都有明确目标，做完之后效果明显，团队信心足，后续推进更加容易。每个阶段的工作量不会太大，可以和业务并行开发。每个阶段的改动不会太大，降低了总体风险。
回到X项目的例子，采用三阶段策略后，第一阶段的“救火”完成后，系统很少再有因为机器过载、缓存响应慢、虚拟机挂死等问题导致的故障了。完成第二阶段的事项后，因为组件、外部系统故障导致系统故障的问题也很少了。完成前两个阶段后，团队终于可以安心地做第三阶段的“服务化”工作了。
S系统的重构做法也类似，但S系统当时面临的主要问题是可用性不高，并没有系统耦合的问题。所以策略是“先救火、后优化、再重构”：“救火”阶段做了扩容和Nginx一键切换功能；“优化”阶段将一些明显的可用性问题解决；“重构”阶段将原来的单点数据库改为多中心。