我在 AWS 技術支援六年的收穫：問題排查與營運思維

TL;DR

我在 Amazon Web Services（AWS）擔任雲端技術支援工程師六年，從 Cloud Support Associate 一路成長為容器服務的 Subject Matter Expert，期間支援來自全球的企業級客戶。這段旅程讓我學到紮實的 Linux、網路與容器相關技術能力，以及以客戶影響為優先、快速解決問題的有效問題排查方法論。

在 Amazon，我的重要收穫包含：及早升級問題的價值、完整記錄工作的必要性，以及建立跨職能人脈網絡，來交付高品質的技術支援。

本文僅反映我個人在 AWS 任職期間的經驗與觀點，無評價 AWS 產品，也不比較 AWS 雲端技術支援工程師與其他公司的支援組織。

前言

我在 AWS 的六年，是人生中一段既有趣又充滿挑戰的時光，也留下了許多回憶。回顧這段經歷，我將它視為一個成長與挑戰並存的階段。

我希望藉由這個機會，記錄並整理我的職涯發展與關鍵學習，聚焦在技術能力、問題排查方式，以及 Amazon 的營運文化，同時也回顧自己在這裡的職涯歷程。

在 AWS 的旅程

• 2019：2019 年 9 月，大學畢業後加入台灣 AWS 雲端技術支援工程師團隊，擔任 Cloud Support Associate（CSA）
• 2020：2020 年 7 月通過內部流程，晉升為 Cloud Support Engineer（CSE），開始支援企業級客戶
• 2021：2021 年 3 月調派至愛爾蘭都柏林團隊，負責支援 UTC+8 時區的夜班客戶
• 2022：2022 年 8 月通過產品專家與開發團隊的認證，成為 Elastic Container Service（ECS）的 Subject Matter Expert（SME），並於 2022 年 12 月晉升為 CSE II（L5）
• 2023：2023 年 9 月通過 AWS Solutions Architect – Professional 認證
• 2025：在任職滿六年、31 歲生日之前，於 2025 年 9 月離開 AWS

加入 AWS 之前的小故事

Linux 旅程的開始

和許多一般學生一樣，我在大學時並不知道自己未來想做什麼。我就讀的是以軟體工程聞名的資工系，但我其實並不熱衷於寫程式。而且在進入大學之前，我幾乎沒有任何 IT 或資訊相關的背景。

不過，我還是決定嘗試找找看自己可能會喜歡的方向，最後發現我其實很喜歡使用 Linux 系統。我覺得在 command line 上操作系統非常有趣。當時我在筆電上安裝了 Ubuntu 13（那時還需要同學幫忙），並開始研讀在台灣相當有名的新手教材──鳥哥的 Linux 私房菜。但不知為何，我始終沒有機會做系統管理員相關的工作。

實習經驗

2018 年大三時，我經由系上一位學長的介紹，有機會到一家名為 Larvata 的軟體公司擔任 Python 開發實習生。有趣的是，我的導師同時也是 DevOps 團隊的 team lead。在實習期間，我看到了他們如何進行自動化、監控與容器相關的工作，也觀察到 Kubernetes 是如何被導入實際環境中。mentor 也很樂於分享他的工作流程，包括在 command line 與 Vim 上的操作。當時我心裡只覺得：「這真的太酷了。」

我在那段時間累積了非常寶貴的經驗。

AWS Support 的面試過程

大四那年，我仍然不知道自己未來要做什麼，直到在校園徵才博覽會上遇到了 AWS 技術支援的攤位。在聊天的過程中，主管與工程師直接問我是否願意在同一天的下午參加面試。我當下非常緊張，因為完全沒有心理準備。不過，面試問題大多圍繞在我感興趣的主題，例如 Linux 作業系統的開機流程、瀏覽器背後實際發生了什麼事情等等。我很幸運地通過了第一關，卻在第二關失敗了。

從那之後，我投遞了許多不同的工作，但心中仍然以 AWS 技術支援為目標。儘管我被許多公司拒絕，但也幸運地拿到了一些軟體工程師或系統管理相關職位的 offer。最終，我選擇拒絕所有這些機會，再次嘗試申請 AWS 技術支援，並在同一年成功通過面試。

我在 AWS 學到的事

技術

AWS 擁有我過去難以想像的龐大資源，從虛擬化、作業系統、電腦網路（L1 到 L7）、容器、CI/CD pipeline、CDN、資料庫、資料分析，到 AI / ML 等等。

只要能力與時間允許（還有時間！），我們都被鼓勵去學習不同領域的技能。只需要幾個點擊，我就能啟動 EC2、EKS 或 ELB 來做實驗與問題排查。我也有機會向在各個領域中擁有紮實技能、知識與經驗的專家請教，他們來自不同背景，例如資深系統管理員、網路管理員、資料庫管理員、軟體工程師與網路開發者等等。

我常常會想，為什麼我能夠有機會和這些人一起工作。

EC2-Linux

我從 EC2-Linux 開始，逐步深入理解 Linux，以及底層硬體與虛擬化的運作方式。我遇到非常棒的 mentor 與資深同事，在每一場知識分享中都學到了很多。

從作業系統層面的問題排查（CPU、記憶體、網路、磁碟效能監控與分析）、套件管理，到 EC2 底層硬體問題、SSH 連線異常，再到在不同條件下的網路效能議題（例如 PPS、頻寬、connection tracking、底層網路元件、noisy neighbor 等），那些資深工程師都能深入排查到我過去難以想像的境界。

Networking（網路）

由於工作中經常需要支援不同領域的服務，我開始跨領域學習網路相關服務，例如 Load Balancing、DNS 等。資深工程師提供了非常紮實的訓練，從 TCP/IP 到 HTTP，從 RFC 規格文件，到 Linux 網路 socket 的實作實驗，甚至包含測試不同 TCP congestion control 演算法與不同 HTTP 版本。

接著我開始接手 ELB、Route53 等案例。雖然一開始處理得並不好，但我非常幸運，有工程師願意在繁忙的工作中撥出時間協助我。後來我也開始能夠協助處理一些網路相關的緊急升級案件。

我記得有一次假期期間，一個緊急的網路案例被升級，但當天沒有其他資深網路工程師值班，我必須站出來處理。即使最後沒能找出 root cause，我仍完成了初步排查並成功升級至內部團隊，直到其他資深的技術支援工程師接手深入調查。

Container（容器）

隨著越來越多客戶在應用與環境中導入容器化，我開始加入容器服務的支援。訓練採用由下而上的方式，從 Linux cgroups、namespaces、容器網路、shim、runc，一路到 Docker、Amazon ECS、Kubernetes 與 Amazon EKS。

AWS 的容器服務與 EC2、Auto Scaling、EBS、EFS、ELB 等服務深度整合，而我在加入容器服務前累積的知識，對我幫助非常大。最終，我取得了 ECS SME 資格，並轉入部署（容器 + CI/CD）的支援領域。

AWS 確實提供了學習這些技術的機會，但前提是願意投入時間與心力，並主動接手一開始超出自己支援領域的案例。資深工程師往往能看見較資淺的人這樣的嘗試，也願意在這些情況下伸出援手。

我記得曾有人建議我不要參加某場分享，因為那可能超出我當時的領域，對我幫助不大。於是我花更多時間補強自己的能力，讓自己有資格參與不同領域的分享與討論。

問題排查

從我的角度來看，AWS 的問題排查相當獨特。一般公司可能一年只會發生一兩次重大的關鍵業務故障的重大事件，但在 AWS 技術支援，處理緊急的生產環境問題卻是日常工作。

SOAP 方法論

在 AWS 技術支援，我學到了來自醫療領域的問題排查方法論 - SOAP：Subjective、Objective、Assessment、Plan。

排查一個案例，就像醫師看診一樣。我們需要先確認客戶主觀描述的狀況（痛點、影響、時間、資源等），再蒐集客觀資料，例如數據、log、截圖。

一個常見的錯誤，是混淆「症狀（symptom）」與「徵象（sign）」。症狀是客戶的主觀描述，而徵象則是與症狀相關的客觀發現。

在蒐集完主觀與客觀資訊後，我們才會進行評估（Assessment）與規劃下一步行動（Plan）。

技術支援工程師可以被比喻為醫師：有些像急診醫師，負責快速初步調查、緩解或提供 workaround，並決定下一步；有些則像專科醫師，擁有特定知識與工具，能深入挖掘 root cause。

縮小問題範圍

我們必須學會如何在短時間內向客戶蒐集有用的資訊，並進行有效的調查，快速判斷問題的範圍與方向。

我記得一位資深工程師曾告訴我：

一個好的技術支援工程師，可以用一個問題排除掉 50% 的可能根本原因。

我們需要不斷縮小可能原因：問題來自 AWS 還是客戶端？是基礎架構問題還是應用程式問題？是網路、作業系統，還是容器層面的問題？

從我的經驗來看，很多時候客戶在開案例時會懷疑是 AWS 的問題，但最後發現其實是他們自己環境中的變更，而這些問題原本就有能力自行排查。

我很喜歡 《DevOps Troubleshooting》書中的一句話：

One thing I’ve learned in my years as a systems administrator is that when there’s a problem, everyone blames the technology they understand least.

在我多年的系統管理員生涯中學到的一件事是，當問題發生時，人們往往會責怪自己最不理解的技術。 (AI 翻譯)

即使在我自己進行問題排查時，也會懷疑是否漏掉了某個不熟悉領域的問題。但很多時候，只要冷靜下來、放慢速度，就會發現問題其實就在自己能掌握的範圍內。

有位同事曾告訴我：當大家都在慌亂時，我們更需要冷靜下來，才能把事情做好。

蒐集資訊

在許多緊急情況下，客戶並不知道該如何縮小問題範圍，也不知道該蒐集哪些資訊。我們需要引導他們提供必要的資料，例如發生問題的時間（包含時區）、資源 ID、錯誤訊息，以及在正常與異常狀態下的效能指標。這點非常重要，正如 《Systems Performance》一書所說：

Performance, on the other hand, is often subjective. With performance issues, it can be unclear whether there is an issue to begin with, and if so, when it has been fixed. What may be considered “bad” performance for one user, and therefore an issue, may be considered “good” performance for another

另一方面，效能（performance）往往是主觀的。在效能問題上，一開始是否真的存在問題，其實並不總是那麼明確；即使有問題，也很難判斷什麼時候才算已經修好。對某些使用者來說被認為是「效能不佳」的情況，對另一位使用者而言，可能反而被視為「效能良好」。 (AI 翻譯)

我們也需要了解事件的背景，例如在問題發生前是否有設定變更或部署，是否有測試環境可以比對。

此外，也要搞清楚案例背後真正的需求是什麼：是需要解法？需要撰寫報告？還是其他目的？以及，是否有最簡單的方式能在測試環境中重現問題？

事實來源（Source of Truth）

在問題排查過程中，我也學會對資訊來源保持警覺。我們參考的是業界規範？官方文件？還是第三方資料？如果是第三方來源，是否值得信任？能否查看原始碼進行驗證？

如果文件內容與實際行為不一致，我們能否自行驗證？日誌是否真的反映了實際狀況？是否需要啟用 debug 或 trace log 來取得更多線索？

我曾多次看到優秀的同事直接引用 RFC 規格或開源程式碼向客戶解釋問題。也有不少情況，是同事透過完整的實驗步驟與結果，回饋給內部團隊，協助修正文檔中的錯誤。

檢查清單（Checklist）

在排查問題時，使用檢查清單有時是很好的方式。例如 Netflix Performance 團隊提出的〈Linux Performance Analysis in 60,000 Milliseconds〉，能快速檢查 Linux 主機的狀態。

在排查 EC2 問題時，我也有一份自己的清單，包含 CloudWatch 的 EC2 與 EBS 指標、底層元件、網路元件，以及可使用的監控工具。

但我也提醒自己，檢查清單只是輔助工具，必須不斷更新。如果只是機械式地照表檢查，而不了解每一項背後的意義，反而會失去價值。

不同產業的需求

我們會接觸到來自各行各業的緊急案例，包括 Fortune 500 企業、新創公司、銀行、遊戲、IoT、加密貨幣、電商、社群平台等。

在問題排查與溝通時，我必須留意不同產業的特殊需求。例如：

• 對遊戲產業來說，重啟 EC2 是非常高成本的行為，在要求重啟前必須確認是否真的沒有其他 workaround
• IoT 客戶非常在意固定 IP，因為 IP 變更可能影響成千上萬甚至數百萬台裝置
• 加密貨幣產業節奏極快，處理問題的速度至關重要（就像幣價一樣）

在 AWS 技術支援團隊工作，讓我有機會深入了解許多平時難以接觸的產業。

案件處理（Case Handling）

AWS 非常擅長將一切標準化。我學到了如何從技術、流程與全局的角度來管理一個案例。

在我剛加入時，資深工程師會從頭到尾檢查我處理的案例，檢視我是否遵循最佳實務，並給我改進建議。這對他們而言需要投入大量時間，但也讓我學會如何撰寫工作記錄、與客戶溝通，以及遵循流程。在處理案例時，我需要不斷決定下一步：是先嘗試重現問題？還是直接升級給內部團隊？何時該尋求資深工程師協助？是否需要聯絡 TAM、Ops Manager，還是先回覆客戶？

工作紀錄（Work Log）

工作記錄是技術支援工程師非常重要的一部分。我需要記錄所有與案例相關的資訊，包括摘要、客戶痛點、排查步驟、重現方式、對外與對內的溝通內容。

所有與 TAM、客戶或 SDE 的共識，都必須記錄在工作紀錄中。一個原則是：假設我不是唯一會查看這個案例的人。如果我下班後案例被升級，其他工程師或主管只要閱讀工作記錄，就能無縫接手，而不需要再聯絡我補資料。

我曾在值班時遇過一個不在我技術範圍內、但原本處理案例的人已下班的升級案件。我僅憑原工程師留下的工作紀錄，就成功為該案例撰寫了內部升級工單，內部團隊與主管也能依照這些步驟重現問題。

一份好的工作記錄，能節省大量溝通與時間成本。

溝通

我們可能透過 email、線上聊天或電話與客戶溝通。每一次互動，都是建立客戶信任的重要環節。

我被教導不要傳遞任何不完整或不正確的資訊給客戶，而是要預先思考：當客戶看到這封回覆時，下一個問題會是什麼？我是否已經提供了清楚的說明、替代方案或解決步驟？

在線上聊天或電話中，客戶往往處於生產環境的壓力之下。我需要在保持專業的同時，展現同理心，並引導排查方向，而不被緊急狀況影響判斷。

很多時候，我可能正在深入排查或進行內部升級，但如果沒有持續更新客戶狀況，之前做的努力很可能變得毫無意義。

升級（Escalation）

升級是 Amazon 文化與 AWS 技術支援團隊的核心價值之一。如果問題超出我能掌控的範圍，就必須升級。解決問題的速度非常重要。

這看似與 Amazon 強調的 Dive Deep、Learn and Be Curious 有些衝突，但我學會根據情境做判斷：什麼時候該繼續深入排查，什麼時候該升級給資深工程師、SDE，或請 TAM 與客戶、管理層溝通。當然，在升級之前，我必須做好功課，清楚準備問題描述，包括：需求是什麼、背景是什麼、已知與未知的資訊，以及我已經做過哪些嘗試。

升級的時機，至今仍是我持續學習的課題。

在 Amazon 工作

團隊合作

在 Amazon，每個人都很忙。這是一間規模龐大的公司與團隊，每個人都有自己的角色與責任。因此，在面對問題時，我們不應該單打獨鬥。

我很欣賞的一位 AWS Developer Advocate 曾說過：

The reality is that although AWS as a whole is a collection of brilliant people, there is no single person who has all the knowledge. What I’ve Learned From 6 Years as a Developer Advocate | Nathan Peck

事實上，雖然整個 AWS 聚集了許多非常優秀的人才，但沒有任何一個人能掌握所有的知識。 (AI 翻譯)

我同時也提醒自己，不要浪費他人的時間。當我向別人求助時，不能只說一句「嗨」。No Hello 是在 Amazon 工作時非常重要的原則。

在聯絡他人或升級時，我會事先整理好問題，使用 STAR 格式 (Situaion, Task, Action, Result) 說明，讓對方清楚知道背景、需求，以及他們需要投入多少時間。更重要的是，要記得肯定他人的付出，無論是公開致謝、寄信，或在指標上給予回饋。

在團隊會議中把握機會提問與討論，是向主管、資深工程師與同儕學習的好機會。如果會議只有公告、沒有討論，那其實是很可惜的。

人脈

當我離開 AWS 時，我道別的人包含：同儕、資深與 Principal 技術支援工程師、團隊內外的主管、架構師、TPM、TAM，以及來自 AMER / EMEA / APJC 的 SDE。能夠認識並與這些人共事、向他們學習，我感到非常幸運。

AWS 是一個能找到各種技術與非技術領域專家的地方。

營運（Operation）

AWS 的規模非常龐大，因此所有事情幾乎都必須建立在數據與指標之上。每個人都有自己的優先順序，而你必須說服別人，為什麼你的事情更重要。

老實說，這也是我仍在學習的部分。我曾參與一些改善工程師工作環境的專案，但最終未能說服管理層，因為這些專案未必與支援團隊的核心指標直接相關。不過，整個過程仍讓我學到很多，包括在推動專案前，應該蒐集哪些資料與數據。

AWS 會關注許多指標，並針對每一項指標建立改善流程，例如 CSAT、案件解決時間、升級率、交接等。我認為這是一把雙面刃。正如貝佐斯所說，指標只是代理；如果無法反映真實狀況與感受，那就不是好的指標。

技術支援工程師的價值其實很難衡量：是解決的案件數量？技術深度？客戶管理能力？還是專案影響力？一位工程師能在 15 分鐘內解決問題，並不代表問題簡單，而是來自長期累積的經驗。

我個人認為，從某個角度來看，技術支援團隊比起開發團隊，更承受不起失去資深工程師的代價。這六年來，我看到許多資深工程師來來去去，但客戶始終是同一群人，只是問題變得越來越複雜。資深技術支援工程師是與客戶一起成長的，能夠累積信任與經驗。一旦離開，要再培養一位能面對這些成熟客戶的工程師，其實非常困難。

Amazon 文化

Amazon 以 Leadership Principles 聞名。我認為這些原則確實很重要，但如何談論與實踐這些原則，本身就是一門藝術。我很幸運在剛加入時，能向一些真正理解並重視這些文化的 Amazonians 學習，他們願意分享如何在不同情境中，根據原則做出決策。

隨著團隊成長，越來越多流程、playbook 與 runbook 被引入。但流程一定會有例外，如果沒有對原則的正確認知，遇到例外時就會不知所措。流程與文件本身也是雙面刃，列得越詳細，例外就越多。相較之下，以原則為核心的文化，反而更有韌性。

寫作

Amazon 非常重視寫作。內部溝通不使用 PowerPoint，這在一開始讓我感到非常驚訝，但後來我發現這確實是正確的方式。無論是一頁或六頁文件，寫作能幫助釐清思路。當我想找某個提案時，會直覺地去找對應的 initiative 或 PRFAQ。在會議中，大家安靜地花 15 分鐘閱讀文件，然後提出意見，這是一個非常有價值的過程。我能從中學到文件缺少了什麼、該如何改進，以及如何讓提案更完整。

結語

感謝你看完我這段 AWS 的旅程。離開 AWS 的決定並不容易，心情也非常複雜。有時在每天處理案例的過程中，我覺得自己學到了很多；但有時又覺得現階段對於職涯成長需要不同的刺激。

我感受到自己的成長，但同時也意識到需要不同的環境，來繼續探索與累積經驗。我期待人生的下一個章節，也期待能繼續和大家一起學習。