俗話說不做不錯
但今天的事件
就是在沒有改動程式碼的狀況下
很不幸的壞掉了

這次的事件主角
是一個小後台
功能是簡單的CRUD
做資料的新增刪改

突然有一天PM回報
在操作後台時
會被頻繁的登出

實測一下
果然和PM說的一樣
登入後操作沒幾下
就顯示401,被踢回登入頁面
接著就是無盡的反覆

查了一下git紀錄
將近兩個月都沒有人改動
網頁的登入驗證
是用公司的OAuth系統
系統上線後也一段時間了
沒道理說壞就壞

我一邊按著F5重刷畫面
一邊想著會是什麼原因
這時神奇的事情發生了
上一秒還顯示401
這一秒顯示正常了

再繼續按F5
下一秒又報401
看來這個Bug跟擲硬幣一樣
是有運氣成分在的
機率也是50/50

查看一下CI/CD設定
的確是分流到兩台server
符合剛剛的機率表現
到這邊幾乎就可以確定
不是程式的問題了

問了一下MIS,有沒有什麼頭緒
才知道這個系統的分流
從sticky轉為round robin了
但不太可能因為這個Bug
把分流方式調回sticky

這個專案是.net Core加docker
突然想起每次程式重新部署時
都會顯示一行警告

1
2
Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of 
the container. Protected data will be unavailable when container is destroyed.

就是告訴你container重啟後
加密的key就會不見
不過因為之前程式都運作正常
就沒有多加理會
現在終於業力引爆了

雖然程式是用OAuth驗證
不過實作上還是會依賴cookie
而.net core又會使用自己的key
去對cookie的值做加密

也就是說A機器登入的cookie
拿去B機器驗證就會失敗
最後的呈現方式
就是機率性失敗導致被登出

知道問題後就好解決
生成一把共用的key
用mount的方式做固定
並且讓兩台機器都一樣
順利解決這個問題
真的是不經一事
不長一智

下回預告
一個API的Request Log
參數的紀錄竟然會憑空消失
到底是誰在我的API動了手腳

下一回
Log異常Bug事件