多方系统集成的启示

集成血泪故事 × 3

唯一不变的是持续变化

辰星系统在与集成方 M 系统进行同步开发，负责开发和联调的程序员老张正盯着屏幕发呆。短短一周，这已经是集成方第三次提出变更了，先是业务流程变更，再是接口变更，现在是调用方式变更，老张心里有句话想送给对方。好在还没提测，紧锣密鼓改起来，键盘敲得啪啪作响。

提测次日，对方语音弹出：“张哥，有个字段还得改一下。业务是这样……所以我们得那样……” 放下电话，老张找到 QA 王同学暂停测试。

“我都测完一半了又要改，有没有谱啊！”

“这集成方就是这样两天三改的。”

“这可不行，返工浪费这么多时间，约等于图财害命啊，得想辙。”

“上次跟赵经理聊过，暂时没什么好办法，唉。”

参与集成的老张和王同学都痛苦着。

功能突然挂了，惊喜不惊喜？

辰星新一轮的上线忙碌过后，研发负责人赵经理刚坐下喘口气喝个咖啡，接到业务客户夺命连环 call：“X 功能挂了，用户投诉爆单，快找人看一下！！！” 隔着语音都能感受到急切情绪。可这个功能这次没动啊，难道有人重构了？赶紧排查一下问题，顺便问问谁动了代码。

排查发现我们确实没动代码，功能确实也没问题，但集成返回却异常了。赵经理跟客户交代完，十分钟后集成 M 系统研发负责人语音过来：“哎赵哥，这不赶上排期么，我们改了返回逻辑，麻烦你们也相应修改一下吧。对对对改动不大，你们很快就能处理好。那什么我马上让我们开发联系张哥！”

放下电话，赵经理揉了揉太阳穴，刚上完线又得热更了，这不是人在家中坐，锅从天上落么。赵经理不知怎的想起那个“儿子，我们搬家了，你猜在哪儿？”的段子，无奈苦笑着。

对不起，我们真的上不了

鉴于辰星与集成 M 系统的对接经验，对于这次的大规模集成业务更新，大家都很紧张。赵经理、老张在聊进度安排时格外注意，非常明确的与 M 系统沟通了各环节时间点，及准入要求（这点 QA 王同学情绪很不好的多次强调了）。

前期还好，虽然时间紧了一些，好在对方没出什么幺蛾子。业务改动较大，但逻辑清晰，我们也加了不少测试，这次上线应该没啥大问题。赵经理舒缓了紧张情绪。

上线当日，辰星系统部署过半，大家都在紧张待命，空气中弥漫着一股“山雨欲来风满楼”的气息。刺耳的铃声响起，赵经理看着手机上的名字愣了两秒，按了接通，对面的声音像是电影里的画外音：“赵哥，我们没测完，今天先不上了。实在对不起啊，我们真的上不了。” 赵经理望向老张，宿命般的对视。

“对方不上了，咱们怎么处理？”

“什么？这个时候说不上就不上啊，早干嘛去了。”

“我跟业务方沟通过了，实在上不了也没办法，现在多说无益，赶紧想想怎么办吧。”

“由于前期已经约定好了时间线，上线是板上钉钉的事儿，我们没有设计功能开关。”

“部署能回滚吗？”

“有些数据结构已经变了，回滚不合适。要不...咱一点一点 revert 代码吧！”

“不是个事，我再沟通一番，看看对方最早什么时候能上。”

十分钟后，“revert 代码吧，我真是……”

“啥也别说了，我喊兄弟们加班。”

多年后赵经理和老张在另外的场合相遇，回忆起那次上线惊魂夜，看似波澜不惊的笑谈着当时焦灼紧张的场域、多方多番的谈判、结没结下的梁子、彻夜不眠的团队……二人仍是心有余悸。若是有机会再来，其实可以预先做些什么，让团队更轻松从容的应对。

大规模集成面临的挑战

集成中不受约束的无节制变更

由于集成涉及业务、干系人、研发进度等多方面的复杂因素，确实存在需要变更的情况，适量变更也是被允许的。但是，无节制的随意变更理应受到约束，毕竟集成需要多方的协作，由于一方的变更造成的返工成本是多倍的，因此当讨论到集成变更时，允许变更的业务范围、在多大程度上可变、允许变更的时间线、变更带来的额外成本等都需要认真讨论并达成共识。

上线后的变更缺乏同步机制

由于在集成研发过程中需要多方联调测试，因此研发过程中的变更会及时同步给干系方。但在上线过后的运维阶段，某一方涉及到集成相关的业务变更或代码重构时，往往就会忘记同步干系方。当功能被悄悄上线后，干系方就会发现原本好端端的功能突然就不能用了，紧急排查后发现是集成方变更，那心情也是相当的复杂。这种情况在集成量大的偏前端业务系统尤甚，不管业务链路中的哪个环节出了问题，最先暴露出来的问题一定是来自用户，前端业务系统苦不堪言。

集成风险认知不足

抽象一下所谓集成过程，就是多方建立并各自履行契约的过程。涉及到履约，就可能存在主动毁约的情况，或由于不可抗力导致被动毁约的发生。当缺乏此类风险的干预措施时，哪怕不是己方的过失，团队也会面临相对被动的窘境。因此进行多方集成时，一定要充分认知集成风险，针对可能发生的风险提前设计响应机制，哪怕这种风险发生的概率偏低，也需要预先考虑和设计风险干预方式。可针对集成的不同风险，设计分级分类的响应机制，确保团队始终保有主动性。

启示及应对思路

明确并共识的集成协作流程

需要清晰明确的集成协作流程，与集成多方达成一致共识，并在整个协作过程中严格遵循。协作流程应包括但不限于以下内容：

• 集成关键环节和各环节关键活动、负责人

• 集成时间线：需求确定、接口定版、研发联调、集成测试、代码封包、上线

• 需求评审和变革评审过程

• 各集成方对接负责人

• 集成问题沟通协作机制

• 集成准入与准出条件

• 线上监控机制

• 线上问题跟踪及响应机制

• ……

示例：集成协作流程

集成需求评审与变更评审

高质量的需求是多方集成过程中必不可少的输入，需要确定需要的范围、内容、变更规则和评审流程。

示例：集成需求评审与变更评审规则

非常重要的提示（宁愿你永远不懂系列）：所有确定的需求内容，包括但不限于业务流程、接口协议、非功能需求描述、异常响应描述等内容，需通过邮件同步给集成方 PO、TL、QA 等相关人员。所有会议均需记录，并发送会议纪要至所有参会者，如有异议需在当天回复邮件并解决。

清晰的准入准出条件

需清晰定义集成相关的准入准出条件，并与多方达成共识，严格遵守门禁标准。预先清晰定义，远好于事后问责。不同上下文内，准入准出标准可能不一致，这是允许的，只需要多方达成共识即可。如下图的示例，里面的一些条件是适合大部分上下文的，此外还有针对特定上下文的验收条件，大家可以按需酌情约定。

示例：集成准入准出条件

集成风险分析

可能影响或引发集成风险的因素有很多，可组织集成相关成员进行充分的风险研讨和分析，制定合理的应对方案：

1. 集成点的数量：试图一次集成所有系统、所有业务的项目，由于极端复杂性和大量相互依赖性，容易产生不利结果。少量、轻量的集成，更有利于降低复杂度和问题排查。

2. 不断变化的需求：当用户场景考虑不全时，需求可能会频繁变化，给集成过程造成混乱。在集成开始前应有时间保证收集到相对完备的需求集。

3. 集成基础设施不足：使用错误的基础架构来支持集成项目可能会导致严重的问题和过高的成本。避免依赖手动编程或过于复杂、繁重的中间件软件集的解决方案。

4. 过于仓促的时间安排：集成要趁早，问题赶前不赶后，集成时间线确实可以相对激进，但应避免过于仓促。可针对集成进行相对准确并留有余地的估算方案。

5. 人员流动：项目管理、业务分析师、开发人员和利益相关者的变化可能会使项目的完成变得复杂。尤其在集成时间线较长时，核心角色的变更会造成关键上下文的损失，需确保人员稳定性，或做好充足的知识管理工作，以减少单点依赖。

6. 变更管理程序：一些组织缺乏处理变更需求的流程和方法。从需求、实施和测试的角度来看，不加约束的变更过程会引发混乱的结果。

7. 新的业务流程：新业务集成时往往面临更大的风险，应确保新业务经过相关干系人、业务方、各集成方的评估和充分讨论。

8. 新的集成基础设施：新的或未经证实的集成基础设施是一个风险因素。

9. 测试计划不足：测试计划应尽早并经常引入测试。测试脚本和自动化测试可能有助于在集成早期更快地发现和定位问题。

10. 针对集成失败的预案：我们对于集成的结果往往过于乐观，有可能的话应给合适体量的集成功能都加上开关，以便于集成失败时快速切换业务功能版本。

我们把这些风险按照影响范围和可能性，放到风险状态矩阵中，可针对不同等级的风险制定不同程度的干预或响应机制。

风险状态矩阵：尽早分析 Over 走一步看一步

写在最后

大规模集成面临的挑战都是复杂问题，解决这类复杂问题，应结合如业务诉求、技术方案、研发流程、管理流程等多方面因素综合考量，从而提出相对理想的方案，确保集成业务价值的最终实现。