一、問題背景：
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一次重啟，數次大範圍的影響流程流轉。自己以往做系統操作之後，也有過未做驗證就進行操作的動作。以後在做相關系統操作的時候，一定要充分驗證之後再做處理。
針對雲主機卡死問題的定位分析方法
此文已由作者楊延亮授權網易雲社群發布。雲主機在執行或者啟動的過程中，可能會存在卡死的情況。往往在雲主機重啟之後又恢復正常，但是問題現場得不到保留，不利於問題的分析定位。本文提供了一種方法，可以通過在雲主機所在的物理節點 宿主機 上執行相關命令，來獲取雲主機卡死時的記憶體棧資訊，以便分析定位 本文只針...
大資料分析的處理流程
大資料的處理流程可以定義為 利用適當的工具，提取和整合不同結構的資料來源，並按照一定的標準進行儲存，然後採用適當的資料分析技術進行分析，最後提取有用的知識，並將結果顯示給使用者以適當的方式在終端的前面。1.資料汲取與整合 由於大資料處理的資料 型別廣泛，而其第 一步是對資料進行抽取和整合，從中找出關...
Spring MVC 處理乙個請求的流程分析
spring mvc是spring系列框架中使用頻率最高的部分。不管是spring boot還是傳統的spring專案，只要是web專案都會使用到spring mvc部分。因此程式設計師一定要熟練掌握mvc部分。本篇部落格簡要分析spring mvc處理乙個請求的流程。乙個請求從客戶端發出到達伺服器...