我在 Amazon 學到的 10 件事

Every day is day 1

今年 (2021) 是我加入 Amazon 這家公司的第三年 (把當 Intern 跟當兵的時間也算進去的話 XD)。在加入這個組織這短短 3 年中，我明顯感受到自己的成長與變化，畢竟 Amazon 也是存活了 20 幾年的公司，在全世界雇用了上百萬名員工，並且仍不斷在成長。在組織運作執行上確實是有非常不得了的一套，許多原因使得我仍願意與企業組織一同成長，以下列舉幾項我至今覺得很寶貴並且感知受用的幾件體會：

1. 快速解決問題比起使用什麼技術來得重要 (完美是更迭出來的)

在過去，我完全就是一個有技術潔癖的人 (比如我是一個 Python 開發者我就一定要用 Python 的 tool stack 完成我所有的工作)，我很執著在解決問題前思考需要使用什麼樣的技術，目的可能是考慮了：擴展、比較嚴謹、之後可能比較不會出問題、想趁機會學習新東西、可以變成一項話題 (比如可以發表或是展現技術應用等) …… 等等。

總之不管什麼原因，可能在處理一個問題時會審慎思考自己用的技術 (比如：需要爬一些網頁資料、整合一些資訊變成另一種形式的操作模型 (比如輸出成報表、戳自己的 webhook 發通知)、設計應用跑運算)，或是基於完美主義覺得一定要所有事情一氣呵成。

拿爬網頁資料來說，我可能要：

• 構建 Python 應用程式
• 查一下需要的套件跟操作方法，比如 requests
• 跑 pip install 安裝需要的套件
• 測試 Python 應用程式是否能正確運作
• Debug 再回去修改應用到爽

這還只是拿 Python 當範例，事實是可能來來回回都花了兩個小時，包含編譯打包做了一大堆工作，但是真正要解決的問題才有可能被解決。

但是在隨著這樣的處理模型下，我發現人們更在乎的是「解決問題」，而不是你使用了什麼樣的技術。客戶的需求跟問題只會每天地不斷地在變化，對於小問題，人們更注重於能否在有效的時間內解決問題。

所以現在，在工作上我可能傾向於使用 Linux 命令加上 Shell script 就可以完成我想做的大部分工作，可能只耗費我 30 分鐘做一個版本，只是步驟會被拆解成：

• 拿 curl 把 html 資料爬回來
• grep 一下！可能在用個正規表達式過濾一下我想要的訊息
• 把結果貼到 Sublime / 文字編輯器在處理下篩選我要的內容
• 需要重複這個操作，Shell Script 寫個幾行就搞定

亦或者是我想要定期爬 facebook 上的資料，如果是用原生語言硬幹，我可能會：

• 構建 Python 應用程式
• 查一下需要的套件跟操作方法，比如 requests
• 跑 pip install 安裝需要的套件
• 模擬使用者登入並且處理 facebook 上的驗證操作
• 測試 Python 應用程式是否能正確運作
• 登入之後在爬爬感興趣的 HTML 資料進行字串處理
• 測試 Python 應用程式是否能正確運作
• 將有興趣的資料進行下一步處理 (比如觸發 Webhook)
• Debug 再回去修改應用到爽

然而我只要在我的執行環境中使用 Greasemonky，並且跑一台 VM 開著瀏覽器，完全可以做到上述的工作：

• 安裝 Greasemonky
• 寫一寫 Javascript 把 DOM 跟感興趣的內容撈出來 (完全不用搞驗證)
• Greasemonky 可以操作跨站存取 (CORS)，所以我可以把撈出來的資料吐到其他地方或是觸發 Webhook
• 在 Greasemonky 腳本裡面插一點檢查機制，發現資料撈不出來可以發個通知手動檢查下

雖然問題拆了幾個部分，並且不是那麼漂亮 (沒有一氣呵成的感覺)，但是，整體開發跟配置相對簡化非常多工作。

如果只是一些小規模或是立即性的需求，這種工作模型卻足以滿足大部分的工作。而且會發現，其實人們對於使用組合技 (特別是對於技術人員來說)，普遍接受程度並沒有自己想像中的低 (因為畢竟大家都只專注在解決問題)。

一旦真的出現規模需要或是下一步更進階的使用需求後，再來設計原生語言的套件也不是一件特別困難的事情。此外，我發現這種模型間接幫助你驗證整體的業務邏輯，再改用原生語言進行實作，其實在開發上像是有了一個規格，也相對「清楚要做什麼」，並且容易許多。

2. 這個世界變化的比你想像中的快 (… and, it’s always day 1)

Amazon 提供的雲端服務 (Amazon Web Services) 提供上百種不同的服務及解決方案，這其中都是上上下下數千個團隊跟不同部門合作下一起構建 (而且是不同跨時區下協同，幾乎整整 24 小時都有人在進行)。

常常過幾個星期就又有團隊迸出新的功能或是服務要上線、一覺醒來又有新的變革，亦或是在你還沒準備好了解這項變動之前，已經有客戶想知道這些釋出的功能的具體細節 (我從沒有跟上客戶的腳步過)。

在還沒加入這樣規模的組織前，我其實無法想像這個世界是多麽積極的在變化，尤其在台灣這樣的小島，每天媒體告訴你、周圍朋友在 Instagram / facebook 告知發生的事情，其實都大同小異，圈圈內流通的資訊更迭的速度其實並沒有那麼快，大家都很被動的感受自己接收的資訊。

但在跨時區分工合作的運作下，你必須習慣睡覺醒來一切又有變化的事實，並且是超級快速，每一天都像是第一天 (Day 1)。這迫使你會需要練習快速學習的能力以適應這個世界的更迭，不斷主動更新自己的知識跟技能。

3. 學習必須有效並深入核心而不是只停留於表面 (Dive Deep)

在 Amazon 提及的 14 條 Leadeship Principles，有一個我感知最深的項目就是 Dive Deep (追根究底)。

我在面試很多候選人後，我發現很多科技圈的人才都有一個普遍的慣性，就是對於新技術或是知識的理解都停留於 Surface Level (表面)，即使是自己熟悉的技術或能力也是。很多人往往對於接受一個知識或技術的理解都停留於表面就感到已經完全理解，但在我的工作中，往往是面對未知甚至是很多應用的 Bug，並且找到一個適當的解決方案。如果保持這樣的思考慣性，很容易導致在遇到問題時無法切入並解決核心問題。

以大家很常說自己會的 Kubernetes 舉例來說，通常問以下問題 95% 的候選人都回答不出來：

為什麼 Kubernetes 在同一個 Pod 中，不同的容器可以使用 localhost 彼此訪問？

你通常就是看書上說說知道 Pod 是什麼，並且會說是一個 Kubernetes 特有的元件。但往往就是這麼一個簡單的問題 (網路上也一堆解答)，讓我發現很多人對於接受一項知識的理解往往停留在：文件如此寫、會操作 kubectl 命令並且部署、看範例就是如此、Kubernetes 直接劃分一個可共用的網路環境 (然後就無限鬼打牆 … 例如：它就是一個抽象元件 等答案)。

但如果你真的試著想要進一步了解其底層運作原理，你會發現其實 Pod 並不是什麼特別的東西，網路的共用特性與 Docker 相同技術定義的 Network sandbox / ECS 定義的 Task 相似，這使得其可以使用 localhost，並且都基於 Linux Kernel 提供的功能執行類似虛擬化的操作。一旦你試著對知識刨根究柢，這在處理有關 Pod 網路相關的問題時，才會有更清楚的脈絡知道要往哪個層級剖析 (是容器？系統？還是外部網路？)。

當然我也不是一開始就如此，而是在經歷過各種亙古難題，並且每天都得想辦法解決未知問題的環境訓練下而養成。也因為如此，我更重視自己在接受知識時，必須以更深層次思考的習慣，並與現有理解嘗試融會貫通，並不斷反思自己現有的知識跟理解是否正確及深入。

這個 Dive Deep 也不是指要你鑽牛角尖，而是了解以更實際及應用的層次，逆推回去學習並引導自己往更核心的底層近一步理解。正是意識到這樣的能力培養在日常工作中的必要性，我仍不斷學習並強化自己的知識理解，進一步培養自己對於問題切入剖析核心的技巧，幫助我解決所遭遇未知的問題。

這樣的原則我感受到不同領域上如此應用，通常能引導自己能提出更深層次的解答、或是嘗試在挖掘更多具體我所需要的資訊，並且有效的行動。

4. 不必太執著於工作，但工作起來必須很執著

Amazon 有一句膾炙人口的標語：

Work hard, Have fun, Make history

看到這裡你覺得 Amazon 就是一家非常 Work hard 的血汗工廠 (加上一堆新聞都說 Amazon 很血汗)。但事實是 Amazon 並不希望自己的員工 Overtime 加班，並且盡可能優化不同團隊之間工作效率。

因此，在內部我們不斷的每天都在想著如何改善產品、改善服務、改善所有不太 OK 的事情，並且專注這些目標，努力在工作崗位上做出一些改變，而不是滿足於現狀，這是我們所謂的 Work hard。

在這裡，老闆會耳提面命希望你不要一直加班，並且要求你必須注重自己的私人時間及生活，否則很快就燃燒殆盡 (Burnout)，領導階層也會時時刻刻了解是不是有任何工作負載過於集中的問題 (有點類似避免單點故障的概念 / Single point failure)。

透過維運的角度盡可能幫忙你找到對應的 backup (換句話說，在身處周遭都是優秀的同事，其實你總能被取代，無需在自己的私人時間太執著於工作，並且需要相信你的隊友)。

當然，該認真工作時絕對是很可怕的。在工作上，除了會有各式的績效及 KPI 你會需要想辦法滿足 (其實並不是特別困難)。但更重要的是，因為身邊的同事都十分優秀，你必須很認真的思考自己的職涯規劃並設定目標，想辦法讓自己成長、努力工作改善現有的問題及自我，並把自己跳出舒適圈往更高的階段推，而非滿於現狀，否則很快面臨瓶頸。如果你是一個很樂於學習及成長的心態，在這個組織下工作是十分有趣的。(反之，你可能待不到幾個月就想走了 XD)

在這裡，大家不是搏感情比誰更努力工作加班，而是比誰能更有效率的完成事情。

5. 在必要的地方花錢不手軟，而不是無限度擴張福利

(我的解讀為：錢要花在刀口上)

在 Amazon 工作，你真的會覺得很「摳」，你會發現組織對於「免費午餐」、「員工旅遊」這類的事情錙銖必較。在過年過節也不會有所謂的三節獎金、上班提供按摩之類的服務 ….。當初 Package 跟你談好多少就是多少，而且不多也不少 (在 Leadeship Principles 有一條 Frugality，完全就是體現這項原則)。

但是相對的，若是對員工生產力、有助於客戶的事情，花錢絕對不手軟，例如：

• 需要擴充硬體設備進行開發
• 員工手機帳單可以報帳以提供在工作上穩定的網路服務
• 需要跨國出差，只要不是亂花錢，都願意全部包機票住宿及食宿給你飛過去 (我有幾次來回美洲幾星期，光一趟就報帳報掉快 7000 USD，折合約 10 - 20 幾萬台幣….)

並且在教育資源及訓練上投入大量的資源，十分專注幫助員工成長。目的都是為了提供給予客戶更好的服務及產品、解決方案。

有時候大家選擇工作可能優先都以公司提供什麼樣的福利及薪資為考量，這並沒有什麼問題，但最怕的是往往沒有意識到談來的薪水可能是一攤死水。然而，Amazon 招聘最為厲害的地方在於，其在吸引人才的招聘政策永遠不是用薪資及福利作為主要的手段 (當然薪水我相信在市場上也是很有競爭力的，但比起其他頂尖的外商我相信有更誇張的數字)，其更重視的是候選人願意用成長的角度加入這家公司，並且積極冒險及試驗，你會更感受到你跟公司的關係更像是合作夥伴，並且珍惜你手中握有的股票，這正是 Amazon 持續十幾年來一直在做的事情，致使你會願意參與這家公司的成長 (然後看著它市值一直一路往上，像是看著自己的孩子長大一樣)。

6. 做出初始版本跟寫好一頁的文件比起做好投影片重要

在 Amazon，我們很少做投影片，你會發現公司上上下下沒有人在專注弄絢麗的投影片樣板 (除非是給外部客戶看的，不然通常都單調並且樸實無華)。大家反而更專注把自己的 Document (文件) 寫好，如果你要說服你的老闆、提交升職、提出一個計畫或改進，在這裡做簡報並把一切描繪(吹噓)的多美好，是不太會有人理你的。

文件一般來說，通常會是 1 頁 (內容不超出一頁)，至多也不會超過 6 頁。在文件的內容上，都明確寫下了具體的 data point (需要有事實的資料陳述) 還有你的計畫、或是績效，因此，寫好一份文件比設計投影片更來得困難。因為 …. 你會發現做了一堆事結果可能在文件上只有一兩行字 ……

構建美好幻想不如實際做出一個初始版本，並且收集到相應的資料 (就算沒有初始資料也必須擁有相應的資料點幫助陳述你的計畫說服其他人)，並且讓他人閱讀你的文件後進行評論。在接受這樣的工作模式幾年後，我也覺得這種方式是一個很有效率的操作，由於你會需要累積足夠的 data points 置入，會更清楚知道自己的目標跟預期計劃是什麼，而不是埋著頭一直做，再讓老闆憑感覺同意你說的。

在我的團隊，大家分享內容後，比較常聽到的是「我把今天提到的內容、相關的資訊也整理成 wiki 跟文件 (或錄影，可以使用 1.5x 倍觀看)，有問題可以再讓我知道」而不是「簡報我已經分享在 …，有需要可以自己去下載」

7. 能不開會就不開會，要開也盡可能開得快

在 Amazon，員工每天都會匿名接受調查對於管理層的相應執行績效 (我們每天都會為管理層執行評分)，其中很常問的類似問題就是 The meeting I've is ... ? (類似可回答的答案: effective / non effective) 或像是 my workload is manageable? 這類的問題。

你可以注意到 Amazon 一直在嘗試減少不必要會議的數量，並且盡可能幫助員工有效地執行工作，包含我所在的團隊，通常只有 team meeting 為慣例會議，並且主管也是快速用幾分鐘講講近期的更新或變動就直接進 Round table (讓團隊成員看看有沒有問題需要提出來的)，一週平均會議時間都低於 2 小時，在其他地區有的團隊也是實行 Stand-up meeting (站著開會，所以開太久會站很酸)，可見大家真的很不愛會議。

即使 Manager 召集的會議，但若有其他重要事項在處理，如果沒什麼特別的事項，是有權拒絕參加的，並且由他人幫忙轉達 (而且通常大家都偏好能不開會就不開會，這點管理層或是上上下下的團隊大部分都很有共識)。通常會議的目的就是進行決議，或是傳遞必要訊息，工作上也會統計每週花在 meeting 上的時間，如果太多，你可能會需要審慎思考是不是真的有必要開這些會。

其他例子像是：所有 interviewer 面到後面投票決定不錄取一位面試者，HR 事先也已經透過意見調查收集大家的共識，會議就會直接取消，而無需裝忙開會。

8. 搞懂 Priority (優先順序) 跟重要性比起做一堆 KPI 來得重要

(如果不是很重要，能不做就不做，而不是一昧瞎忙)

在上萬人的組織中工作，你會發現每天要做的事情真的是很多，且每天收到的 Email 就像雪花般的飄進來。由於每個人都很忙，每個團隊都有自己的問題需要解決，有時候你做了一堆 KPI 跟數字，卻到頭來發現並不能長遠解決團隊所遭遇的問題，以及契合目前公司營運的發展目標。這體現了正確工作的重要性，因此每次在新的季度，領導階層一定會告訴大家 KPI 跟目標是什麼。

在每天被塞爆的工作中，你需要時時刻刻檢視自己正在做的事情是不是真的有必要，並且是完成重要的工作。在這裡達到 KPI 是應該的，並沒有什麼特別。

大家反而會不斷提出的問題是：「這真的是我們需要做的嗎？真的是重要的嗎？長遠來看對團隊是有幫助並能改善問題的嗎？」

因此，正確的配置任務的優先順序，並且有效平衡你的時間運用。正確滿足 KPI 需求之外，同時需要契合你的成長目標更顯重要；而不是一昧地瞎忙，或是出於人情幫忙做了一堆事情 (搞得自己表面很忙)，卻不符合團隊的營運目標。

9. 在很重要的事情十分快速，在不重要的事情無限拖延

Amazon 真的是道道地地的美國企業。你完全可以在這裡感受到外國人做事的效率 (在有些事情上真的是超 …. 級 …. 慢 ….)。像是我曾經為了在 AWS 官方部落格發佈一篇文章，整整花了半年 (其實也就 2 個季度、6 個月，我已經見識過擺至少 1-2 年的待辦事項，仍懷著感恩的心)。

像是在台灣你訂個包裹可能等個 3 天就快受不了了，但自從我在 Amazon 工作後，有些卡在其他團隊的事情，如同前面提到的，每個團隊都很忙。如果不是那麼緊急的事情，我在幾天至一個星期內得到回覆，真的是說不出的感激，並且覺得很快。在這樣的環境下，完全顛覆我過去的時間觀念，並且練就一身好耐性。

在這裡，大家會對重要的事情十分快速，並且立刻做出相應的行動 (例如發現有 Bug 需要 Roll back 以解決一個非常嚴重的影響)。但如果優先順序並不是那麼急迫，或是影響並不是那麼大，那你得預期可能會是一場持久戰，甚至很可能並不會被解決，並且需要抱持著不斷騷擾人的心理準備。如果想加快，你必須用 data point (數據) 說服其他團隊為你做事，而不是只因為你想或是你職位比較大。

事實上，我認識很多國外的同事們並不愛加班、到晚餐時間一堆商店都關門，但這樣做出來他們的工作結果並不差。反過來真的會思考亞洲人拼命的文化到底是在拼什麼 (大陸的 996 工作制度真的有比較好？)，太執著於細節或是一些小事情，似乎並沒有帶來更大的效益，也許這也是值得你我學習的工作模式。

10. 永遠思考對客戶是否有幫助及符合長遠的目標，而不是只因短期利益選擇做事

在我的工作中，時常會在不同的解決方案中建議客戶選擇合適的項目。若是一般的商業利益考量，大部分會為了短期績效及利益，可能建議客戶使用不見得適合他們且昂貴的方案。當然，這確實有助於增加年度營收。然而，這並不符合 Amazon 追求對於客戶服務的目標。在這裡，我們會想著如何幫客戶省錢 (例如: Amazon EKS 折 50% 的定價、AWS Fargate 降價)，並且思考如何提供更好的服務及產品反饋給客戶，與客戶建立信賴關係。同時，為其帶來長遠的收益 (AWS 幾乎用了整整 10 年創新，並由虧轉盈)。即使可能短期效果並不是立即的反應，但這一直是 Amazon 做事的風格。

總結

最後讓我用 VP - James Hamilton (同時也是分散式系統的專家) 在 2016 年發表的文章進行總結，與你分享我在這幾年切身感受的體會：

As a member of the AWS engineering team, my first impressions are probably best summarized as fast. Decisions are made quickly. New ideas end up in code and available to customers at a speed that just makes the pace of enterprise IT look like continental drift. In a previous role, I remember (half) jokingly saying “we ship twice a decade whether customers need it or not.” Now new features are going out so frequently they are often hard to track.

作為AWS工程技術團隊的一員，新環境給我留下的第一印象就是一個“快”字-決策制定流程非常迅速，新思路能夠很快以代碼形式推出，並立即被交付至客戶手中 。這一切都讓傳統企業IT的響應速度看起來像是大陸板塊漂移。我記得自己曾經半開玩笑地回憶過往角色稱呼：“我們在十年中只發布了兩次客戶可能需要，也可能不需要 的更新。”現在新功能正以驚人的頻率推出，我們甚至很難追踪其推進節奏。

Another interesting aspect of AWS is how product or engineering debates are handled. These arguments come up frequently and are as actively debated at AWS as at any company. These decisions might even be argued with more fervor and conviction at AWS but its data that closes the debates and decisions are made remarkably quickly. At AWS instead of having a “strategy” and convincing customers that is what they really need, we deliver features we find useful ourselves and we invest quickly in services that customers adopt broadly. Good services become great services fast.

AWS的另一種有趣的特質在於對產品和工程技術相關的處理方式。各種爭議會不斷出現，而且AWS內部的辯論之聲要遠遠超過任何其他企業。這些決策的流程讓我可以選擇， AWS除了擁有卓越的數據處理能力外，也能夠快速中止逐步並存並採取出征性意見。在AWS中，我們不再自以為是地制定“戰略”並強行說服客戶認同其適用性，而又推出了適合自身業務環境 的方案，並通過面向服務的快速投入幫助更多客戶快速享受至由其帶來的便利。如此一來，優秀的服務能夠快速取代為卓越的服務。

(source: A Decade of Innovation / 中文: AWS的十年创新之路)

看更多系列文章

• 我在 Amazon 學到的 10 件事
• 我是如何在還沒畢業就錄取並進入到 Amazon 工作
• 我是如何在一年內通過 AWS 五大核心認證
• Amazon Cloud Support Engineer 到底是在做什麼 (Amazon Web Services / AWS)
• 關於 Cloud Support Engineer 職位的常見問題 (Amazon Web Services / AWS) - AWS Cloud Support Engineer FAQs
• 在 AWS Cloud Support Engineer 面試中脫穎而出：必備的技術能力和重要特質
• 身處 Amazon 工作 5 年學到的事：在 AWS 擔任 Cloud Support Engineer 是什麼樣的體驗