每年年底或年初都会有各种总结规划，业务部门有业务的规划，研发部门有研发的技术规划，下面分享一下对系统技术规划的几点思路。

研发技术规划重点对所负责系统的技术架构升级、技术债问题以及运维问题进行梳理并根据梳理的问题制定匹配的方案，据此方案提前进行技术储备和资源预留。

业务数据分析

我们在做系统技术规划时，首先要做的不是去规划技术，而是分析一下业务数据，了解系统里每种业务类型的相关数据量以及占比，结合和产品经理的沟通或者和业务部门的调研情况，对未来业务发展做一个预判，哪些业务会出现大的增长，哪些业务可能会逐渐收缩，有了这些数据的认知，后面做技术规划就有参考和侧重点，提前进行相关技术储备，因为技术规划的最终目的是服务好业务，为业务增长保驾护航。有的发展不好的业务，即便系统有问题，考虑到投入产出比，只要不出现大的问题，没有影响到业务使用，暂时不进行较大范围的技术调整。

关停并转

随着业务的发展和系统的升级，有的系统业务已经不使用了，需要关闭，有的业务还在使用，但是用户量少，没有必要单独作为一个系统来维护，可以考虑和别的系统进行整合。

这里有两个比较棘手的问题，一个就是外部系统的交互问题，如果有交互，需要推动外部研发部门同步进行改造下线或者转移，如果交互系统比较多，协调沟通的成本会很高，需要提前周知并逐个进行排期改造。

另外一个棘手的问题就是数据库的迁移，这个迁移分数据库表和数据的迁移，数据库表迁移还好，挑战在于数据的迁移，因为如果数据需要使用，而且线上系统还在运行，为了能保证数据迁移后的正确性，并且不影响业务使用，大概率需要开发数据迁移同步工具。

技术架构升级

升级技术架构需要非常慎重，有两个思路，一个是引入新技术来升级，升级这事取决于两个条件，一是老架构无法通过打补丁的方式来满足业务的快速增长了（业务数据量增长和并发流量增长），二是通过调研有更好更成熟的技术可以很替换这个老的技术。如果这两个条件都满足，那么就可以规划升级了。还有个思路就是不引入新技术，而是引入新的设计模式来升级重构老代码，将老代码通过划分边界的方式分包、分层、分类进行解耦，提升架构的可维护性和可扩展性。

性能问题

性能问题是技术规划中非常重要的一块，性能问题分两类，一类是显性的，比如系统里面操作一个查询功能，要等待一段时间才出来结果，非常影响用户的使用体验，迫切需要优化改善；另一类是隐形的，比如后台任务处理，由于数据量大的原因或者多表关联存在一些不易被发现的慢SQL查询。这些性能问题非常消耗容器资源，很容易引发服务器宕机。所以需要非常重视性能问题的优化，这关系到整个系统的稳定性。

运维问题

系统在日常运行过程中，难免出现用户操作问题、外部系统问题以及内部系统漏洞问题，这些问题一方面影响业务使用，另一方面研发需要花费大量的时间去修复数据问题，耗时耗力，所以为了提升日常运维效率，需要揪出那些严重影响效能的问题，有的问题可以通过逻辑优化来修复，有的很难完全杜绝，需要额外开发运维问题处理工具，当有问题来的时候可以快速解决处理，既不影响业务使用，也快速解决了问题。

效能提升

降本增效近几年甚至未来很长时间都是研发的一项非常重要的工作，研发需要探索各种新的模式来提升效能，需求开发方面，比如低代码模式，通过配置化的方式实现需求的快速交付，今年非常火爆的ChatGPT，通对话模式实现代码的编写、纠错等功能，这些都是可以探索的方向，借助这些工具提升研发效能。

制定方案

以上这些方式只是从不同的角度和不同的思路来进行规划，具体深入到问题本身时，可以对问题进行归类，归类后会发现不同的方式识别到的问题可能是同一个问题，只不过表象不同而已。比如一个运维问题可能也有性能方面的问题，也有可能是技术架构的问题，甚至也可能需要关停并转。

问题确定下来后，接下来就需要根据问题来制定解决方案。在制定方案的过程中，需要做一些技术调研，也可以组织团队人员头脑风暴共同讨论，集思广益，制定匹配的方案，方案的制定是一个从粗到细、逐步完善的过程，最终输出一个方案的概要设计，有了这个设计作为基础，后面在推进过程中更容易落地和实现。