企業搬遷的核心動力是成本控制，但「自建更便宜」需多維度評估。作者：黃婉中（雲端架構師）

企業搬遷的核心動力是成本控制，但「自建更便宜」需多維度評估。

[caption id="attachment_222913" align="alignnone" width="863"] （圖／黃婉中提供）[/caption]

我最近觀察到有些客戶開始考慮把部分工作負載搬回私有環境。但這不代表企業在逃離雲端，公有雲整體仍在成長，2025 年全球公有雲支出預計達 723 億美元，年成長 21%。

我認為更準確的描述是：更多企業打算採用混合模式，公有雲和私有雲並存。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

最大動力：節省成本

企業轉向私有雲或混合雲，最大原因就是成本控制。根據 IDC 調查，59% 的組織在 2024 年雲端支出超出預算。

37signals（Basecamp 的母公司）每年付 AWS $320 萬，搬回去後預計五年省超過 $700 萬。而巴菲特旗下的美國保險公司 GEICO，經歷了十年的雲端遷移，結果費用漲了 2.5 倍。

「費用更低」不是對所有企業都成立

但仔細研究，會發現這些案例有個共同點：他們的工作負載非常穩定，不是偶爾爆發。

如果你的工作負載是「偶爾爆發、容易停」，那公有雲的彈性優勢仍然明顯，成本會更低。問題是，現在有越來越多企業發現自己的工作負載其實是「穩定型」，不是「爆發型」。對於這類工作，自建硬體的總持有成本（TCO）可能比長期租用公有雲便宜。

但成本不是唯一因素

不過，穩定的工作負載 = 自建更便宜，這個方程式有例外。

以 AI 工作負載為例。這幾年 GenAI 爆發，AI 從「實驗」變成「持續業務」，看起來工作負載穩定了。但企業面臨新的問題：不願因為三年承諾就被鎖定在特定方案上。

開源模型品質快速提升，已能應付大多數需求，而 AI 市場變化太快，下個月可能有更便宜或更好的選擇出現。結果是很多企業選擇：不簽長約，保有轉換的靈活性。 他們願意付略高的價格，換來隨時切換的自由。

這說明：在市場變化快速的領域，即使工作負載穩定，企業也可能為了保留靈活性而放棄純成本優勢。

自建不是簡單的決定

GEICO 的案例很有啟發性。他們決定搬遷回私有雲後，才發現自建帶來的實際挑戰遠比想像中複雜。他們在一年後公開談論搬遷過程中碰到的問題：

• 電源系統不相容，得自己開發混合方案
• 韌體管理幾乎要從零建起
• 跨不同硬體廠商的管理工具各自為政，難以統一
• 需要招募一批在傳統 OEM 採購模式下根本不需要的專業人才

GEICO 的經驗說明：自建不只是成本問題，還有運維複雜度、人才要求、技術整合等多個維度的挑戰。

所以，如果你發現自己的工作負載其實是穩定型，在考慮自建之前，可以評估以下幾個方面：

1. 人力資源（最大挑戰）

自建最大的成本來自人。不只是「有人會裝機器」，還要「有持續的人來維護、優化、處理突發狀況」，就像 GEICO 遇到的韌體管理和工具整合問題。組一個團隊，光薪資成本就很龐大，必須節省夠多才值得。

判斷標準：

• 你現在有多少人懂基礎設施管理？
• 自建的成本節省是否超過他們的薪資？
• 如果關鍵人物離職了，有接班人嗎？

2. 工作負載的穩定性

如果有臨時的、不可預測的專案，自建不只是不划算，甚至會來不及。

混合雲的做法是：穩定的放在私有，臨時的放在公有。 但代價是複雜度增加，跨雲管理、資料一致性、工具整合都需要額外投入。

3. 合規與安全

某些行業（金融、醫療、政府）或地區有特殊的監管要求，資料必須在特定地區、有特定的安全認證。

判斷標準：

• 你的行業是否有數據位置或安全認證的硬性要求？
• 公有雲廠商是否在你需要的地區有合適的 Data Center？

先檢查公有雲廠商是否提供符合要求的服務（Azure EU、阿里雲等）。只有都不符合，才需考慮自建。

4. 未來的靈活性需求

如果你計劃全球擴展，自建可能不夠靈活。建立全球私有基礎設施的成本和複雜度很高。

判斷標準：

• 業務是否會擴展到新的地理區域？
• 業務模式或技術棧是否會頻繁改變？

如果是，公有雲的靈活性更有價值。如果業務相對穩定，自建的長期成本優勢更明顯。

所以，我該怎麼辦

如果你在考慮是否應該轉向私有雲或混合雲，我建議這樣評估：

第一步：評估你的工作負載

• 哪些是持續穩定跑的？
• 有沒有臨時或不可預測的專案？

第二步：評估你的人力資源

• 有多少人懂基礎設施管理？轉向混合需要改變什麼？
• 你有沒有辦法在關鍵人物離職後保持營運？

第三步：評估你的特殊需求

• 有沒有合規或地理位置的硬性要求？
• 是否需要對特定資料有完全的控制權？

第四步：做成本計算 別只看公有雲的月費。要算上：

• 硬體購買、安裝、更新的成本
• 人力成本（招聘、培訓、流失）
• 機房成本（電力、冷卻、物理安全）
• 隱性成本（緊急維修、停機時間）

如果能清楚回答上面 4 個評估維度時，自然會知道什麼選擇最好。

這篇文章 混合雲時代：為什麼「省成本」可能是假命題｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

秒懂ISO27001合規生態系中各角色的功能與協作方式作者：黃婉中（雲端架構師）

秒懂ISO27001合規生態系中各角色的功能與協作方式

[caption id="attachment_222901" align="alignnone" width="864"] 很多人第一次接觸 ISO 27001 都會被搞糊塗。（圖／黃婉中提供）[/caption]

很多人第一次接觸 ISO 27001 都會被搞糊塗。

證書是誰發的？顧問是幹嘛的？工具又算什麼角色？這幾件事只要搞混，合規的邏輯就會轉不清楚，結果就是花了錢、花了時間，卻不知道為什麼要做。

我後來發現用健身來解釋最好懂。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

教練：輔導顧問公司

想健身，第一步通常是找教練。請他幫你評估現在的體能狀況、教正確的動作，讓你不要做白工或受傷。

這個角色，在 ISO 的世界裡，就是輔導顧問公司。台灣市場上的顧問生態，大致可以歸納為三種類型：

第一種：專業管理認證顧問公司 例如鼎新資安、萬弘資訊、領導力企管等。這類公司專精於管理制度的合規輔導，從風險評估、政策文件建置、員工訓練、到內部稽核，能一路陪企業準備好接受最終的正式審查。

第二種：資安技術服務商提供之輔導 例如中華資安國際 (CHT Security)。這類公司本身具備強大的資安技術背景，在提供 ISO 27001 輔導的同時，能針對技術面的控制項（如弱點掃描、系統加固等）提供技術支援，將合規與防禦技術整合在一起。

第三種：大型管理顧問公司 即 Deloitte（勤業眾信）、PwC（資誠）、KPMG（安侯建業）、EY（安永） 等四大會計師事務所。他們通常服務大型企業或金融機構，擅長處理組織整體的治理框架（Governance），並將資安管理與企業內部控制制度對接。

顧問的角色是幫你把整套「資訊安全管理系統（ISMS）」從零建起來。他們確保你的組織架構、文件流程與日常執行都能符合國際標準要求，讓你在面對正式稽核時，能拿出合規的證據，也能確保制度在公司落地。

裁判：驗證機構

教練很厲害，卻不能發證書給你。要確認達到 ISO 27001 的標準，必須由獨立的第三方機構來評估。

很多人以為是 ISO 組織本身派人來審查，其實不是。ISO（國際標準化組織）只負責制定標準，本身不做認證。真正來現場「考試」的，是各國經過認可的驗證機構。

台灣常見的驗證機構包括：

• BSI（英國標準協會）
• SGS（台灣檢驗科技）
• TÜV Nord（北德）
• Afnor（環亞貝爾）
• TCIC（環球認證）

這些機構都必須經過財團法人認證基金會（TAF）的「認證（Accreditation）」，才有資格幫企業進行稽核 並核發帶有 TAF 標章的正式證書。

審查流程分為兩階段：第一階段（Stage 1）是文件審查，確認你的管理架構符合標準要求。第二階段（Stage 2）是實地稽核，稽核員會到現場抽查，確認你真的有照著制度走。從零開始到最終取證，企業通常需要預留 6 到 12 個月的準備時間。

健身 App：合規管理工具

隨著科技進步，大家開始流行健身 App。

你不需要每天請教練在旁邊盯著，App 可以給你訓練菜單、追蹤你每天的訓練完成狀況、提醒你今天該做什麼、幫你記錄有沒有達標。

在 ISO 27001 合規這件事上，這個角色對應的是 GRC（Governance, Risk, and Compliance）合規自動化平台，例如Sprinto、Drata、Vanta，各有不同的強項和適用規模。

它把顧問幫你建起來的那套制度，變成一個可以日常持續運作的平台：

• 跨多個合規框架的控制項自動對應，不需要每次新增框架就重新來過
• 佐證蒐集自動化，持續從你的系統抓取資料，讓你隨時都有稽核就緒的證據，不需要臨時動員
• 稽核人員可以直接登入專屬儀表板，查看所有控制項的狀態和佐證，減少來回溝通的時間

以前這些事情都靠人工追蹤，Excel 表格、Email 來回、各種提醒，費時費力又容易漏掉。現在這類工具的出現，讓日常合規管理這件事從「靠人盯」變成「讓平台跑」。

智慧手錶：雲端資安監控工具

手腕上的智慧手錶，做的事情是：隨時告訴你身體現在的狀態。 心跳、血氧、睡眠品質，數值出現異常馬上通知你，讓你不用等到健康檢查當天才發現問題。

這就是Microsoft Defender for Cloud（DFC）在雲端合規上扮演的角色。

它持續評估你的雲端環境，哪台伺服器設定錯了、帳號權限過高、資源沒有加密、SSL 憑證快過期。並在 Regulatory Compliance Dashboard 上即時顯示每個控制項的合規狀態。

它的覆蓋範圍不只是 Azure，還可以同時監控 AWS 和 GCP。透過 Azure Arc，可以把地端私有雲的伺服器也納入同一個儀表板，讓你在單一介面看到整個混合環境的合規狀態。

它支援的合規框架包含 ISO/IEC 27001:2022、PCI DSS、SOC 2、NIST 等主流標準，並且可以直接產出 PDF 或 CSV 格式的稽核報告，提供給稽核人員作為佐證。

把 4 個角色放在一起看

顧問公司（教練）：幫你把制度建起來，評估風險、設計控制項、建立流程。

認證機構 BSI、SGS（裁判）：定期來做正式評估，確認你真的達到要求，核發證書。

合規管理工具（健身 App） ：讓這套制度在日常持續運作，追蹤政策更新、員工訓練、佐證蒐集，不需要每次靠人工動員。

Defender for Cloud（智慧手錶） ：隨時監測雲端環境的技術面合規狀態，出問題馬上告訴你，不用等到稽核季才發現。

這個生態系不只適用於 ISO 27001，SOC 2、PCI-DSS、資通安全管理法都是同樣的邏輯。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

這篇文章 搞懂 ISO 27001生態系，其實跟健身沒什麼兩樣｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

在 Azure 工作這幾年，我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了，你會發現這句話通常不是架構師在擔心的，而是採購或決策者在說的。作者：黃婉中（雲端架構師）

在 Azure 工作這幾年，我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了，你會發現這句話通常不是架構師在擔心的，而是採購或決策者在說的。

[caption id="attachment_215083" align="alignnone" width="880"] 所謂的「抽象層」，其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。（圖／AI生成）[/caption]

他們真正的意思，其實不是怕技術上搬不走，而是想保留一個「我隨時可以離開」的姿態。這是一種商業談判：客戶會在單一雲端環境穩定使用三到五年，等量跑大了、折扣拿夠了，在合約快到期時，再拿著這些使用量去跟另一家談。

就像我們手機門號約滿了，不一定是因為收訊不好才想轉電信商，單純只是想看看別家能不能給出更優惠的續約條件。在雲端市場，這種採購策略其實每天都在發生。

更多科技工作請上科技專區：https://techplus.1111.com.tw/
科技社群討論區：https://pei.com.tw/feed/c/tech-plus

為了追求「隨時能搬走」所付出的代價

我曾經遇到一個客戶，為了保持「跨雲可攜性」，花了三年在做一套中立的架構。

他們規定所有的東西都要跑在 Kubernetes (AKS) 上，完全不碰 Azure 的原生服務，像是 Azure Functions、Service Bus 或 Cosmos DB。

所謂的「抽象層」，其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。但為了讓這個轉接頭相容，你必須放棄每家雲端最強的獨特功能，導致工程師大半的時間都在維修這個轉接頭，而不是在開發產品。

三年後，他們的 CTO 來找我，決定放棄這套架構，改為大量採用原生服務。因為他們發現，如果直接用雲端長好的功能，部署週期能大幅縮短。

這就是最弔詭的地方：為了防範「萬一要搬家」的風險，他們付出了三年研發緩慢的「確定損失」。

我們常擔心被廠商綁架，但冷靜想想，雲端大廠倒閉或惡意漲價的機率，跟我們自己公司因為產品出太慢而倒閉的機率，哪個比較高？至少在過去十年，雲端市場整體定價都是下降的。

有時讓團隊痛苦的，是為了追求靈活性而過度複雜的架構設計。

Egress Cost 不是供應商的陷阱

很多人把跨雲傳輸的成本當成鎖定的風險，其實有點誤會了。

不論你選哪一家雲，只要有資料傳輸，就會產生 Egress Cost。就算你在同一個 Azure 帳號下，跨區域 (Region) 傳輸一樣會計費。所以，成本高低跟「你選哪家雲」其實關係不大，反而是跟「你的資料流怎麼設計」有直接關係。

如果架構設計得不好，製造了大量不必要的跨區傳輸，那這就是病因，而帳單只是症狀。

監管合規的現實：服務完整性與法規

每次談到「為了合規所以要多雲」，其實背後有個假設：每家雲在各個地區的服務都一樣好用。但現實完全不是這樣。

以中國市場為例，雲端環境與全球是分開的。Azure 由世紀互聯營運，AWS 則由本地合作夥伴營運，兩者的架構邏輯相似，帳號與全球版不互通。受限於當地的營運環境，中國區的服務項目通常會比全球版少一些。而 GCP 則選擇了不同的市場策略，目前在中國境內不提供直接的雲端服務。

在美國聯邦政府市場，情況又不一樣。Azure Government 和 AWS GovCloud 都是實體與邏輯完全獨立的專屬雲端平台。而 GCP 則主要透過 Assured Workloads 等技術控管手段來滿足合規要求。

所以，你的業務在哪、面對什麼法規，決定了你的選項。

如果供應商在當地的服務支援並不符合你的特定業務需求，那麼談論多雲架構的靈活性，在實務上就會面臨很大的挑戰。

「深度整合」帶來的競爭優勢

其實，如果能把 Azure 的生態系用深、用透，這反而是你的優勢。當服務之間能無縫串接，開發節奏會快很多。

統一的 IAM 權限、監控和成本管理，能省下許多維運心力。如果你的對手更敢用這些工具，讓產品迭代得更快，那他雖然「被鎖定」了，卻能跑得更快。

我常跟客戶分享：先想辦法讓產品成功。等到公司真的大到需要擔心 Vendor Lock-in 的時候，你到時絕對有足夠的資源去處理它。在那之前，專注在業務的成長吧。

重點回顧

• 「避免 Vendor Lock-in」是談判桌上的語言：客戶三到五年跳一次雲，是為了用離開的可能性，換回議價的籌碼。
• 為了保持可攜性付出的確定損失，可能大於被 Lock-in 傷害的不確定風險。
• Egress Cost 跟選哪家雲無關，跟資料流怎麼設計才有關。
• 監管合規的真正問題不是「要不要多雲」，而是你需要的那家雲，在你需要的地區，服務完不完整、法規合不合規。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

延伸閱讀：當 ETL 不再需要工程師：Databricks、Fabric、Snowflake 開戰，資料人的下一站在哪？｜專家論點【黃婉中】

這篇文章 雲端供應商綁定（Vendor Lock-in）沒有你想的那麼可怕｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

想像一下：週五下午五點，你正想著等下要點哪一家的鹹酥雞，手機突然震了一下。收到雲平台的安全警告，甚至暫時停用。作者：黃婉中（雲端架構師）

想像一下：週五下午五點，你正想著等下要點哪一家的鹹酥雞，手機突然震了一下。收到雲平台的安全警告，甚至暫時停用。

[caption id="attachment_215078" align="alignnone" width="816"] 雲端供應商負責維護實體機房與底層網路的安全，但「你的客戶」在平台上傳了什麼資料、這些資料是否違規，屬於你必須控管的「資料治理」範疇。（圖／AI生成）[/caption]

電話接不完，你甚至不知道是哪一個天兵客戶上傳了什麼東西。

原因不是你的程式碼出錯，而是因為你的客戶上傳了惡意程式（Malware）的檔案，觸發了底層的自動防禦機制。

這不是都市傳說，是我客戶的真實經歷。

這就是 ISV 最擔心的「連帶風險」。雖然違規的是你的客戶，但承擔損失的卻是你。等到問題擴大到影響系統安全或觸犯法規紅線，停權與法律訴訟的壓力就會接踵而來。

更多科技工作請上科技專區：https://techplus.1111.com.tw/
科技社群討論區：https://pei.com.tw/feed/c/tech-plus

我們不能預期每個用戶都守規矩，但可以思考：如何在這些行為影響到 Azure 訂閱帳號之前，系統就能自動處理掉？

誰的責任？

根據 Azure 官方的雲端共享責任：無論你使用的是 IaaS、PaaS 還是 SaaS，「資料分類與保護」始終是你的責任。

換句話說，雲端供應商負責維護實體機房與底層網路的安全，但「你的客戶」在平台上傳了什麼資料、這些資料是否違規，屬於你必須控管的「資料治理」範疇。

當風險發生時，供應商會依據此模型要求你履行保護義務。如果你沒有建立過濾機制，就可能面臨訂閱帳號被暫停的風險。

安檢站的架構建議：利用 Defender for Cloud 建立防線

當違規事件發生時，雲端供應商的處理速度通常很快。與其等著收通知，不如在自己的架構裡先蓋好「安檢站」。

你的系統需要資料落地前，就具備初步的判斷能力。

機場安檢不會因為你看起來像好人就放你走。你的雲端架構也該有一套「不信任何人」的安檢站。

我們不需要從頭開發，Azure 已經提供了現成的工具來搭建這套防護網。

第一層：靜態過濾（Defender for Storage + Purview）

檔案上傳時，建議先經過一個「暫存區」，而不是直接進入正式儲存區。

• 安全性掃描： 透過 Microsoft Defender for Storage 的惡意軟體掃描（Malware Scanning），可以在檔案進入 Blob 的瞬間攔截有害程式。
• 合規性檢查： 配合 Microsoft Purview，系統可以識別出檔案中是否包含未經授權的敏感資料（如身分證號或信用卡資訊）。這能幫你的客戶擋掉許多無心但具備法律風險的上傳行為。

除了主動掃描內容，建議你也參考 Azure 官方的適用於 Blob 儲存體的安全性建議，從帳號權限、網路控制與記錄監視等維度，為你的儲存基礎設施打好底子。

第二層：行為分析（Microsoft Sentinel）

除了檔案本身，我們也要監控用戶的行為模式。 如果某個帳號在短時間內出現異常的大量上傳或存取，這常是是攻擊或違規的徵兆。這時 Defender for Cloud 會發出警報，並將數據匯入 Microsoft Sentinel。

你可以利用 Sentinel 的自動化功能（Playbooks）來設定規則：一旦偵測到高風險行為，系統就自動暫停該用戶的權限。這種「壯士斷腕」的做法，能確保問題被鎖定在單一用戶身上，而不會延燒到你的整個 Azure 訂閱帳號。

影像內容：補足防禦的缺口

文字過濾已經是基本功，但現代的違規內容大多藏在圖片或影片中。 如果你的 SaaS 有大量影像分享，建議整合 Azure AI Content Safety。它能以極低的成本（每千張影像約 $1 美元）自動偵測暴力或不當內容。

比起人工審核，這能提供更即時、更全面的保護。

架構之外的應變準備

除了技術手段，還有兩件事對 SaaS 服務商很重要：

1. 完善的服務條款（ToS）： 確保你有權力在用戶違規時終止其服務。
2. 詳盡的防禦日誌： Defender for Cloud 留下的攔截紀錄非常重要。萬一帳號真的被偵測到異常，這些紀錄就是你向 Azure 團隊說明「我已盡到管理責任且有過濾機制」的最佳證據。

好的架構設計除了處理流量，也要在異常發生時，把損害控制在最小範圍。透過這套自動化安檢機制，你可以將「用戶違規」這個不確定因素，化為系統可以自行消化的例行程序。

重點回顧

1. 釐清連鎖風險：你的客戶若行為違規，會直接影響你的 Azure 帳號。
2. 入口即時掃描：善用 Defender for Storage 掃毒並配合 Purview 識別個資，在資料進入你的儲存區前就攔下風險。
3. 自動化隔離異常：透過 Microsoft Sentinel 監控，一旦發現某位客戶有異常行為，系統可自動限制其權限。
4. 補齊影像盲點：別漏掉圖片與影片，整合 Azure AI Content Safety 才能確保你的客戶上傳的視覺內容也符合合規要求。
5. 留存證據：防禦日誌能幫你爭取復權。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

延伸閱讀：當 ETL 不再需要工程師：Databricks、Fabric、Snowflake 開戰，資料人的下一站在哪？｜專家論點【黃婉中】

這篇文章 雲端服務怎麼自動抓違禁資料？一個「安檢站」比喻讓你秒懂｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

分析雲端架構從複雜 ETL 轉向「垂直整合」的趨勢，消除資料搬運成本與延遲，使架構師價值從「規劃路徑」轉向「資料治理」。作者：黃婉中（雲端架構師）

分析雲端架構從複雜 ETL 轉向「垂直整合」的趨勢，消除資料搬運成本與延遲，使架構師價值從「規劃路徑」轉向「資料治理」。

[caption id="attachment_210511" align="alignnone" width="872"] 工程師的日常工作，有大半時間在解決一個問題：「怎麼把資料從 A 點搬到 B 點？」（圖／黃婉中提供）[/caption]

身為雲端架構師，我觀察許多工程師的日常工作，有大半時間在解決一個問題：「怎麼把資料從 A 點搬到 B 點？」

在過去 10 年的大數據時代，我們的架構圖長得像迷宮。業務系統（OLTP）收到資料後，我們會寫一套 ETL 程序，把原始資料抽出來，洗乾淨後放進數據湖（Data Lake）。
為了讓老闆看報表，我們再從湖裡撈出來，轉成特定格式，放進資料倉儲（Data Warehouse, DW）。

如果資料科學家要做 AI 模型，可能又要再搬一次。

這種架構，養活了許多工具供應商，但代價是：

• 資料延遲：報表是昨天的
• 成本昂貴：同一份資料存了 3 次、算了 3 次
• 維護複雜：只要一個關卡斷了，流程就癱瘓

但我最近觀察到，這個情況正在改變。資料領域的供應商們不再各自為政，而是開始「垂直整合」。

3 大巨頭的「越界」戰爭

如果你也在觀察最近的趨勢，會發現資料界的領頭羊們，功能做得越來越重疊，邊界也越來越模糊。

1. Snowflake：從資料倉庫轉型 AI 平台

Snowflake 曾是「雲端資料倉儲」的代名詞，當年靠著運算與儲存分離的架構一戰成名，讓擴展這件事變得輕而易舉。

不過 Snowflake 顯然不滿足於只當個存放資料的倉庫。

最近，他們往 AI 領域進攻的腳步很快（像是 Cortex AI 服務）。邏輯很直覺：「資料在哪，AI 就在哪。」 與其讓客戶費工夫把資料搬出去訓練模型，不如直接在資料倉儲裡內建 AI 能力。

觀察這陣子的佈局，Snowflake 已經跳脫單純查詢引擎的框架，轉向打造一個完整的 AI 資料平台。

2. Databricks：從 ML 專家跨足資料庫

Databricks 的路徑剛好相反。這家以 Apache Spark 起家、專精大數據與機器學習（ML）巨頭，核心概念是「Lakehouse」，想把資料湖變得跟倉儲一樣好用。

最近，他們做得更徹底：發表 Lakebase，正式跨足 OLTP（交易型資料庫）。

以前他們是等資料搬過來再處理，現在提供一個基於 PostgreSQL 的資料庫，讓你的業務系統直接長在上面。

邏輯很簡單，既然資料最終都要進湖，做分析或跑模型，那為什麼不一開始就讓它「生」在我的平台裡？

這個舉動顯示 Databricks 正逆流而上。不只當後端的分析工具，也想成為底層資料庫。

3. Azure Fabric：讓搬運隱形的 Mirroring 技術

至於我最熟悉的 Azure，則推出了 Fabric。核心是 OneLake（概念就像資料界的 OneDrive）。

Fabric 強調 End-to-End 的流程整合，不僅包含資料庫與倉儲，連 AI、Spark 與報表工具都整合在一起， 也消除了 OLTP（交易處理）與 OLAP（分析處理） 之間的界線。

過去我們得手動開通多個服務，串接資料流。現在 Fabric 透過 Mirroring 技術，讓業務資料庫的變動，能即時同步到分析層，達成「湖倉一體」。

大家好奇，為什麼不需要進去查資料表也能同步？祕訣在於它讀取的是資料庫的「異動日誌」。

想像資料庫是一間繁忙的餐廳廚房。資料表（OLTP）就像是「冰箱裡的庫存」，你要盤點剩幾顆蛋，得開門進去數，這會擋住廚師的路（影響效能）。

而異動日誌則像是冰箱旁的庫存單，每進出一次，庫存單就記錄：「拿走 2 顆蛋」。

Mirroring 技術就是直接檢查那份庫存單，譬如看到廚房拿走 2 顆蛋，就同步在分析室（OLAP）的帳本上更新。

因為看的是「庫存單」而不是「冰箱」，所以不會撞到廚師，讓交易與分析能在同一個生態系中完成。

為什麼這對你很重要？

總結一下我們的觀察：

• Snowflake：由上而下（從倉儲往 AI 走）
• Databricks：由下而上（從機器學習往資料庫走）
• Azure Fabric：橫向掃蕩（用一個生態系把所有東西包起來）

不論是 Snowflake、Databricks 還是 Azure，雖然切入點不同，但目標都是：縮短資料從產生到發揮價值的距離。

對於企業來說，搬運與格式轉換的苦功正逐漸消失，而我們也能把更多精力放在挖掘商業洞見上。

當供應商完成垂直整合，對 IT 實務會帶來 3 個轉變：

1. 「資料治理」越來越重要

過去，工程師投入大量時間在處理資料搬運與格式轉換。隨著供應商將交易、分析與 AI 整合在同一平台，這些重複性的工作量將大幅減少。

架構師的價值，將從「規劃資料路徑」轉向「制定管理規則」。我們會花更多心思在資料的安全控管、確認資料正不正確，以及如何讓業務部門能自己撈資料、解決自己的問題。

2. 成本結構更單純

以前資料在不同服務間搬運，就像出國換匯，每換一次就被抽一次手續費（運算費）和匯差（存儲空間）。

現在一體化平台推動「一份資料、多種用途」。平台走向一體化，資料能做到只儲存一份，卻能同時被 SQL、Spark 或 AI 讀取。大幅減少了格式轉換產生的運算損耗，帳單更好懂了。

對企業管理層而言，也代表預算分配與資源利用率變得更清晰。

3. 加速決策

這是我最有感的轉變。

以前主管問現在的狀況，我們可能要回答「等明天的報表出來再說」。但在現在這種架構下，資料一進來就能直接分析。

當一筆交易產生的同時，AI 就能同步偵測異常或給出建議。讓技術支援與業務目標保持一致。

凡事總有不好

雖然整合很方便，但身為架構師，還是要提醒：凡事總有好不好。

選擇高度整合的平台，也代表「供應商鎖定」。哪天想換掉其中一個服務，成本會變高。

另外，整合平台並不代表能省去架構設計。相反地，因為操作門檻降低，資料量增長的速度會比以往更快。

當搬運變簡單了，垃圾資料（Garbage in, Garbage out）產生的速度也會變快。如果缺乏良好的資料治理，原本期待的一體化平台，可能在短時間內就堆積出大量資料，增加維護成本。

小結

觀察這些改變，可以幫助我們理解趨勢。這些整合是為了提高資料流動性，讓技術能跟上業務的速度。

如果你負責決策，現在是重新檢視「資料孤島」的好時機。

如果你是開發者，請不要只學工具操作，要理解背後的架構邏輯。

當你發現原本要寫好幾天的資料整合，現在能很快完成時，這代表技術替你省下了體力活。這多出來的時間，正好讓我們回歸本質，去思考更有價值的核心問題。

[caption id="attachment_210507" align="alignnone" width="845"] 專家論點【黃婉中】[/caption]

這篇文章 當 ETL 不再需要工程師：Databricks、Fabric、Snowflake 開戰，資料人的下一站在哪？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

為何「提供存取」違法，分享如何運用 VDI、PIM等技術防線，轉為自動化合規。作者：黃婉中（雲端架構師）

為何「提供存取」違法，分享如何運用 VDI、PIM等技術防線，轉為自動化合規。

[caption id="attachment_210506" align="alignnone" width="778"] 工程師只是遠端連進去看一下畫面，沒有下載或儲存資料到電腦，這樣也會被認定不符合 GDPR 嗎？（圖／黃婉中提供）[/caption]

快速摘要

• 法規要求：根據歐洲資料保護委員會（EDPB）規定，只要資料從歐盟境內被傳輸或「提供存取」給位於第三國的對象，就必須遵守 GDPR Chapter 5 的跨境傳輸規則。
• 合規工具：根據 GDPR Chapter 5 Art 46，境外資料傳輸必須簽署標準資料保護條款 (SCC) 並執行傳輸影響評估 (TIA)。
• 技術防線：業界大廠通常透過虛擬桌面 (VDI)、臨時權限申請 (PIM/JIT) 以及客戶鎖箱機制 (Customer Lockbox) 來防堵風險。
• 不合規代價：2025 年 TikTok 因遠端存取控管不當，被重罰約 5.3 億歐元。

最近有客戶問我：「我們的客戶在歐盟，但支援團隊在中國。工程師只是遠端連進去看一下畫面，沒有下載或儲存資料到電腦，這樣也會被認定不符合 GDPR 嗎？」

更多科技工作請上科技專區：https://techplus.1111.com.tw/

答案是：會，而且可能罰很重。

延伸閱讀：聾啞創作者，如何用 AI 拿回創作的主控權？｜專家論點【黃婉中】

💡GDPR 全稱為 General Data Protection Regulation（通用資料保護規則），是一項歐盟的法律，目的是加強個人數據保護，是目前史上最嚴格的隱私法。

為什麼「看一眼」也不行？看看 TikTok 的例子

TikTok 在 2025 年被重罰 5.3 億歐元，原因之一，就是歐洲用戶的資料被中國員工遠端存取。

歐盟監管機構的認為，只要資料傳輸缺乏足夠的技術與法律保障（如 SCC 或 TIA），即便是為了技術支援，也被視為違法。

客戶問：「但工程師沒有儲存任何資料啊？」

在 GDPR 裡，資料處理不只是「存檔」。只要資料跨越了國境，進入了非合規地區，法律上就認定這是一次「資料傳輸」。

雖然你沒點「下載」，但工程師可以用手機翻拍螢幕、可以憑記憶背下客戶資料，讓敏感資料曝露在不受控的環境，風險與直接把檔案傳出去是一樣的。

💡遠端存取算傳輸嗎？ 算。根據 GDPR Art 4 對「處理 (Processing)」的定義：任何對個人資料的操作，包含讀取、使用或「提供存取 (making available)」，都算。

解決方案：國際大廠如何做到「防彈級」合規？

面對嚴格規定，跨國軟體公司通常準備了多層防護：

1. 簽標準資料保護條款 SCC

標準資料保護條款（Standard Data Protection Clauses，簡稱 SCC） 就像一份法律上的「保證書」。
企業必須與境外的支援單位簽署歐盟認可的合約，承諾：即便工程師人在境外，也會像在歐盟境內一樣嚴格保護資料。

2. 執行傳輸風險評估 TIA

傳輸影響評估 (Transfer Impact Assessment，簡稱 TIA) 是面對 GDPR 稽核時，證明企業已盡到「盡職調查」義務的證據。

自 Schrems II 判決後，法律要求單簽 SCC 已不足夠，出口商必須額外執行 TIA，確認目的地國家（如中國）的法律是否會干預資料安全。

軟體供應商如微軟，已經提供一份完整的跨境傳輸合規評估指南 (Compliance Assessment)，裡面詳細列出了針對目的地國家的法律分析與技術防護措施，幫助客戶大幅簡化 TIA 的撰寫過程。

客戶有時會把 TIA 與 DPIA 混淆，兩者雖都很重要，但重點不同：

• SCC (標準資料保護條款)：法律層面的「合約保證」。
• TIA (傳輸影響評估)：傳輸層面的「實地徵信報告」。
• DPIA (資料保護影響評估)：針對「資料處理過程」本身的風險評估（例如在 Azure 上運算的安全性）。

簡單來說：TIA 關注的是「跨境傳輸」，DPIA 關注的是「資料處理」，兩者缺一不可。

3. 使用虛擬桌面 (VDI)

虛擬桌面基礎架構 (Virtual Desktop Infrastructure，簡稱 VDI)，是最關鍵的技術防線。工程師不允許直接連線到資料庫，必須先登入一個位於歐盟境內的虛擬桌面（如 Azure Virtual Desktop）。

在這種架構下，工程師只能看到螢幕畫面，所有檔案無法下載、無法截圖，也無法將資料複製貼上到自己的本地電腦。

透過「資料不落地」的技術手段，確保敏感資訊始終留在歐盟境內的受控環境中。

4. 申請臨時存取權限

透過臨時存取（Just-In-Time，簡稱 JIT） 與特權身分管理（Privileged Identity Management，簡稱 PIM) 機制，達成「零常駐權限」的資安原則。

工程師平時不具備任何存取身分，只有在處理特定案件時，才能申請約 2 小時的臨時授權。

任務一旦結束，系統便會自動回收權限，且全程留存詳細的操作紀錄 (Logs)，確保每一筆存取都有跡可循。

5. 設置客戶核准機制

客戶鎖箱機制（Customer Lockbox） 是最後一道關卡。即便內部工程師申請了臨時權限，當他準備進入系統存取資料時，仍必須由客戶端的管理員點下「同意」，工程師的螢幕才能看到畫面。

這項機制將資料的「最終決定權」交還給客戶，確保任何一次存取，都是在客戶知情且授權的情況下發生。

談話中，我發現客戶對於合規報告，以及雲端工具如 Defender for Cloud (DFC) 如何自動化監控這些規則，很感興趣。

我發現對話已經從法條解釋，轉移到了技術實戰。

後來，那位客戶沒再問過我「看一眼行不行」的問題了。

[caption id="attachment_210507" align="alignnone" width="1038"] 專家論點【黃婉中】[/caption]

這篇文章 只是遠端看一眼也算「傳輸」？從 TikTok 被罰 5 億歐元看 GDPR 跨境合規｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

如果有一天，你發現一個完全不懂程式、甚至連母語書寫都有困難的人，竟然能自己開發出一套創作工作流和 AI 助手。你的第一直覺是什麼？作者：黃婉中（雲端架構師）

如果有一天，你發現一個完全不懂程式、甚至連母語書寫都有困難的人，竟然能自己開發出一套創作工作流和 AI 助手。你的第一直覺是什麼？

[caption id="attachment_208155" align="alignnone" width="873"] 一個完全不懂程式、甚至連母語書寫都有困難的人，竟然能自己開發出一套創作工作流和 AI 助手。你的第一直覺是什麼？（圖／AI生成）[/caption]

這不是科幻劇本，而是最近在韓國真實發生的故事。

一個關於「重新連線」的故事

故事的主角是 Min-ji So，她是一位聾啞畫家，在 Instagram 上用漫畫分享她作為聾啞母親養育聽覺正常孩子的日常生活。

更多科技工作請上科技專區：https://techplus.1111.com.tw/

對我們來說，韓語或中文是母語，但對聾啞人士而言，手語才是他們的第一語言。書寫文字（如韓文或中文）對他們來說更像是「第二外語」。

Min-ji 在創作網漫時，最感到挫折的是無法精準掌握文字的細微差別。例如韓語中「我不知道」與「難道你不知道嗎？」在語氣上的微妙差異，常讓她卡關。

過去，她必須依賴真人編輯幫她修稿。但這產生了兩個問題：第一，必須等真人回覆，創作流會中斷；第二，創作能不能往下掌握在別人手裡，讓人感到「失去自主權」。

後來，她參加了微軟的 AI 計畫，利用 Copilot 開發了一個「網漫分鏡助手」，一個 AI Agent。當她輸入簡單的意圖，AI 會反過來問她：「你想表現的是衝突感嗎？」、「要不要試試用劇本式的台詞來強化張力？」

Min-ji 說：「感覺就像多了一位創意助理。」

觀察一：意圖導向架構（Intent-based Architecture）

從這件事，我看到的第一個技術轉型是：我們正在告別 GUI（圖形介面），迎向 Intent（意圖）。

過去30年，介面設計（UI/UX）是軟體開發的重點。我們設計了各種按鈕、選單、下拉視窗，假設使用者是「標準人」，訓練他們學會我們的系統邏輯。如果使用者有特殊需求（比如視障或聽障），我們就補一塊「無障礙（Accessibility）」的補丁（Patch）。

但 Min-ji 的案例告訴我們，未來的架構將會是 「去介面化」 的。 使用者不再需要去適應軟體，而是軟體要具備「語義層（Semantic Layer）」來理解使用者的意圖。

未來的系統前端可能只是一個對話框或語音窗口，但後端需要強大的 Orchestration（編排）能力。系統必須能從模糊的語義中解構出邏輯，並驅動下層的 API。

這就是所謂的「意圖導向架構」。當系統能理解意圖，原本屬於「邊緣案例」的弱勢需求，就會自動變成系統的「原生能力」。

觀察二：將專家服務「Serverless 化」

第二個觀察是關於能力解耦（Decoupling）。

在 Min-ji 的舊流程中，「編輯與校對」是一個中心化的資源，必須仰賴特定的人力。這在系統設計上叫作「單點故障（SPOF）」，如果編輯請假，創作就癱瘓。

但在 AI 時代，這種「專業能力」正在被 SaaS 化與 Serverless 化。 以前我們談 Serverless 是指運算資源（CPU/RAM）按需分配，現在談的是「能力（Capability）」按需分配。

編輯、法律諮詢、代碼審查、數據摘要，這些原本壟斷在專家手中的隱性知識，現在被封裝進了大型語言模型（LLM）中，成為可以隨時呼叫的 API。

這對企業軟體架構有巨大的衝擊。想像一下，未來的 ERP 系統不再需要請會計師一一核對，而是由一個「會計 Agent」自動偵測數據異常並給出建議。這種「能力的去中心化」讓個體（如 Min-ji）擁有了以前只有大型工作室才有的「智庫」。

不只是身障者，我們每個人都在受益

你可能會說，我不是聾啞人士，這跟我有什麼關係？ 其實，我們或身邊的人在某些時刻都是「有障礙者」。

• 過動症（ADHD）者：在冗長的視訊會議中難以集中，AI 摘要讓他更專注。
• 口吃者：在重要簡報前，AI 語音修飾工具能將斷續的語音轉化為流暢的音軌。
• 菜鳥工程師：在面對複雜的 Legacy Code 時，AI Agent 幫他版本升級。

結語

當 Copilot 或是各種 AI Agent 成為標準配備，SaaS 產品的競爭點漸漸從「功能多寡」，轉向「理解深度」。

從架構師的角度來看，AI 賦能（Enablement）的核心價值在於擴展人類的能力邊界。它就像就像「數位義肢」一樣，接上斷掉的連線，幫助我們前往更多被遺忘的角落。

這篇文章 聾啞創作者，如何用 AI 拿回創作的主控權？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

每週三，74 歲的 Michael 坐在倫敦的公寓裡，等著電話響起。電話那頭是他的志工朋友 Gemma。他們什麼都聊，從偵探小說聊到 Gemma 家的小狗。這通電話對 Michael 來說是救命稻草，讓他覺得自己還跟這世界連接著。作者：黃婉中（雲端架構師）

每週三，74 歲的 Michael 坐在倫敦的公寓裡，等著電話響起。電話那頭是他的志工朋友 Gemma。他們什麼都聊，從偵探小說聊到 Gemma 家的小狗。這通電話對 Michael 來說是救命稻草，讓他覺得自己還跟這世界連接著。

[caption id="attachment_208147" align="alignnone" width="783"] 接受 AI 隨時監聽你的心事嗎？或者你覺得，直接跟 AI 聊天反而更自在？（圖／AI生成）[/caption]

但我最近讀到這則報導時，注意到一個細節：這兩人的對話，後台其實有一套 Azure 的 AI 系統在「監聽」。

以雲端架構師的角度來說，這是一個很棒的技術落地案例。今天我想跳脫感性的故事，從技術人的角度聊聊我的幾個觀察。

更多科技工作請上科技專區：https://techplus.1111.com.tw/

效率革命

Age UK 服務的長者很多，疫情後通話量更是暴增。在傳統架構下，若要確保通話安全（防止志工詐騙或長者發生意外），工作人員必須「肉身監聽」。

假設一名全職員工一天工作 8 小時，他頂多只能完整聽完 16 通 30 分鐘的電話。如果要覆蓋 3 萬通以上的通話，人力成本將是天文數字。

他們採用了 Azure OpenAI 的語音轉文字（Speech-to-Text）技術。這套系統至今轉錄了超過 30,700 通電話，AI 自動過濾掉大半無風險的對話，只有約 3% 的通話需要人工介入。

這種效率倍增，是技術帶來的紅利。它讓社會福利服務從勞力密集型的「手工業」，轉化為具備雲端彈性的「智慧服務」。

是保護還是審查？

但在閱讀技術細節時，我還是覺得有點毛毛的。報導提到，系統會針對 500 個敏感詞進行監控，包括「肚子餓」、「見面」、「旅館」甚至是「WhatsApp」或「TikTok」。只要觸發關鍵字，系統就會評分並交由審查員重聽。

這讓我想起專制政權的言論審查。「保護」與「監聽」只有一線之隔。

雖然通話雙方都知道有錄音，但如果我知道自己講的每一句話都在被演算法掃描，可能很難聊得自在。

當我們為了保護長者不被詐騙而錄音，是否也剝奪了他們的隱私權？長者在通話時，如果知道每一句話都在被 AI 掃描，他們還能坦誠地分享那些微小、破碎但珍貴的心事嗎？

架構師的解藥：數據治理與被遺忘權 

如果你問我如何優化這套架構以降低不安感，我會建議從以下幾點著手：

1. 存取控制（RBAC）： 嚴格定義誰有權限調閱轉錄稿與錄音，並留下完整的審核日誌（Audit Log）。
2. 數據生命週期管理： 只要 48 小時內沒人回報問題，數據就應該物理刪除。實踐 「被遺忘權」。
3. 知情同意： 必須向長者解釋：「錄音是為了在您遇到困難（譬如被騙）時，我們能及時伸出援手。」，並獲得同意。

當 AI 成為完美的伴侶：人類志工還有位子嗎？

報導中還有一個觀點讓我思考：現在 AI 聊天技術已經這麼強，為什麼不直接讓長者跟 AI 聊就好？

從功能來看，AI 簡直是「完美伴侶」：

• 超有耐心： 它不會嫌你重複講年輕時的故事。
• 物理安全： AI 沒有銀行帳戶，不會騙走長者的退休金。
• 24/7上線： 它不怕被打擾，不需要睡覺。

但友誼的本質是雙向的。志工 Leigh 在文中提到，她在這段關係中也感到了「被需要」的快樂。這種人與人之間的情感流動，是目前 LLM（大型語言模型）即便模擬得再像，也無法真正產生的「靈魂連結」。

不過，從使用者體驗（UX）來看，這種服務也有缺陷。如果長者每次配對到的都是不同志工，每次都要重新介紹自己的生平、病史與愛好，會膩吧？

「狀態化」設計

未來這類架構可以引入「狀態化（Stateful）」的設計。AI 可以幫忙總結（Summarize）上次的談話重點，讓下一位志工接手時，先看過上次對話重點，關心長輩：「Michael，你上次說膝蓋痛，這週好點了嗎？」這種技術輔助，能幫助友誼延續。

結語

身為一名雲端架構師，我常說「技術是中性的」。同樣的語音識別技術，可以用來追蹤異議人士，也可以用來挽救一個被扣款 900 英鎊而焦慮不已的孤獨老奶奶。

我沒有一個完美的標準答案來消除那種「被監聽」的負擔感。但我認為，技術應該扮演「沉默的守護者」。 我們的努力方向，是建立一個能讓脆弱的人們安全交流的空間。

如果你是 Michael，你會為了這份安全感，接受 AI 隨時監聽你的心事嗎？或者你覺得，直接跟 AI 聊天反而更自在？歡迎留言跟我聊聊你的看法。

這篇文章 如果 AI 知道你所有的心事：長者陪伴電話背後的精靈｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

在IT圈，我們常聽到 Whiteboarding（白板討論）。這詞聽起來專業，其實說白了，就是「拿起筆，直接在白板上邊畫邊跟人討論」的過程。作者：黃婉中（雲端架構師）

在IT圈，我們常聽到 Whiteboarding（白板討論）。這詞聽起來專業，其實說白了，就是「拿起筆，直接在白板上邊畫邊跟人討論」的過程。

[caption id="attachment_206099" align="alignnone" width="835"] Whiteboarding（白板討論）。這詞聽起來專業，其實說白了，就是「拿起筆，直接在白板上邊畫邊跟人討論」的過程。（圖／AI生成）[/caption]

在 UI/UX 或軟體工程師的面試裡，這種形式很常見。但在雲端架構師的場景中，大家似乎比較少把它當成一項必修課。不過根據我的經驗，這是一個在簡報之外，非常實用的溝通輔助工具。

為什麼不只用簡報？

身為雲端架構師，我們習慣準備一疊厚厚的簡報。但架構有時很複雜，不管是混合雲遷移還是資料分析，投影片講久了，有時候客戶不一定能完全跟上。

這時 Whiteboarding 就派上用場了。它不是要「取代 」簡報，而是「補充」。當客戶對某個細節有疑問時，放下雷射筆、拿起白板筆，把死板的簡報切換成動態討論。這能幫助雙方把認知對齊，讓討論更聚焦。

簡報是靜態且封閉的，當客戶對某個設計有疑慮時，翻找投影片常會打斷思考。白板則提供了靈活性，而且不需要從零開始。通常我會先畫好核心框架，在簡報過程中針對客戶關心的特定節點進行補充。

以下跟你分享3個適合「動筆」的場景。

白板技術在不同情境的應用

1. 釐清需求：確認目前遇到了什麼問題

我常用白板和客戶盤點現有架構痛點。客戶通常比較冷靜，不會主動描述細節。這時，我會在白板上劃出簡易的現況圖（As Is），並針對可能有優化空間的部分（如資料庫、特定串接點）詢問客戶的看法。

看著圖討論，通常比對著簡報的條列清單更容易讓客戶確認現狀，減少雙方的認知誤差，也能確認哪些是優先事項。

2. 梳理需求：達成共識

一個例子是討論資料如何從地端搬遷到雲端。 企業專案經常有多種資料來源（如不同資料庫、第三方 API），簡報的更新常趕不上變動。我不止一次聽到客戶邊看簡報邊說：「這裡後來我們又加了東西，來不及畫在上面。」

我會直接在白板上畫出資料流。討論內容包含：這段資料是 Batch 還是 Real-time？傳輸過程需不需要處理去識別化？我發現這麼做以後，能夠省下許多會後email來往確認的時間。

3. 處理突發提問：展示方案的彈性

白板也很適合在既有的方案架構上，針對客戶特定需求進行局部調整。當客戶提出「如果以後要擴充到其他區域，這套架構怎麼改？」這類假設性問題時，白板就是最好的補充工具。

即使現場沒時間去改簡報，我會直接在原有的圖上繼續補充，讓客戶理解這份方案是可以根據需求微調的。

給架構師的實作建議

• 預先畫好底圖：現場時間有限，我通常會在會議開始前，先畫好大約 70% 的基礎架構。正式討論時，只針對需要變動的部分動筆，這樣比較省時間，也維持溝通的節奏。
• 工具分工：PPT 用來呈現最終目標跟結論、白板則用來處理討論過程中的變數。
• 拍照留存：建議討論完後，當場用手機拍下白板圖，直接貼進當天的會議記錄（Meeting Minute）。這能確保「共識」被保存下來，不會因為白板被擦掉就沒了。
• 參考公開資源：想學習如何把複雜雲端架構畫得清晰，可以參考 YouTube 上的 John Savill，他的視覺化邏輯非常值得學習。

結語

白板不需要畫得像藝術品，只要能把邏輯講清楚就夠了。誠如那句老話：「A picture is worth a thousand words」（一張圖勝過千言萬語）。

在雲端架構這種資訊量大的工作中，白板是一個能幫你把複雜事物變簡單的工具。下次發現會議溝通有點卡關時，不妨拿起白板筆試試看。

這篇文章 雲端架構師實測：除了 PPT，為什麼你也該試試「白板討論」？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

讀者常問我：顧問究竟在做什麼？既然顧問也懂技術，跟工程師有什麼不同？跟你舉個例子作者：黃婉中（雲端架構師）

讀者常問我：顧問究竟在做什麼？既然顧問也懂技術，跟工程師有什麼不同？
跟你舉個例子。

雲端成本大增

前陣子《中途筆記》網站常常斷線無法使用，原因是 CPU/Memory 常會無預警的不夠用，導致頻繁斷線。

[caption id="attachment_206094" align="alignnone" width="779"] 顧問解決商業目標，而工程師搞定技術（圖／AI生成）[/caption]

觀察虛擬機器數據後，發現多數時候利用率都很低，也查不出具體原因。為了讓網站運行更穩定，我打算加上異地備援（DR）並同步進行成本優化（FinOps），將網站遷移至更合適的虛擬機器（VM）。

我的虛擬機器放在雲平台上，因此先嘗試更換虛擬機器，卻發現沒有一台機器可以選，於是開了一張 ticket 請求支援。

得到答案是我放機器的東南亞區域已經沒有容量，客服工程師建議我在東亞區域開。隨後說東亞區域容量申請完成了，可以關單了嗎？

我說換區域沒問題，但你得教我怎麼搬遷。他於是聯繫了一位虛擬機器工程師，向我解釋怎麼把同台虛擬機器搬到東亞區域。又問可以關單了嗎？

我覺得不對勁，平常幫客戶作搬遷不是這樣的阿。通常會跟客戶討論計畫，說明會造成哪些停機時間、需要多少時間能復原、對使用者影響有多少等，而你們只是教我怎麼複製磁碟？

再次解釋這只是複製而不是搬遷，網路都沒設定呢。新虛擬機器的網址根本與《中途筆記》的 IP 無法關聯。客服於是又聯繫了一位網路工程師。

網路工程師研究了幾天後回應：沒有問題啊，我看你網站好好的，可以存取，問題在哪呢？

我簡直快暈倒，說目前可以運行是因為機器現在還在東南亞區域上面跑，關掉以後怎麼存取呢？中間解釋了半天，這位工程師顯然對於一個對外網站背後，有一台虛擬機器、怎麼運作都很陌生。

總結一下目前為止發生的事：

1. 區域工程師： 告訴我東南亞區沒容量了，建議改開東亞區。他完成了容量申請，隨即問：「可以關單了嗎？」——他只在意他管轄的「配額」。
2. VM 工程師： 教我如何複製磁碟，卻無視我的網站還在運行。他問：「可以關單了嗎？」——他只在意「資料有無搬移」。
3. 網路工程師： 研究幾天後回覆：「網站現在跑得很好啊，問題在哪？」他忘了，現在跑得好是因為我還沒切斷舊主機的連線。——他只在意「當下的連線狀態」。

這張 ticket 開了兩個月，我都從台灣飛到澳洲了，問題還卡在原地。已經從「技術問題」，延伸到「溝通斷層」。

這 3 位工程師的技術能力可能都非常頂尖，但他們被框在各自的指標（KPI）與工作範圍（Scope）裡

• 區域工程師的 KPI 是「配額管理」。
• VM 工程師的 KPI 是「虛擬機存取」。
• 網路工程師的 KPI 是「連線通暢」。

當每個人都只守著自己那一塊「拼圖」時，就沒人在意整張「拼圖」最後長什麼樣子。對雲端平台商來說，他們每個環節都按照標準流程（SOP）走，技術上完全沒錯。但對客戶來說，我正在燃燒雲端預算、承擔斷線風險，這就是最大的商業損失。

這也是為什麼很多大公司雖然擁有最頂尖的工程團隊，專案卻依然會延宕，原因不是技術不夠，而是缺乏一個能把技術拼圖組裝起來、看見全局的人。

工程師搞定技術，顧問解決商業目標

注意到了嗎？使用者跟工程師使用的語言天差地遠。

對使用者來說，目標是：更省錢、更穩定地運行業務（Business Goal）。 對工程師來說，目標被拆解為：複製磁碟、修改 A 紀錄、配置網段（Technical Task）。

而不同專長的工程師團隊中間彼此不溝通、也不在意對方在做什麼。對於他們來說，「搬遷」是一個太模糊的詞彙，要細到具體技術目標，譬如複製磁碟、修改 A 紀錄等，才夠具體。

讀到這裡，你可能會好奇故事的結局是什麼？結局是我心一橫，決定將網站搬遷到另一個提供搬遷解決方案的主機商，從下單到搬遷完成只花了半天。

工程師負責產品，顧問熟悉解決方案

這就是「產品思維」與「解決方案思維」的差異：工程師負責產品，而顧問要熟悉解決方案。這個例子中，平台商是賣虛擬主機產品，而主機商賣的是搬遷解決方案。也許雲平台的主要客群都擁有一定技術能力，而不像我一樣是以營運目標為首要考量的使用者。

顧問知道搬遷並順利運行是一個技術目標，而背後的商業目標是什麼？是網站能順利的運行，所以產品能繼續銷售、公司能繼續賺錢。

此外，他還需要清楚使用者有哪些限制和期望。能用使用者的語言溝通，而不會拋出一堆聽不懂的專有名詞。更重要的是可以一步到位，不需要使用者顧前顧後，拆解成數個步驟。

• 工程師負責產品（Product）： 確保每個零件（VM、Network、Storage）正常運作。
• 顧問熟悉解決方案（Solution）： 確保這些零件組合起來，能讓客戶的網站賺錢、省錢、避險。

當然，因為執掌和專案類型不同，有時工程浩大、參與其中的成員太多，工程師沒有問題的全貌是常態。顧問也沒有工程師的技術深度。我只希望用這個例子告訴你兩種職能的差異。

科技人的轉型關鍵：從「搞定技術」到「交付價值」

如果你希望從純技術職轉向顧問職，或是在科技產業中發揮更大的影響力，這場搬遷經驗整理出的 4 個「顧問思維」核心是關鍵：

1. 鎖定最終目的地（Business Outcome）： 不糾結於技術路徑的岔路，而是問：「這動作能否達成商業目標？」
2. 提供量身訂做的解決方案： 清楚客戶的限制（如：預算、停機時間），而不是只給標準手冊。
3. 翻譯官的能力： 用客戶聽得懂的語言溝通，將「磁碟 I/O」轉化為「使用者體驗」。
4. 一步到位的交付： 顧問的價值在於「整合」，不需要客戶像拼圖一樣自己去湊合各個部門。

試著在下次接到需求時，多問一句：「這個調整對公司的業務目標有什麼幫助？」當你開始思考這個，就在通往顧問的路上了。

這篇文章 別只會搞定技術！科技人從「產品」跨向「解決方案」的4個顧問核心思維｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。