有的放矢：从纷繁问题中识别核心，而非试图解决所有问题

通常当系统架构不满足业务发展时，表现形式是系统不断出现各种问题，轻则响应慢、数据错误、部分用户访问失败，重则宕机、数据库瘫痪、数据丢失，或者开发效率很低。一开始技术团队往往只针对具体问题逐个解决，但如果持续半年甚至一年情况都不见好转，就可能有人开始怀疑是架构本身出了问题，进而启动架构重构分析。真正开始做架构重构分析时，架构师常常会感觉自己进了一片迷雾森林，到处都是问题，每个问题看起来都需要解决——有的架构师一上来就搜集出一份上百行的问题清单Excel表格，看着这么多问题瞬间懵掉：这得猴年马月才能全部解决完。但期望通过架构重构解决所有问题是不现实的，架构师的首要任务其实是从一大堆纷繁复杂的问题里，识别出真正需要通过架构重构来解决的核心问题，集中力量快速解决，而不是妄图靠一次重构毕其功于一役地解决所有问题。否则很容易陷入”人少事多头绪乱”的处境——团队累死累活折腾大半年，最后发现好像什么都做了一点，但每个问题依然还在那里。尤其对于刚接手新系统的架构师或技术主管来说，一定要克制住”新官上任三把火”的冲动，避免摊大饼式、运动式的重构和优化。至于那些被识别出来、暂不属于本次架构重构范畴的问题，也不是就此放任不管——可以在架构重构完成后，另外启动多个优化项目来专门解决它们；此时的优化因为主要由团队内部就能完成，和其他团队没有太多关联，推进速度反而很快。相比之下，如果不先做”有的放矢”式的架构重构、而是让这些非核心问题混在重构范围里一起优化，那每次优化都要拉一大堆关联业务团队来讨论方案，效率会非常低下。