公告
恐怖列表開始了!
Spookality 是我們一年一度的黑暗、詭異與 ██████ 主題慶典。今年，創作者有機會在 9 月 22 日至 10 月 13 日提交角色和世界。
現在我們已經公布了獲獎者名單!如下:
________________省略
提醒更新SDK 3.9
在一周後將阻止所有人上傳新頭像，除非你有SDK 3.9。你被阻止必須要升級到SDK 3.9才行。
你可以繼續編輯舊的avatar，但無法上傳新的。
_________________
2025.3.4 發布！
2025.3.4 為 VRChat 帶來了一個全新的標籤：商店！
可以買各種東西
__________________
開啟你的糖果探索之旅
去商店免費領取你的糖果法典吧!
還有兩個新品分別是 Treats 和 Kath，是你的同伴。可以進行互動和把糖果送給他人，如果它們有耐心的話。
你無法從自己夥伴獲得糖果，只能從他人獲取。
填寫糖果法典獲得你的特殊徽章!
_________________
2025.4.1 現已開放測試！
此版本目前處於測試階段，帶來了許多功能：Boops、Live Now 標籤、透過 Discord 登入 VRChat、Warp Effects、新的報告流程、實例連結等等。
________________
使用 Discord 登入 VRChat！
我們已為所有使用者開放了使用 Discord 在 Web 上登入的功能！造訪 VRChat 網站時，您可以在登入頁面上點擊「使用 Discord 登入」。
完成所需的安全性檢查後，您將成功將您的 Discord 帳戶連結到您的 VRChat 帳戶！
如果您想將 Discord 帳戶關聯到 VRChat 帳戶，但 Discord 帳戶的郵件地址與 VRChat 帳戶的郵件地址不匹配，您可以前往 VRChat 網站的「使用者設定」頁面，從那裡關聯您的 Discord 帳戶。您也可以在同一頁上取消關聯您的 Discord 帳號。
目前，透過 VRChat 用戶端使用 Discord 登入也已在公開測試版中推出，快去那裡試試看吧！
_________________
Steam Audio 實驗
我們正在嘗試對 Steam Audio 進行一些更改，以使其表現得更像人類的語音！
Steam Audio 的用戶可能已經注意到，其他用戶的聲音在前面更響，在後面更安靜。這就是所謂的「心形」指向——Steam Audio 支援在任何聲音來源上使用這種指向。 Steam Audio 還支援在任何音訊來源上設定均衡器頻段——因此，您可以擁有低音更強或尖銳的聲音。
遺憾的是，Steam Audio 不支援同時使用這兩種功能，大概是因為這種功能比較小眾吧——不過人類的語音就是這樣的！低音頻率幾乎是全向的，但高頻幾乎完全是向前的。
幸運的是，由於 Steam Audio 是開源的，我們能夠進行一些修改以在內部支援這項變更。目前，內部測試的回饋多種多樣，從「心形三頻段抑制的實際效果似乎明顯更好」到「到目前為止，我感覺不到啟用和禁用三頻段心形指向有什麼區別」。
我們希望這項功能能讓您在擁擠的環境中，即使不使用耳罩也能聽清對方說話，因為背對著您的用戶說話時，聲音會更悶。目前的體驗有點像所有在聽力範圍內的人都正對著您說話一樣。不妨親自試聽一下，看看您有什麼感想！
________________
上游供應商以及最近的 AWS 中斷對我們基礎設施的未來意味著什麼
在 VRChat，我們（現在！）嘗試建立不嚴重依賴第三方 SaaS 或其他類型服務提供者的基礎設施。幾年前VRchat基礎設施都是由第三方構建。
因為當時沒有專門的開發團隊。
如今，我們的目標是完全掌控我們所使用的服務棧，而不是像使用第三方服務那樣簡單易用。這種轉變的原因之一是，VRChat 的絕大多數服務中斷都是由上游服務商的服務故障所造成的。
這些上游供應商之一是 Amazon Web Services（簡稱 AWS）。 AWS 提供了一系列出色且易於使用的服務和工具。例如，我們繼續使用 Amazon Simple Queue Service (SQS)，因為它與我們的一些舊版服務堆疊深度整合。
我們將 SQS 與 Valkey 結合使用，以實現跨伺服器通信，尤其適用於那些我們不希望 API 端點伺服器耗費 CPU 週期的長時間運行任務。因此，我們透過 AWS 支援的通訊通道將這些任務轉移到專用的工作節點上。
由於此次 AWS 故障，我們用於安全相關事務的另一個上游供應商也同時下線，導致部分使用者無法登入並加入執行個體。不過，一旦加入，你就可以繼續使用，和朋友一起玩耍。
然而，不久之後，我們開始看到與嘗試向 SQS 佇列寫入新訊息相關的錯誤。這意味著我們伺服器端應用程式的一些關鍵功能無法再正常運行，而是放棄了，將應用程式錯誤拋回給用戶。這對我們來說不太理想，因為這意味著用戶體驗低於我們的預期，但這仍然沒有阻止我們的用戶與未受影響的 API 端點進行互動。
快進到 2 小時 30 分鐘後，我們用於安全相關事務的上游提供者突然開始恢復，用戶再次湧入……但是，我們自己的應用程式仍然不高興，因為 SQS 仍然基本上不可用。
這意味著我們自己的伺服器端應用程式堆疊現在拋出的錯誤數量比平常高得多。最終，這些錯誤超過了將伺服器標記為「不健康」的閾值。我們的負載平衡器嘗試替換這些「不健康」的應用伺服器，但沒有新的實例能夠上線，因為它們始終無法滿足被視為在線運行的健康檢查要求。如此反覆。
幾分鐘之內，我們的伺服器端應用程式堆疊就損失了一半以上的容量，剩餘的伺服器承受了更大的負載，因為它們現在要處理的 API 請求數量是其容量的兩倍以上。
幾分鐘後，我們的應用程式堆疊清空了——0台健康伺服器。我們立即開始冷啟動程序，試圖讓應用程式重新上線。
這個冷啟動過程由多個步驟組成，但最關鍵的步驟是：在負載平衡器上阻止所有用戶請求，將我們的應用程式擴展到典型容量的兩倍，然後解除所有請求的阻止。
我們這樣做（而不是為了緩慢啟動而逐漸增加流量），因為我們的一些用戶的第三方應用程式最終會透過即時重試而不是正確退出來淹沒我們的應用程式。
順便說一句，如果您創建了與我們的 API 互動的第三方應用程序，並且沒有使用適當的退避機制進行重試，請修復此問題。謝謝！
無論如何，我們的方法允許我們預先「儲存」額外的容量，直到情況穩定下來，然後我們可以縮減規模。
問題在於，由於多個 AWS 內部控制平面因該問題而出現故障，我們突然發現 Auto Scaling 組中很大一部分運算能力由於縮減請求而消失，導致容量在幾秒鐘內減少了 80%。通常情況下，這種情況會在幾個小時內發生。
這導致我們沒有足夠的運算能力來支援我們的應用程式實例。一旦我們注意到發生了什麼，我們嘗試將這個 Auto Scaling 群組擴充到我們所需的 400%（以提供足夠的空間），但 AWS 並沒有為我們啟動新的運算實例。最終，我們只剩下3% 的運算能力來服務我們的應用程式流量。
這顯然還不夠。我們繼續手動啟動並設定新實例，將它們註冊到擴展組中，最終使我們的應用程式實例能夠開始提供更多容量。
這項任務非常繁瑣，因為有多種因素影響了我們啟動運算實例的能力，尤其是那些運作正常、沒有故障的實例。我們花了大約一個小時才將足夠的運算能力上線，但使用者體驗卻嚴重下降，幾乎無法為使用者提供服務。
為了達到這一點，我們不得不關閉多個系統，包括好友清單和頭像清單端點。為了管理容量，我們還必須阻止某些區域存取我們的應用程式。這就是為什麼雖然有些用戶可以登錄，但卻無法看到他們的好友或頭像。
接下來的幾個小時，我們手動提升了更多運算能力，以解除所有區域對我們應用程式的存取限制，並最終恢復了剩餘的服務（好友、頭像）。最終，一切恢復正常。
在過去幾年裡，我們已將多項服務從第三方 SaaS 供應商遷移到內部託管系統。我們將繼續這樣做，以便我們能夠根據自身需求優化這些系統的配置。這將賦予我們更強的控制力，延長整體正常運作時間，並縮短平均恢復時間 (MTTR)。
作為短期解決方案，我們將使我們的應用程式更能抵禦 SQS 中斷，然後採取長期解決方案，從 SQS 遷移到另一個內部託管服務。
____________
開發者更新本次就到這裡!
下次是11/6
___________
AWS事件幾乎把全球用到雲端比如算力平台等等全部送走，甚至三到十小時後才勉強能用且存在一堆奇怪問題和bug...
有的公司幾乎只能待命等待修好處理一下然後夠快上線，坑死一大票的人員。
恐怖列表開始了!
Spookality 是我們一年一度的黑暗、詭異與 ██████ 主題慶典。今年，創作者有機會在 9 月 22 日至 10 月 13 日提交角色和世界。
現在我們已經公布了獲獎者名單!如下:
________________省略
提醒更新SDK 3.9
在一周後將阻止所有人上傳新頭像，除非你有SDK 3.9。你被阻止必須要升級到SDK 3.9才行。
你可以繼續編輯舊的avatar，但無法上傳新的。
_________________
2025.3.4 發布！
2025.3.4 為 VRChat 帶來了一個全新的標籤：商店！
可以買各種東西
__________________
開啟你的糖果探索之旅
去商店免費領取你的糖果法典吧!
還有兩個新品分別是 Treats 和 Kath，是你的同伴。可以進行互動和把糖果送給他人，如果它們有耐心的話。
你無法從自己夥伴獲得糖果，只能從他人獲取。
填寫糖果法典獲得你的特殊徽章!
_________________
2025.4.1 現已開放測試！
此版本目前處於測試階段，帶來了許多功能：Boops、Live Now 標籤、透過 Discord 登入 VRChat、Warp Effects、新的報告流程、實例連結等等。
________________
使用 Discord 登入 VRChat！
我們已為所有使用者開放了使用 Discord 在 Web 上登入的功能！造訪 VRChat 網站時，您可以在登入頁面上點擊「使用 Discord 登入」。
完成所需的安全性檢查後，您將成功將您的 Discord 帳戶連結到您的 VRChat 帳戶！
如果您想將 Discord 帳戶關聯到 VRChat 帳戶，但 Discord 帳戶的郵件地址與 VRChat 帳戶的郵件地址不匹配，您可以前往 VRChat 網站的「使用者設定」頁面，從那裡關聯您的 Discord 帳戶。您也可以在同一頁上取消關聯您的 Discord 帳號。
目前，透過 VRChat 用戶端使用 Discord 登入也已在公開測試版中推出，快去那裡試試看吧！
_________________
Steam Audio 實驗
我們正在嘗試對 Steam Audio 進行一些更改，以使其表現得更像人類的語音！
Steam Audio 的用戶可能已經注意到，其他用戶的聲音在前面更響，在後面更安靜。這就是所謂的「心形」指向——Steam Audio 支援在任何聲音來源上使用這種指向。 Steam Audio 還支援在任何音訊來源上設定均衡器頻段——因此，您可以擁有低音更強或尖銳的聲音。
遺憾的是，Steam Audio 不支援同時使用這兩種功能，大概是因為這種功能比較小眾吧——不過人類的語音就是這樣的！低音頻率幾乎是全向的，但高頻幾乎完全是向前的。
幸運的是，由於 Steam Audio 是開源的，我們能夠進行一些修改以在內部支援這項變更。目前，內部測試的回饋多種多樣，從「心形三頻段抑制的實際效果似乎明顯更好」到「到目前為止，我感覺不到啟用和禁用三頻段心形指向有什麼區別」。
我們希望這項功能能讓您在擁擠的環境中，即使不使用耳罩也能聽清對方說話，因為背對著您的用戶說話時，聲音會更悶。目前的體驗有點像所有在聽力範圍內的人都正對著您說話一樣。不妨親自試聽一下，看看您有什麼感想！
________________
上游供應商以及最近的 AWS 中斷對我們基礎設施的未來意味著什麼
在 VRChat，我們（現在！）嘗試建立不嚴重依賴第三方 SaaS 或其他類型服務提供者的基礎設施。幾年前VRchat基礎設施都是由第三方構建。
因為當時沒有專門的開發團隊。
如今，我們的目標是完全掌控我們所使用的服務棧，而不是像使用第三方服務那樣簡單易用。這種轉變的原因之一是，VRChat 的絕大多數服務中斷都是由上游服務商的服務故障所造成的。
這些上游供應商之一是 Amazon Web Services（簡稱 AWS）。 AWS 提供了一系列出色且易於使用的服務和工具。例如，我們繼續使用 Amazon Simple Queue Service (SQS)，因為它與我們的一些舊版服務堆疊深度整合。
我們將 SQS 與 Valkey 結合使用，以實現跨伺服器通信，尤其適用於那些我們不希望 API 端點伺服器耗費 CPU 週期的長時間運行任務。因此，我們透過 AWS 支援的通訊通道將這些任務轉移到專用的工作節點上。
由於此次 AWS 故障，我們用於安全相關事務的另一個上游供應商也同時下線，導致部分使用者無法登入並加入執行個體。不過，一旦加入，你就可以繼續使用，和朋友一起玩耍。
然而，不久之後，我們開始看到與嘗試向 SQS 佇列寫入新訊息相關的錯誤。這意味著我們伺服器端應用程式的一些關鍵功能無法再正常運行，而是放棄了，將應用程式錯誤拋回給用戶。這對我們來說不太理想，因為這意味著用戶體驗低於我們的預期，但這仍然沒有阻止我們的用戶與未受影響的 API 端點進行互動。
快進到 2 小時 30 分鐘後，我們用於安全相關事務的上游提供者突然開始恢復，用戶再次湧入……但是，我們自己的應用程式仍然不高興，因為 SQS 仍然基本上不可用。
這意味著我們自己的伺服器端應用程式堆疊現在拋出的錯誤數量比平常高得多。最終，這些錯誤超過了將伺服器標記為「不健康」的閾值。我們的負載平衡器嘗試替換這些「不健康」的應用伺服器，但沒有新的實例能夠上線，因為它們始終無法滿足被視為在線運行的健康檢查要求。如此反覆。
幾分鐘之內，我們的伺服器端應用程式堆疊就損失了一半以上的容量，剩餘的伺服器承受了更大的負載，因為它們現在要處理的 API 請求數量是其容量的兩倍以上。
幾分鐘後，我們的應用程式堆疊清空了——0台健康伺服器。我們立即開始冷啟動程序，試圖讓應用程式重新上線。
這個冷啟動過程由多個步驟組成，但最關鍵的步驟是：在負載平衡器上阻止所有用戶請求，將我們的應用程式擴展到典型容量的兩倍，然後解除所有請求的阻止。
我們這樣做（而不是為了緩慢啟動而逐漸增加流量），因為我們的一些用戶的第三方應用程式最終會透過即時重試而不是正確退出來淹沒我們的應用程式。
順便說一句，如果您創建了與我們的 API 互動的第三方應用程序，並且沒有使用適當的退避機制進行重試，請修復此問題。謝謝！
無論如何，我們的方法允許我們預先「儲存」額外的容量，直到情況穩定下來，然後我們可以縮減規模。
問題在於，由於多個 AWS 內部控制平面因該問題而出現故障，我們突然發現 Auto Scaling 組中很大一部分運算能力由於縮減請求而消失，導致容量在幾秒鐘內減少了 80%。通常情況下，這種情況會在幾個小時內發生。
這導致我們沒有足夠的運算能力來支援我們的應用程式實例。一旦我們注意到發生了什麼，我們嘗試將這個 Auto Scaling 群組擴充到我們所需的 400%（以提供足夠的空間），但 AWS 並沒有為我們啟動新的運算實例。最終，我們只剩下3% 的運算能力來服務我們的應用程式流量。
這顯然還不夠。我們繼續手動啟動並設定新實例，將它們註冊到擴展組中，最終使我們的應用程式實例能夠開始提供更多容量。
這項任務非常繁瑣，因為有多種因素影響了我們啟動運算實例的能力，尤其是那些運作正常、沒有故障的實例。我們花了大約一個小時才將足夠的運算能力上線，但使用者體驗卻嚴重下降，幾乎無法為使用者提供服務。
為了達到這一點，我們不得不關閉多個系統，包括好友清單和頭像清單端點。為了管理容量，我們還必須阻止某些區域存取我們的應用程式。這就是為什麼雖然有些用戶可以登錄，但卻無法看到他們的好友或頭像。
接下來的幾個小時，我們手動提升了更多運算能力，以解除所有區域對我們應用程式的存取限制，並最終恢復了剩餘的服務（好友、頭像）。最終，一切恢復正常。
在過去幾年裡，我們已將多項服務從第三方 SaaS 供應商遷移到內部託管系統。我們將繼續這樣做，以便我們能夠根據自身需求優化這些系統的配置。這將賦予我們更強的控制力，延長整體正常運作時間，並縮短平均恢復時間 (MTTR)。
作為短期解決方案，我們將使我們的應用程式更能抵禦 SQS 中斷，然後採取長期解決方案，從 SQS 遷移到另一個內部託管服務。
____________
開發者更新本次就到這裡!
下次是11/6
___________
AWS事件幾乎把全球用到雲端比如算力平台等等全部送走，甚至三到十小時後才勉強能用且存在一堆奇怪問題和bug...
有的公司幾乎只能待命等待修好處理一下然後夠快上線，坑死一大票的人員。
