标题：干货！构建稳定性高、弹性强的 RPA 机器人看这（上）

目前，各大金融财会领域的企业或行业部门都纷纷上线 RPA 机器人，以达到降本增效的成果。RPA 作为数字化的智能抓手，其最大的优势在于 7×24 无间断工作，代替人工完成重复、枯燥、标准化的工作。而充分发挥 RPA 的优势，从 RPA 部署到 RPA 运行各环节的稳定性以及应对突发事件的抗风险能力则成为关键。

如何增强 RPA 的稳定性，在出现异常的状况之下仍可继续运行，不出现崩溃和退出等现象，且不影响后续项目的执行便显得尤为重要。

我们将从RPA 异常的三大场景以及如何从 RPA 的设计方法、管理手段、变更维护三个方面来谈谈如何构建稳定性高、弹性强的 RPA 机器人。

RPA 脆弱性来源的三大异常：

01

环境异常

在 RPA 开发工程中，程序开发、单元测试与系统集成测试通常是在测试环境进行，但在进行用户验收测试或 RPA 投产上线后可能会遇到非应用或业务异常的情况。这是由于生产环境和开发测试环境之间可能存在差异性所导致的，而这些差异又非常细小，比如操作系统或浏览器的版本不同、系统的某些相关设置不一致、某时段补丁插件自动推送安装导致的弹窗等，这些差异极易被忽略，但又对 RPA 的正常运行起到决定性作用。

02

应用异常

RPA 在上线投产前已经过多次测试，包括单元测试、系统集成测试与用户验收测试等多项测试。但RPA 在日常运行中可能会出现某应用程序中断或因网络等原因卡顿、网站的某个页面打不开或应用出现异常报错等特殊情况，若设计 RPA 时未考虑此类情况的发生，此时 RPA 要么报错，无法继续执行或者重复错误的运行，导致后续任务执行失败。在开发 RPA 之初，开发人员很难预测此类异常情况。

此外，上线投产的 RPA 流程也可能会因为操作系统、浏览器、应用的自动升级，界面模块升级前后不一致而出现运行异常的情况。

03

业务异常

RPA 在执行过程中可能会存在一些数据异常或超出业务规则的情况。尽管测试阶段测试人员已经尽可能模拟了各种业务情况，但测试样本数据和真实业务数据之间的差异性仍旧是不能避免的。在未引入 RPA 之前，此类异常情况的解决通常需要业务人员采用特别的手段进行处理。因此，RPA 在执行过程中遇到此类问题时采用人机交互 (将错误的数据交给员工处理，机器人只处理正常的数据) 的方式来解决。

最后，三类异常如果在 RPA 投产上线后很长时间才爆发，还可能会引发业务运行黑盒化的问题。即 RPA 导入应用以后，某些业务的流程就被封装到了 RPA 里。企业为了解决上述问题，却发现很多原始细节上的处理方法除了最初部署的业务人员，就只有 RPA 机器人知道，当前业务人员无法处理，而原本业务人员可能会因生疏而无法确知细节，或工作调度早已不在岗，以及交接说明不够细致等，难以解决黑盒化问题，严重影响着后续进程。

可见，设计完整能够常久稳定运行的 RPA 流程不仅仅对软件产品本身有着极高的技术性要求，对于部署经验、预案能力、风险防控意识一样有着更高的标准，牵涉到诸多的变量。任何一环出现问题，作为执行标准流程作业的 RPA 都可能出现罢工。针对上述状况该如何做到从源头上规避呢？

我们给出从设计方法、管理手段、变更维护三方面的建议，关于三方面详细的内容我们将在下篇中介绍，请密切关注艺赛旗。