工程

工程

Mythex 是如何打造和運作的，包括哪裡出了問題、我們如何修復。

• 失敗的重新發佈絕不會刪除運作中的後端 — 一次失敗的重新發佈可能會刪除應用程式正在運作的 API，或者讓壞掉的新版本繼續運行。以下是 Mythex 如何撤銷出錯發佈的三項修正。
• 警報只響一次，而非每部伺服器各響一次 — 一個每日只應發出一次的警報，在同一個下午就送到了我們這裡五次。為何記憶體內去重在兩部伺服器和部署之下會失效，以及共享狀態如何修正了它。
• 遷移至更大的工作區，又不讓任何人等待 — 我們改為 2 GB 之後，四分之一的工作區仍停留在 1 GB。我們第一次的修正令一位用戶等了七分鐘。我們改了什麼，以及又再改了什麼。
• 按實際用量為資料庫計費 — 我們過去會估算每個應用程式的資料庫成本，而估算在兩個方向上都出錯。現在每個資料庫都按實測用量逐小時計費。
• 及早發現發佈後立即崩潰的應用程式 — 有三次發佈通過了我們的健康檢查，儘管它們的 API 在每次啟動後的數秒內都會崩潰。原因是：崩潰次數是在一個最多只能容納五個條目的清單中計算的。
• 令大量圖片嘅代理回合保持喺記憶體範圍之內 — 一個代理回合一直睇緊目錄掃描圖，喺 952 MB 時記憶體耗盡。三個獨立原因，每個都令圖片留喺記憶體太耐，以下係點樣修正。
• 令長時間嘅代理回合保持喺上下文視窗之內 — 我哋嘅子代理會一直增長，直到模型拒絕處理、為咗省位而提早停止，或者喺俄文入面計錯 token。三個修正，令長時間嘅 AI 工作得以完成。
• 手機休眠時保持對話運作 — 手機會休眠、切換分頁，並且喺建構途中斷開網絡。兩個錯誤令 Mythex 嘅對話之後停滯，或者只顯示半個回覆。我哋點樣搵到並修好呢兩個問題。
• 一個龐大嘅對話點樣可以令我哋嘅 API 停頓 — 九月二十八日，我哋兩部 API 伺服器同時耗盡記憶體。第一個修正係加多記憶體；真正嘅修正，係按大小而唔係按數量去載入對話歷史。
• 撳兩次發布，而家只會發布一次 — 同一個 app 嘅三個發布請求，相隔 84 毫秒抵達，每個都觸發一次完整部署。我哋點樣令資料庫決定邊個負責發布，並誠實告知其他請求。
• 修復自家網站後學到的 SEO 經驗 — 重複的 FAQ 標記、Google 顯示錯誤的縮圖、沒人點擊的範本頁面，以及被邊緣伺服器拒絕的路徑：我們在 mythex.ai 上發現並修復的問題。
• 靜態網站在重新發佈時保持上線 — 以往重新發佈靜態網站時，會先清空現有檔案，才上傳新的建構版本。現在舊網站會持續提供服務，直到新版本就位，變更數秒內即可顯示。
• 隱藏在進度標籤中的記憶體不足崩潰 — 我們的 AI 代理在寫入一個大型檔案時記憶體耗盡。原因不是模型，也不是並行的子代理——而是一個狀態標籤被重複傳送了 41,000 次。
• 令伺服器凍結的缺失交換檔案 — 一台正式伺服器停止回應，但沒有崩潰——沒有因記憶體不足而被終止，只是在沒有交換空間的機器上出現頁面快取抖動。發生了什麼，以及我們改了什麼。
• 喚醒資料庫時不再遇到失效連線 — 已發佈的應用程式從休眠中醒來時，第一個請求會因睡眠期間失效的資料庫連線而卡住 10 至 12 秒。我們如何把它降到 2.3 秒。
• 我們一直在限制自己的服務 — 我們 API 的每個地址速率限制，把自家服務當成一個繁忙的用戶，結果正式環境中它們開始收到 429。我們如何發現問題並修復。
• 我們為何把 Mythex 伺服器遷移到 ARM — 重任務轉移到各專案沙盒後，我們的主伺服器只用了三分之一的記憶體。較小的 ARM 機器令每月伺服器費用減少約 30%。以下是我們的做法。
• 如何把部署的 502 錯誤降至零 — 一個與部署競爭的看門程式，以及一個反應太慢的負載平衡器：我們如何找出兩者、修復它們，並把每次部署的 502 錯誤由 10 個降至零。