金融机构换 IM 的连续性测试表：6 类场景与标准

金融机构换 IM，常见的错是把验收做成功能演示：单聊能发、群聊能建、文件能传，就认为可以上线。真正会出问题的地方，往往在切换当天才暴露：组织架构同步慢半拍，离职账号还在线，关键告警没有送到值班群，历史文件打不开，旧系统已经停了，新系统又回不去。

这张 IM 连续性测试表把切换前要验证的内容分成 6 类：身份与组织、消息与会话、文件与知识资产、业务集成与通知、安全与权限、故障与回退。每一类都给出最低通过标准、证据要求和一票否决项。它不是功能清单，而是上线决策表。对金融即时通讯来说，连续性不是功能齐全，而是关键沟通不断、关键数据可查、关键故障可回退。这里以商业银行为主要参照，证券、保险、基金等机构可以按自身监管要求调整条款。

一、先定基线，测试表才不会变成功能清单

连续性测试的第一步不是打开新 IM 的功能菜单，而是把“什么不能断”写清楚。没有基线，测试结果只能停留在“感觉能用”。

建议先定五件事。

基线项	要写清楚的内容	不写会怎样
关键业务与关键用户	哪些部门、岗位、值班链路依赖 IM；哪些消息和通知属于 P0	测试样本选偏，关键场景漏测
恢复目标	IM 承载的是日常沟通、重要业务通知还是应急指挥；对应的 RTO、RPO 是多少	出故障时不知道该多快恢复，也无法判断是否达标
切换窗口与并行期	避开月末、季末、结息、报表、发薪和重大活动；旧系统保留多久只读	在业务高峰切换，问题被放大
测试样本	2 至 3 个部门、1 个分支机构、1 个外部协作群、20 个关键群、5 个 P0 集成、1 个高峰时段	用演示账号测试，真实环境一上线就出问题
证据与签字	日志、截图、配置、实测时间、问题清单；业务、IT、安全、合规各自确认	出问题后无法复盘，也无法界定责任

《商业银行业务连续性监管指引》（银监发〔2011〕104号）第二十五条提出，重要业务恢复时间目标原则上不得大于 4 小时，恢复点目标不得大于半小时；第四十九条要求至少每三年对全部重要业务开展一次业务连续性计划演练；第五十七条要求业务功能或关键资源发生重大变更时，及时修订业务连续性计划。IM 替换往往同时触及关键资源、组织账号和业务通知链路，按这套思路做专项验证，比只做功能演示更接近真实风险。

如果 IM 承载的是重要业务通知或应急指挥，建议把恢复目标写进测试表，而不是等到出事后再讨论。第五十一条还提到，外部供应商也应纳入演练范围，这意味着新 IM 的厂商不能只交账号和文档，还要参与故障切换和回退演练。

二、6 类场景总表

先把总表放在前面，方便项目组在启动会上对齐范围。每一项的“最低通过标准”不是建议值，而是进入下一轮测试的门槛。

场景	最低通过标准	一票否决	证据
身份与组织	账号、部门、岗位、权限与权威源一致；入离职和调岗在约定时限生效；跨组织可见范围正确；无孤儿账号	离职或停用账号仍可登录；跨组织看到不该看的人；管理员权限失控	账号映射表、同步日志、权限矩阵、抽样记录
消息与会话	单聊、群聊、离线、多端、弱网和高峰收发正常；没有未声明的丢消息、重复或乱序；历史消息按约定可检索	P0 会话丢消息；离线消息不送达；切换前后记录断裂且未披露	消息 ID 与时间戳、收发日志、弱网和高峰记录
文件与知识资产	关键文件可打开、内容一致；权限继承正确；消息里的文件引用可追溯；备份可恢复	关键文件打不开；权限过宽；没有可用备份	文件清单、校验记录、权限测试、恢复记录
业务集成与通知	P0 集成端到端通过；通知送到正确的人或群；失败可见、可重试；没有重复风暴	告警静默失败；通知发错对象；没有重试和告警	集成清单、测试事件 ID、投递日志、告警记录
安全与权限	未授权访问被阻断；加密分层与合同一致；管理员操作可追溯；数据留存和删除符合制度	明文传输；权限越界；关键操作没有记录；数据可以绕过管控流出	配置截图、测试账号、日志、安全签字
故障与回退	故障可发现；P0 沟通有降级通道；RTO、RPO 实测达标；回退演练通过；旧系统只读期可用	没有回退路径；旧系统已关停；RTO、RPO 未测；数据无法核对	演练记录、时间戳、实测 RTO 与 RPO、回退日志

这张表有一个使用前提：所有测试都要在机构自己的网络、身份源、终端和集成环境里做。厂商演示环境跑得通，不代表生产环境跑得通。

三、逐类怎么测

1. 身份与组织连续性

组织架构是账号、群组和权限的底座。组织没并清楚，账号就只能靠姓名和部门猜，后面容易出现重名、错配和权限残留。

测试时至少覆盖这些动作：

• 以 HR、AD 或 LDAP 为权威源，抽取 50 至 100 个真实账号，核对部门、岗位、上级和账号状态。
• 分别测试入职、转岗、离职、返聘、兼职、外包和服务账号，确认权限在约定时限内开通或回收。
• 测试多法人、多分支和跨组织可见范围，确认总部、分支和子公司管理员各自能管什么。
• 测试同步失败场景：身份源不可用时，已有账号能否登录，是否有应急账号和恢复步骤。
• 抽查群主、管理员和文件权限，确认没有把旧系统的高权限原样带过来。

判定可以浓缩成三句话： 账号对得上，权限收得回，组织看得清。 如果离职账号还能登录，或者跨组织能看到不该看的人，这一项直接不通过。

如果机构同时涉及两套 IM 合并，组织、账号和资料的处理顺序可以参考 两套 IM 合并时组织、账号与资料的处理顺序。

2. 消息与会话连续性

消息测试不能只测“在线发一条，对方收到”。金融场景里，离线、弱网、多端和高峰才是更容易出问题的地方。

建议按下面几组场景测试：

• 单聊、群聊、@、回复、转发和文件消息，分别用真实账号跑一遍。
• 接收方离线 30 分钟后重新上线，检查离线消息是否送达、顺序是否正确、有没有重复。
• 同一账号在 PC、手机和 Web 端同时登录，检查消息同步、已读状态和历史记录是否一致。
• 在 Wi-Fi、移动网络和网络切换之间切换，检查断线重连和消息补发。
• 在早高峰或会议开始前模拟并发，记录发送成功率、延迟和资源占用。
• 按切换时间点检查历史消息：关键词、发送人、日期能不能检索，附件能不能打开。

判定用四个短语： 不丢、不重、不乱、可查。 测试中出现的丢消息、重复消息和顺序错乱，要能定位到具体账号、会话和时间点；如果只能回答“偶尔有”，就不能算通过。

历史消息和文件的迁移范围，可参考 从 SaaS 迁移到私有化 IM 的完整指南。

3. 文件与知识资产连续性

文件测试的重点不是上传速度，而是切换后还能不能找到、打开和授权。

测试时选一批真实文件：合同、审批单、报表、告警记录、项目文档。逐项检查：

• 上传、下载、预览和另存为是否正常，中文文件名和特殊字符是否受影响。
• 大文件、批量文件和移动端下载是否可用，失败时有没有明确提示。
• 文件权限是否跟随群组和角色，离职人员、外部成员和跨组织成员是否越权。
• 消息里的文件引用是否还能定位到原文件，历史版本和现行版本是否分得清。
• 备份恢复后，文件能不能打开，内容和校验记录是否一致。

判定是四件事： 找得到、打得开、权限对、能恢复。 只测新文件、不测历史文件，只测上传、不测下载和预览，是常见的漏测。

群和文件的盘点方法，可参考 切换前先盘点群和文件。

4. 业务集成与通知连续性

IM 不只是聊天窗口，它还接着单点登录、审批通知、工单、监控告警、报表提醒和机器人。这些集成往往不在群成员列表里，却直接影响业务是否断链。

先拉一张集成清单，逐项记录用途、调用方、接收方、触发条件、负责人和失败处理。然后做端到端测试：

• 用真实业务事件触发通知，确认消息送到正确的人、正确的群，内容完整。
• 检查失败重试和幂等，确认同一事件不会重复轰炸，也不会静默丢失。
• 断开一个集成或填错凭证，确认监控能发现，值班人员能收到告警。
• 测试单点登录、组织同步和接口鉴权，确认账号停用后接口权限同步失效。
• 给每个 P0 集成指定备份负责人和降级通道，避免只依赖一个机器人或一个接口。

判定是三句话： 发得对，到得快，失败看得见。 只看到接口返回成功，不等于消息真的到了人；这是集成测试里常见的误判。

5. 安全、权限与合规边界连续性

安全测试不要只看登录页。把加密拆成三层问：传输层怎么加密，服务端文件怎么加密，数据库里的消息怎么存储。三层实现方式可能不同，验收要拿到配置和验证方法，而不是只看一句笼统的加密承诺。

测试至少覆盖：

• 非白名单 IP、停用账号、离职账号和外部设备登录，确认该拦的能拦住。
• 管理员、部门管理员和普通用户的权限边界，确认改角色、调部门、离职后权限及时变化。
• 组织隔离、界面水印、文件访问和外部共享，确认敏感内容不会流向不该看的组织。
• 管理员操作记录、登录记录、消息留存和删除策略，确认出现问题时能追溯。
• 加密配置与合同、部署文档一致，确认没有把测试环境的配置当成生产配置。

判定是四句话： 进不来，看不该看，带不走，查得到。 任何一条出现缺口，都不应该用“后面再优化”带过。

以喧喧IM为例，传输与服务端文件采用 AES 256 位加密，消息在数据库中加密存储；IP 登录限制、组织隔离、界面水印、LDAP/AD 等能力要结合专业版和实际部署核验。安全能力的边界要在测试前写清楚，不能把宣传页上的功能当成已经配置好的能力。更多能力边界可参考 通讯安全页面。

6. 故障、降级与回退连续性

前五类测的是“正常时能不能用”，这一类测的是“不正常时能不能活下来”。

至少设计这些故障场景：

• 服务进程退出、数据库或存储异常、网络中断，观察发现时间和影响范围。
• LDAP、OA、监控平台等外部依赖不可用，确认 IM 是否能继续提供基础沟通。
• 客户端升级失败、旧版本不兼容，确认是否有回退安装包和操作步骤。
• 高峰过载，确认限流、排队和降级策略是否生效。
• 从新系统回退到旧系统，确认旧系统只读期、历史消息、文件和权限仍然可用。

每次演练都要记录五个时间点：故障发生、发现、决策、恢复、业务确认。RTO 和 RPO 不是写在方案里的数字，而是这五个时间点算出来的实测结果。

判定是四句话： 发现得了，降得下，回得去，对得平。 只做桌面推演、不做实际回退，或者旧系统已经关停才想起来回退，都是不合格的。

四、从测试结果到上线判定

测试做完，难点在于一张“问题很多，但不知道能不能上线”的清单。建议在测试前就定好三级分类：

• P0：不能上线。包括丢消息、越权访问、P0 通知静默失败、没有回退路径、RTO 或 RPO 未达标、关键历史数据断裂且未披露。
• P1：可有条件上线。影响范围可控，有补偿措施、责任人和复测日期，但不能全面放量。
• P2：上线后优化。不影响核心连续性，可以进入迭代清单。

对应的判定可以写成一张表。

判定	条件	允许的动作
通过	P0 全部通过；P1 有明确整改计划和补偿措施；回退演练通过；业务、IT、安全、合规完成签字	全面上线
有条件通过	没有 P0；P1 未清零，但影响范围可控，有补偿措施和复测日期	限定范围试点，不全面放量
不通过	任一 P0；或 P1 涉及关键业务、数据、权限且没有补偿措施；或回退不可用	暂停上线，整改后重测

回退触发条件也要提前写死，不能等出事再讨论。常见的触发项包括：P0 会话持续丢消息或重复；出现未授权访问；P0 告警没有送达；实测 RTO 或 RPO 超出基线；关键集成失败且无法在窗口内恢复；影响范围超过预定阈值；发生安全事件。

上线节奏建议先试点、再放量。选 1 至 2 个代表性部门，用真实业务跑 2 至 4 周，每天复盘问题，达到退出条件后再扩大范围。不要用全员硬切来验证，问题会在最忙的时候集中出现。

五、把这张表放进 POC 和合同

POC 阶段常见的情况，是厂商在演示环境里把功能跑得很顺，机构回到自己的网络却发现身份源、终端和集成都对不上。测试表要放进机构自己的环境，用真实账号、真实终端、真实文件和真实业务事件跑。

选型时，至少核对下面几项：

核对项	要问清楚的问题	需要拿到的证据
部署与数据归属	能否部署在自有服务器或内网；消息、文件和组织数据存在哪里；备份怎么做	部署架构、数据流向、备份与恢复记录
身份与组织	能否对接 LDAP/AD 或 HR 系统；多法人、多分支怎么管；离职如何回收权限	同步日志、权限矩阵、入离职测试记录
客户端与终端	覆盖哪些操作系统和终端；国产系统和国产 CPU 怎么适配；旧版本怎么升级和回退	兼容性清单、安装包、升级与回退步骤
集成与扩展	是否提供 API、Webhook 或 SDK；单点登录、告警和审批怎么接；失败怎么重试	接口文档、联调记录、失败告警记录
迁移与退出	历史消息和文件怎么处理；旧系统保留多久；合同到期或更换供应商时怎么退出	迁移方案、导出格式、退出演练记录
版本与服务	开源版和专业版差什么；高级安全能力在哪个版本；升级和技术支持怎么安排	版本说明、服务条款、升级记录

以喧喧IM为例， 私有化部署把消息、文件和组织数据放在企业自有服务器；支持通过 LDAP/AD 承接账号体系，提供开放 API 与 Webhook，客户端覆盖 Windows、macOS、Linux 和移动端，并适配麒麟、统信 UOS 等国产系统与鲲鹏、申威、飞腾等国产 CPU。涉及组织隔离、界面水印、IP 登录限制等高级安全能力时，要按专业版和实际部署核验，不能默认所有版本都一样。

即时通讯迁移不是把账号导过去就结束了，历史聊天记录的迁移要单独设计。导出成功不等于新系统能还原成可检索的会话，附件、引用关系和权限也可能在迁移中丢失。比较稳妥的做法是先定保留义务，再按关键群、关键时间段做抽样迁移，旧系统保留一段只读期。不要把“一键导出”当成默认能力，也不要在合同里接受模糊的迁移责任。

六、常见问题

历史消息一定要全部迁移吗？

通常不需要。先看业务是否还需要回溯、是否有合同或审计留存义务、新系统能不能承接原格式。多数机构只保留关键群和关键时间段的记录，其余在旧系统保留只读期后归档。把全部历史消息搬过去，成本高，价值未必大。

切换期要不要新旧系统并行？

连续性要求高的机构，建议并行或分阶段切换。并行期要明确哪套是主系统、哪些群在新系统、哪些群暂时留在旧系统，以及并行的退出条件。长期双系统会带来信息不同步、权限重复和运维成本，不能把并行当成长期方案。

没有专职测试团队，怎么把 6 类场景跑完？

先保 P0。身份、消息、关键文件、P0 集成、安全边界和回退这六项不能省，其余可以按风险抽样。选 1 至 2 个代表性部门，用真实业务跑 2 至 4 周，每项测试指定负责人和证据留存人。测试表的作用是防止漏项，不是要求每个功能都做一遍。

RTO 和 RPO 怎么定？

先做业务影响分析，确认 IM 承载的是日常沟通、重要业务通知还是应急指挥，再定恢复目标和恢复优先级。《商业银行业务连续性监管指引》对重要业务提出 RTO 不大于 4 小时、RPO 不大于半小时的要求，可以作为参照；IM 是否属于重要业务、目标是否更严，要由机构自己的业务影响分析决定。定完之后，用演练实测，不要只写在方案里。

开源版能不能用于金融机构？

要看具体需求和版本边界。开源版核心功能开放，可用于验证核心沟通和私有化部署，但高级安全、组织隔离、界面水印、IP 登录限制、LDAP/AD 等能力可能涉及专业版或特定部署配置。金融机构在选型时要把版本差异、技术支持、升级路径和退出方案一起核对，不能只看“开源免费”四个字。

参考资料

• 中国银行业监督管理委员会《商业银行业务连续性监管指引》（银监发〔2011〕104号），上海发展和改革委员会网站转载，查阅于 2026 年 11 月 6 日：http://fgw.sh.gov.cn/ys-hqjrfw-1.3.1.2-h5/20240820/c1cca14a63624bb99c82608ea32ccc46.html