EAS流程卡死问题的分析处理报告

一、问题背景：

11月4日，EAS发生第一次流程大面积卡死，部分流程卡死无法进行。11月5日重启服务后相关流程正常运转。之后又发生了数次流程大面积卡死现象。

二、分析处理过程：

第一次未引起重视，认为是个案，所以未进行仔细的研究。发生第二次后，发现后台数据库有锁，但锁的语句为传递的参数，未能定位到确定的单据。考虑11月份发生了两个业务，第一个是启用差旅费用报销单，一个是修改了自助餐的汇报关系。开始怀疑为汇报关系导致的。分析由于后台数据库锁为费用报销单，但是汇报关系不仅仅是费用报销单使用，排除。之后分析差旅费用报销单，发现设计的时候使用的是费用报销单的审核功能，首先定位的是这个，但是测试系统未能重现问题，修改后，相关问题未解决。

将问题提交给金蝶后，金蝶分析了相关日志和流程。给出的问题为平台问题，需要打流程补丁。由于这个问题不是一开始就有的，确定金蝶给的方案不是这个问题的针对性方案。所以继续分析该问题。

12月中旬，物业保障中心反馈说每次流程卡死，他们的流程的单据状态都修改不过来。1月8日，物业保障的一个费用报销单卡死。后台产生锁，结束锁后，改流程重新卡死，重新启用该流程，后台重新产生锁。反复多次后，确定后台锁由该流程引起。

分析物业保障中心报销流程，发现11月3日做了更改。分析更改前后的变化，为在部门经理后加入了自动变更单据状态为审批中的环节。咨询FI模块系统管理员，是为了解决单据经过部门经理审批后提单人依然可以修改单据的问题。分析流程发现，流程有一个分支符合条件后会出现更新单据状态为“审批中”紧接着更新状态为“审批通过”。理论上解释了数据库死锁的产生。

针对这个理论分析，在测试系统中进行试验，成功重现出问题。确定问题的根本原因为对物业保障中心流程对一个单据同时提交了两条更新状态的语句互相占用导致数据库锁。流程引擎等待确认消息而导致的流程全面卡死。

三、改进措施：

1、查询在走的可能引起的流程卡死的流程实例，沟通业务终止流程，重新打出相关单据；

2、修订物业保障中心报销工作流、中央厨房报销工作流；

3、针对单据经过部门经理审批后提单人依然可以修改单据的问题，改进正餐报销，门店发展中心报销，物流中心报销三个流程；

4、EAS流程的变更纳入变更管理的范围。

四、总结经验教训：

Ø  经验：

1、对于不熟悉的领域，要不断的从细节中去比对差异，缩小问题的范围，使自己接近问题的本质；

2、要耐心，看是毫无头绪的问题，每天拿出15-20分钟的时间思考一下这个问题，那天也许就顿悟了。但是如果没有这个过程，问题永远不会得到解决；

3、尊重但不迷信权威。供应商、专家提供的建议，要成为自己思考问题的扩展，让自己能从更宽、更深的思考问题，而不是成为自己思考问题的拘束。

Ø  教训：

1、问题的重视程度。如果第一次发生这个问题自己引起足够的重视，及时沟通相关业务的变化点，可能就没有后面那么复杂的分析过程了；

2、EAS变更管理的漏洞。EAS目前对流程没有做变更管理。导致整个流程修改后未在测试系统中做充分测试，直接打到正式系统。导致问题的产生。

3、严谨的态度。一个小的逻辑漏洞，导致了EAS一次重启，数次大范围的影响流程流转。自己以往做系统操作之后，也有过未做验证就进行操作的动作。以后在做相关系统操作的时候，一定要充分验证之后再做处理。