附屬伺服器故障 Auxiliary service outage

原因 ID in-subservice · 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）

聊天、隊伍、拍賣場這類與遊戲伺服器分開運作的伺服器故障時，只有那個功能無法運作。

為什麼 功能專用伺服器變慢或掛掉 → 於是只有該功能的請求沒有回應 → 畫面上 無法聊天、組隊邀請沒反應、交易所無限讀取（戰鬥正常）

症狀: 吃指令／回檔, 連不上／無限讀取
因素: 停滯, 遺失
誰會遇到: 只有特定功能
何時: 偶爾隨機發生, 人潮湧入時
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）
遊戲開發團隊要做的事: 設計成即使失敗遊戲也能繼續、顯示各功能的狀態、不把多個功能集中在一台中央伺服器。
基礎設施團隊要做的事: 每台附屬伺服器的健康檢查與警示、備援與自動重新啟動。
圖表上: 連線同時大量中斷 · 各功能的請求成功率、附屬伺服器的連線數與健康檢查
查看位置: 聊天、隊伍、拍賣場等各附屬伺服器的健康檢查、處理程序狀態與連線數，各功能的請求成功率與回應時間。若在負載平衡器後方，看目標群組的 UnHealthyHostCount
符合的跡象: 只有負責被回報功能的伺服器出現健康檢查失敗或連線數驟降，遊戲伺服器的 tick 與戰鬥正常
不符合的跡象: 多個功能同時停擺時，是一起轉送這些功能的中央伺服器或連鎖故障的問題
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）
深入了解: 如果隊伍、公會、密語、跨伺服器移動全都由一台中央伺服器（world／manager 伺服器）轉送，這台伺服器一變慢，多個功能就會同時停擺。

出處

Bulkhead Pattern Microsoft Azure
以資源池隔離元件後，一個元件失敗其他仍能繼續運作，故障也不會擴散
REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies AWS
AWS Well-Architected。設計成依賴對象故障時，核心功能仍能用稍舊的資料或替代資料繼續運作
CloudWatch metrics for your Network Load Balancer AWS
UnHealthyHostCount：健康檢查判定為異常的目標數