Yang-Xin Cao (Eason Cao)

Yang-Xin Cao (Eason Cao)

Engineer@Amazon
- AWS All-5 certified / ECS & EKS SME / Marathon Runner / PADI Open Water Diver

身處 Amazon 工作 5 年學到的事：在 AWS 擔任 Cloud Support Engineer 是什麼樣的體驗

2 minute read

2023 是我在 AWS 擔任 Cloud Support Engineer 的第六年，這份工作對我來說某種程度上是又愛又恨。作為見證 AWS 中文技術支援團隊的一員，五年時間說長不長，說短也不短，卻有非常多學習和體悟。

身處 Amazon 工作 5 年學到的事：在 AWS 擔任 Cloud Support Engineer 是什麼樣的體驗
身處 Amazon 工作 5 年學到的事：在 AWS 擔任 Cloud Support Engineer 是什麼樣的體驗 (source: Unsplash)

一轉眼五年過去，除了見證團隊的成長，也看過各種人來來去去。在 Amazon 待超過五年的員工不正確估算在全球大概佔 PR 90，在同一個團隊待超過五年的人更是稀缺。一滿五年，你就能夠晉身橘色識別證的一員1。作為團隊少數幾個拿橘牌的員工，不免有一些勵志或是辛苦的工作歷程可以分享，可惜忙碌跟快速的工作步調讓很多想法稍縱即逝。尤其是回顧自己過去寫下的內容 (我在 Amazon 學到的 10 件事)，驚覺這些改變其實無時無刻都在發生，我確實明白自己有些模樣在這五年前已經有所改變，慶幸的是我沒有因為環境而變得事故。

我想或多或少是因為能夠透過回顧這些內容，甚至是因為協助面試的緣故，很多來面試的候選人甚至主動提及曾經讀過我的內容並且因此受到一些啟發 (不論是否最終有進入我們團隊工作)。這些文字跟反饋都讓我時刻刻提醒自己要永保初心，也要求自己用更成熟的方法處理事情。有些文章甚至獲得很多各方高手的迴響，但一直遲遲沒有安排時間再繼續寫更多。因此寫下這篇內容，也算是我個人對自己在用五年後的視角，來總結我對這個團隊喜歡和認為有待加強的地方。

在這裡先提個免責申明，AWS 雖然作為 Amazon 整個集團重要的一個業務，但有許多管理的方式可能也因不同組織和角色而有所差異。畢竟 Amazon 在全球有數十萬名員工分佈在世界各地，工作時遇到一堆奇奇怪怪的部門早已屢見不鮮，用 AWS Support 不能以偏概全所有團隊的樣貌。

此外，這篇內容僅為個人的觀察，不代表任何官方立場，本篇內容更不期待帶有任何批判色彩。在團隊裡身為一個獨立貢獻者 (Individual Contributor)，大部分時間我也是站在第一線解決各式各樣的工程問題，而非討論管理維運議題。因為不是站在管理層的角度用宏觀的面向關注團隊維運，工程師關注的議題跟管理者的議題多少都有些不同，我僅分享我對於身為工程師及親身經歷的相關感受，不意味著任何一方不好。

畢竟我的角度為「工程師」而非「管理者」，因此可能部分觀察的角度也會有所侷限，但會盡可能用客觀的角度寫下我個人的觀察，還請閱讀者自行評判。

認識不同年齡層工作者的機會間接拓展更廣的人際網路

我在中文技術團隊觀察一直沒變的事情是，團隊中充滿了各式各樣優秀的同事，許多不乏都是在業界工作數年的工程師並且擁有豐富的經歷。有趣的是，時下的招聘政策也鼓勵許多剛畢業的學生加入 AWS Support 技術團隊，不時為團隊注入心血，使得整個團隊的組成十分多元。常常也有許多不同的新進同事從其他公司帶來不一樣的經驗和想法，甚至從原本使用 AWS 產品的客戶端變成解決問題的角色，都促使團隊中因為不同背景的工作者加入彼此交流而建立強大的人脈網路。

與全世界交流

Cloud Support Engineer 是一個全球化的團隊，工程師遍佈世界各地。當你身肩的責任和任務越多，自然越有更多機會與全世界的同事交流和執行專案。我個人曾經主持過跨三個時區的技術講座和訓練，不僅讓我實際應用專案管理的思維、訓練教學技能，更讓我進一步增加自己的能見度，並且實質提升團隊的技術職能，為團隊作出貢獻。

能進一步打開自己的視野並與全世界交流，是我個人最喜歡的部分。尤其身處 Dublin，多得是不同語言和背景的工程師，充滿了不同國家、語言、背景交流的機會，除了專注在技術上的交流，工作之餘也可以聊聊不同背景之間的特色和學習彼此的文化。

但如果人為在台灣的技術團隊，實際上可能因為時區的緣故，部分交流多少會有一些受限。但與世界各地的同事交流仍只是使用通訊軟體這種觸手可及的事情，壞處就是你可能要額外安排其他時間 (比如你必須要早起、晚上回訊息或參加會議)。

增強抗壓能力

我認為這份工作與一般軟體開發最大不同的是，由於面對的是客戶的生產環境，Cloud Support Engineer 不時會有面對高壓的情境，例如功能故障、應用程式不工作的事件、系統崩潰等等。有時候客戶甚至會不斷的催促你盡快給予資訊，在這種情況下，你需要學會保持冷靜和集中注意力，同時，不能因客戶的情緒引領你往不正確的調查方向。

我還記得第一次面對客戶環境故障時，我還得請求資深工程師一同指導解決客戶所遭遇的技術問題。但在從中觀摩學習後，並且檢討學習排查問題的方法不斷練習，慢慢將這種壓力視為對客戶的理解，學會用冷靜的態度處理棘手的狀況，正確的釐清和排除。可能有些人認為是缺點 (例如：客戶很難搞)，但實際在走過一遭後，一旦你跨過那個不舒服的過程，將成為無懈可擊且帶得走的軟實力，就看你是否願意視這些挑戰為成長的機會。

這樣的經驗和訓練不自覺在生活中產生一些幫助，尤其是面對系統故障或是一些非預期的狀況發生時，第一直覺反應是釐清問題並且如何找出解決問題的方式，而不是受情緒或環境影響不斷焦慮。

磨練跨團隊的溝通技巧

Cloud Support Engineer 與軟體開發不同的是，這是一個大量需要溝通的工作角色，並且將技術問題用淺顯易懂的方式與客戶分享相關的調查結果、提及可執行且理解的步驟供客戶採納 (不論是書信、Chat 或是電話形式)。由於面向的客戶端存在各式各樣的角色，你除了要學會用開發者能理解的方式解釋問題和解決方案，不免遇到客戶端主管級別的角色想釐清問題的相應狀況；同時，AWS 也會有不同面向的客戶端角色一同協助客戶的問題，身為技術工程師也讓我多了很多必須要學會與這些不同角色溝通的技能。

某種程度上學會站在他人角度、同理他人。在產品開發團隊前面，我會需要了解客戶遭遇的問題是什麼、如何複製、點出產品當前的問題、建議如何修正。除了要讓產品團隊理解當前問題要排查的方向，更需要對產品整體的核心運作有一定的認識，才能使用開發團隊所能理解的語言有效的將問題修正；在客戶前面，我需要了解客戶所遭遇的問題、客戶的痛點，並且提出可參考的實務建議，以幫助他們在業務上透過產品的功能和方法，滿足他們業務上所期待的目標，甚至有時候需要引導客戶改正問題以爲他們帶來長遠的效益 (因為有時候客戶有自己的想法並且多急於解決當下的短期問題)。

提升書信寫作能力

除了 Amazon 組織文化本身就具備寫文件的精神外，技術支持工程師會有大量的時間會投入在將複雜的問題調查報告轉譯成客戶或是產品團隊能理解的語言，並且寫出能夠讓客戶理解的書信內容。

一個 AWS Support Center 的通訊範例 (非技術相關)
一個 AWS Support Center 的通訊範例 (非技術相關)

各種曝光和成長的機會

AWS Support 除了是一個跨國組成的團隊外，AWS 本身就提供了一個能夠讓你成長和曝光的平台。

身處中文 DevOps/Container 領域的技術團隊，我特別喜歡的一點是週遭的同事都非常支持且互相幫忙，並且在自己的職涯規劃上都很積極，不會只侷限在日常協助客戶解決單一 Support Case 的問題上。

即使每天日常解決多少個 Support Case (Ticket) 很重要，但更多得是其他面向的工作幫助你成長不同面向的技能。由於 AWS Support 密切的與不同產業的客戶合作，一個顯著的例子是透過客戶端面向的教育訓練機會幫助你成長，為不同規模的企業客戶分享有關 AWS 產品的使用建議和最佳實踐。

此外，為了協助更多客戶解決技術問題，內部不時充斥各種專案和計畫。不論是藉由影片、技術文章或是教育訓練，團隊成員們都會透過不同的方式提升自己的技能。除了使中文的客戶受益，更多時候貢獻己力讓全球的客戶受益，並且在全球打開能見度。例如，以下都是我或是同事們貢獻的各種內容：

AWS Knowledge Center

更甚者，我厲害的同事們多是路見不平拿 Pull Request 來填，甚至會提交對應的修補程式，或開發對應的工具讓更多客戶從中受益，例如：

彈性的職涯規劃路徑

作為開啟 AWS 職涯的敲門磚，Cloud Support Engineer 著實是一個充滿學習廣度機會的工作，這也是我個人覺得這份工作十分有趣的地方，例如：

  • 處理客戶案例所累積對於 AWS 服務的技術知識和高可用架構設計思維、在客戶端大量的提供教育訓練或最佳實踐建議，轉職成為解決方案架構師 (Solution Architect)
  • 針對特定客戶所遭遇的問題提供協助而逐步轉職成為技術經理 (Technical Account Manager)
  • 協助客戶執行教育訓練或是訓練內部工程師，培養成為講者的能力 (Trainer)
  • 設計內部工具和相關專案計畫累積系統設計相關的開發技能 (Software Development Engineer)
  • 大量的書信寫作訓練和開源文件貢獻機會，轉職成為技術寫手 (Technical Writer)
  • 整合內部資源執行跨區域或是全球的計畫，逐步成為主管 (Operation Manager) 或是資深工程師

還算可接受的 Work-life balance

雖然每個人對於 Work-life balance 的定義不同 (就我的觀點，這是一種相對感受)，但比起很多公司的 IT Support 或是工程師職位，「相對來說」，AWS Cloud Support Engineer 可能不會是一個非常輕鬆的工作。

以目前團隊的工作型態，為了提供客戶 24 x 7 x 365 天不間斷的支持，除了意味著國定假日或是週末會是你的工作時間外，團隊成員彼此之間通常工作時間會有部分不重疊的輪班制度。

但之所以我認為這還算可接受，主要有以下幾點觀察：

  • (1) 在過去，在台灣的中文團隊值班時間需覆蓋整整 16 小時，直到晚上 11 點左右才轉移至北美時區 (這意味著當時有部分同事需要工作到晚上 11 點)。由於值晚班這件事情對很多人來說並不是一個很健康的工作型態，管理層也在台灣團隊成立不久後，不斷地尋求可能的解決方案。隨著歐洲團隊的建立，這樣的現象也趨於改善，使得台灣能從值晚班的噩夢中解放，將工作時間往前推移 (能下班的時間越來越早)。

  • (2) 即使 Cloud Support Engineer 同樣會有 Oncall 的機制，團隊的 Oncall 會以工作時間為主。由於是全球化的團隊，工作時間結束後的 Oncall 班次將會由其他時區輪值。

大部分情況下，新進人員在 Work-life balance 這件事情上面通常能有很好的控制。但隨著想做的事情越多，可能在你身上肩負的責任也越多，使得工作與生活上不見得能夠充分平衡。例如：我觀察到資深的工程師，有時候也得必須配合美洲時區在晚上時間 (21:00) 之後開會。但「相對來說」，比起傳聞有些 Amazon 的開發團隊需要半夜 Oncall 起床處理問題，確實種程度上是還可接受的 Work-life balance。

雖然難以置信，但在提供客戶 24 小時不間斷服務的背後，仍有 AWS 開發團隊需要負擔全天候的 Oncall 工作，不得不得在半夜時間起床。尤其你身為 AWS 技術支持工程師並具備一定資歷後，多少會接觸到客戶生產環境故障的問題，多的是把北美時區的開發者叫起床的機會。

作為曾經在半夜被叫醒的工作者，我個人十分認同半夜起床值 Oncall 是一個很不健康的工作型態。雖然團隊對於工作型態的設計不是我很喜歡的一點，但在方面團隊整體確實有在以緩慢的節奏進步。隨著加入的人才越多，整個團隊的工作安排會趨於理想值。

客戶無法區分清楚真正的問題緊急程度：客戶預期和實際環境的衝突導致工作時間碎片化

日常工作時間的碎片化是我個人很不喜歡的一點。要討論這點之前，需要先理解整體環境的影響佔這個問題的關鍵性因素。取決於市場型態不同，客戶的行為也會有所不同；對於中文的客戶，由於客戶習慣即時通訊方法和立刻響應速度，這往往造就了客戶使用技術支持服務時，產生很多非預期的行為。

即使在文件和產品頁面中明確定義了嚴重性的不同 2 3，客戶習慣仍傾向選擇最少的時間來開啟案例 (能選多短就選多短)，而非真正的問題嚴重性影響 (例如：客戶有一個專案趕著下週上線所以選擇最短的響應時間 15 分鐘，而非系統正在當機)：

在產品頁面明確定義的案例嚴重性
在產品頁面明確定義的案例嚴重性
在文件頁面明確定義的案例嚴重性
在文件頁面明確定義的案例嚴重性

即使明白客戶常常不正確的選擇案例嚴重性，AWS Support 仍提供客戶最大的決定權。然而，這樣的現象某種程度上確實也導致工程資源被濫用。這就好比家喻戶曉的伊索寓言「狼來了」中描述的故事，當假警報一多，除了使得團隊無法正確區分真正受到生產環境影響的故障，更嚴重的是由於工程師都被一堆非故障影響的問題佔用，使得團隊工程師無法很好平衡不同問題之間的嚴重性，即時協助真正有環境受損影響的故障。

這個現象所帶來的影響更使得中文技術團隊必須大量的應付客戶這種短而快的回覆，而往往喪失能夠專注在技術問題上的時間。我看過許多新進人員因此無所適從，迫使被拉去處理大量需要短時間回應的案例，而無法真正的在單一案例中投入太多充分的時間進行調查：一下忙 A 案例，一下被抽去做 B 案例，或是手邊正在忙碌的事情、正在開的會不得不中斷去協助客戶，導致工作時間的碎片化。如果間接犧牲的是客戶長遠的服務品質，我相信整個市場型態有很多有待改進的空間。

相對來說，日文客戶就慣用「一般指導」、「系統效能不佳/系統受損」等這類真正反應其事實狀況的案例嚴重性，進行問題指導和事件後的相關問題調查。這樣的市場型態讓我從日文團隊同事中間接受益，從他們每個人身上提供給客戶的回覆我學習到非常多。我常常可以觀察到他們提供給客戶的訊息都十分詳細且完整，在回覆前不僅做了非常多詳細的測試，更提出各種可參考的方案或是 PoC，甚至在內部已經討論過一圈 (但缺點是客戶需要有足夠的耐心)。

當然這並不是要比較哪種客戶比較好，畢竟，從親身體驗過印度客戶的型態，也覺得支持上充滿挑戰，就明白這並不是單一語系客戶的問題，每種客戶都有各自的特性。而是從實際經驗中，讓我對文化和市場差異有更深的體悟。

同時，團隊也在針對這項問題做了很多不同面向的嘗試，以試圖優化工程師在工作上的痛點，讓客戶學習如何更好且正確的使用 AWS 技術資源，以幫助他們解決真正重要的問題。

快速迭代的流程有時讓人無所適從

由於團隊快速成長且存在多時區的問題，為了適應不同問題的情境，流程的修訂和快速迭代有時往往讓人跟不上。例如：有時候今天建議的工作流程 A，可能明天會變成 A-1 版本，再過幾週可能變成 A-10。由於流程常因客戶需求和問題不斷迭代，有時候不見得能夠即時的在各區域中套用，或是特定區域根本是獨立的系統，有自己的一套系統運作。

除了「朝令夕改」大概是最適合用來形容團隊一些流程上的現況，很多時候團隊會不斷嘗試導入一些新的方法或是流程。我自己有時候都會覺得無所適從。必須要不時回去翻翻內部的文件，或是回到一些原則性的討論，以了解是否有任何理解錯誤。

雖然有時候感到混亂，但這種迭代的過程在團隊中會一直不斷的進行，你得學會適應快節奏和不斷變化的文化。

學會如何成為一名更好的客戶

最後，「學會如何成為一名更好的客戶」絕對是我任職客戶面向技術支持工程師角色這幾年收穫最大的體悟，絕對可以列為最重要的一點。由於日常工作中實際就是在做類似客戶服務性質的工作，工作中不免看盡客戶百態，了解不同客戶的型態，並且了解到什麼是好的、什麼是不好的。

身為一名技術支持工程師，隨著協助客戶經驗的累積，漸漸地學會如何站在客戶服務人員的角度思考，並且同理身為客戶服務角色的辛苦。

當你了解到客戶並未尊重專業時，那份挫折感絕對是深深擊潰你對於技術的自信。甚至很多時候即使你的建議正確，並且成功解決客戶問題後，客戶可能就只把你當做一名 AWS 的後台人員，也不見得會獲得客戶的肯定。

在開始工作的頭幾年我很不能理解，往往覺得在工作上付出了努力但仍得不到任何客戶的反饋；但轉頭一看，其實還是有非常多的客戶展現充分的專業並且在工作上有很好的合作體驗，更加學會心平氣和的理解不同性質的客戶。也因此學習到如何成為一名「好客戶」，更懂得如何在日常的生活中，向不同產業、工作的客戶服務人員展示尊重，可以是餐廳服務生、是銀行電話客戶服務人員，或是任何一種客戶面向的工作者。在我所處的團隊中，團隊成員也都不吝分享自己的經驗，並且分享如何針對不同客戶提供適當的處理方式，藉由這些經驗成長。

自從成為客戶服務角色後，能更同理不同行業類別的客服工作，更加重視第一線的服務人員背後所付出的辛勞。並且在未獲得預期的服務水平時，能提出實質的建議、想法而不是純抱怨。有趣的是，這樣做往往讓我獲得更為滿意的結果 (不是更快的退費效率或是獲得更多的補償)，一同促使產品和服務進步。

總結

在這篇內容中，深入探討了在 Amazon Web Services (AWS) 擔任 Cloud Support Engineer 的工作體驗，並分享了個人在過去五年中學到的寶貴技能和體驗。以上幾點完全屬於個人的觀察，不代表任何官方立場。

如果你正對 AWS Cloud Support Engineer 職位感興趣，希望以上的內容對您有所幫助，也可以透過參考其他系列文章以幫助你了解更多資訊。

看更多系列文章

References

  1. Discover what’s behind the Amazon ID badges ↩

  2. 比較 AWS Support 計畫 ↩

  3. 建立支援案例和案例管理 - 選擇嚴重性 ↩

Leave a comment

You May Also Have Interest

You may also enjoy