微軟 on 澳洲雲端架構師 EC

文組轉職澳洲科技大廠工程師—我的科技業職涯的反思

Fri, 12 Apr 2024 00:00:00 +0000

Photo by Christopher Sardegna on Unsplash

分享我從文組轉職科技業工程師後，在科技大廠 Amazon、微軟，以及大型石油公司 Shell 三個不同技術職位的任職經驗中獲得的技能與經驗分享。進一步分析我認為要轉職成功需要具備哪些要素。

前言

作為一名從文組背景轉職到科技業的工程師，我在過去幾年中有幸在三個不同規模和性質的公司工作：科技大廠 Amazon、微軟 (Microsoft)，以及大型石油公司 Shell。每一段經歷都帶給我不同的技能和視野，也讓我對科技業職涯有了更深入的理解。

在這篇文章中，我想分享這些寶貴的工作經驗，包括在不同公司文化中的學習成長，以及我認為轉職成功需要具備的關鍵要素。希望能為正在考慮轉職或剛踏入科技業的朋友們提供一些實用的參考。

我的科技業職涯歷程

Amazon：我的第一步

在 Amazon，我學會了如何在快節奏的環境中工作。Amazon 的文化強調客戶至上和創新思維，這讓我快速適應了科技業的工作模式。在這裡，我：

學會了敏捷開發方法 (Agile Development)
培養了數據驅動的決策思維
體驗了高效能團隊的協作模式
接觸到了雲端技術和大規模系統架構

Microsoft：深化技術能力

在微軟的工作經驗讓我更深入地了解企業級軟體開發。微軟重視技術深度和產品品質，這段經歷幫助我：

強化了軟體工程的基礎知識
學習了企業級應用程式的設計模式
參與了開源專案的貢獻
培養了跨文化團隊合作的能力

Shell：跨領域的挑戰

在石油公司 Shell 工作是一個有趣的跨領域體驗。作為一家傳統能源公司，Shell 正在積極進行數位轉型：

將科技應用於傳統產業的機會
學習了能源產業的專業知識
參與了數位轉型專案
體驗了大型企業的組織運作

轉職成功的關鍵要素

根據我的經驗，我認為成功轉職到科技業需要具備以下幾個關鍵要素：

1. 持續學習的心態

科技業變化快速，新技術層出不穷。保持學習熱忱和適應能力是非常重要的。我建議：

定期更新技術知識
參與線上課程和工作坊
關注產業趨勢和技術發展
建立個人學習計畫

2. 實務經驗的累積

理論知識固然重要，但實務經驗更是不可或缺。建議透過以下方式累積經驗：

參與開源專案
建立個人專案作品集
尋找實習或兼職機會
參加程式設計競賽或黑客松

3. 軟實力的發展

除了技術能力，軟實力同樣重要：

溝通能力：能清楚表達技術概念給非技術背景的同事
團隊合作：在跨功能團隊中有效協作
問題解決：面對挑戰時能系統性地分析和解決問題
時間管理：在多重任務間有效分配時間和資源

4. 網絡建立

在科技業建立專業網絡是非常有價值的：

澳洲面試心得：微軟 Industry Solution Engineering — Software Engineer

Fri, 13 Oct 2023 00:00:00 +0000

澳洲微軟 Industry Solution Engineering — Software Engineer 面試經驗分享

Photo by Jon Tyson on Unsplash

如果有在追蹤我的朋友，看到這篇文章一定會覺得很奇怪「EC 你不是今年八月才從微軟離職嗎? 怎麼又會去微軟面試 software engineer 這個職位?」

前情提要

這件事真是說來話長！大約七月時，我在微軟內部申請了一個 software engineer 的工作，甚至還私下傳訊息聯繫 hiring manager，但完全沒有收到任何回覆、申請系統上也沒有任何進展，後來我確定自己真的不喜歡 Cloud Solution Architect (CSA) 這個職位，又收到了能源公司的 DevOps Engineer 的 offer，於是我就辭職離開微軟啦～

沒想到在九月中，我突然收到一封來自微軟 recruiter 的信，大意是「EC 你好～我們現在準備處理你的申請了，但是我們發現你已經離開微軟了，這個職缺其實也關閉了，想請問你對於這個職缺還有興趣嗎？如果有的話，我們可以重新開一個職缺讓你申請。」

雖然我非常滿意自己現在的工作，絲毫沒有考慮回到微軟，但基於我對於 Industry Solution Engineering (ISE) 這個部門的好奇心，我還是答應了 recruiter 的要求 (其實在看到這個職缺前，我從來不知道有這個部門存在XD)。

收到申請後，Recruiter 迅速地幫我安排了三關面試。這點跟我第一次面試微軟的經驗非常不一樣，當初的我只有確定前一關面試通過後才會開始安排下一關的面試時間。

Recruiter 也說我的身份其實有點特殊，因為我申請的時候其實是內部員工，其實只要面試兩關即可，但因為我現在是外部申請人了，所以還是要面試三關。當時的我沒有多想 (畢竟也沒有真的想要回去)，所以也沒有爭取要豁免第三關。

Industry Solution Engineering (ISE) 部門簡介

在 YouTube 上其實有相關介紹，雖然影片中寫的是 Commercial Solution Engineering (CSE)，但這應該只是改名前的 ISE，有興趣的人可以看一下介紹影片。

Introducing Commercial Software Engineering

微軟雲端架構師 (Azure Cloud Solution Architect) 入職九個月的反思：那些職務想像與現實的差距

Fri, 28 Jul 2023 00:00:00 +0000

微軟雲端架構師 (Azure Cloud Solution Architect) 入職九個月的反思：那些職務想像與現實的差距

Photo by Yeshi Kangrang on Unsplash

這是我在 2023 年寫的文章，寫完這篇後不久我就毅然決然從微軟離職了XD 現在我決定免費公開這篇文章，算是跟大家分享一下我當時的心路轉折～

前言

每一個選擇，背後都有它的犧牲以及需要承擔的後果 (comprises and consequences)。這段時間我不斷在思考，如果離開微軟的話，我會失去什麼?

但我突然發現，我好像還沒認真思考過，我在微軟的這段時間裡，得到了什麼? 有哪些是跟我當初的預期不同的地方? 如果最後決定繼續留下來的話，什麼是我在微軟的未竟之志呢? 所以這就是我今天想要跟你們分享的主題～

我在微軟獲得了什麼

回頭一看，其實當初我想達成的事都達成了，簡單的心路歷程請參考下面這篇 < <從 AWS (Amazon Web Services) 到微軟 Azure：為什麼我決定跳槽到另一朵雲？»

從 AWS (Amazon Web Services) 到微軟 Azure：為什麼我決定跳槽到另一朵雲？
_AWS 是雲端服務的龍頭，也是市佔率最高的供應商，但在工作兩年後，我還是選擇離開，轉而加入微軟。這篇文章記錄我從亞馬遜離職的心路歷程，以及進入微軟後所面對的轉變與挑戰。希望能帶給正在思考職涯方向的你一些參考。

雖然過程很辛苦也很挫折，但我學到了比預期的更多。

1. 體驗了 Solution Architect 這個職位

結果發現我其實也沒有這麼喜歡這個工作的實際工作內容XD

但不得不說這個職位聽起來很高級，到底是哪個聰明人取的職稱哈哈

2. 職等成功升級

從在 Amazon 的 Associate/Graduate level，現在這個職位已經是 Mid-Level。

但是古人說的好「少年得志大不幸」，古人誠不欺我！沒有相對應的實力與經驗，就爬到這個在 IT 界來說通常是擁有 10–20 年業界經驗的人才能做的職位，其實也不是一件好事。最近看到一句話「You can’t skip experience by working hard. (沒有辦法單純靠努力來取代經驗) 」，讓我深有感觸。

微軟雲端架構師 (Solution Architect) 職位解析 1：Org Chart

Fri, 28 Jul 2023 00:00:00 +0000

Photo by Smartworks Coworking on Unsplash

前言

跟讀者們或是朋友們聊天時，他們對我提出的第一個問題總是「所以雲端架構師 (Solution Architect) 到底是在做什麼?」但我每次解釋後，大家看起來還是一知半解。所以我決定用近期在工作上遇到的實際案例，來描述一下雲端架構師的日常工作內容，希望可以增進大家對於這個職位的了解。

這個系列預計會有五篇文章，以雲端架構師在日常工作中最主要的任務為例 :

Org Chart » 你正在閱讀的文章
Solution Architecting
Technical Guidance/Customer Meetings
Technical Presentation/Workshops
Sales Pipeline Management

我希望大家在看完這個系列之後，可以留言告訴我:

如果你不是微軟雲端架構師 (Azure Cloud Solution Architect)，你覺得這個職位符合你對於技術職位 (technical role) 的想像嗎?
如果你是微軟雲端架構師 (對，我最近發現有同事會看我的部落格! 太可怕了QAQ)，你覺得我對於 CSA 的工作描述還算客觀嗎?

當然，總是要先放一下免責聲明XD

這個系列完全是以我個人在澳洲微軟工作的親身經歷作為出發點，所以是我個人的主觀感受。雖然我敘述時會盡可能客觀呈現，讓各位讀者自行判斷。如果你在不同國家的微軟工作，甚至是你在不同的微軟團隊，你對於這個職位的感受可能會跟我略有出入或完全不同。

核心組織架構：ATU、STU、CSU

開始這個系列前，為了讓大家更了解架構師這個職位的背景，先來簡單講一下微軟目前的組織架構圖(PS: 這個東西每年都在改，所以我現在是以 FY24 的配置來講，上一個財政年 FY23 是沒有 Technical Specialist 的。)

雲端架構師 (Cloud Solution Architect) 隸屬於 CSU (Customer Success Unit)，基本上分為三個領域: Core/Infrastructure、Application Innovation、Data & AI。CSA 跟 Specialist「通常來說」是一對一的關係，也就是說 Specialist 有哪些客戶 (accounts)，CSA 負責的就是那些客戶。

微軟的銷售階段分為五個階段(我不能講太細，怕洩漏公司機密XD)，但簡單來說:

微軟雲端架構師 (Solution Architect) 職位解析 2：Solution Architecting

Fri, 28 Jul 2023 00:00:00 +0000

Photo by Daniel McCullough on Unsplash

前言

這篇文章是 «微軟雲端架構師 (Solution Architect) 職位解析» 系列的第二集。

這個系列預計會有五篇文章，以雲端架構師在日常工作中最主要的任務為例 :

《微軟雲端架構師 (Solution Architect) 職位解析 1：Org Chart》
Solution Architecting » 你正在閱讀的文章
Technical Guidance/Customer Meetings
Technical Presentation/Workshops
Sales Pipeline Management

我希望大家在看完這個系列之後，可以留言告訴我:

如果你不是微軟雲端架構師 (Azure Cloud Solution Architect)，你覺得這個職位符合你對於技術職位 (technical role) 的想像嗎?
如果你是微軟雲端架構師 (對，我最近發現有同事會看我的部落格! 太可怕了QAQ)，你覺得我對於 CSA 的工作描述還算客觀嗎?

當然，總是要先放一下免責聲明XD

其實我發現寫這篇之前應該要來寫一篇解釋「到底什麼是雲」文章，但我最近真心忙到昏天黑地哈哈哈！所以繼續列入待寫清單，這個清單目前已經越來越長囧

第二集會是這個系列中最技術性的一篇，如果覺得太多技術概念看不懂，我建議可以直接等待第三集跟第四集，因為這兩集會有趣許多，請不要因此放棄這個系列XDDD

讓我們就以經典的案例 3-tier web app migration 來說吧！

如果你對於 3-tier web app 沒有概念，這件事是這樣的。一般來說 web applications 的基本概念會分為三層：

Presentation Tier ：這一層簡單來說就是使用者看得到、摸得到的那層。可以再細分成 web clients (使用者用來打開 app 的電腦或手機) 跟 web servers (企業用來呈現靜態內容或是動態內容的伺服器)。
Logic Tier ：這一層就是廣義的後端 (backend)，是用來運行企業商業邏輯的 application servers。
Data Tier ：這一層就是廣義的資料庫 (databases)。

微軟雲端架構師 (Solution Architect) 職位解析 3：Technical Guidance/Customer Meetings

Fri, 28 Jul 2023 00:00:00 +0000

Photo by Austin Distel on Unsplash

前言

這篇文章是 «微軟雲端架構師 (Solution Architect) 職位解析» 系列的第三集。這個系列預計會有五篇文章，以雲端架構師在日常工作中最主要的任務為例 :

《微軟雲端架構師 (Solution Architect) 職位解析 1：Org Chart》
《微軟雲端架構師 (Solution Architect) 職位解析 2：Solution Architecting》
Technical Guidance/Customer Meetings » 你正在閱讀的文章
Technical Presentation/Workshops
Sales Pipeline Management

我希望大家在看完這個系列之後，可以留言告訴我:

如果你不是微軟雲端架構師 (Azure Cloud Solution Architect)，你覺得這個職位符合你對於技術職位 (technical role) 的想像嗎?
如果你是微軟雲端架構師 (對，我最近發現有同事會看我的部落格! 太可怕了QAQ)，你覺得我對於 CSA 的工作描述還算客觀嗎?

當然，總是要先放一下免責聲明XD

以下我會以時間線作為小標題，讓大家一同來體驗雲端架構師平常是如何跟客戶開會並提供技術指導。

週三早上: 收到客戶 CTO 來信，希望我可以跟客戶內部的 Domain Architect 聊一下DSC

客戶的信大概是以下這樣的:

Hi EC,

Hope you are well.

I'm just wondering if you can spend some time talking about DSC with xxx?

微軟雲端架構師 (Solution Architect) 職位解析 4：Technical Presentation/Workshops

Fri, 28 Jul 2023 00:00:00 +0000

Photo by airfocus on Unsplash

前言

這篇文章是 «微軟雲端架構師 (Solution Architect) 職位解析» 系列的第四集。這個系列預計會有五篇文章，以雲端架構師在日常工作中最主要的任務為例 :

《微軟雲端架構師 (Solution Architect) 職位解析 1：Org Chart》
《微軟雲端架構師 (Solution Architect) 職位解析 2：Solution Architecting》
《微軟雲端架構師 (Solution Architect) 職位解析 3：Technical Guidance/Customer Meetings》
Technical Presentation/Workshops » 你正在閱讀的文章
Sales Pipeline Management

我希望大家在看完這個系列之後，可以留言告訴我:

如果你不是微軟雲端架構師 (Azure Cloud Solution Architect)，你覺得這個職位符合你對於技術職位 (technical role) 的想像嗎?
如果你是微軟雲端架構師 (對，我最近發現有同事會看我的部落格! 太可怕了QAQ)，你覺得我對於 CSA 的工作描述還算客觀嗎?

當然，總是要先放一下免責聲明XD

這個系列完全是以我個人在澳洲微軟工作的親身經歷作為出發點，所以是我個人的主觀感受。雖然我敘述時會盡可能客觀呈現，讓各位讀者自行判斷。如果你在不同國家的微軟工作，甚至是你在不同的微軟團隊，你對於這個職位的感受可能會跟我略有出入或完全不同。這次依然會以時間軸的推進作為小標，讓大家身入其境地體驗微軟架構師的生活XD

在架構師的日常中，我們也常常會應客戶或是內部同事的要求，針對某個主題或是特定的 Azure Services 來進行 technical presentation 或是 workshop。

前情提要

這個 workshop 光是要跟客戶喬定日期，就已經談了好幾個月，我看了一下我個人的筆記，我們從今年一月就已經把這件事列上議程 (我們跟這個客戶每週開會兩次)，一直談到七月終於敲定了日期，但沒有敲定講者XD

Workshop 倒數 8 天

其實我覺得這件事真的好神奇，這麼早以前就已經開始談的事，會讓我覺得微軟這邊應該早就把資源都找好了，只要客戶一旦確定日期，我們就可以開始，沒想到不是這樣。我的 Sales Specialist 一直到八天前才開始寄信找資源，這時候他開始把我 cc 進內部郵件裡，我以為他都談好了，應該不需要我處理。

微軟雲端架構師 (Solution Architect) 職位解析 5：Sales Pipeline Management

Fri, 28 Jul 2023 00:00:00 +0000

Photo by Markus Spiske on Unsplash

前言

這篇文章是 «微軟雲端架構師 (Solution Architect) 職位解析» 系列的最終章。這個系列總共有五篇文章，以雲端架構師在日常工作中最主要的任務為例 :

《微軟雲端架構師 (Solution Architect) 職位解析 1：Org Chart》
《微軟雲端架構師 (Solution Architect) 職位解析 2：Solution Architecting》
《微軟雲端架構師 (Solution Architect) 職位解析 3：Technical Guidance/Customer Meetings》
《微軟雲端架構師 (Solution Architect) 職位解析 4：Technical Presentation/Workshops》
Sales Pipeline Management » 你正在閱讀的文章

當然，總是要先放一下免責聲明XD

Sales Pipeline

Solution Architect 這個職位在不同公司或是不同地方(例如 service companies like AWS/Mircrosoft、consulting companies like Accenture/EY 或是 customer side like 銀行/一般企業)，可能會有不一樣職責。

但在微軟，Solution Architect 就是 technical sales，也就是說我們的薪資組成裡面有 25% 是 sales commission，實際計算的公式有點複雜，但裡面佔比例最高的要素我們叫做 Azure Consumption Revenue (ACR)。

微軟員工績效評估 (Microsoft Employee Performance Review)

Sat, 03 Jun 2023 00:00:00 +0000

微軟員工績效評估 (Microsoft Employee Performance Review)

Photo by John Schnobrich on Unsplash

今天要來跟大家分享微軟是怎麼進行員工績效評估。

前言

微軟用的內部 performance review 工具叫作 Connect，Connect 通常發生在每年 4–5 月 (細節跟時間點每年可能會有所調整，畢竟微軟的公司文化就是充滿chnages XD)。每年到了Connect 的季節，員工就必須要在 Connect 上根據下面幾個類別寫出自己在過去一年所產出的影響力 (impacts)，接著你的經理會就你寫的 Connect 內容跟你討論有沒有需要改動的地方。討論結束後，你的經理會再額外找時間在你寫的 Connect 下面寫出他的評論。

Connect 一旦提交之後就不能再做出更改，而且 Connect 會一直伴隨著你在微軟的職涯，不管你之後換了部門或是換了經理，他們都有辦法看到你過去的 Connect 紀錄。

Connect 內容

Connect 內容主要分成以下幾個部分。

Reflect on the past (回顧過去) — 要求你總結一下你過去一年的影響力，分為兩大部分。

1.1 核心優先事項 (Core priorities) 就是你的KPI，根據每個人的職位會有所不同。Cloud Solution Architect 是以下幾個部分:

Azure 消費影響 (Consumption Impact) : 你手上的客戶總共在 Azure 上花了多少錢，你做了什麼事情幫助客戶可以在 Azure 上順利部署 (i.e. 花錢)。
Azure 擴張影響 (Expansion Impact) : 你在 sales pipeline 裡面創造了多少新的 opportunties，簡單來說就是你挖掘了多少客戶可能在 Azure 上花錢的新機會。
UCR (Unified Revenue Impact): 微軟內部用語，簡單來說就是你 deliver 了多少客戶需要額外付費的微軟 workshops。(哇，又是錢哈哈哈! 大家可以知道我為什麼說這個工作跟我的個人價值觀不符了吧? 雖然說 CSA 是個技術職位，但我們的 KPI 幾乎都是用銷售數字在衡量 >”<)
**技能專業化與精通的增長 (Growth in Specialization & mastery across skills): **過去在技能上的成長，我寫了我過去六個月考過了兩張 Azure 證照。
對他人成功的貢獻 (Contribution to success of others) : 寫你做了什麼事幫助你同事成功。這點其實是我還滿喜歡的一點，你協助他人成功的地方也可以列為你自己的 KPI。
建立在他人工作基礎上的成果 (Results that built on other’s work): 寫你做了什麼事是建立在你的同事的工作基礎上。這點也是我還滿喜歡的一點，與其大家各做各的，如果已經有人做過類似的工作，那下一個人遇到同樣問題時，可以直接利用前人的工作成果，而不是每個人都花時間自己在從頭摸索。只可惜理想是美滿的，現實是骨感的，微軟內部的不管是同一個 team 或是 cross team 之間的溝通都不是太好XDDD 所以還是常常發生每個人各幹各的，費時又耗力，還沒有一個統一的成果或標準的結果…

1.2 **多樣性與包容性 (Diversity & Inclusion, D&I)，**需要描述你的行動對於促進更多元且包容的微軟文化有什麼影響？

澳洲微軟新進員工第一週的心得+坎培拉微軟辦公室分享

Fri, 24 Feb 2023 00:00:00 +0000

澳洲微軟新進員工第一週的心得+坎培拉微軟辦公室分享

微軟坎培拉辦公室-門口

(這篇是原來是我 2022.10.28 寫的文章，現在轉發到 Medium 上面跟大家分享XD)

加入微軟的第一週! 近來坎培拉的天氣真心遭到不行，每天都狂風暴雨像颱風天一樣。今天終於放晴，於是我立刻前往坎培拉辦公室一探究竟 (但今天最高溫還是只有15度，布里斯本都已經32度了 lol)

結果不看不知道，一看嚇一跳! 微軟的坎培拉辦公室非常迷你，而且樓層也很低 (分別在大樓的二樓跟四樓，請不要問我三樓怎麼了，我也不知道XDD)

微軟坎培拉辦公室-廚房

廚房沒零食，重點是居然只有一個螢幕哈哈哈哈哈哈 (Amazon 是雙螢幕，而且桌子大概是微軟的兩倍大)。這個差異深深讓我體驗到由奢入儉難啊XD

微軟坎培拉辦公室-辦公桌

硬體設備除外，我覺得MS的同事人都還不錯。我的 manager 非常搞笑，我每次跟他catch up 都要被他逗得哈哈大笑。我的 team也非常迷你，加上manager 跟我也才8個人。這一週我幾乎跟每個人都 one-on-one 聊過 (是我主動傳訊息給大家約 one-on-one catch up的)，覺得大家的故事都非常有趣!

我的team還有另一個比我早加入兩週的同事，也是從AWS來的，跟我分享了很多很好的意見！(說真的我覺得我們兩個都有點不適應，因為AWS跟微軟文化真的太不一樣了。)

我的另外一個文化衝擊則是我跟兩個 MS graduate level 的同事聊天 (MS 的graduate program 是兩年，也不輪調，就在同一個職位。兩年在 AWS 我們都可以被 promoted to L5了)。他們都是以 experienced hire 的眼光看我 (覺得我是職場前輩)，可是我內心還是覺得我是一個 graduate/associate，讓我不禁懷疑我撐得起我現在的 level 嗎？

另一個文化衝擊是，我的這個職位其實分成三個組織：Core (也就是 infrastructure)、Application Innovation、Data Analytics。我所屬的 team 是 core，但其實我個人的背景偏向 app innovation (因為我是 web development 出身)，然後我在 AWS 的最後一年做的是 data analytics 的 project ，也就是說這三個分支裡我最沒有關係的就是我現在的core team 哈哈哈

澳洲微軟菜鳥 Azure Cloud Solution Architect 的一天

Fri, 16 Dec 2022 00:00:00 +0000

澳洲微軟菜鳥 Azure Cloud Solution Architect 的一天

Photo by Raychel Sanner on Unsplash

Azure Cloud Solution Architect (CSA) 是我在微軟的工作職稱，這是我加入微軟的第八週。在微軟之前，我在另一個雲服務平台 AWS 工作，也就是說這些 Azure services，對我來說都是全新的知識。

上週有客戶寫信問 sales 一個關於 Azure 防火牆 (Web Application Firewall) 的問題，對方的 DevOps 工程師提出了兩個可能的解決方案，但不知道哪個好，於是向微軟求救，想知道微軟的 best practices。由於是技術問題，於是 sales 就把信轉交給我負責。然而我從來沒有用過這個服務，也不是網絡 (networking) 專家，於是就開始起了我尋覓答案的旅程!

首先，我先在網路上搜尋了一下相關資訊，有了一點基本的概念後，我覺得這個問題可以有第三個解法，於是傳訊息給帶我的前輩想要找她驗證我的想法。想當然而，人家很忙沒空回我。好險我早就經過 AWS 的一番薰陶，知道不懂的就要馬上問/求救，於是我立刻在 team channel 上發問，結果沒人理我……

後來我又私訊了我的經理，跟另外兩個在紐西蘭跟新加坡的 CSA (她們之前是我的AWS同事)，沒想到大家不知道答案。

好不容易過了幾天，帶我的前輩終於有空了，她跟我說她也不知道答案，但給了我另一個內部的論壇連結跟另一個 security CSA的聯繫方式。

最終的最終，我總算在各種不同的管道中蒐集到了我想要的資料，歷經與客戶的數封 emails 往返，我提出了三個選項的解決方案 (根據解決方案的安全性跟複雜度，我建議他們依序開始嘗試)，然後跟客戶約了一個時間開會，也就是這週三。

不得不說開會前我還是有點緊張的，其實我根本不知道這個問題的答案，我只是從各種網路資源、Azure的官方文件、微軟內部的論壇回答跟幾個其他team 的人回我的 email 中拼湊出了答案。這也是我第一次在沒有前輩的陪同下直接跟客戶開技術性會議。

會議開始後，客戶 (DevOps 工程師) 告訴我她已經進行了解決方案一，把 security framework 升級到版本 3.2，然而這並沒有解決問題。我跟她說「在我們繼續討論之前，我想要知道升級後你們有遇到新的問題嗎?」她說沒有，所以也是一件好事。(她本來也在想說不定升級後會有其他問題，所以她一開始也是不敢升級的XD)

接著客戶告訴我她也進行了解決方案二，嘗試了各種設定組合之後，還是沒有辦法達到我們想要的結果。這也是我們可以預期的，因為我其中一個微軟的同事早已告訴我，解決方案二不可能會成功，這點只是應證了他的理論而已。(在我之前給客戶的email中，我已經表明這點。但由於客戶真的不想走選項三，所以我建議她我們還是先試試選項二，說不定會有奇蹟出現? 哈哈)

於是我們只好面臨了我們最不希望選的解決方案三，由於這個解決方案特別複雜，所以客戶還沒有嘗試。此時客戶的經理也在會議中，她問我「所以方案三不是一個好的解決方案嗎?」我回答「不是的，方案三也是一個很好的解決方案，只是因為這個方案的設計比較複雜，而且一旦設計得不好，很容易會產生安全漏洞，所以我們才會想說要從比較安全/簡單的方案一跟二開始。然而我們現在已經試過方案一跟二，知道他們無法滿足我們的需求，方案三是我們最後的選擇。」