来阿里学到的第一件事竟然是

上一篇offer 总结文之后有很多玩家后台给我留言在阿里怎么样？996吗？这篇文章主要讲来阿里做的很重要的一件事，主要还是围绕技术侧给大家做一些输出。

开场

晚上和供应商沟通完商业合同的细节(先卖个关子)，已经12点了，然后开始刷公众号，刷了一会饿了，床头放了一罐老婆刚买的牛肉干，纠结挣扎了3秒，妥协了（主要是懒得再刷牙），开吃，边吃边刷搞笑段子，一不小心没收住，半罐子没了。这牛肉干后劲太大，直接辣到肚子疼，肚子疼怎么办？觉是没法睡了，那就写篇文章吧！

给你们看一眼我的牛肉干，可能厨师家辣椒籽不要钱，随便撒。

腊牛肉

节奏

交代这个写作背景，是为了让你们不要对这篇文章的质量有要求或者期待，安琪拉是顶着疼痛的肚子在做输出，身残志坚，不来个三连(转发评论在看)良心不会痛吗。好了，不卖惨了，下面开始说正事。

1.学到的第一件事

不卖关子，在阿里学到的第一件事就是”写文档“。

你可能会问，在之前难道不写文档吗？写，但是阿里写的更细致、更具体，文档是工程非常核心的一部分，写文档时间甚至多余写代码时间，因为其中涉及很多思考沉淀，画流程图、交互图，还有修改完善。文档是整个研发流程中非常关键的一个步骤，蚂蚁大体的研发流程是：

提需求 -> 需求评审 -> 研发做系分 -> 系分评审 -> 编码 ->  MR -> 代码效能检测 -> CR -> ….

安琪拉今天主要说的文档是蚂蚁非常重视的系分文档，系分是“系统分析与设计” 的简称。在蚂蚁的研发体系培训中专门有一门“系分”课程，是鲁肃来教的，可见蚂蚁对系分的重视。这么说吧，做的好的系分的标准就是让另一个开发拿到你的系分文档，可以直接依据系分文档完成编码。

系分评审会议上大家会直接抛出很多问题，你需要对系分设计的每一个细节考虑清楚，比如交互逻辑、技术风险等，安琪拉的系分在评审会议上第一次没有通过，后面好几晚都弄到凌晨2点，二个周末在高铁上、餐桌上都在做系分。第二次评审非常顺利，还得到了Leader 的赞扬。另外为什么强调是技改，因为技改和新需求不太一样，新需求的系分主要为了满足业务新需求，技改系分设计主要对现有实现做方案调整优化。

你们可能会怀疑，不就是一个文档嘛，至于又是熬夜、又是牺牲周末时间来弄嘛。我就仔细说说技改的系分文档都包含哪些内容，个人觉得对开发想要往架构师方向发展是有借鉴意义的，即使不往架构走，把自己业务和技术细节梳理清楚也大有裨益。

做系分文档有什么好处呢？安琪拉认为最大的好处是：通过系统分析设计文档可以降低编码的不确定性，系分做的越详细，编码时不确定性就越小，因为所有问题、边界、流程、数据处理你都提前想清楚了，文档就是一种把脑海中的设计思路具体化的方式，另外一方面就是通过系分评审，让小组内成员帮你把关，可能你考虑有遗漏的地方，大家一起评审就容易发现问题，最后一个好处就是可维护性，不管是新人还是后续接手项目的人，不用你一点一点口口相传教他，看你的文档一目了然，另外是人就会遗忘，战胜遗忘最好的方式就是记录。

下面以安琪拉在国服群里讨论的黑名单需求说明系分设计是怎么做的，不会太细，但是整体框架思路相信基本可以借鉴。大家甚至可以依此作为技改需求开发规范的模板。

需求背景

举一个案例，是关于黑名单治理的，商家发布的商品信息可能需要放置到黑名单池子中，主要就是防止一些黑灰产、敏感词、恶意导流等，还有一些场景，相信做技术的同学应用里面多多少少都有这种类型的黑、白名单的功能。

系分内容

大纲

0. 修订历史

1. 概述

2. 业务流程

3. 现有系统设计与问题

4. 技改方案

5. 非功能性需求

6. 保障性方案

7. 工作量评估与排期

8. 关键节点与问题跟进

9. 附录

10. 参考文档

看大纲觉得是没什么，鉴于信息保密的原因，不能把完整的目录细节截图放出来，大家做过毕业答辩的系统设计文档应该知道有多详细，这份技改的系分文档差不多就是这个程度。看大纲没觉得东西多，遇到影响面大的技改，第3点的内容就够喝一壶的。

下面具体介绍每一部分：

• 0.修订历史

  把每一版本的文档修改点和时间列出来，好追溯，目前这份需求已经到第四个版本

• 1.概述

  这部分主要是交代需求背景，为什么要做这件事，要达到什么业务目标和技术目标？目标要清晰、可量化，不能模棱二可。

• 2.业务流程

  这部分会画一些用例图，业务场景描述，核心业务流程等。

• 3.现有系统设计与问题

  上一部分描述完业务的场景和流程，这一趴就讲现在系统是如何满足和实现这些业务需求的，实现的有什么问题。这部分需要描述：

  3.1 现在用的技术方案，例如：使用的领域模型、关键技术栈(用到的中间件、缓存等)、数据流、模块的交互逻辑等。

  3.2 现在技术方案的问题，例如：数据一致性问题、模块实现的时间复杂度高、有异常、不满足业务扩展性等等问题。

  3.3 问题的影响范围和引用点，例如：有业务交互的外部系统、内部模块，引用点的调用量，区分影响点哪些是关键业务。这一块在安琪拉这次技改中花了最多时间，因为黑名单几乎所有关键业务链路都用到了，需要梳理清楚影响的范围和实现的逻辑，我是按照TPS 从高到低排列这些引用点(为了切新流程的时候优先切流量低的引用点验证新技术实现的正确性)，把实现的逻辑归类，交互时序图画出来。下面截了一张系分的问题汇总的图：

  
  

  外部系统影响范围花了个示例图：

  
  

  可以列出关键链路。

• 4.技改方案

  上一部分提到的问题，在这一趴需要有对应的方案解决。包括：新的领域模型设计、扩展性更好的接口设计、新方案的技术分层，如下给了一张示意图，隐去了部分敏感信息，这个是我找的一个老版本的，新版本core-service模块再扩展出来一层。

  
  

  对于关键业务链路的交互实现，也需要把技改方案和历史方案作对比，尤其是新方案的风险，这个是很重要的，一般在稳定性方面都要求做开关配置，在新方案试运行期间，可以通过开关切到旧方案中。

  关键链路需要把方案的数据流程也表达出来，如果有资金方面的交互也要表达出来。下图是一个关键链路的交互图：

  
  

• 5.非功能性需求

  就是非功能方面的需求，字面意思

• 6.保障性方案

  新功能上线，蚂蚁是强制要求做到三点：可灰度、可监控、可回滚，灰度是用少部分流量验证功能正确性，监控是随时随地明确知道系统运行监控状况，可回滚不用说，有问题时不能回不去。

• 7.工作量评估与排期

  这个需要定开发、提测、代码review、走读和评审、测试、联调、上线的时间

• 8.关键节点与问题跟进

  关键节点记录，遗留问题记录和跟进，相当于备忘录

• 9.附录

  不适合在主要系分设计中列出的附加说明

• 10.参考文档

  文章依赖的一些例如中间件、技术栈出处，让系分文档评审的人，以及后面接手维护的人知道技术方案的来源。

2. 首尾呼应

文章开头那个商务合同是昨晚在和旅行社定团队outing 合同的细节，马上要去和小伙伴们一起去爬山了，有一起的吗？你们说安琪拉要不要把老板拉到一边，问他：”今年的晋升，你看我还有机会吗？“

觉得时间真的太少，要弄得东西太多了，本来昨天晚上就想把这篇文章写好，实在太困，今天还在机场候车厅码字，下面放了机场码字图，渣技术，马上要去西安了，大家有什么推荐的吃的吗，虽然就半天时间，还是想尽快多吃点西安美食。

— 【 THE END 】—
本公众号全部博文已整理成一个目录，请在公众号里回复「m」获取！
3T技术资源大放送！包括但不限于：Java、C/C++，Linux，Python，大数据，人工智能等等。在公众号内回复「1024」，即可免费获取！！