主题 08：如何熟悉一个完全陌生的系统

1. 引言

作为工程师，在职业生涯中不可避免的会遇到以下场景：

• 入职新公司或者转岗到新部门，如何有条不紊地熟悉已有系统？
• 支援陌生系统的迭代开发或者维护，如何快速上手？
• 所在团队同事离职或转岗，需要你接手相关系统，如何尽快进入角色？

面对上述场景，梳理一套方法论，从而有序、高效地应对十分必要。笔者结合自身经验和与优秀同事交流的结果，将熟悉一个陌生系统的方法总结为三部分：业务学习、技术学习、实践强化。三个部分由浅入深，循序渐进，同时每个部分都列举了常见的问题。

2. 业务学习

欲了解一个系统，必先了解其业务。业务学习，即从业务角度去学习系统，我们需要了解系统的用户是谁、提供了哪些功能、带来了什么价值、有哪些参与方等。清楚系统相关的业务，透彻理解系统在干什么。作为一名工程师，不能脱离业务，须知技术是为业务落地而服务的，再优秀的技术最终也需要以具体的业务形式触达用户、服务用户，如此才能真正创造价值。

既然业务学习是熟悉一个系统的首要任务，那么，如何开展业务学习呢？首先，你应该体验一下你所面对的陌生系统，对其形成一个具象的认知，体验的同时记录一下业务相关的问题，带着这些问题学习将事半功倍。在此，笔者列举一些常见问题：

• 系统所在行业的情况是怎样？
• 系统的目标用户是谁？比如是给公司高层做决策用？给运营或客服用？还是服务互联网用户？
• 平均有多少人在使用？高峰期多有少人在用？有多少 DAU（daily active user）、MAU（monthly active user）？
• 系统有什么业务价值？有哪些指标可以衡量系统业务价值？系统有哪些功能模块？系统有哪些领域概念？梳理下系统的领域模型。
• 系统的关键业务流程有哪些？关键业务流程是怎样的？系统的非功能性需求有哪些？如性能、质量、扩展性、安全性等。
• 系统的历史遗留问题有哪些？目前面临的问题有哪些？系统未来的发展规划是怎样的？系统是否有相关监控大盘？监控了哪些指标？

带着上述业务相关的问题，你可以分别跟产品、运营、开发沟通，并学习产品的需求文档、设计文档、运营手册；查看业务监控大盘（互联网企业，重要业务一般都有业务监控大盘，从中可以看到很多运营数据）；此外，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。

总结一下，带着具体的业务问题，通过与产品、运营、开发的沟通，辅以系统相关的文档资料，了解一个陌生系统的业务将事半功倍。

3. 技术学习

业务学习之后，再通过技术学习了解业务是如何落地的。技术学习的主要内容包括系统的架构、实现的技术、系统的运维等。其中，就描述一个软件系统的架构而言，比较有代表性的方法论是五视图，五视图方法论将系统架构划分为逻辑架构、开发架构、运行架构、物理架构、数据架构。目前，虽然很少有企业完全采用五视图来分工和设计，但作为一种方法论，用来剖析一个软件系统的架构仍然具有很多优点。

3.1 逻辑架构

逻辑架构着重考虑功能需求，系统应当向用户提供什么样的服务，其关注点主要是行为或职责的划分。逻辑架构关注的功能不仅包括用户可见的功能，还应当包括为实现用户功能而必须提供的辅助功能。逻辑架构的表达图形可分为静态图和动态图，其中静态图用于描述抽象职责的划分，如包图、类图、对象图；动态图则描述承担不同职责的逻辑单元之间的交互与协作，如序列图、协作图、状态图、活动图。

就系统的逻辑架构而言，我们学习之后需要明确哪些问题呢？这里给出几个参考：

• 系统本身包括哪些子系统或模块？它们之间的关系是怎样的？
• 系统对外上下游服务（系统）有哪些？如何接入？对接团队是？
• 关键业务流程怎么实现的？用类图、序列图等方式表达出来。

3.2 开发架构

开发架构的设计着重考虑开发期质量属性（如可扩展性、可重用性），关注点是在软件模块的实际组织方式，具体涉及源程序文件、配置文件、直接使用的第三方 SDK、使用的框架、中间件、工具包等。

需要明确的问题举例：

• 系统相关的代码地址，相关权限如何获取？
• 系统相关的包是怎么划分的？如何分层？如 MVC、controller-service-dao。
• 用了什么框架，如 Spring、Dubbo。
• 用了哪些工具包？如 Apache Commons、Guava。
• 用了哪些中间件？如 RockeMQ、Redis、ETCD。
• 依赖哪些平台？外部平台如阿里云，内部平台如用户鉴权、推荐中心等。

3.3 运行架构

运行架构的设计着重考虑运行期质量属性（如性能、可伸缩性、可用性、安全性），关注点在于系统的并发、同步、通信等问题，涉及到进程、线程、对象等运行时概念。运行架构在静态方面偏重程序包在编译时期的静态依赖关系，动态方面则关注运行时单元之间的交互机制。

需要明确的问题举例：

• 系统日常能支撑多少 QPS？峰值 QPS 多少？
• 与上下游系统怎么交互的？RPC？HTTP？同步还是异步？
• 关键链路是否具有降级方案？降级策略是怎样的？
• 关键业务是否具有兜底策略？运作机制是怎样的？如淘宝首页商品推荐算法服务挂掉后，如何保证用户体验？

3.4 物理架构

物理架构的设计着重考虑系统软件的安装和部署，关注点在于目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性、持续可用性、性能和安全性等要求。

需要明确的问题举例：

• 系统如何发布部署？有哪些部署环境？
• 系统日常有多少台机器？是否具备动态扩/减容能力？
• 系统是否容器化？
• 系统是否多机房部署？
• 系统是否具备容灾能力？容灾能力背后的部署架构是怎样的？如支付宝的“三地五中心”容灾部署架构。

3.5 数据架构

数据架构的设计着重考虑数据需求，关注点是持久化数据的存储方案，不仅包括实体及实体关系数据存储格式，还可能包括数据传递、复制及同步等策略。

需要明确的问题举例：

• 数据存储在哪？用了什么数据库，如 Oracle、MySQL。
• 梳理 E-R 图。
• 数据量有多少？是否有分库分表？分库分表的以什么维度进行？
• 用了哪些 NoSQL 库？
• 有哪些数据同步任务？
• 大数据框架的使用情况如何？

3.6 系统运维

通常，系统运维包括系统关键运行参数监控、业务指标监控、应急预案管理与执行等方面。其中，运行参数监控又可分为 OS 视角（CPU、Load、内存）监控和 JVM 视角（Young GC、Full GC）监控。业务指标监控与具体的业务相关，比如主要接口调用秒级/分钟级失败次数。应急预案重点关注系统可能出现的问题，什么时候会出问题，出了问题怎么解决。

需要明确的问题举例：

• 系统什么时间容易出问题？比如电商双十一大促，对系统的压力很大，这时候很容易出问题。
• 系统核心功能是否有监控？有哪些监控指标？指标可表征什么问题？
• 出了问题怎么解决？是否有应急预案？比如开关配置、降级、限流配置。
• 系统有哪些坑（历史包袱、祖传 Bug）？找开发同学回顾历史问题，以免踩坑。如果解决成本可控则尽量把这些坑填上，如果当下很难解决（比如一些历史包袱）则应总结记录。
• 运营、客服反馈的常见问题有哪些？如何应对？

4. 实践

熟悉系统的业务和技术后，下一步就该投身实践了，以进一步加深对系统的熟悉程度。实践可以做需求、修 Bug、重构缺陷代码等作为切入点，亲自动手编码、调试、测试、发布。

5. 总结

已有系统通常经历了从 0 到 N 的建设过程，熟悉系统其实是一个逆向推导过程，也是一个学习架构、阅读源码的过程。在学习的过程中最好能带上思考，比如为什么要这么设计，为什么要用这个中间件？是否有更好的编码方式？哪些地方可以优化等，以此达到一个深入熟悉的过程。