工作隨筆小記 — 任務分派自動化

本文最初發表於 Medium,已搬運至個人 blog。

最近上班完成一項專案,故且讓我稱它為 「任務分派自動化」。做完覺得蠻有趣,因此想紀錄下來。


engine auto work workers,圖片來源:https://pixabay.com/

engine auto work workers,圖片來源:https://pixabay.com/

最近上班完成一項專案,故且讓我稱它為 「任務分派自動化」。做完覺得蠻有趣,因此想紀錄下來。

專案緣起

這次的專案主要是想把一些例行性任務改由系統自動處理,減少不必要的重複性工作,進而轉做更有生產力的項目。讓我先說明原先的工作流程:

基本配置

  1. 商品池:裡面有一大堆商品,稍微分類成 productA, productB, productC
  2. 處理人員:負責處理商品的人員,處理流程會是先到 workerFirst -> workerSecond
  3. Manager:負責分派任務,從商品池挑出需要處理的商品,分派給 workerFirst 或 workerSecond

過往模式

過往的工作模式是 Manager 會從商品池的介面,分派商品給處理人員,並需時時確認處理人員的狀況,以利流程順利進行。但 Manager 也無法每時每刻都盯著商品池及處理人員工作狀況,這時就會造成處理人員未取得商品的閒置期。

調整流程

這次專案是希望能抽離 Manager 分配商品的這層任務,將其自動化。調整方式為若處理人員一開始會領到一個商品,若完成此商品的處理,系統便會分配下一個商品,若商品池暫無商品可處理,則待有商品時,系統自動通知處理人員並分配商品給他。

設計方式

一開始我開了一張 table,用來控制處理人員是否有商品在處理、以及是否為上線模式,如下表:

|id| userId | hasItem | isLogin | created_at | updated_at |
|--|--------|---------|---------|------------|------------|
|1 |519 | 0| 0|2020-06-28 |2020-06-28 |

這時會有一隻 cronjob 定時去執行,檢查此表中是否有 isLogin = 1 以及 hasItem = 0 的人員,如果有找到,就會從商品池撈出相當數量的商品,並根據處理類型,分配 workerFirst 或 workerSecond,並在分配到時發送 slack 通知,再將被分配到商品的人員 hasItem 更新成 1。

另外每個處理人員都有自己的待處理商品頁面,裡面會有被分配的一筆商品,處理完此商品後按下「已完成」,假設自己是 workerFirst,這檔便會被指派到 isLogin = 1 且 hasItem = 0 的 workerSecond,並且再去商品池撈出一檔商品。假設自己是 workerSecond,則會讓商品進入後續流程,並且再從商品池取出 workerFirst 完成的商品。

過程中只要取不到商品,就會將 hasItem 更新成 0,以等待 cronjob 撈到時再分配,並透過 slack 訊息就可以知道是否收到了。

總結

新模式在開發、測試、上線運行後,最後在每日完成的商品處理數量上,平均翻了一倍。可以歸功在系統自動化分配導入後減少的等待商品時間所產生的閒置。

技術上我覺得這套自動化是建構在原先有在運行的工作模式,在整體開發上並沒有遇到太多困難,只是剛開始對於照套工作流程不太熟悉,多是在處理背後邏輯產生的認知誤差。

不過對於上線後提昇的效率數據以及看到處理人員操作自己做出來的介面,心裡也覺得蠻有成就感的。