RPA自动化软件如何运营维护

大家都说上车容易下车难，今天给大家已经上车RPA的朋友聊聊如何长期开车，更重要的是如何保持“低油耗”。

首先抛出观点，RPA运维是RPA自动化工具长期服役的至关重要的一环，但是同样也可以做到低成本。

作为RPA早起的从业人员，同时也是企业的负责人之一，我考虑问题从来都不会只看技术，我会同时考虑ROI，是否值得投入。

现在大家都在讨论上不上RPA、选什么RPA工具为主，今天我这里和已经上车RPA的朋友首次谈一谈RPA流程的运维。如何做RPA运维呢？我们首先需要看RPA的特点：

1）流程逻辑基本一目了然，不存在大量代码，不存在各种常见code中的回调函数导致时序复杂化的问题；

2）程序运行基本可视化，见即所得，即使不需要分析日志也知道问题大概所在。并且异常栈各个RPA工具都会打印出来，很容易定位；

3）无侵入式的UI操作，无法预测大量第三方目标业务系统UI层面的迭代修改，可能一个很小的元素变化会导致整个流程中断；

4）运行环境抗莽撞性差，可能一个莫名其妙的软件弹窗或者是网络稍有不稳定会导致流程中断；

在RPA流程的运维实践中，1）和2）非常重要，这个是和传统的软件运维完全不同。传统的软件code当代码量达到一定的复杂程度之后，逻辑复杂、并且单独通过日志无法了解程序全貌，运维是非常难的；往往不得不由当初的软件开发团队的帮助下才能完成运维，并且常常需要搭配专业测试人员做全面的测试用例，才能在各个角度完成程序的质保。--然而RPA流程的运维不需要借助开发人员的帮助，再复杂的流程都逻辑清晰，新的运维工程师仅仅通过阅读流程文件本身就可以大体知道业务逻辑，再跑通一遍程序，辅以开发流程工程师的思路文档，即可对流程有个八九不理十的把握。就运维成本角度来考虑的话，完全可以用成本更低的专业运维服务商来取代高额成本的流程开发服务商，同时不影响服务质量SLA。

那么剩下的特点3）和4）会导致一个常见的现象，就是往往一个RPA流程每过一段时间，就会出现小问题，不是这出问题，就是那出问题；但是问题又不是很大，调一下就好，但是你无法预测到底什么时候会有问题，也往往做不到100%的容错。这使得运维人员很痛苦，然后流程的使用部门又经常会发现问题，不断挑战运维人员的负责度和专业度。这个就是上线RPA流程的最大挑战。

对于这个问题，我们在实践的过程中可以采用一下机制：

1）标准化桌面。我们将所有部署RPA的PC完全虚拟化，制作完全干净和标准化的桌面环境和网络环境，即“云桌面“。这样使得各种参数一次配置即可全公司使用；避免环境个体差异。杜绝机器个体差异导致的程序异常。

2）模块化设计。和传统的MVC架构的程序一样，一个流程可以分解为流程模型和流程数据；一个大流程可以分解为多个小流程，并且流程直接是可以实现跨文件调用的。所以，我们最好把数据分解开来、子模块也分解开来，既可以实现改一处而修复所有的最佳实践。比如，有N个流程都是查询A网址，然后基于A网址的内容做各种不同的事情；我们不需要在每个流程中都包含查询A的流程，而是把它单独出来做一个模块，供给其他流程调用即可。在我们的服务实践中，很少有企业在流程开发中考虑到了这一点，使得后续运维人员很苦恼。

3）异常报警机制。这个是我们的运维人员最后的关口。我们的目的是使业务人员发现业务中断之前完成流程的修复工作。具体实现可以私信探讨。

通过以上运维机制，我们发现，企业RPA流程在高可用的同时，可以节约大量的预算：

通过标准化、模块化设计降低运维复杂度，降低总体工作量

通过异常报价机制，降低对全职运维工程师的工作量，往往一人可以完成数十个流程的日常运维；低于数十个流程的公司甚至可以不需要雇佣全职的运维工程师

本文由RPA自动化提供，https://www.ai-indeed.com