AWS企業開戶代辦 AWS Elastic Beanstalk 部署新版本失敗（Environment Health Degraded）排查

一、先搞清楚：Degraded 不是一個問題，而是一個結果

AWS Elastic Beanstalk 的 Environment Health Degraded，很多人第一次看到會以為是部署失敗，其實它更像一個「綜合判定」。也就是說，環境健康變差，不一定只是程式碼沒發上去，也可能是應用啟動慢、健康檢查失敗、資源不足、反向代理異常、資料庫連線超時，甚至是滾動更新過程中某一台機器沒有跟上。

所以遇到這個狀態，第一件事不是急著重部署，而是先分清楚：是部署流程卡住了，還是新版本已經上線，但應用服務不可用。這兩種情況的處理順序完全不同。前者要看部署事件和平台日誌，後者要看應用是否正常啟動、是否能回應健康檢查、是否存在依賴服務故障。

實務上，Elastic Beanstalk 的問題常常不是單點故障，而是幾個小問題疊在一起。單看控制台上的紅字，很容易誤判。真正有效的做法，是先從事件、再到日誌、再到應用本身，一層一層往下拆。

二、排查前先看這三個地方，別一上來就猜

如果新版本部署後直接變成 Environment Health Degraded，建議先固定看三個地方：環境事件、應用日誌、EC2 主機狀態。這三處通常能快速判斷問題落在哪一層。

1. 環境事件

環境事件會告訴你部署過程中發生了什麼，例如應用版本建立失敗、某台實例啟動超時、健康檢查連續失敗、Auto Scaling 無法完成替換。這些訊息雖然看起來簡短，但方向性很強。很多時候，事件裡已經寫明是某個執行個體無法通過 health check，只是大家沒有仔細看。

2. 應用日誌

應用日誌是最核心的線索。新版本上線後，若程式在啟動階段就拋錯，Elastic Beanstalk 會把環境判成 degraded。常見狀況包括：缺少環境變數、程式進程沒起來、啟動腳本失敗、套件版本不相容、連資料庫時超時、設定檔格式錯誤。只要應用沒成功回應健康檢查，狀態就不會好看。

3. 主機層狀態

有些問題不是程式碼，而是主機資源。CPU 長時間滿載、磁碟空間不足、記憶體壓力過大、Nginx 或 Apache 沒起來、Docker 容器啟動失敗，都會把健康度拉低。尤其是在流量高峰或版本切換時，資源不足的問題會被放大。

三、最常見的五類原因

Elastic Beanstalk 部署新版本失敗，背後最常見的原因其實很固定。只要把下面五類問題排一遍，通常就能找到八成以上的根因。

1. 應用啟動失敗

這是最常見也最容易被忽略的原因。程式在本地跑得好，不代表到 EB 上也能正常啟動。常見差異包括執行環境版本不同、缺少系統套件、啟動命令不正確、工作目錄不對、編譯產物沒有打包進去。特別是 Node.js、Python、Java 這幾類應用，啟動階段報錯通常就會直接拉低健康狀態。

判斷方法很簡單：看啟動日誌裡有沒有 exception、stack trace、exit code。如果進程根本沒起來，後面的健康檢查一定過不了。

2. 健康檢查路徑不對

很多團隊在本地測試的是根路由，但 Elastic Beanstalk 的 health check 可能打的是另外一個路徑。如果新版本改了路由、加入登入驗證、或健康檢查接口也跟著變了，環境就會連續判定失敗。這種情況很典型：服務其實活著，但健康檢查一直回 301、302、401、403 或 500，最後還是變成 degraded。

排查時要確認健康檢查打的是哪個 URL，回應碼是否符合預期，是否需要白名單繞過驗證，是否有反向代理重寫規則影響結果。

3. 環境變數或設定缺失

新版本常常會新增依賴設定，例如資料庫位址、API Key、第三方服務 token、S3 bucket 名稱。若部署時只更新程式，沒有同步補齊環境變數，就會出現啟動錯誤或執行期異常。這種錯誤很隱蔽，因為開發機可能有預設值，到了正式環境卻沒有。

有些情況更麻煩：變數名稱沒變，但值被改成錯誤格式，例如原本應該是完整 URL，卻只填了主機名；原本要整數，卻放了字串。程式可能在啟動時就炸掉，也可能在第一個請求時才報錯。

4. 依賴服務不可用

Elastic Beanstalk 上的應用常常不是獨立存在，它依賴資料庫、Redis、ElastiCache、外部 API、訊息佇列。新版本部署後如果改了查詢方式、連線池配置、超時設定，任何一個依賴服務不穩，都會讓應用表面上像是部署失敗。其實真正的問題，可能是資料庫連不上，或者 DNS 解析異常。

這一類問題要特別注意區分：如果版本回滾後馬上正常，那就不一定代表新版本有 bug，也可能是新版本對外部依賴更敏感，把原本隱藏的問題暴露出來了。

5. 部署策略與容量不足

EB 在做滾動更新或替換部署時，需要足夠的容量支撐新舊實例交替。如果環境本來就只開一台實例，或 CPU、記憶體吃緊，再遇到新版本啟動時間較長，就很容易在切換期間進入不健康狀態。這時控制台看起來像是部署失敗，實際上是容量不夠撐住更新流程。

如果使用負載平衡器，還要看 target group 的 deregistration delay、health check interval、healthy threshold、unhealthy threshold 是否合理。太激進會誤判，太寬鬆又會讓故障拖太久。

四、建議的排查順序：從外到內，不要跳步

AWS企業開戶代辦 遇到 Environment Health Degraded，最怕的是東查一下、西查一下，最後還是沒有結論。比較穩的方式，是按固定順序排查，這樣效率最高。

第一步：看事件時間線

先確認是什麼時候開始 degraded，是否剛好在部署之後，還是部署之前就已經有健康風險。很多環境其實早就有輕微異常，只是新版本發布後被放大了。事件時間線能幫你分辨這是一個部署引發的問題，還是一個原本就存在、只是現在爆出來的問題。

第二步：確認應用是否真的啟動成功

不要只看部署完成字樣。Elastic Beanstalk 顯示部署成功，不代表應用真的能服務。你要看的是進程是否存活、服務埠是否監聽、健康檢查接口是否回應正常。若應用框架有自己的啟動日誌，一定要拉出來看第一屏，因為大多數錯誤都出現在啟動前幾秒。

第三步：對照最近一次變更

排查時不要把範圍放太大。只看最近一次版本變更內容，包括程式碼、環境變數、Buildspec、Dockerfile、Procfile、反向代理設定、資料庫 migration。新版本失敗往往不是一個大 bug，而是一個小變更，例如少了一個依賴、改了一個路徑、刪了一個必要檔案。

第四步：檢查平台層設定

AWS企業開戶代辦 包括執行平台版本、實例規格、健康檢查、負載平衡器、Auto Scaling、超時配置。尤其是在平台升級後，舊設定不一定還適用。比如舊版 Node 或 Python 的啟動方式在新版平台上已經不推薦，照舊配置就可能出問題。

第五步：必要時先回滾

如果線上已經受到影響，且排查暫時無法立即完成，先回滾到上一個穩定版本通常是最務實的選擇。不要把回滾視為失敗，它其實是控制風險的正常手段。先恢復服務，再慢慢找根因，比硬撐著讓環境持續 degraded 更划算。

AWS企業開戶代辦 五、幾個最容易踩坑的細節

Elastic Beanstalk 的問題，很多都卡在一些不起眼的小地方。這些細節平常不痛不癢，一到生產環境就會變成大麻煩。

1. 本地能跑，不代表 EB 能跑

本地環境通常有你熟悉的工具、設定和快取，但 EB 上的容器或 EC2 實例是乾淨環境。任何依賴本機狀態的程式，在雲端都可能失效。不要把本地成功當成部署成功的證明。

2. 啟動腳本可執行權限

如果使用 shell script、Docker entrypoint 或自訂啟動指令，請檢查檔案權限與換行格式。Windows 換行、缺少執行權限、路徑錯誤，這些都會造成部署後服務起不來。這類錯誤在日誌裡常常只是一句「permission denied」或「no such file or directory」，但影響非常大。

3. 資料庫 migration 順序

有些新版本一上線就會依賴新的資料表欄位。如果 migration 沒先跑，應用可能直接報錯。反過來，如果 migration 不可逆，回滾也會卡住。所以在設計部署流程時，最好把 schema 變更和應用發版拆開考慮，避免把風險綁死在一起。

4. 記憶體與啟動峰值

有些應用平常很穩，但一啟動就會短暫吃掉大量記憶體。如果實例規格太小，進程還沒完全起來就被 OOM kill，健康檢查自然失敗。這種情況常被誤認為程式碼錯誤，實際上只是資源配置不夠。

六、一個實戰思路：把問題拆成可驗證假設

面對 Environment Health Degraded，最有效的方法不是「猜」，而是把問題拆成一個個可以驗證的假設。比如：是不是應用沒啟動？是不是健康檢查路徑錯了？是不是資料庫連不上？是不是資源不足？每次只驗證一個方向，找到證據再往下走。

例如你懷疑是健康檢查失敗，可以先直接從瀏覽器或 curl 打那個 endpoint，看回應碼與內容。如果回 200，但 EB 還是 degraded，那就要往負載平衡器或反向代理層查。如果 endpoint 根本回 500，就去看應用日誌。如果回 401 或 403，通常是權限或路由策略問題。

再例如你懷疑是資料庫連線問題，可以先在實例內測試連線是否成功，確認 DNS、Security Group、子網路路由、認證資料是否正確。很多時候，問題不在程式，而在環境網路。尤其在 VPC 內部，安全群組和子網設定錯一個，應用就會像壞掉一樣。

七、如何降低下次再出事的機率

修好一次不代表結束。真正成熟的做法，是讓下一次更容易排查、更不容易故障。

1. 把健康檢查做成真正可用的接口

健康檢查不要依賴太多外部資源，最好只檢查應用核心進程是否活著，不要每次都去打資料庫或第三方服務，不然一個外部抖動就會把整個環境判成不健康。

2. 讓部署前檢查先擋掉低級錯誤

例如環境變數完整性檢查、設定檔格式驗證、依賴安裝檢查、migration 檢查、啟動 smoke test。能在部署前發現的問題，就不要留到線上才處理。

3. 觀測要完整

至少要有應用日誌、錯誤日誌、健康檢查紀錄、部署事件、資源使用率。當問題出現時，沒有觀測就只能靠猜。有足夠的觀測，很多問題三分鐘內就能定位到大概範圍。

4. 不要把單點配置當成標準答案

如果環境只有一台實例，一旦更新失敗就容易全站受影響。至少保留能回滾、能切換、能臨時擴容的空間。Elastic Beanstalk 的便利性很高，但前提是你要給它足夠的容錯餘地。

八、結語：看懂狀態，比盲目重試更重要

AWS Elastic Beanstalk 的 Environment Health Degraded，表面上是健康變差，實際上是在提醒你：部署鏈路、應用啟動、平台配置、依賴服務、容量和健康檢查之間，至少有一環出了問題。真正高效的排查，不是無腦重試，而是先看事件，再看日誌，再看應用和環境。

AWS企業開戶代辦 只要你把排查順序固定下來，把常見原因整理成清單，這類問題其實沒那麼可怕。新版本部署失敗不可怕，怕的是每次都從零開始猜。當你能快速分辨問題屬於程式、配置、依賴還是容量，Environment Health Degraded 就不再是黑盒，而是可以被一步步拆開的結果。