1. 为什么系统越多数据越乱数据孤岛的三个隐形推手我做了十来年企业信息化见过太多这样的场景公司从创业期的三五套系统成长到集团规模后账面上一口气躺着ERP、CRM、MES、OA、HR、财务共享中心看着“数字化建设成果丰硕”可真要把某个订单的全链路数据串起来IT部门的同事得在六个系统之间来回导Excel折腾大半天。这不是个别企业的窘境而是整个行业在数智化转型过程中几乎必经的一道坎。坦白说数据孤岛从来不是“没有系统”造成的恰恰相反是系统上得太快、太散、太重所致。而iPaaSIntegration Platform as a Service集成平台即服务之所以能在近几年成为企业数智化转型的关键词本质上是它恰好踩中了这组矛盾的命门——用一套相对轻量、可视化、可治理的方式把那些互相不说话的系统和数据重新“缝”在一起。先说清楚数据孤岛到底怎么来的。我把它拆成三个隐形的推手每个都藏在日常运维的细节里。第一个推手是业务系统的演进速度永远跑在IT治理前面。业务部门今天说要上CRM下个月又因为销售线索漏跟要加一套营销自动化工具再过半年工厂那边为了排产又搞了一套MES。每一套系统的选型通常都以“解决当下痛点”为唯一导向没人系统性地思考过这套系统产生的数据哪些要流出给下游哪些要从上游接进来于是每一套系统都成为一条独立的数据管道各跑各的谁也不挨着谁。这种“积木式”上系统的模式短期看是响应业务需求长期看就是在给企业埋数据地雷。第二个推手是部门之间的数据主权意识。销售部门认为客户数据是我的核心资产不能随便给财务生产部门觉得工单数据涉及成本秘密不宜对采购开放连HR系统的组织架构数据都因为薪酬模块的敏感性连IT运维都拿不到全量权限。这种部门墙看上去是管理问题落到技术上就成了数据契约的缺失——两边连“哪些字段可以共享、以什么格式共享、多久同步一次”这种最基本的约定都很难达成更谈不上实时打通。数据孤岛表面上看是技术架构的问题骨子里是数据责任机制的问题。第三个推手也是最容易被低估的是“点对点接口”的不可持续。我刚入行那几年系统集成的主流做法就是点对点开发两套系统之间写一堆自定义脚本、定时任务、API调用代码。两个系统只需要一个接口三个系统就要三个五个系统就到了十个N个系统熬成N乘以N减1再除以2的接口数量双向调用的话还要翻倍。我在一家制造企业审计集成现状时发现他们的CRM、ERP、MES、WMS、TMS之间盘出了47个接口其中有13个是已经没人维护的僵尸接口剩下的半数以上靠一个已经离职两年的工程师留下的定时脚本在跑。这种蜘蛛网式的集成架构才是数据孤岛的最顽固形态——它不是没有通路而是通路太多太乱根本没人说得清哪条路是通的、哪条路已经断了大半年。这三个推手叠加在一起就形成了一个很讽刺的局面企业的“数字化系统”越多数据的割裂程度反而越严重。各个系统的数据在本地都治理得清清楚楚漂亮得像孤岛上的花园但岛与岛之间没有桥连摆渡船都是临时租的。到这一步所谓的低效协同就不是某个部门的问题而是整个组织的系统性损耗了。如果此刻贵司的IT团队也正陷在“导数、对账、救火”的循环里那你大概率需要了解一下iPaaS到底能在哪个环节上真正发力。2. iPaaS到底做什么不做什么先划清能力边界我接触过的企业里有不少人对iPaaS的预期是失真的。有人把它当万能胶觉得任何两个系统之间只要接上iPaaS数据就自动打通了也有人把它当成又一套“中台”指望它顺手把数据治理、BI报表、主数据管理的活儿全包了。这两个预期都会在项目启动后迅速碰壁。所以聊iPaaS怎么解决问题之前我觉得有必要先花点篇幅把它真正的能力边界划清楚。2.1 从ESB到iPaaS集成中间件的前世今生要理解iPaaS最好带着集成中间件演进史的视角。早些年企业做系统集成主流方案是ESB企业服务总线。ESB的理念很“重”——它试图在业务系统之外构建一个中心化的消息路由中枢所有系统间的通信都经由总线转发还需要专门的团队维护那套总线基础设施。它在那个年代确实解决了不少问题但代价也相当沉重部署重、开发重、运维重。一套ESB上线的周期往往以年为单位定制开发的工作量甚至比业务系统本身还大这导致它只能在大型集团或银行、电信这类预算充裕的行业里生根发芽。iPaaS走的是另外一条路。它在“平台”这件事上继承了ESB的治理思想但在交付方式上普遍采用了云原生架构把集成开发从“写代码、跑服务”变成“可视化编排、托管运行”。原来的ESB更像你要自己买一台中央交换机再请专人维护线路iPaaS则更像是运营商直接给你一条按需开通的专线线路质量、故障切换、容量扩缩都在平台侧兜底你只需要关心两端怎么接。这个转变对绝大多数中小企业来说意义重大——它头一次让“系统集成”这件事从“重资产项目”变成了“可订阅的服务”。2.2 iPaaS的核心能力块具体拆开看一个合格的iPaaS平台至少包含四大能力块这也是你评估任何一款iPaaS产品时的基础框架连接器管理预置主流SaaS、本地系统、数据库、消息中间件的连接器云端应用走API本地系统走Agent或反向连接至少覆盖CRM、ERP、IM、数据库、文件存储这些常见对象。集成流编排用可视化的方式定义“触发-处理-输出”的链路支持分支、聚合、循环、并行等流程逻辑让非深度开发人员也能读懂甚至参与搭建集成逻辑。数据映射与转换解决源系统字段到目标系统字段的对应问题包括格式转换、枚举映射、数据清洗以及复杂情况下的脚本扩展。运行监控与治理对每个集成任务做执行日志、失败告警、重试策略、链路追踪这是集成平台区别于“一堆脚本”的根本标志。但请注意我这里说的是“至少”因为不同厂商的iPaaS产品还会在API全生命周期管理、事件驱动架构、低代码应用搭建等方向上延伸能力选购时需要结合自身需求判断哪些是必要的。2.3 常见误解iPaaS不是数据中台也不是低代码平台这两年“中台”概念降温之后很多人试图用iPaaS来接棒数据中台的位置我认为这是一个需要澄清的误解。数据中台的核心价值在于对多源数据进行采集、清洗、建模和分析它的产出物是“数据资产”和“数据服务”主要服务于分析决策类场景。而iPaaS的核心价值在于“连接”和“流转”它保证的是订单数据在CRM到ERP之间准确、及时、可追溯地流动而不是这份订单数据在未来三个月里能跑出什么销售趋势。打个比方数据中台是炼油厂负责把原油炼成汽油iPaaS是输油管道负责让汽油从A油库安全顺畅地流到B加油站。你不能要求一根管道去承担炼油的任务。同理iPaaS也不是低代码应用开发平台。低代码平台的定位是“帮你快速搭出一个业务应用的表单、页面和逻辑”而iPaaS的定位是“帮你把已有的应用和数据连起来”。两者虽然都强调可视化但服务的对象截然不同。也有厂商把低代码和iPaaS揉在一个产品里那是产品策略但你自己心里要有一杆秤我在买的是“造应用的工厂”还是“通数据的管道”对绝大多数团队来说先解决管道问题往往比再造一个新应用更紧迫。只有把iPaaS的能力边界想清楚了后续的架构选型、范围规划才不会跑偏。3. 破解数据孤岛的核心机制连接器、集成流与数据映射的三板斧划清了边界接下来聊聊iPaaS具体靠什么机制拆掉数据孤岛。这一节我尽量讲得“可触摸”一些因为只有理解了底层机制你在配置集成任务时才不会被厂商的Demo演示牵着鼻子走。3.1 预置连接器数量是表象深度才是关键几乎所有iPaaS厂商在对外宣传时都会强调“预置了XXX个连接器”这个数字看起来很有冲击力但我在实际选型中会更关注连接器的“深度”。所谓深度是指某个具体产品的连接器到底覆盖了它的API的多少比例。以CRM系统为例有的连接器只能读写“客户”和“联系人”这两个对象而你的业务恰恰需要同步“报价单”“订单”“产品价格表”那么这个连接器的可用性就要大打折扣。判断深度最直接的办法是让厂商给出一份连接器所支持的完整对象清单也就是元数据然后拿你业务里最冷门的三五个对象去核验凡是清单里找不到的基本就意味着该连接器对你的核心场景帮不上忙。连接器的认证方式也需要提前关注。现代的SaaS应用普遍采用OAuth 2.0但在配置时往往会遇到Token过期、刷新失败的问题尤其当你的集成任务跑在夜深人静的批量作业时段Token静默失效会让整个同步任务静默失败。成熟的iPaaS平台都会在连接器层自动处理Token刷新和重连但具体实现是否稳定一定要通过长周期压测来验证不能只看POC概念验证时那一次连接成功。3.2 集成流编排从“点对点”到“可视化流水线”iPaaS在“连接”这件事上的核心抽象是集成流。你可以把它理解成一条处理数据的流水线最上游是一个触发器它决定这条流水线什么时候启动中间是一个个处理节点负责数据的变换、校验、分支判断最下游是一个或几个目标动作把处理好的数据写进目标系统。这种抽象相比点对点脚本的巨大进步在于整条数据路径是可见的、可改的、可版本化的不再散落在一堆看不见的crontab和.py文件里。我举一个真实的配置场景。某零售企业需要把电商平台每天产生的订单同步到ERP同时根据订单金额判断是否触发财务审核流程。在iPaaS里这个需求可以拆成一个判断分支触发器用定时轮询或Webhook接收新订单数据节点把订单金额从分转成元、把平台特有的“待发货”状态映射成ERP的“O20”状态然后走一个条件分支——金额小于一千的订单直接写入ERP并回传成功标志金额大于一千的订单则先推送一个待审核事件给OA系统等审批通过后再继续写入ERP。整个过程可以在可视化画布上拖拽完成运行后的每一步都有日志可查这就是集成流相对于脚本集成最直观的优势。3.3 数据映射与转换格式统一只是第一步语义对齐才见功力很多初学者认为数据映射就是“把A字段的值填到B字段”其实真正困难的是语义对齐。举个常见例子CRM里的客户名称叫“深圳市恒达电子科技有限公司”到了ERP里可能被录成“恒达电子深圳有限公司”这两个字段如果只是机械复制下游系统在做客户合并时会直接创造出一条重复客户数据。更复杂的还有日期格式、时区转换、货币精度、计量单位——这些看似细节的问题在企业数据量大了以后每一个都会演变成数据质量的硬伤。iPaaS平台一般都会提供可视化的字段映射界面支持源和目标字段的一一对应以及常量填充、表达式计算、字典翻译比如把“M/F”翻译成“男/女”、条件映射等能力。这项工作是集成建设项目里最耗时但也最能体现业务理解深度的环节。我在评估一个iPaaS项目的工作量时通常会给“字段映射”预留30%以上的交付时间。很多集成项目延期不是平台不行而是业务方始终没想清楚“两个系统之间同一份数据到底以谁的为准、冲突时谁覆盖谁”。3.4 实时性设计同步调用、异步队列与事件驱动怎么选数据孤岛的“拆除”不只是打通还要考虑以什么节奏打通。iPaaS在实时性上通常提供三种模式你在设计集成方案时一定要提前想清楚每一条链路的诉求。第一种是同步请求/响应适合需要立即拿到结果的强一致场景比如用户在前端页面查询库存可用量这个查库动作必须实时穿过iPaaS去ERP里取数基本延时控制在几百毫秒级别。第二种是异步消息/批处理适合对实时性要求不高的场景比如T1的销售日报汇总、夜间成本核算这类任务用定时触发的批处理就够了既能减轻源系统压力也方便集中维护。第三种是事件驱动架构当源系统发生特定事件比如订单创建、库存变更时通过Webhook或消息队列主动推送iPaaS收到事件后立刻触发下游动作。事件驱动的实时性最好但对源系统的开放性要求也最高很多传统本地系统根本不具备事件推送能力这时就需要在数据库层面做日志抓取或者轮询补偿。这三种模式没有绝对优劣成熟的方案往往是混合使用。便宜和贵的差别往往就体现在设计者有没有在架构阶段就想清楚哪些链路必须同步、哪些可以异步、哪些能靠事件驱动而不是统一用最简单的定时同步把一切都拉平。如果所有集成都走定时批处理数据孤岛暂时是打穿了但业务部门很快会抱怨“系统的数据怎么总是慢半拍”如果所有链路都追求实时同步又会把源系统和中间平台的压力拉到透支。这个度需要在架构评审时一项一项过。4. 解开低效协同的死结从接口调用到流程协同数据孤岛打通之后紧接着要面对的就是标题里另一个关键词低效协同。很多企业把协同问题简单归因于“数据没通”但真等数据通了才发现协同低效的另一半原因藏在流程设计里——系统间的数据能传了可是业务上谁该干什么、下一步该推到哪、卡住了怎么处理这些流程逻辑并没有跟着数据一起流转起来。4.1 一个订单流程的协同效率剖析我习惯用一个订单履约流程来说明这个问题。一家年营收数亿元的制造企业客户通过CRM下单订单要传递到ERP生成正式销售订单再传到MES进入生产排程最后通过WMS发货、TMS配送。理论上这就是一条标准的集成链路可实际上过去的流程是这样的销售助理每天定时从CRM导出订单Excel手动整理后邮件发给PMC生产与物料控制专员PMC专员把订单录入ERP核对库存排好生产计划之后再在MES系统里手工建工单仓库发货之后物流单号还要人工回填到ERP和CRM。整个过程涉及三个部门、四套系统、两个人工搬运节点。光是订单信息在多个系统间的不一致对账每个月就能耗掉一个全职员工一半的工作时间。这种协同模式的问题不是简单的“系统没打通”而是流程被人工节点割裂成了碎片每个部门都只看到自己那一小段数据整个订单的状态就成了一个说不清的黑洞。4.2 状态机与流程编排让跨系统流程看得见iPaaS解决这类协同问题的方式是引入“流程协同”的视角把原本松散的系统调用组织成一个有状态、有分支、有异常出口的流程。在具体实现上关键是对核心业务对象做状态机设计。还是拿订单来说iPaaS里的订单状态机可以定义成待审核→已审核写入ERP→生产排程中写入MES→已发货写入WMS→已完成回写CRM的订单状态再加上几个异常状态审核驳回、库存不足、物流异常。每一条状态迁移都由iPaaS触发对应系统的数据动作每完成一步下游系统的状态字段都会实时刷新。业务部门不再需要靠打电话或者查Excel来确认“订单到哪一步了”打开任何一个系统看到的都是同一条订单的最新状态。流程编排的价值还体现在跨系统的“断点续跑”能力上。过去人工搬运数据时如果录入到一半发现ERP报错往往整张订单要退回重来。在iPaaS的流程编排中每一步的中间结果可以被持久化保存哪一步失败了就从哪一步重试不用回到流程起点重新跑一遍。这种健壮性对于动辄上千笔日订单量的制造或零售企业来说节省的时间和人力成本是相当可观的。4.3 异常处理与补偿机制协同链路的兜底逻辑做集成协同一定要直面一个问题链路越复杂出错的环节就越多。一个订单从CRM到ERP再到MES中间任何一个系统升级、字段调整、网络抖动都可能导致流程中断。过去人工操作时出错了还有个人在那儿顶着现在自动集成了如果异常处理做不好错误会在几秒钟内沿着链路扩散到所有下游系统那场面比过去还惨。所以我在设计集成流时有一条铁律每条自动化的链路必须同步设计它的失败出口。具体来说iPaaS的异常处理至少要考虑三层第一层是重试针对网络超时、目标系统临时不可用这类瞬时故障设置合理的重试次数和退避策略避免一失败就立刻告警轰炸第二层是降级设置主备双通道比如主通道走API故障时自动切换走消息队列保证业务链路不被单点拖垮第三层是人工兜底当重试和降级都失效时把失败任务推入人工处理队列由业务人员在iPaaS的运维界面里查看失败原因、修改数据后手动触发重跑。很多平台会把这套能力叫“补偿机制”本质上就是给自动化链路系上安全带。没有这套安全带iPaaS不仅解决不了低效协同反而会变成新的效率杀手。4.4 审批与数据回写人机协同的边界协同并不等于全自动化很多业务节点天然需要人来拍板。我曾经陪一家企业做采购协同流程最初的诉求是“采购订单全程自动化”可在实际梳理时发现超过五十万的采购单必须经过财务总监审批这是内控红线不可能被绕过。此时iPaaS的合理做法是把“是否触发审批”这个判断交给规则引擎让流程自动走到审批节点后挂起推送待办到OA系统等审批事件返回再继续流转。这个过程的本质是把人的判断嵌入机器执行的流程里而不是简单地把人从流程中抹掉。顺带提一个容易被忽略的技术细节当审批动作完成后审批结果和审批意见要能从OA系统回写到源系统比如CRM或ERP的审批备注字段。这种“数据回写”看起来只是多一次接口调用但在实际项目里回写字段的权限控制、审计日志、内容格式经常被做砸。数据回写如果不设计好就会出现“流程走了记录没留下”这种情况到年底财务审计时又是一地鸡毛。综上iPaaS破解低效协同的要义并不是把所有的协同都一刀切成“无人值守”而是把确定性的、规则清晰的环节交给自动化把需要判断的、需要授权的环节通过流程编排留给人工再用完善的状态机、异常补偿和数据回写机制把自动化和人工节点无缝地串成一个整体。能达到这个状态协同效率的改善是能直接体现在订单交付周期、对账时耗这些经营指标上的。5. 选型与落地iPaaS上线前必须想清楚的五件事聊完了机制和价值我相信不少读者已经动了“我们也上iPaaS”的心思。作为一个旁观过不少失败项目的从业者我建议你在立项之前先冷静把下面五件事想清楚。每一件都直接关系到项目最终是成为标杆还是烂尾。5.1 连接器生态深度的评估方法前面说过连接器的“深度”比“数量”更关键。在选型阶段建议让厂商的售前工程师提供连接器对象清单然后把你业务中涉及的Top 10高频对象挨个检核。不要只看“有没有”还要看“读写的字段覆盖了多少”。如果一款iPaaS连接器对某个关键对象只支持读不支持写那很可能意味着你的核心双向同步场景根本跑不通。另外一定要考察连接器面对上游系统版本升级时的应对策略——SaaS应用通常每季度都会发布新版本字段和接口发生变更很常见连接器的维护节奏是否跟得上决定了你的集成流会不会在下个季度集体“罢工”。5.2 部署模式公有云、私有化还是混合iPaaS的部署模式是我在选型中被问得最多的问题。对于业务系统以SaaS为主的企业直接用厂商的公有云服务是最省力的选择平台侧的扩容、升级、运维都由厂商负责你的团队只需要专注配置集成流。但对于核心业务系统还在本地机房的传统企业数据出域这件事会卡在信息安全部门的审批上此时通常需要评估私有化部署版本的可行性。私有化部署的好处是数据不出内网但代价是你要自行承担平台的运维工作包括版本升级、高可用、存储扩缩容——这些工作过去是厂商帮你扛的私有化之后都回到了你的团队身上。我见过的折中方案是采用混合模式跨SaaS应用的集成走公有云涉及本地核心系统的集成走私有化Agent或边缘网关两边由同一套控制台统一纳管。这种模式兼顾了安全和效率但对iPaaS厂商的产品能力要求更高评估时需要确认清楚。5.3 失败处理与可观测性出问题第一眼看到哪里集成项目的上线只是开始真正考验平台功力的是运行期的可观测性。我在评审iPaaS平台时会重点关注三件事第一每条集成流的执行日志是否完整记录了入参、出参、耗时和报错详情避免出问题时还要去翻源系统和目标系统的日志做交叉比对第二是否有链路追踪能力一个订单从CRM到ERP再到MES每一步的状态是否能在一个界面里拉通查看而不需要逐个系统去查第三告警策略是否灵活能否按集成流、按失败率、按延迟分级别设置告警而不是要么不报、要么在凌晨三点把运维群轰炸到全员静音。这三个能力直接决定了当某天凌晨数据同步出问题时你的团队是五分钟定位问题还是折腾到天亮。5.4 组织配套集成治理不能只靠工具这一点可能是最容易被忽视的。很多企业以为买了iPaaS就等于建好了集成能力结果半年后发现没人愿意维护平台变成了新的僵尸系统。集成的长期运行本质上是一项需要有人负责的“平台运营”工作。我建议在启动iPaaS项目时就同步组建一个跨部门的集成治理小组至少包含业务侧的接口代表、IT侧的集成架构师和运维工程师。业务侧负责需求梳理和数据规范IT侧负责平台架构和运行保障。这个小组每个月至少要开一次例会审视集成流的数量变化、失败率趋势、新增需求排期。没有这个组织配套iPaaS项目的长期健康度是无法保证的。5.5 成本模型与ROI测算最后是预算问题。iPaaS的采购成本通常包括订阅费用按连接器数量、API调用量、或集成流数量计费和实施服务费。在立项时我建议做一份显性的ROI测算把“不建iPaaS的成本”摆到桌面上包括现有点对点接口的维护人天、人工导数的工时损耗、因数据不一致导致的对账差错和业务决策延误。下表是一个简化版的测算模板大家可以按自己企业的数据往里填成本项现状未上iPaaS预期上iPaaS后点对点接口维护人天/年约240人天约30人天平台内置连接器可视化配置人工导数与对账工时/年约120人天约10人天因数据延迟导致的订单交付出错损失/年约数十万元降低60%-80%集成需求交付周期平均2-4周/个平均2-3天/个我见过不少企业算完这笔账后项目优先级直接被拉高了一档。ROI测算不是走流程而是给决策层一个真实的参照系。6. 上线之后的长期治理避开集成项目烂尾的三个坑很多iPaaS项目死于上线之后。前三个月新鲜感还在大家积极配流、看监控、提优化半年之后集成工作开始变得琐碎乏味人员一流动平台就逐渐沦为没人管的“老系统”。我在这一节专门聊聊如何避开集成项目烂尾的坑。第一个坑接口资产化意识缺失。iPaaS上线时你可能只配置了十几个集成流但这十几个流会像雪球一样越滚越多。如果最初的接口命名、归属部门、业务含义没有按资产标准来管理半年后你会看到一套充满“test_20250218”“临时同步_3”“最终版_v2”这种名字的集成流没人说得清哪个在生产环境跑着、哪个已经废弃。我的习惯是在iPaaS平台里建立一套命名规范和资产目录每条集成流必须有明确的业务名称、归属部门、负责人、上下游系统清单和SLA承诺。这套规范要和代码仓库的分支规范同等对待资产化管理是长期运维的基石。第二个坑版本治理与变更流程形同虚设。集成流的本质是代码但它又和业务数据强相关所以变更风险比普通代码更高。上游系统一个字段类型从字符串改成枚举就可能导致下游系统写入失败。因此在iPaaS的治理机制里必须建立“变更评审”环节任何集成流的修改都要有变更说明、影响范围评估、回归测试记录再走发布审批。发布后的变更要能回滚到上一个稳定版本。这些能力大部分iPaaS平台都具备但能不能真正用起来取决于你的团队有没有把它当成生产系统的发布纪律来执行。第三个坑监控告警与SLA管理流于形式。我在前面提过可观测性那是平台层面的能力在运营层面还要有人真正去看告警、盯SLA。建议为每条核心集成流设定明确的SLA指标比如“订单同步链路可用性不低于99.5%端到端延迟不超过5分钟”然后按月对SLA达成情况进行复盘。凡是连续两个月未达标的链路要专门立项做根因分析和优化。这个动作听起来很重但对那些承载核心业务的集成链路来说它是避免平台在无声中腐化的唯一手段。我见过不少企业iPaaS控制台里的失败任务红点挂了几个月都没人点开看那就不是平台的问题而是运营机制的失守了。从“项目制”到“平台运营制”的转型是我认为iPaaS治理的最终形态。项目制的心态是“上线即结束”平台运营制的心态是“上线即开始”。我会建议在项目立项阶段就规划一个持续运营的预算盘子哪怕是每季度一次的平台健康巡检也能让集成资产的生命力比“上线后不管”强得多。回到开头说的那句话企业数智化转型这条路上iPaaS不是银弹但它确实是我见过的最能直接回应“数据孤岛”和“低效协同”这两个顽疾的工程化手段。它把集成从“工程师手里的一堆脚本”变成“平台上可编排、可治理、可迭代的数字管道”让数据像水一样在系统之间流动让业务协同像流水线一样有序衔接。如果你们团队正准备启动类似的项目我的建议是不要急着上来就买最贵的平台先拿一条最痛的跨系统链路做POC把连接器深度、异常处理机制、组织配套这三件事验证透了再考虑规模化推广。这条路走扎实了数据孤岛和低效协同这两个老问题是可以用一套平台、一套规范、一支小团队实实在在打掉的。