工程

工程

Mythex 是如何打造和營運的，包括哪裡出了問題、我們怎麼修好。

• 失敗的重新發布絕不會刪除運作中的後端 — 失敗的重新發布可能會刪掉應用程式正在運作的 API，或讓壞掉的新版本繼續執行。說明 Mythex 如何修正復原發布失敗時的三個問題。
• 警示只發一次，而不是每台伺服器各發一次 — 每天只該送一次的警示，一個下午就送了五次。說明為何兩台伺服器加上部署會讓記憶體內的去重失效，以及共享狀態如何修正。
• 換到更大的工作區，又不讓任何人等待 — 約四分之一的工作區在我們升級到 2 GB 後仍停留在 1 GB。我們第一次的修正讓一位使用者等了七分鐘。說明我們做了什麼，以及為何又改了一次。
• 依實際用量計費的資料庫 — 過去我們預估每個應用程式的資料庫費用，而且估算在兩個方向上都不準。現在每個資料庫都依實際量測的用量，以每小時為單位計費。
• 攔下發布後立即當機的應用程式 — 三次發布都通過了健康檢查，但 API 每次開機幾秒後就當機。原因是以最多五筆的清單來計算當機次數。現在改為比對最新一次當機的時間。
• 讓大量圖片的代理回合留在記憶體之內 — 一個持續查看商品目錄掃描檔的代理回合，在 952 MB 時耗盡記憶體。三個各自讓圖片保留過久的成因，以及我們如何修正。
• 讓長時間的代理作業留在上下文視窗之內 — 我們的子代理可能會成長到模型拒絕處理、為了省空間而提早停止，或在俄文中誤算權杖數。三項修正讓長時間的 AI 作業能夠完成。
• 手機休眠時讓對話保持連線 — 手機會休眠、切換分頁、中斷網路。兩個錯誤讓 Mythex 的對話卡住，或事後只顯示半則回覆。說明我們如何找到並修正這兩者。
• 一個龐大的對話可能會讓我們的 API 停擺 — 9 月 28 日，我們的兩台 API 伺服器同時耗盡記憶體。第一個修正是增加記憶體；真正的解法，是依大小而非筆數來載入對話歷史。
• 連按兩次發布，現在只會發布一次 — 同一個應用程式的三個發布請求在相隔 84 毫秒後抵達，每個都觸發了一次完整部署。我們如何讓資料庫決定由誰發布，並誠實告知其他請求。
• 修正自家網站的 SEO 心得 — 重複的 FAQ 標記、Google 使用錯誤的縮圖、沒人點擊的範本頁面，以及邊緣伺服器拒絕的路徑：我們在 mythex.ai 上發現的問題與修正方式。
• 靜態網站重新發佈時仍維持上線 — 過去重新發佈靜態網站時，會先清空線上檔案，再上傳新建置。現在舊網站會持續提供服務，直到新網站就位，變更幾秒內即可顯示。
• 藏在進度標籤裡的記憶體不足當機 — 我們的 AI 代理人在寫入一個很大的檔案時記憶體不足。原因不是模型，也不是平行的子代理人，而是一個狀態標籤被重送了 41,000 次。
• 凍結我們伺服器的那個缺少的交換檔 — 一台正式環境伺服器停止回應，但沒有當機——沒有記憶體不足的終止，只有沒有交換空間的機器上頁面快取不斷抖動。發生了什麼，以及我們改了什麼。
• 喚醒資料庫時不帶著失效的連線 — 已發佈的 App 從休眠中醒來時，第一個請求會在睡眠期間已失效的資料庫連線上卡住 10–12 秒。我們如何把它降到 2.3 秒。
• 我們一直在限制自己的服務 — 我們 API 的每位址速率限制把自家服務當成一個忙碌的人，於是在正式環境中它們開始收到 429。我們如何找到並修正它。
• 我們為什麼把 Mythex 的伺服器遷移到 ARM — 當繁重的工作移到每個專案的沙盒後，我們的伺服器只用到三分之一的記憶體。較小的 ARM 機器讓成本降低約 30%。以下是做法。
• 我們如何把部署的 502 錯誤降到零 — 一個與部署競爭的看門狗，以及一個太晚察覺的負載平衡器：我們如何找到並修正兩者，並把每次部署的 502 從 10 個量測為零。