一、表面遷移是VMware，背後動的是全公司的業務依賴很多人理解的VMware替代方案，就是V2V搬一下磁碟、安裝一個代理程式、改改IP。

但企業的生產環境不是普通的辦公IT。

每天早上九點，ERP開始跑MRP，MES源源不斷下發工單，PLM被調度部門高頻調用，WMS調度著倉庫進出貨，OA和郵件裝載著全員配合，數據庫著著批處理和報​​表。任何一台虛擬機器啟動後效能掉幾幀、儲存IO慢幾秒鐘，產線上的庫存就會積壓，財務月結就會延後，客戶訂單就會中斷。

環境裡，十幾台虛擬機器遷移過去運作正常，只能說明「能開機」。到了生產環境，數百台上千台虛擬機器持續測試運行，跨叢集呼叫、異質鎖、共享儲存同時承壓，系統還能不能穩定住，才是真正的問題。

二、表面遷移是VMware，背後動的是全公司的業務依賴 

一次遷移協調會，ERP、MES、PLM、WMS、OA、郵件、資料庫、中介軟體廠商坐了一個房子。

資訊部讓大家逐條確認介面和依賴關係：虛擬機器IP變不變？集群心跳地址變不變？域控還是怎麼處理？軟體授權綁定MACUUID？有人說已經測試過。有人說要等ERP提供新地址。還有人問：“這條接口今年是誰開發的？”

沒有人敢回答，也沒有人敢回答。

軟體的介面已經運作了很多年了，原來的工程師已經離職了，只剩下許久沒有更新的舊文件。

這才是VMware遷移真正困難的地方。

· 虛擬機器使用了VMware全球交換器（VDS）的存取VLAN、連接埠轉送、流量整形，國產虛擬化預設的標準交換器不支持

· 虛擬機器是專業配置備併用了PVSCSI控制器驅動，遷移後驅動無法識別，直接導致藍屏或核心panic

· 資料庫使用了RDM裸映射磁碟，創建V2V工具根本無法辨識與轉換

·  Windows動態磁碟、AD叢集網域控、軟體授權依賴UUID或MAC位址；SAP等商業應用授權與硬體資訊綁定，遷移後可能直接失效

這些，是我十餘年前做售後工程師時總結的筆記。

我記得有一年給某大企業客戶做遷移時就踩過這些坑：RDM裸磁碟不支援直接V2V遷移，FT容錯虛擬機遷移後高可用失效。每一個問題都在凌晨割接時暴雷，出現問題就只能自己去官網或論壇查KB了。

更難受的是：有的問題上線當天就能發現，但有的問題要等到月底結等特定時段才會出現。

資訊部最怕的不是系統徹底打不開──徹底打不開反而很容易處理。真正可怕的是：系統整體時候都正常，偏偏在財務某張訂單銷售、某筆訂單上或某條生產工單上出錯。

三、批量遷移的「隱性陷阱」，比想像中 

VMware替代遷移涉及虛擬機器的運算配置、儲存策略、網路配置等多個維度的參數繼承。如果遷移工具僅支援部分參數自動繼承，其餘參數需要人工逐項補配置，那麼在批次場景中，人工補配置的遺漏機率顯著上升。

更麻煩的是國產虛擬化平台與VMware VCF環境的低階差異：OVA/OVF格式與基於KVM的雲端平台有天然差異，VMDK磁碟格式需要轉換為qcow2，同時必須配備Virtio等驅動程式。直接搞過去，常出現無法啟動或效能下降的問題。

靜默故障也是個致命殺手：磁碟亞健康、RAID卡降級、網路硬體間歇丟包，在傳統監控系統下往往無法及時捕捉。這些硬體靜默故障在累積到臨界點後突然爆發，直接導致節點突然中斷與業務中斷。如果新平台僅依賴故障後HA恢復，那麼數分鐘的業務中斷——在這幾分鐘內，ERP可能就無法開出卸貨線路，MES無法下發工單，WMS無法出庫。

四、最難的不是故障，但沒人說得清 

系統偶爾變慢，熟悉的一幕就會出現：虛擬化廠商說資源正常，儲存廠商說IO正常，資料庫廠商說連線池正常，網路廠商說沒有丟包，ERP廠商說請求已經提交。

每一家都證明自己沒有問題，但生產線已經停了，業務部門在投訴，損失已經造成。

業務人員不會關心底層是VMware還是KVM架構，也不會問虛擬化平台相容了多少種CPU指令集。他們只會問：“以前用得好好的，為什麼換完以後不行了？”

最後，所有廠商之間的技術邊界，都會成為IT資訊部門的責任。

因此，許多企業IT負責人並不是不支援VMware替代方案。之所以擔心是因為太了解企業業務，所以不敢草率切換。

他們真正需要確認的，不是「不能遷移」，而是：

· 業務分級做了嗎？哪些是一類核心業務（ERP、資料庫），哪些是二類重要業務（MES、PLM），哪些是非核心業務（OA、郵件、測試）

· 依賴梳理清楚了嗎？虛擬機器之間、應用之間、資料庫之間、網路之間的關係必須清楚

· 授權綁定識別了嗎？ SAP等商業應用授權與MAC綁定，Windows網域控制、Linux虛IP綁定方式與切換邏輯

· 演練已經了嗎？不要第一次遷移就碰生產核心系統

· 回退機制設計了嗎？包括資料回退、網路回退、應用程式回退和平台回退

· 切換失敗以後，能不能安全退回恢復系統？

五、VMware替代方案：知易行難的根本原因

表面看，替換VMware似乎是「換個平台」，實則是牽一發而動全身：

1. 技術依賴深，解耦合高。 VMware的vSphere成本不僅是虛擬機器管理器，其vCenter、vSAN、NSX等元件互連耦合，構成封閉生態。業務系統長期運作其上，形成了對VDS高階網路策略、FT容錯、RDM裸磁碟等進階功能的隱形依賴。

2. 數據一致性是巨大考驗。確保遷移一致資料的完整性、一致性，尤其對事務型系統來說是巨大考驗。增量同步、回滾機制的重要性至關重要。

3. 效能與相容性陷阱。新平台驅動、虛擬硬體支援、作業系統（尤其是較舊的CentOS、Windows Server）相容性、應用程式運作效率都可能成為問題。

4. 架構與運維模式轉型。從傳統三層架構遷移到國內超融合，一次架構轉型遷移，需要團隊了解新的資源調度、資料分配、故障域設計邏輯。同時如果新平台提供封閉的維運介面、缺乏標準API，資訊部也需要在平台切換的同時重構監控體系和自動化維運流程，在切換過渡期管理真。

5. 全端自主可控的合規深層要求。不只是替換VMware軟體本身，其底層的伺服器硬體（海光、鯕鵬、飛騰等）、網路（麒麟、系統信等）、上層應用均需滿足信創要求，形成完整的合規鏈條。國家信創要求2027年央企、關鍵產業完成虛擬化全替代，現在如果還沒啟動的企業，2026年大機率趕不上合規節點。

六、真正穩定適合的遷移，長什麼樣子？ 

參考某頭部股份制銀行超萬台虛擬機的金融級遷移實戰，以及眾多大型企業的遷移實踐，VMware替代的正確姿勢不是「一刀切」，而是「長期驗證、分批實施、自動兜底」：

第一步：工作負載精簡與分級

投入足夠的時間和資源完成系統性的工作負荷評估和依賴梳理。 Gartner在《2026年VMware現代化轉型路線圖》中明確指出，工作負載重組與架構調整是降低遷移風險的四大核心內容之首。哪些是核心交易系統、哪些是可離線遷移的辦公室系統，業務承受度分別是多少。

第二步：先納管，再遷移

如果企業VMware環境複雜，不建議一上來就全部遷移。更穩定的方式是先透過新平台對VMware環境進行統一管理，再按業務逐步遷移。這樣既降低了遷移風險，也可以讓維運團隊逐步熟悉新平台。

第三步：選擇合適的遷移工具與策略

· 無代理遷移vs 有代理遷移：無代理遷移透過呼叫VMware vCenter/ESXi API讀取虛擬機磁碟資料和配置訊息，針對業務系統入侵，適合大規模批量遷移

· 非核心業務：採用免代理批量遷移

· 核心資料庫：採用有代理增量遷移，割接前不動

第四步：遷移批次規劃

基於依賴與中斷窗口，綜合業務之間的呼叫與依賴關係、通訊連接埠與防火牆策略、業務分級以及緊張中斷關係、是否存在不可中斷的業務拓撲、虛擬機器IP/資源切換/網域控制等特殊配置、授權方式是否與硬體資訊綁定等關係，對具有大量依賴關係的業務實行統一遷移。

某頭部股份制銀行就是採用「長期驗證、分批實施、自動兜底」的策略，歷時三年完成兩萬餘台虛擬機平滑遷移，核心業務保持連續運行，實現真正意義上的「靜默遷移」。

第五步：設計事故回退機制

系統遷移屬於高風險變更操作，即使在充分測試和嚴格管控的前提下，仍有小機率遷移失敗或異常的可能性。因此在遷移方案設計階段即需同步規劃緊急回退機制，以確保業務連續性與資料安全。多系統回滾能力是必備的：

· 虛擬機器層級回滾：單一虛擬機器遷移失敗可獨立回滾

· 業務分組級回滾：依業務分組大量回滾

· 全域回退：保留VMware來源環境一定天數（個人建議15天以上），確保重大故障時可全域回退

第六步：增量同步 + 短不切換

透過「全量同步 + 多次增量同步 + 短暫定期切換」的模式，將單一批次佇列嚴格控制在分鐘級甚至20分鐘以內，最大限度地保障核心業務連續性。最後在短暫切換後5分鐘內完成資料一致性校驗，異常可在規定時段回溯至原庫。

第七步：特殊配置前置處理

·  RDM相容模式磁碟：統一轉換為普通VMDK虛擬磁碟進而執行批次遷移

·  VDS進階網路策略：透過PowerCLI腳本取得所有連接埠群組配置，識別依賴項，對於保留的策略必須透過實體交換器配置替代

·  SAP等商業應用授權：事先與廠商充分探討，透過連接埠搶佔MAC資訊結合手動修改業務系統綁定資訊的方式，解決遷移後的授權問題

· 資料庫未來不能執行增量同步：會產生讀取數據，割接前必須得像樣的

· 防毒、備份軟體Agent：遷移前未關閉會導致Agent攔截，必須事先處理

寫在最後

VMware被博通收購後的商業策略調整，使得企業用戶面臨成本激增與供應鏈穩定性風險。Gartner預測：“到2028年，成本問題將推動70%的企業級VMware客戶遷移50%的虛擬工作負載”。

也就是說，VMware遷移不是「要不要做」的問題，而是「怎麼做才不出事」的問題。

平台到貨，只是VMware替代品最容易完成的一步。

真正的國產化替代方案，不是機房裡換了現有設備，而是換了虛擬化基礎繼續發展，ERP依然能跑MRP，MES依然能下發工單，WMS依然能調度倉庫，財務依然能按時月，客戶訂單依然能準交付時結。

企業不需要一套永遠不會出問題的系統——這樣的系統就不存在。

企業需要的其實也很簡單：生長問題能夠快速定位，切換失敗能夠及時回退，關鍵時刻有人負責。

因為企業遷移的從來不只是一台虛擬機器。背後是一條不能停的產線，是一張不能錯的訂單，也是新聞部不敢拿企業去經營的一次切換。

在人工智慧快速發展的今天，GPU 無疑成為 AI 計算的核心硬體。從大型語言模型（LLM）訓練，到生成式 AI 應用部署，市場焦點長期集中在 GPU 效能與算力競爭上。

然而，隨著 AI Agent（智能體） 技術逐漸成熟，CPU 正迎來新的角色定位。

過去 CPU 主要負責：

• 執行作業系統
• 處理一般應用程式
• 管理 I/O 任務

而在 Agent AI 時代，CPU 不再只是「計算輔助元件」，而正在轉變為：

AI 智能體的任務管理中心、工作流協調器以及企業系統控制核心。

---

一、AI Agent 正在改變運算模式

傳統 AI 應用通常是：

使用者輸入問題
↓
AI 模型推理
↓
返回答案

例如：

使用者詢問 ChatGPT：

「幫我整理這份報告。」

模型生成文字後完成任務。

---

但 AI Agent 的運作方式不同。

Agent 不只是回答問題，而是可以：

• 理解目標
• 制定計畫
• 呼叫工具
• 執行任務
• 檢查結果
• 持續調整

例如：

使用者要求：

「幫我分析公司上季度銷售資料，製作簡報。」

Agent 可能會：

1. 讀取企業資料庫
2. 分析銷售數據
3. 呼叫分析工具
4. 生成圖表
5. 建立簡報
6. 發送給指定人員

這種多步驟、自動化工作流程，對系統架構提出新的需求。

---

二、CPU 在 AI Agent 時代重新定位

在傳統 AI 架構中：

GPU：

負責模型訓練與推理。

CPU：

負責系統管理與一般運算。

但 Agent AI 引入後，CPU 的重要性開始提升。

原因在於：

AI Agent 需要大量「管理型工作」。

例如：

• 任務調度
• 流程控制
• 資料管理
• API 呼叫
• 安全驗證
• 系統協調

這些工作並不一定需要 GPU，但非常適合 CPU 處理。

因此未來架構可能變成：

          AI Agent Layer
                |
        任務規劃 / 決策 / 協調
                |
        -----------------
        |               |
       CPU             GPU
        |               |
 系統控制與管理     AI模型運算

---

三、CPU 成為 AI Agent 的「大腦管理層」

GPU 更像 AI 的高速計算引擎，而 CPU 則逐漸成為 AI Agent 的控制中心。

CPU 可以負責：

1. Agent 任務管理

一個企業可能同時運行：

• 財務 Agent
• 客服 Agent
• IT 維運 Agent
• 安全 Agent

CPU 需要協調：

哪個 Agent 執行什麼任務？

什麼時候呼叫 GPU？

資料從哪裡取得？

結果如何回傳？

---

2. 工作流程編排

企業 AI Agent 通常不是單一模型，而是一組服務組合。

例如 IT 維運 Agent：

監控系統

↓

發現異常

↓

分析日誌

↓

執行修復腳本

↓

通知管理員

其中大量流程控制工作，需要 CPU 處理。

---

3. 企業資料連接

企業 AI 應用需要連接：

• ERP
• CRM
• Database
• Cloud Service
• API

CPU 長期擅長：

• 資料交換
• 網路處理
• 系統整合

因此在 Agent 架構中具有重要價值。

---

四、GPU 與 CPU 將形成新的 AI 協同模式

未來 AI 基礎架構不會是：

CPU vs GPU

而是：

CPU + GPU + NPU 協同。

不同硬體負責不同任務：

GPU

適合：

• 大模型訓練
• AI 推理
• 大規模矩陣運算

CPU

適合：

• Agent 控制
• 任務調度
• 資料處理
• 系統管理

NPU / AI Accelerator

適合：

• 本地 AI 推理
• 邊緣 AI 應用

---

五、伺服器市場正在重新設計

AI Agent 發展也正在影響伺服器架構。

過去企業採購：

更多 CPU 核心

更多記憶體

更高儲存容量

未來 AI Server 可能更加重視：

• CPU 與 GPU 協同能力
• 高速互連
• 記憶體頻寬
• AI 工作負載調度

伺服器廠商：

• Dell Technologies
• HPE
• Lenovo
• Supermicro

都正在布局 AI 基礎架構市場。

---

六、AI Agent 對資料中心運算模式的影響

AI Agent 的普及可能帶來新的資料中心需求：

從集中式計算走向分布式智能

過去：

大型模型集中在雲端。

未來：

AI Agent 可能分布於：

• 雲端
• 企業資料中心
• 邊緣設備
• 個人終端

CPU 將負責協調不同環境中的 AI 工作。

---

七、企業 IT 運維也將受到影響

AI Agent 將改變傳統 IT 管理模式。

例如：

傳統方式：

工程師監控告警

↓

人工分析

↓

執行命令

Agent 模式：

AI Agent 發現問題

↓

分析原因

↓

調用工具

↓

執行修復

↓

生成報告

在這個過程中：

GPU 提供 AI 能力；

CPU 負責執行與協調。

---

八、未來 CPU 的價值將重新被認識

AI 時代並不代表 CPU 失去價值。

相反，隨著 Agent 智能體增加，CPU 將承擔更多：

• 決策流程
• 系統控制
• 資源管理
• 任務編排

未來的資料中心，不會只是「GPU 工廠」，而會變成：

CPU 管理智能、GPU 提供算力的協同型 AI 基礎架構。

---

結語：AI Agent 讓 CPU 回到舞台中心

過去十多年，GPU 因深度學習浪潮成為 AI 核心。

但隨著 AI Agent 從「回答問題」走向「自主完成任務」，運算架構正在發生變化。

GPU 負責思考能力；

CPU 負責行動與協調。

在下一代 AI 基礎設施中，CPU 不再只是傳統運算核心，而將成為連接模型、資料、工具與企業流程的重要智慧控制中心。

AI 時代的競爭，將不只是 GPU 算力競爭，而是整個 CPU、GPU、網路與儲存協同能力的競爭。

OGEA-103 是 The Open Group 的 TOGAF Enterprise Architecture Combined Part 1 and Part 2 Exam，通過後可取得 TOGAF Enterprise Architecture Practitioner 資格。本文整理 OGEA-103 考試資訊、題型、核心考點、備考方向、常見易混淆內容與原創練習題。
建議關鍵詞： OGEA-103 認證考試、TOGAF Enterprise Architecture Practitioner、TOGAF Enterprise Architecture Combined Part 1 and Part 2、TOGAF Standard 10th Edition、企業架構認證、ADM、Architecture Governance、Architecture Vision、Migration Planning

OGEA-103 是什麼考試？

OGEA-103 是 The Open Group 針對 TOGAF Standard, 10th Edition 推出的 TOGAF® Enterprise Architecture Combined Part 1 and Part 2 Exam。這是一門合併考試，適合希望一次完成 Part 1 與 Part 2，直接取得 TOGAF Enterprise Architecture Practitioner 資格的考生。官方文件說明，OGEA-103 以 TOGAF Standard, 10th Edition 作為 Body of Knowledge，通過後授予 TOGAF Enterprise Architecture Practitioner 資格。

與單獨參加 OGEA-101 Part 1 和 OGEA-102 Part 2 不同，OGEA-103 將 Foundation 與 Practitioner 兩個層級放在同一次考試中完成。因此，考生不只要理解 TOGAF 基礎概念，也要能在情境題中應用 ADM、架構治理、利害關係人管理、需求管理、差距分析與遷移規劃等方法。

OGEA-103 考試基本資訊

OGEA-103 的英文考試名稱為 TOGAF® Enterprise Architecture Combined Part 1 and Part 2，考試代碼為 OGEA-103；簡體中文版本代碼為 OGEA-C103。官方考試文件列出此考試共有 48 題，總時間為 2 小時 30 分鐘。

OGEA-103 分為兩個部分：Part 1 包含 40 題 Simple Multiple Choice questions；Part 2 包含 8 題 Scenario Based, Complex Multiple Choice。Part 1 的通過標準為 60%，也就是 40 分中至少取得 24 分；Part 2 的通過標準同樣為 60%，也就是 40 分中至少取得 24 分。考生必須兩個部分都通過，才算整體通過 OGEA-103。

Part 1 是閉卷考試，Part 2 是開卷考試，但開卷資料不是自帶紙本書，而是在 Part 2 中透過考試系統提供 TOGAF Enterprise Architecture Body of Knowledge 的電子參考資料。官方也說明，完成 Part 1 後不能回到 Part 1，且兩個部分之間沒有休息時間，Part 2 會直接接續 Part 1。

根據 The Open Group 2026 年 2 月 1 日起適用的考試費用表，OGEA-103 / C103 的 Exam Booking Fee 為 USD 610，Retail Voucher Fee 為 USD 640；官方同時提醒，不同國家或地區可能有稅費、匯率與價格調整。

OGEA-103 適合哪些考生？

OGEA-103 適合希望一次完成 TOGAF Enterprise Architecture Foundation 與 Practitioner 要求的考生。對企業架構師、解決方案架構師、業務架構師、技術架構師、IT 經理、轉型負責人、顧問與專案／計畫管理相關角色來說，這門考試可以用來驗證對 TOGAF 方法與企業架構實務應用的理解。

The Open Group 對 TOGAF Enterprise Architecture Practitioner 能力的角色映射中，提到相關能力包括使用 TOGAF Standard 指導轉型與管理變更、執行 ADM、利害關係人管理、差距分析、遷移規劃、需求管理、Architecture Vision、Architecture Content Framework，以及架構分層與架構景觀管理。

因此，OGEA-103 不太適合完全沒有企業架構概念的入門考生。它更適合已經接觸過 IT 架構、業務流程、數位轉型、解決方案設計、架構治理或企業級技術規劃的人員。

為什麼 OGEA-103 值得關注？

企業架構的價值不只是畫架構圖，而是協助企業在業務目標、技術能力、組織治理與轉型路線之間建立一致性。TOGAF 作為企業架構方法論，核心價值在於提供一套可重複使用的架構開發方法、治理框架與交付內容結構。

OGEA-103 的特點在於一次覆蓋 Part 1 與 Part 2。Part 1 更偏向基礎知識與術語理解，Part 2 則更偏向場景應用與分析能力。The Open Group 的 Part 2 考試說明也指出，Part 2 建立在 Part 1 基礎上，並評估更高層次的應用與分析能力。

對於希望快速取得 TOGAF Enterprise Architecture Practitioner 認證的考生來說，OGEA-103 是一條集中式路徑。但也正因為它把兩個部分合在一起，考生需要同時準備記憶型內容與情境型判斷。

OGEA-103 核心考點一：TOGAF 基礎概念與標準結構

Part 1 的重點是 TOGAF 基礎概念，包括企業架構的目的、TOGAF Standard 的組成、Architecture Development Method、架構內容、架構治理、Architecture Repository、Building Blocks、Deliverables、Artifacts，以及 TOGAF 中常見術語。

這部分的難點不是技術深度，而是名詞多、定義細、容易混淆。考生需要清楚區分 Deliverable、Artifact、Building Block，也要理解 Architecture Repository、Architecture Landscape、Standards Information Base、Reference Library 等概念各自的作用。

準備 Part 1 時，建議以官方 syllabus 對應的學習成果為主。The Open Group 說明，TOGAF Standard, 10th Edition 相關認證的 syllabus 發布於 Document X2202，涵蓋 TOGAF Enterprise Architecture Foundation、Practitioner、Practitioner Bridge 與 Business Architecture Foundation 的學習成果。

OGEA-103 核心考點二：ADM 與架構開發流程

ADM，也就是 Architecture Development Method，是 OGEA-103 的核心考點。考生需要理解 Preliminary Phase、Phase A 到 Phase H，以及 Requirements Management 如何貫穿整個 ADM 週期。

Part 1 可能會直接考查每個階段的目的、輸入、輸出與主要活動；Part 2 則更常透過企業轉型場景，要求考生判斷應該使用哪個 ADM 階段、應該產出什麼交付物，或應該如何調整架構方法。

例如，Preliminary Phase 偏向建立架構能力與治理框架；Phase A 著重 Architecture Vision；Phase B、C、D 分別處理 Business、Information Systems 與 Technology Architecture；Phase E、F 關注 Opportunities and Solutions 與 Migration Planning；Phase G 著重 Implementation Governance；Phase H 則關注 Architecture Change Management。

OGEA-103 核心考點三：架構治理與利害關係人管理

企業架構不是單純的技術設計文件，而是需要被治理、溝通與落地的管理機制。OGEA-103 對 Architecture Governance、Architecture Board、Compliance Assessment、Architecture Contract、利害關係人管理與溝通計畫都有一定要求。

Part 2 情境題常見的切入點是：企業有多個業務單位、轉型目標不一致、技術標準缺乏治理、專案偏離目標架構，或不同利害關係人對架構價值存在衝突。這類題目通常不會只問定義，而是測試考生是否能按照 TOGAF 方法選出最合適的治理與溝通方式。

The Open Group 的能力映射中，也將 stakeholder management、requirements management、gap analysis、migration planning 等列為 TOGAF Practitioner 相關能力。

OGEA-103 核心考點四：Architecture Vision、需求管理與業務對齊

Architecture Vision 是 TOGAF 中非常重要的內容。它不是單純的願景描述，而是用來建立業務目標、架構範圍、限制條件、價值主張與利害關係人期望之間的初步一致性。

OGEA-103 考題可能會描述一家公司準備啟動數位轉型，但業務部門、IT 部門與管理層對目標認知不同。此時考生需要判斷是否應該先釐清架構願景、定義範圍、識別利害關係人、建立業務情境，或進一步形成 Statement of Architecture Work。

需求管理也是高頻概念。TOGAF 的 Requirements Management 不只發生在某一個階段，而是持續貫穿 ADM。考生需要理解需求會如何被識別、記錄、管理、追蹤與變更，並且如何影響不同架構階段。

OGEA-103 核心考點五：差距分析、遷移規劃與架構路線圖

Part 2 的場景題通常會考查考生是否能把架構從「目標狀態」轉換為「可執行的轉型計畫」。因此，Gap Analysis、Work Packages、Transition Architectures、Architecture Roadmap、Implementation and Migration Plan 都是需要重點理解的內容。

企業架構不是只定義未來目標，而是要說明如何從 Baseline Architecture 過渡到 Target Architecture。這中間需要識別差距、評估依賴關係、安排優先順序、規劃遷移階段，並透過治理機制確保實施過程符合架構方向。

準備這部分時，考生應避免只背名詞，而要理解這些內容如何串成一條完整路徑：Baseline、Target、Gap、Roadmap、Work Package、Transition Architecture、Implementation Governance、Change Management。

OGEA-103 常見易混淆考點

第一組容易混淆的是 Foundation 與 Practitioner。Foundation 更重視術語、概念與基本理解；Practitioner 更重視應用、分析與情境判斷。

第二組是 OGEA-101、OGEA-102 與 OGEA-103。OGEA-101 是 Part 1，OGEA-102 是 Part 2，OGEA-103 是 Part 1 與 Part 2 的 Combined Exam。官方說明，OGEA-103 是讓考生在一次考試中直接取得 Level 2 Practitioner 資格的合併考試。

第三組是 Deliverable、Artifact 與 Building Block。Deliverable 是正式交付成果，Artifact 是架構描述中的具體內容形式，Building Block 則是可重用或可組合的能力單元。

第四組是 Architecture Vision 與 Target Architecture。Architecture Vision 是早期高層次方向與價值定位，Target Architecture 則是在後續階段中更完整展開的目標架構。

第五組是 Architecture Roadmap 與 Implementation and Migration Plan。前者更偏向高層次轉型路線與工作包安排，後者更偏向具體實施與遷移計畫。

OGEA-103 備考建議

準備 OGEA-103 時，建議分成兩條線進行。

第一條線是 Part 1 的基礎知識線。考生需要熟悉 TOGAF Standard, 10th Edition 的核心術語、ADM 階段、架構內容、治理概念與常見交付物。這部分適合透過反覆閱讀、整理筆記和關鍵詞對照來準備。

第二條線是 Part 2 的情境應用線。考生需要練習如何在具體企業場景中選擇最符合 TOGAF 方法的做法。Part 2 是 Scenario Based, Complex Multiple Choice，並採用梯度計分方式：最佳答案 5 分，次佳答案 3 分，第三佳答案 1 分，干擾項 0 分。

The Open Group 也提供 TOGAF Standard, 10th Edition 相關官方學習材料，包括 PDF study guides、online self-study materials、practice tests 和 hard-copy publications。官方說明，Study Guides 適合考試準備或一般參考，Practice Tests 可幫助考生熟悉題型並評估準備狀況。

OGEA-103 原創練習題示例

問題 1：
一家公司準備建立企業架構能力，並需要先定義架構原則、治理結構與方法裁剪方式。這最符合 TOGAF ADM 的哪個階段？

A. Phase A
B. Preliminary Phase
C. Phase E
D. Phase G

問題 2：
在 TOGAF 中，哪一項最能描述 Requirements Management 的角色？

A. 只在 Phase A 使用一次
B. 貫穿 ADM 週期，持續管理架構需求與變更
C. 只用於技術架構設計
D. 只負責制定專案預算

問題 3：
一個企業已完成 Baseline Architecture 與 Target Architecture，下一步需要識別差距並規劃轉型工作包。哪一組概念最相關？

A. Gap Analysis、Work Packages、Architecture Roadmap
B. Password Policy、DNS Cache、Firewall Rule
C. Source Code Review、Unit Test、Build Artifact
D. Incident Queue、SLA Report、Backup Window

問題 4：
OGEA-103 的 Part 2 題型主要考查什麼能力？

A. 單純記憶 TOGAF 術語
B. 在企業架構場景中應用和分析 TOGAF 方法
C. 撰寫程式碼
D. 配置網路交換器

問題 5：
如果考生通過 OGEA-103 的 Part 1，但未通過 Part 2，官方規則下應如何完成認證？

A. 必須重新參加整個 OGEA-103
B. 只需要補考未通過的 Part 2
C. 直接取得 Practitioner 資格
D. 必須改考 TOGAF 9

答案：

1. B
2. B
3. A
4. B
5. B

FAQ：OGEA-103 認證考試常見問題

OGEA-103 通過後取得什麼資格？

通過 OGEA-103 後，可取得 TOGAF Enterprise Architecture Practitioner 資格。官方考試文件明確列出 OGEA-103 的 qualification upon passing 為 TOGAF Enterprise Architecture Practitioner。

OGEA-103 是閉卷還是開卷？

OGEA-103 的 Part 1 是閉卷，Part 2 是開卷。Part 2 的開卷資料由考試系統內建電子版 Body of Knowledge 提供，且只在 Part 2 可用。

OGEA-103 一共有多少題？

OGEA-103 總共 48 題，其中 Part 1 有 40 題 Simple Multiple Choice，Part 2 有 8 題 Scenario Based, Complex Multiple Choice。

OGEA-103 需要前置資格嗎？

OGEA-103 官方列出的 prerequisites 為 None。它是為希望直接取得 TOGAF Enterprise Architecture Practitioner 資格的考生設計的 Combined Exam。

如果 OGEA-103 其中一部分沒通過，需要重考全部嗎？

不需要。The Open Group Help Center 說明，Combined exams 如果通過其中一部分但未通過另一部分，只需要重考未通過的單一部分；通過後，The Open Group 會將結果合併並授予相應資格。

結語

OGEA-103 是一門覆蓋 TOGAF Enterprise Architecture Foundation 與 Practitioner 的合併型認證考試。它的難點不只在於內容範圍廣，更在於考生需要同時具備基礎概念記憶能力與場景應用判斷能力。

準備 OGEA-103 時，建議先掌握 TOGAF Standard, 10th Edition 的核心結構，再深入理解 ADM、Architecture Governance、Architecture Vision、Requirements Management、Gap Analysis、Migration Planning、Architecture Roadmap 與 Implementation Governance。

如果能把 TOGAF 從「術語清單」轉化為「企業轉型方法」，OGEA-103 的學習方向就會清楚很多。對希望往 Enterprise Architect、Solution Architect、Business Architect、Transformation Leader 或 Architecture Consultant 方向發展的人來說，這門考試具有明確的專業定位與實務價值。

CKAD（Certified Kubernetes Application Developer） 是由 Cloud Native Computing Foundation（CNCF）與 Linux Foundation 聯合推出的 Kubernetes 專業認證，主要面向負責設計、建立、部署以及維護 Kubernetes 應用程式的開發者。

與偏向 Kubernetes 叢集管理的 CKA（Certified Kubernetes Administrator） 不同，CKAD 更關注「如何在 Kubernetes 平台上運行雲原生應用」，包括 Pod 設計、Deployment 管理、服務暴露、配置管理、應用監控以及故障排查等能力。

---

一、CKAD 考試基本資訊

項目	詳細資訊
考試名稱	Certified Kubernetes Application Developer
考試代碼	CKAD
認證組織	CNCF / Linux Foundation
考試形式	線上監考、實作操作考試
考試時間	120 分鐘
題型	Performance-Based Tasks（實務操作題）
操作方式	使用 Kubernetes CLI（kubectl）完成任務
考試語言	English
考試環境	Kubernetes Cluster Terminal
建議背景	Docker、Container、Kubernetes 基礎知識

CKAD 不是傳統選擇題考試，而是要求考生直接在 Kubernetes 環境中完成操作任務，例如建立資源、修改 YAML、排查錯誤等。

---

二、CKAD 認證定位

Kubernetes 認證路徑：

KCNA
  ↓
CKAD ─── 應用開發方向
  ↓
CKA ─── 叢集管理方向
  ↓
CKS ─── 安全方向

CKAD 主要適合：

✅ Kubernetes Application Developer
✅ DevOps Engineer
✅ Cloud Native Developer
✅ Backend Developer
✅ Platform Engineer
✅ SRE 工程師

如果工作內容涉及：

• 微服務部署
• Container 化應用
• CI/CD
• Kubernetes 平台開發

CKAD 具有較高參考價值。

---

三、CKAD 考試五大領域解析

CKAD 目前主要包含五個考試領域：

領域	比例
Application Environment, Configuration and Security	約25%
Application Design and Build	約20%
Application Deployment	約20%
Services and Networking	約20%
Application Observability and Maintenance	約15%

---

1. Application Design and Build（20%）

這部分考察如何建立 Kubernetes 應用。

主要內容：

Container Image

需要理解：

• Docker Image
• Container Registry
• Image Tag
• Image Pull Policy

例如：

image: nginx:latest

需要知道：

• Image 從哪裡取得
• 如何控制版本
• 如何更新 Image

---

Pod 設計

核心概念：

• Pod
• Multi-container Pod
• Sidecar Pattern
• Init Container

例如：

應用容器：

Application Container
        +
Logging Sidecar

這類設計是 Kubernetes 常見模式。

---

Jobs 與 CronJobs

需要掌握：

Job

適合：

• 一次性任務
• Batch Processing

CronJob

適合：

• 定時任務
• 排程執行

例如：

每天凌晨執行資料備份。

---

2. Application Deployment（20%）

這是 CKAD 非常重要的部分。

主要包括：

Deployment

需要熟悉：

• ReplicaSet
• Rolling Update
• Rollback
• Scaling

常見操作：

kubectl create deployment

---

Deployment Strategy

包括：

Rolling Update

逐步替換舊版本：

Version A
   ↓
Version A+B
   ↓
Version B

---

Canary Deployment

部分流量測試新版本。

例如：

95% 使用舊版本

5% 使用新版本

---

Helm

需要了解：

• Helm Chart
• Values
• Release

CKAD 不要求深入開發 Helm Chart，但需要理解如何使用 Helm 部署應用。

---

3. Application Environment, Configuration and Security（25%）

這是 CKAD 權重最高部分。

---

ConfigMap

用於保存非敏感配置：

例如：

database_url=mysql

---

Secret

用於保存敏感資訊：

例如：

• Password
• Token
• API Key

---

Security Context

需要理解：

• User ID
• Group ID
• Container Permission

---

Resource Management

包括：

Resource Request

最低需要資源：

resources:
 requests:
   cpu: 500m

---

Resource Limit

最大限制：

limits:
 cpu: 1

---

RBAC

需要掌握：

• ServiceAccount
• Role
• RoleBinding

例如：

限制某個應用只能讀取指定 Namespace。

---

4. Services and Networking（20%）

主要考察 Kubernetes 網路通信。

---

Service

需要理解：

ClusterIP

內部通信：

Pod → Service → Pod

---

NodePort

外部訪問：

Client
 ↓
NodePort
 ↓
Service
 ↓
Pod

---

LoadBalancer

雲環境常用：

• AWS
• Azure
• Google Cloud

---

Ingress

重要考點：

• HTTP Routing
• Host Rules
• Path Rules

例如：

example.com/api
        ↓
API Service

---

NetworkPolicy

控制：

• Pod Ingress
• Pod Egress

例如：

只允許：

Frontend Pod

訪問

Backend Pod

---

5. Application Observability and Maintenance（15%）

主要考察應用監控與故障排查。

---

Probe

非常重要：

Liveness Probe

判斷：

容器是否正常運行。

---

Readiness Probe

判斷：

是否可以接收流量。

---

Startup Probe

用於：

啟動時間較長的應用。

---

Debug 技巧

常用命令：

查看 Pod：

kubectl get pods

查看詳細資訊：

kubectl describe pod

查看 Log：

kubectl logs

進入 Container：

kubectl exec -it

---

四、CKAD 考試難點分析

1. 最大挑戰是時間

CKAD 是實作考試，不是背誦考試。

需要：

• 快速寫 YAML
• 熟悉 kubectl
• 快速定位問題

---

2. YAML 熟練度非常重要

很多失分原因：

• indentation 錯誤
• apiVersion 錯誤
• field 名稱錯誤

建議：

多練習：

kubectl create --dry-run=client -o yaml

快速生成模板。

---

3. 排錯能力比理論重要

例如：

Pod 無法啟動：

不要只看 YAML。

需要檢查：

1. Image 是否存在
2. Secret 是否正確
3. Volume 是否掛載
4. Probe 是否失敗

---

五、CKAD 與 CKA 差異

項目	CKAD	CKA
方向	應用開發	叢集管理
面向	Developer	Administrator
重點	Application	Infrastructure
YAML	高	中
kubectl	高	高
Cluster Setup	少	多
Network	Application Network	Cluster Network

---

六、CKAD 備考建議

第一階段：Kubernetes 基礎

掌握：

• Pod
• Deployment
• Service
• Namespace

---

第二階段：大量練習 YAML

練習：

• Pod YAML
• Deployment YAML
• Service YAML
• ConfigMap
• Secret

---

第三階段：熟悉 kubectl

常用：

kubectl get

kubectl describe

kubectl apply

kubectl delete

kubectl logs

kubectl exec

---

第四階段：模擬實戰環境

建議：

• Minikube
• Kind
• Kubernetes Playground

反覆練習：

• 建立應用
• 修改配置
• 排查問題

---

七、CKAD 職涯價值分析

隨著企業大量採用：

• Kubernetes
• Microservices
• Cloud Native
• DevOps

CKAD 能證明考生具備：

✅ Kubernetes 應用部署能力
✅ Container 技術能力
✅ 雲原生開發能力
✅ DevOps 工作流程理解

對希望進入：

• 雲端工程
• DevOps
• AI 平台工程
• Kubernetes 平台開發

方向的人員具有較高價值。

---

總結

CKAD（Certified Kubernetes Application Developer）是一張偏向「實戰操作」的 Kubernetes 開發者認證。

考試核心不是記憶 Kubernetes 概念，而是要求考生能夠：

• 建立 Kubernetes 應用
• 管理 Deployment
• 配置 Service
• 處理安全設定
• 監控與排查應用問題

對已經具備 Linux、Docker、Cloud 或 DevOps 基礎的人員來說，CKAD 是進入雲原生技術領域的重要認證之一。

本文系統化梳理網路通訊中MTU、MSS核心概念、換算公式、Ping測試原理、隧道封裝適配問題及故障排查思路，是解決Giants、網路分片、VPN卡頓、網頁存取異常等問題的核心基礎。
一、MTU（最大傳輸單元）MTU 全稱 Maximum Transmission Unit指資料鏈結層單次能夠傳輸的完整最大資料包總大小，包含所有協定頭部及資料內容，為鏈結層的傳輸上限。
預設標準值：乙太網路（Ethernet）預設 MTU = 1500 位元組，為區域網路、公網常規鏈路標準值。
結構說明：整個連結幀最大承載1500字節，包含IP頭部、傳輸層頭部、業務數據，是完整資料包的總尺寸上限。
二、MSS（最大分段大小）MSS 全名為 Maximum Segment Size，是 TCP 協定的專屬參數
指TCP封包中真正的業務資料最大大小，不含 IP 頭部、TCP 頭部，且僅承載使用者業務資料。

1. 核心換算公式常規網路場景下，IP頭部、TCP頭部預設基礎長度均為20位元組，固定公式如下：
MSS = MTU – IP頭部(20) – TCP頭部(20) = MTU – 402. 
預設標準值基於乙太網路預設MTU 1500計算：1500 – 40 = 1460 字节
結構說明：1500位元組總MTU中，固定預留20位元組IP頭部+20位元組TCP頭部，剩餘1460位元組純資料區域即為MSS最大值，僅承載用戶業務資料。
三、Ping測試MTU原理（1472位元組的由來）Ping 工具基於 ICMP 協議實現，並非TCP協議，因此計算規則與MSS不同，是日常快速檢測鏈路MTU上限的常用手段。
1. 資料包組成ICMP資料(1472位元組) + ICMP頭部(8位元組) + IP頭部(20位元組) = 1500位元組（標準MTU上限）
2. 標準測試指令及參數意義
ping -f -l 1472 
目標位址•-l 1472：
指定資料大小為基礎1472：指定資料名稱為單位的Fragment（禁止分片），核心作用：若資料包大小超過連結MTU上限，直接丟棄資料包、測試失敗，不會自動分片傳輸，精準偵測連結最大承載能力此指令的核心用途：驗證目前連結是否支援標準1500位元組的MTU傳輸。

四、MTU變小的核心原因（隧道場景）很多人誤以為MTU變小是連結品質變差，實際上與連結頻寬、穩定性無關，僅由隧道封裝協定導致。
VPN、GRE、IPSec 等隧道技術會在原始資料包外層額外新增一層協定頭部，整體資料包體積變大。
而連結物理MTU上限（1500）固定不變，封裝頭部佔用了部分空間，導致能承載的原始業務資料空間被壓縮，即有效MTU變小，這也是隧道網路最容易出現分片、丟包的核心原因。
不同隧道協定的封裝頭部佔用位元組不同，是實戰調參的核心依據，常見隧道頭部開銷標準：
•GRE隧道：基礎頭部佔用 24 字節
•IPSec隧道（ESP）：常規封裝佔用 50~60 字節
•VPN接合隧道：多層丟裝頭套MTU + 真實位元組數值做三段精化

實戰舉例：
案例1：
公網無隧道場景（正常、無分片）普通公網/區域網，無任何隧道封裝：TCP業務資料1460 + TCP頭20 + IP頭20 = 1500位元組（剛好塞滿MTU）此時封包大小等於連結最大承載值，無需分片、不會丟包，傳輸完全正常，這也是一般上網、手機流量存取網路穩定的原因。
案例2：接入GRE隧道（不調MSS，必丟包/必分片）GRE隧道會在外層額外封裝24位元組GRE頭部，物理鏈路MTU依然固定1500不變。
沿用預設TCP 1460資料發包，總包大小計算：1460(資料)+20(TCP)+20(IP)+24(GRE隧道頭) = 1524位元組1524 > 1500，超出連結MTU上限！
此時設備只能執行IP分片，將一個完整大包拆成多個小包傳輸；而現代防火牆、VPN設備、運營商骨幹網，預設開啟分片報文攔截策略（防攻擊），直接丟棄分片資料包。
最終現象：微信發文字（小包）正常，開啟網頁、傳文件（大包）打不開/卡頓超時，是最典型的隧道MTU適配故障。
案例3：IPSec加密隧道IPSec ESP加密隧道封裝開銷更大，常規佔用50~60位元組頭部。
同樣預設1460 TCP資料發包，總包可達 1550+ 字節，超限更嚴重，分片、丟包、TCP重傳機率大幅提升，VPN辦公系統、內網業務存取異常高發。
案例4：微調MSS解決問題針對GRE隧道場景，全域下調TCP MSS至1360：1360(資料)+20(TCP)+20(IP)+24(GRE) = 1424位元組1424 < 1500，完全在MTU承載範圍內！無需分片、不會被防火牆攔截，從源頭徹底解決隧道大包丟包、網頁打不開、業務卡頓、TCP反覆重傳的問題。
此時裝置只能對超大資料包進行強制分片分割傳輸。
而大部分防火牆、VPN設備預設開啟分片偵測、防碎片攻擊策略，會直接丟棄分片封包，最後引發大封包傳輸失敗、小封包正常的詭異網路故障。
資料包結構：新增隧道頭部 + 原始完整資料包（原頭+原資料）五、手動調整MSS的必要性網路隧道封裝後，有效MTU降低，預設1460位元組的TCP資料段會超出連結承載上限，導致資料包必須分片、甚至直接丟包，引發各類網路異常。
1. 精準MSS計算公式（隧道通用萬能公式）物理出口MTU預設1500場景下，隧道環境調參唯一標準公式：
最優MSS = 1500 – 隧道外層頭部開銷 – 40（TCP+IP基礎頭部固定開銷）
原理：預留所有頭部開銷，讓杜包後的最終包完備全包尺寸，≤10005 2. 各隧道對應標準MSS精準參數（實戰直接套用）•純GRE隧道（頭部24位元組）
計算：1500-24-40 = 1436
標準配置：ip tcp adjust-mss 1436•IPSec ESP加密隧道（常規60位元組最大開銷）
計算：1500-60-40 = 1400
標準配置：ip tcp adjust-mss 1400•GRE+IPSec雙層封裝（高開銷80~100位元組）
計算：1500-100-40 = 1360
標準配置：ip tcp adjust-mss 13603. 為什麼網路上大多用 1360？1360 不是所有場景的精準最適值，而是全場景通用保守安全值。
無論單層隧道、雙層疊加隧道，設定1360皆可相容，不會超限丟包，適合不確定隧道封裝格式、懶人一鍵適配場景。

4. 核心設定指令// 精準場景按需配置
ip tcp adjust-mss 1436    // 純GRE
ip tcp adjust-mss 1400    // 單層IPSec
ip tcp adjust-mss 1360    // 雙層疊加/通用保守值
5. 作用原理主動告知客戶端，當前網路存在隧道封裝開銷，限制TCP單段最大資料尺寸，從源頭杜絕大包機超限，避免攔截設備IP分片、防火牆分頁封包表ip tcp adjust-mss 13602. 
作用原理主動告知客戶端，目前網路環境不支援超大TCP資料段，限制TCP單段資料最大大小，從來源避免資料包分片、丟包、TCP重傳，適配隧道封裝後的網路環境，解決VPN、專線隧道異常問題。
六、MTU/MSS異常典型故障現像
出現以下網路問題，優先檢查MTU、MSS適配問題：
•網頁打不開、網頁載入不全，但微信、QQ等即時通訊正常（小資料包正常，大封包傳輸異常）
•網頁連線卡頓、業務存取不穩定
•網路頻繁出現記憶資料含數、資料包丟七TCP純業務資料大小（不含任何頭部）
3. 常規固定換算：MSS = MTU – 404. VPN/隧道本質：給予原始資料包外層多套一層協定殼，擠佔傳輸空間，降低有效MTU

基本資訊

• 考試代碼：303-300
• 證照名稱：LPIC-3 Security
• 發證機構：Linux Professional Institute
• 等級：LPIC-3（Linux 專家級）
• 考試時間：90 分鐘
• 題型：選擇題 + 填空題
• 題數：約 60 題
• 前置條件：需具備 LPIC-2（建議或必要）

---

考試核心內容（重點領域）

LPIC-3 Security 的重點不是「基礎 Linux」，而是企業級資安架構與防護。

1️⃣ Cryptography（密碼學）

重點：

• X.509 憑證
• PKI 架構
• OpenSSL 操作
• 金鑰管理
• TLS/SSL 基礎與實務

常考方向：
如何建立 CA、簽發憑證、驗證鏈

---

2️⃣ Access Control（存取控制）

重點：

• DAC / MAC / RBAC
• SELinux 基本與策略
• AppArmor
• Linux permissions 深層機制

常考方向：
如何限制服務權限、強化系統安全模型

---

3️⃣ Application Security（應用程式安全）

重點：

• SSH hardening
• Web server security（Apache/Nginx）
• 容器與應用隔離
• sudo 與權限設計

---

4️⃣ Operations Security（營運安全）

重點：

• logging / auditing（auditd）
• system hardening
• patch management
• backup security

---

5️⃣ Network Security（網路安全）

重點：

• iptables / nftables
• VPN（IPSec / OpenVPN）
• firewall design
• secure network services

---

6️⃣ Threats & Vulnerability（威脅與弱點）

重點：

• 漏洞掃描工具
• 入侵偵測 IDS/IPS
• log 分析
• attack surface reduction

---

考試難度分析

✔ 難度：⭐⭐⭐⭐☆（偏高）
✔ 特點：

• 不只是 Linux 指令
• 更偏「企業資安架構設計」
• 題目常是情境題（scenario-based）
• 需要理解系統如何整體防護

---

適合考的人

非常適合以下人群：

Linux / IT 工程師

• 已有 LPIC-2 / RHCSA / 同等能力

資安工程師

• 想走 Linux Security / SOC / Blue Team

雲端 / DevOps

• 想補「系統安全能力」

想升級到架構級能力的人

• 從「會操作 Linux」→「會設計安全系統」

---

建議學習路線

如果你要準備 303-300：

Step 1：Linux 基礎要很熟

• permission / systemd / networking

Step 2：補安全核心

• SELinux / AppArmor
• firewall (nftables)

Step 3：加強密碼學

• OpenSSL
• PKI / certificate chain

Step 4：做實驗

• 搭 CA
• 建 VPN
• 做 firewall policy

---

考試定位（很重要）

LPIC-3 Security =
Linux + Enterprise Security + System Design

不是：

• 單純指令記憶
• 也不是初級 Linux 考試

而是：

「你能不能設計一個安全 Linux 生產環境」

LPIC-3 303-300 Security（版本 3.0）完整考試大綱 + 權重

權重說明：
數字越高＝題目越多、考試占比越重

• 5 = 高權重（核心必考）
• 4 = 次核心
• 3 = 中等
• 2 = 基礎理解

---

Topic 331：Cryptography（密碼學）

331.1 X.509 Certificates & PKI（權重：5 ⭐⭐⭐⭐⭐）

核心內容：

• X.509 憑證結構
• 公鑰基礎設施（PKI）
• CA（Certificate Authority）架構
• OpenSSL 操作
• TLS/SSL 信任鏈

必考能力：

• 建立 Root CA / Intermediate CA
• 簽發與撤銷證書
• 驗證 certificate chain

---

Topic 332：Host Security（主機安全）

332.1 Host Hardening（權重：5 ）

核心內容：

• BIOS / GRUB 安全
• systemd service hardening
• SELinux / AppArmor 基礎概念
• SSH CA 與憑證登入
• USBGuard 裝置控制
• kernel security（ASLR / DEP）
• chroot sandbox

重點技能：

• systemd 限制服務權限（capabilities / syscalls）
• SSH certificate-based authentication
• 系統最小權限化（least privilege）

---

332.2 Host Intrusion Detection（權重：5 ）

核心內容：

• auditd Linux 審計系統
• AIDE 檔案完整性檢查
• rootkit detection（chkrootkit / rkhunter）
• malware scanning（Linux Malware Detect）
• RPM / DPKG integrity check

必考能力：

• 建立 audit rule
• 分析 log（ausearch / aureport）
• 設計 host IDS 架構

---

332.3 Resource Control（權重：3 ）

核心內容：

• ulimit 限制資源
• cgroups（CPU / memory / IO）
• systemd slices / scopes
• process resource isolation

重點：

• 限制 service CPU / memory 使用
• cgroup v1 vs v2 基本概念

---

Topic 333：Access Control（存取控制）

333.1 DAC（Discretionary Access Control）（權重：3 ）

核心內容：

• Linux permissions（rwx / owner / group / others）
• SUID / SGID / sticky bit
• ACL（getfacl / setfacl）
• extended attributes（xattr）

必考：

• ACL 權限設計
• SUID/SGID 安全風險

---

333.2 MAC（Mandatory Access Control）（權重：5 ）

核心內容：

• SELinux（重點中的重點）
• type enforcement
• RBAC model
• AppArmor / Smack（概念）

必考能力：

• SELinux mode（enforcing/permissive）
• context 管理（chcon / restorecon）
• policy troubleshooting

---

Topic 334：Network Security（網路安全）

334.1 Network Hardening（權重：4 ）

核心內容：

• Wireshark / tcpdump 分析封包
• wireless security
• rogue DHCP / router attack
• FreeRADIUS
• network traffic inspection

必考：

• 封包分析與 filter
• 無線網路攻擊識別

---

334.2 Network Intrusion Detection（權重：4 ）

核心內容：

• IDS / IPS 系統
• network monitoring tools
• traffic anomaly detection
• log correlation

重點：

• Snort / Suricata（概念級）
• network behavior analysis

---

334.4 VPN（權重：4 ）

核心內容：

• OpenVPN
• IPsec / strongSwan
• WireGuard
• IKEv2
• site-to-site vs remote access VPN

必考能力：

• VPN 架構設計
• WireGuard config
• IPsec negotiation 基本概念

---

Topic 335：Threats & Vulnerability（威脅與弱點）

335.1 Security Threats（權重：2 ）

核心內容：

• malware（trojan / virus / rootkit）
• DoS / DDoS
• phishing / social engineering
• injection attacks（SQL/XSS/CSRF）
• privilege escalation

特點：
幾乎是「概念題」，不深挖配置

---

335.2 Penetration Testing（權重：3 ）

核心內容：

• ethical hacking 流程
• pentest phases（recon → exploit → maintain）
• nmap 使用（掃描 / OS detection / NSE）
• Metasploit 架構
• Kali Linux 工具概念

必考：

• nmap scan type（SYN / TCP / version scan）
• penetration testing 流程順序

---

全考試權重總覽（重點地圖）

類別	權重	重要性
Cryptography	5	⭐⭐⭐⭐⭐
Host Hardening	5	⭐⭐⭐⭐⭐
Host IDS	5	⭐⭐⭐⭐⭐
MAC / SELinux	5	⭐⭐⭐⭐⭐
Network Security	4	⭐⭐⭐⭐
VPN	4	⭐⭐⭐⭐
Resource Control	3	⭐⭐⭐
DAC / ACL	3	⭐⭐⭐
Pentest	3	⭐⭐⭐
Threat Concepts	2	⭐⭐

---

考試結構重點結論（非常重要）

LPIC-3 303-300 的本質：

「Linux Enterprise Security Architect」

不是：

• 單純 Linux 指令考試
• 記憶型考試

而是：

• 安全架構設計
• 主機防護
• 企業級安全治理