如何熟悉一个系统_如何快速熟悉一个系统-优快云博客

在平时的工作中，接手别人的系统上一个一年还是会有几次的工作，本期我们就来梳理下，一般接手一个新系统都要从哪些方面来尽快熟悉下，保障自己不掉队。

接手一个新系统，一般要从这几个方面来熟悉：

一、业务知识；

二、技术知识：

1、逻辑架构

逻辑架构主要要了解以下这几部分：

1.1系统整体和每个子系统的架构图、核心领域模型；

1.2几块核心模块和业务流程、时序图；

1.3每个系统的上下游系统依赖、核心联系人、交互协议方式

2、开发架构

开发架构主要关注使用的框架、第三方 SDK、中间件、工具包

3、物理部署

4、数据架构

5、系统运维

下面我们就来详细看下每部分应该如何做：

一、业务知识
1、系统有哪些领域概念？梳理下系统的领域模型；
系统的关键业务流程有哪些？关键业务流程是怎样？

系统的非功能性需求有哪些？如性能、质量、扩展性、安全性等；

系统未来的发展规划是怎样？

2、系统有什么业务价值？有哪些指标可以衡量系统业务价值？
系统有哪些功能模块，大的模块系统的目标用户是？规划平均有多少人在使用？

高峰期多有少人在用？有多少 DAU（daily active user）、MAU（monthly active user）？

二、技术知识：
1、逻辑架构
逻辑架构主要要了解以下这几部分：

1.1系统整体和每个子系统的架构图、核心领域模型；

1）架构图主要描述总体架构、系统模块、子系统模块定位；

2）子系统模块主要描述子系统定位和其架构和子系统之间的关系；

3）系统集成关系：侧重跟外围系统之间的关联和交互；

4）核心领域模型可以按照ddd的模式来梳理，并和数据库的表对应；

5）网络架构图；

6）系统部署图；

1.2几块核心模块和业务流程、时序图；

1）每个大的功能系统操作页面、入口类和其业务流程图；

2）对应的接口或者入口类及从页面到数据库的线，从接口到数据的线、主模块设计细节图例如静态的包图和类图，动态的有序列图、协作图、状态图、活动图；

3）与其他系统之间关键流程扭转，状态流转图等；

4）本模块能做的需要监控的核心业务流程和其监控告警策略；

5）需要几个子系统间甚至系统间进行数据分析验证的数据库表和分析逻辑；

6）公共模块、核心模块或者影响面大的模块是哪些；

7）各个模块的非功能性现状大致是怎样的，例如：性能、扩展性、安全性等；

1.3每个系统的上下游系统依赖、联系人、交互协议方式

1）本系统的上线游依赖，内部交互方式是rpc、http、http？同步还是异步？联系人？

2）和外部交互的也需要整理进来，和各个核心交互能处理的阈值和失败处理方式（是指在正常情况下的阈值，非其他业务不运行，单独某个接口的处理阈值）

2、开发架构
开发架构主要关注使用的框架、第三方 SDK、中间件、工具包，具体如下：

1）使用技术框架、前端和后端都列；

2）对接使用的第三方sdk列表；

3）用了哪些开源工具包和对应版本号；

4）用了哪些中间件和其版本，还有对应的java引用的客户端类型，例如redis是Jedis 还是Lettuce 、还是Redisson ，中间件加载使用所在的包和类和其行业通用解决方案梳理，例如redis分布式锁的代码；

5）各个子系统依赖内部什么资源才能启动，

依赖公司内部或者其他平台的什么资源才可以正常运行核心功能，启动时间大致多少；

3、物理部署
1）系统如何发布部署？和系统各自有多少台机器？

2）系统怎么部署的？接入层，部署方式，如集群部署、分布式部署等

3）假设系统扩容，所依赖的资源例如网络、机器等申请多少，假设做异地多活或者单元化架构有哪些改造点

4、数据架构
1）所用的数据库类型，承担了什么功能，已经使用容量、总容量、告警类型和阈值，

可能的限制因素和数据硬件部署方式和软件架构，例如mysql的mma还是mgr还是mha等，有无和其他系统混合部署情况？

2）梳理表之间的E-R 图；

3）核心表现有数据量有多少？每日增量多少，业务投放对现有容量的影响？是否需要分库分表？

4）用了哪些 nosql 库？和1）一致的问题，是否有使用nosql做存储的情况；

5）有哪些数据同步任务？不仅本系统的主库从库同步和延迟，还有业务系统和大数据的同步和延迟情况，

和大数据同步后对方提供的接口是否有其特殊逻辑处理？

5、系统运维
1）什么时间容易出问题？对关键功能是否有监控？需要看系统有配置了哪些报警项，监控了哪些方面；

出了问题怎么解决？日志在哪？是否有全链路跟踪？是否有一些紧急操作，比如开关配置、降级、限流配置；

解决后怎样保障如何不出同样或者类似的问题，类似保障手册、应急预案、资损盘点之类的内容

2）研发同事总结的历史问题case；

3）运营、客服、技术支持、政府事务组、公关、财务、其他上下线游反馈的常见问题有哪些？

4）遗留线上 Bug 清单和 Owner 分配

有参考：如何熟悉一个系统？（内含知识大图） - 掘金

https://juejin.cn/post/6844904051872628750

前言

开发人员经常会面临下面一些场景：

新人入职，需要学习已有系统，作为 landing 的一部分，如何学习？
被拉过去参与一个陌生系统的迭代开发或者系统维护（bugfix），如何快速上手？
同事离职或转岗，需要把系统交接给你，怎么去接？内心 os：这是一口锅吗？

这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。本文总结熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。

业务学习

业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。

常见问题：

系统所在行业的情况是怎样？
系统的目标用户是谁？比如是给公司高层做决策用？给运营或客服用？还是互联网用户用？
平均有多少人在使用？高峰期有多少人在用？
系统有什么业务价值？有哪些指标可以衡量系统业务价值？
系统有哪些功能模块？
系统有哪些领域概念？梳理下系统的领域模型；
系统的关键业务流程有哪些？关键业务流程是怎样？
系统的非功能性需求有哪些？如性能、质量、扩展性、安全性等；
系统未来的发展规划是怎样？

技术学习

技术学习主要学习系统的架构、如何实现、系统的运维等。描述一个系统的架构有五视图方法论。

五视图分别是：

逻辑架构
开发架构
运行架构
物理架构
数据架构

逻辑架构

逻辑架构着重考虑功能需求，系统应当向用户提供什么样的服务，关注点主要是行为或职责的划分。常用表达图形，静态图有包图、类图、对象图；动态图有序列图、协作图、状态图、活动图。逻辑架构的核心设计任务是模块划分、接口定义、领域模型细化。

常见问题：

有哪些子系统或模块？系统之间是什么样的关系？
对外上下游接口有哪些？对接人是谁？
关键业务流程怎么实现的？用类图、序列图等方式表达出来。

开发架构

开发架构关主要关注系统源代码、第三方 SDK、使用的框架、中间件、工具包。

常见问题：

代码在哪？
包怎么划分的？怎么分层？如 mvc、controller-service-dao；
用了什么框架，如 ssh、dubbo；
用了哪些工具包？如 apache commons、guava；
用了哪些中间件？如 metaq、tair、schedulerX、Diamond；
依赖哪些平台？如权限平台、流程引擎等。

运行架构

运行架构的着重考虑运行期质量属性，关注点是系统的并发、同步、通信等问题，这势必涉及到进程、线程、对象等运行时概念，以及相关的并发、同步、通信等。

常见问题：

系统能支撑多少 qps？峰值 qps 多少？
与上下游系统怎么交互的？rpc？http？同步还是异步？

物理架构

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

常见问题：

系统如何发布部署？有哪些部署环境？
系统有多少台机器？
系统部署怎么部署的？关注接入层，部署方式，如集群部署、分布式部署等
有没有容器化？
有没有多机房部署？

数据架构

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

常见问题：

数据存储在哪？用了什么数据库，如 oracle、mysql；
梳理 E-R 图；
数据量有多少？是否有分库分表？
用了哪些 nosql 库？
有哪些数据同步任务？
大数据框架的使用情况如何？

系统运维

系统运维重点关注什么时候会出问题，出了问题怎么解决。

常见问题：

什么时间容易出问题？比如电商双11，对系统的压力很大，这时候很容易出问题；
对关键功能是否有监控？需要看系统有配置了哪些报警项，监控了哪些方面；
出了问题怎么解决？日志在哪？是否有全链路跟踪？是否有一些紧急操作，比如开关配置、降级、限流配置；
系统有哪些坑？找开发同学回顾历史问题，以免踩坑。通过同事总结的 case，或者与负责的产品、运营、技术与了解。系统总会有一些坑，需要把这些坑填上。历史代码经过多次迭代总会导致复杂度高（分支、嵌套、循环很多），存在设计漏洞，性能隐患等，很难维护，这些就需要我们去重构了。记住有一句话：填的坑越大，能力越大；
运营、客服反馈的常见问题有哪些？