大家都说上车比下车容易。今天就和已经上车电液推杆的朋友聊聊如何长时间开车，更重要的是如何保持“低油耗”。

首先，电液推杆运维是电液推杆自动化工具长期服务中至关重要的一环，但也可以实现低成本。

作为一名电液推杆的早起员工，我也是企业的lingdaozhe之一。当我考虑问题时，我juebu会只看技术。我也会考虑touzihuibao率，是否值得投资。

现在大家都在讨论电液推杆和选择什么电液推杆工具。今天在这里和已经上车电液推杆的朋友们diyi次聊聊电液推杆流程的运维。如何做电液推杆运维？首先，我们需要看看电液推杆的特点:

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

2)程序运行的基本可视化，所见即所得，即使不需要分析日志，也能了解问题。并且异常栈中的每一个电液推杆工具都会打印出来，便于定位；

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

4)运行环境对鲁莽不稳健，莫名其妙的软件弹出窗口或网络的轻微不稳定都可能导致进程中断；

在电液推杆流程的运维实践中，1)和2)非常重要，这与传统的软件运维完全不同。当传统软件代码量达到一定复杂程度时，逻辑复杂，单靠日志很难理解整个程序，因此运维难度很大。往往需要在原软件开发团队的帮助下完成运维，为了从各个角度完成程序质量保证，往往需要和专业测试人员一起做综合测试用例。-但是，电液推杆流程的运维并不需要kaifazhe的帮助。不管过程有多复杂，逻辑都很清楚。新的运维工程师一般只需要读取流程文件本身就可以知道业务逻辑，然后再把程序运行一遍。借助开发过程工程师的思维文件，他可以很好地掌握过程。从运维成本来看，成本较低的专业运维服务商完全可以替代高成本的流程开发服务商，而不影响服务质量SLA。

那么剩下的特征3)和4)就会导致一个共同的现象，那就是每经过一个电液推杆的过程，就会出现小问题，不是这个问题就是那个问题；但是问题不是很大，只要调整一下就可以了，但是你无法预测什么时候会出现问题，而且你往往无法做到100个点的容错。这让运维人员非常痛苦，然后流程的用户部门经常发现问题，不断挑战运维人员的责任心和敬业精神。这是线上电液推杆流程zui大的挑战。

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

1)标准化桌面。我们将所有部署了电液推杆的PC完全虚拟化，打造一个完全干净、标准化的桌面环境和网络环境，即“云桌面”。使得各种参数一经配置就可以供全公司使用；避免环境个体差异。杜绝个别机器差异导致的程序异常。

2)模块化设计。与传统的MVC架构程序一样，一个流程可以分解为流程模型和流程数据。一个大进程可以分解成几个小进程，这些进程可以跨文件直接调用。因此，我们zui好分解数据和子模块，这样我们就可以进行更改并修复所有zui佳实践。比如有n个进程都是查询A网站，然后根据A网站的内容做不同的事情；我们不需要在每一个流程中都包含查询A的流程，而是将它单独做成一个模块，供其他流程调用。在我们的服务实践中，很少有企业在流程开发中考虑过这一点，这让后续运维人员非常苦恼。

3)异常报警机制。这是我们运维人员的zui后一道关口。我们的目标是让业务人员在发现业务中断之前完成流程修复工作。实现可以私下讨论。

通过以上运维机制，我们发现企业电液推杆流程在高可用的同时，可以节省大量预算:

通过标准化和模块化设计，降低操作和维护的复杂性以及总体工作量。

通过异常报价机制，可以减少专职运维工程师的工作量，往往一个人就可以完成几十个流程的日常运维；流程少于几十个的公司甚至可能不需要雇佣全职的运营和维护工程师。