開發與運維之間思維方法

Photo by Jeremy Perkins on Unsplash

上午行銷部門客戶跟我反應，產品名稱比對不上，為什麼旁邊數據顯示匹配無。他已經手動處理，但是希望我能調查原因。

一般開發者會的思維

步驟會把只有沒有找出來的產品，用細微方式一筆兩筆重新跑一遍，然後會直覺反應，這明明就沒有匹配上，寫無很正常啊。於是用這樣步驟一一檢查：

1. 檢查單筆運作是正常，沒有出任何例外錯誤。
2. 近期沒有改代碼。
3. 細看程式碼，這邊產品名稱會跟另外一張試算表做對照，而那張試算表沒有那組產品名稱，找不上還是正常的，這就是不存在這筆產品名稱呀。

於是很合理回報：產品名稱哪邊來的？因為我們對找產品表裡面沒有，找不到。邏輯是找出官網課程名稱，前往 spreadsheet 活動通課統計表，如果找不到，就寫無。

問題還是沒有解決。

運維角度分析的方法

這張試算表資料沒有進來，往上一層作業流程，產品是來自於外部 Saas 服務，跟那邊取行銷部門放上去的產品。於是進入數據庫查看，看到數據從 4 天前最後一筆同步記錄，缺少了 3 天的記錄，也就是某一組作業程序停擺了。檢查步驟：

1. 近期運轉系統是否有異動？
   有的，我們在 4 天前因為運轉主控制系統掛掉，升級不上去，復原不了，整個壞掉了，透過人工方式補了一天，到了花了一天才把運轉主控制系統復原，而且不是透過備份還原，而是手動一一配置上去。漏掉了配置這組作業程序。

找到原因了，是沒有備份，所以花比較辛苦從頭配置還原，花時間還會遺漏，甚至以前怎麼配置碰到問題都還要一一克服才配置的起來。

於是將當初回報有問題訂單產品，重新匹配上了，訂單流程可以順利往下階段走了。

回到 Git 查看，解決這題不用修改任何邏輯，代碼都不用異動，這部分是運維方面要更穩健些。也想到以往有的年輕工程師只有在開發者思維時候，找不到問題就不管了，讓專案經理管理起來很吃力。值得一提是在面對這問題時候，兩種不同角度切入解決問題思維方式。