結論先講
好的 Infra/DevOps 工程師不是「會在 AWS console 上點來點去」的人，也不是「CI/CD pipeline 工程師」。是能讓系統穩定運行、快速部署、出事時快速恢復的人。
如果你只會 docker run、只會複製貼上 Terraform 範例、監控只設了「CPU > 90% 就告警」——你可能還在入門階段。這篇幫你看清楚好的 Infra 工程師需要的完整能力。
1. Linux 基礎：不只是會下指令
DevOps 的底層是 Linux。你不需要從頭編譯 kernel，但你需要理解作業系統在做什麼。
Process 管理：
ps、top、htop只是入口- 理解 PID、PPID、zombie process、orphan process
- 知道 signal 是什麼（
SIGTERMvsSIGKILL的差別很重要） - systemd 的基本操作（
systemctl、journalctl）
檔案系統：
- inode 的概念（為什麼「磁碟還有空間但無法建立檔案」？）
- 檔案權限不只是
chmod 777（那代表你放棄了所有安全） /proc和/sys是系統的窗戶，不是不能碰的東西- 常用的除錯：
lsof（誰開了這個檔案）、df/du（空間去哪了）
你該能回答的問題：
- 一個 process 跟一個 thread 差在哪？
- OOM Killer 是什麼？為什麼我的 process 被殺了？
- swap 是什麼？什麼時候該關掉？
- 為什麼
rm一個大檔案後，磁碟空間沒有增加？
2. 網路概念：不只是「通了就好」
| 概念 | 你該知道什麼 | 常見問題場景 |
|---|---|---|
| DNS | A、CNAME、TTL、遞迴查詢 | 換 IP 後為什麼還是連到舊的？ |
| TCP/IP | 三次握手、TIME_WAIT、MSS | 為什麼連線數爆了？ |
| HTTP/HTTPS | TLS 握手流程、HTTP/2 | 為什麼 SSL 憑證過期了沒人知道？ |
| Load Balancer | L4 vs L7、health check | 為什麼 502 一直出現？ |
| CDN | cache hit/miss、purge | 為什麼改了但使用者看到舊的？ |
| Firewall | iptables/Security Group | 為什麼連不上？ |
除錯工具箱：
dig/nslookup：DNS 問題curl -v：HTTP 層問題tcpdump/wireshark：封包層問題traceroute/mtr：路由問題ss/netstat：連線狀態
真實案例：某服務間歇性 timeout。用
ss發現大量TIME_WAIT狀態的連線。原因是 connection pool 設定不當，每個 request 都建新連線。修復方式：調整 connection pool 設定，順便加了 keepalive。
3. Container：不只是 docker run
會把 app 包進 Docker 只是起點。好的 Infra 工程師要考慮更多。
Dockerfile 最佳化：
| 做法 | 為什麼 |
|---|---|
| 用 multi-stage build | 最終 image 不需要 build tool |
| 把不常變的層放前面 | 利用 layer cache 加速 build |
用 .dockerignore | 不要把 node_modules 和 .git 複製進去 |
不要用 latest tag | 不可重現，遲早出事 |
| 不要用 root 執行 | 安全基本原則 |
| 選對 base image | alpine 小但有時相容性差，slim 通常是好選擇 |
Orchestration（編排）：
Docker Compose 適合開發環境，但 production 需要更多：
- Kubernetes：業界標準，但學習曲線陡。如果團隊小，考慮 managed K8s（EKS/GKE/AKS）
- 你該懂的 K8s 概念：Pod、Deployment、Service、Ingress、ConfigMap/Secret、HPA
- 你不需要第一天就會的：Custom Operator、Service Mesh、eBPF
Container 安全：
- 定期掃描 image 漏洞（Trivy、Snyk）
- 不要在 image 裡放 secrets
- Read-only filesystem（如果可以的話）
- Network policy 限制 pod 間通訊
4. IaC 思維：為什麼不在 Console 上點
Infrastructure as Code 不是工具選擇，是思維方式。
為什麼要 IaC：
| 手動操作 | IaC |
|---|---|
| 「那個設定是誰改的？」 | Git blame 就知道 |
| 「能不能再建一個一模一樣的環境？」 | terraform apply |
| 「staging 跟 production 差在哪？」 | diff 兩個檔案 |
| 「新人要多久才能上手環境？」 | 看 code 就懂 |
工具選擇：
| 工具 | 特色 | 適合 |
|---|---|---|
| Terraform | 宣告式、多雲、社群大 | 大多數場景 |
| Pulumi | 用程式語言寫 IaC | 不想學 HCL 的團隊 |
| CloudFormation | AWS 原生 | 全 AWS 的團隊 |
| Ansible | 設定管理、imperative | VM 設定、一次性任務 |
IaC 的紀律：
- 所有環境變更都走 code review
- State file 存在遠端（S3 + DynamoDB lock）
- 不要手動改 console（改了就跟 code 不同步了）
- Module 化：重複使用，不要複製貼上
5. 監控哲學：Metrics vs Logs vs Traces
監控不是「設幾個告警就好」。好的監控讓你在用戶發現問題之前就知道出事了。
三根支柱：
| 類型 | 回答什麼問題 | 工具範例 |
|---|---|---|
| Metrics | 系統現在怎麼樣？趨勢是什麼？ | Prometheus + Grafana |
| Logs | 剛剛到底發生了什麼事？ | ELK Stack、Loki |
| Traces | 一個 request 在各個服務間走了什麼路徑？ | Jaeger、Datadog APM |
告警設計原則：
- 告警要 actionable：收到告警後你知道要做什麼。「CPU 高」不是好告警，「訂單 API P99 延遲超過 2 秒」是
- 減少噪音：告警太多 = 沒有告警。大家會開始忽略
- 分級：P1（立即處理，用戶受影響）、P2（盡快處理）、P3（工作時間處理）
- SLO-based alerting：基於服務等級目標來設告警，不是基於資源使用率
Golden Signals（Google SRE 的黃金訊號）：
- Latency：request 回應時間
- Traffic：request 量
- Errors：錯誤率
- Saturation：系統容量還剩多少
比起監控 CPU 使用率，你更應該監控 error rate 和 latency。CPU 80% 但一切正常 = 沒問題。CPU 20% 但 error rate 暴增 = 大問題。
6. Incident Response：出事了怎麼辦
出事是正常的。重要的是你怎麼處理。
On-Call 的基本紀律：
- 收到 page 在 X 分鐘內回應（通常 5-15 分鐘）
- 先止血，再找根因（先把服務恢復，再慢慢查為什麼壞）
- 溝通比修復重要（讓相關人知道狀況）
Runbook 該有什麼：
| 區塊 | 內容 |
|---|---|
| 症狀 | 什麼告警觸發了？用戶看到什麼？ |
| 影響範圍 | 誰受影響？嚴重程度？ |
| 診斷步驟 | 一步一步怎麼確認問題 |
| 修復步驟 | 怎麼止血？怎麼根治？ |
| 升級路徑 | 解決不了找誰？ |
Postmortem（事後檢討）：
- Blameless：不是找誰的錯，是找系統的問題
- 時間軸：什麼時間點發生了什麼
- 根因分析：用 5 Whys 或 Fishbone diagram
- Action items：具體的改善措施，有 owner 有 deadline
- 分享：讓整個團隊學到教訓
好的 Infra 工程師不是「讓系統永不出事」的人（那不可能），是「出事時能快速恢復，而且同樣的事不會出第二次」的人。
7. Junior vs Senior 能力對比表
| 面向 | Junior | Senior |
|---|---|---|
| Linux | 會下基本指令 | 理解 OS 層面，能從系統層面除錯 |
| 網路 | 知道 IP 和 port | 能從封包層面分析問題 |
| Container | 會 docker run | 能設計 container 策略、優化 image、管理 orchestration |
| IaC | 會跑 terraform apply | 能設計 module、管理 state、建立 IaC 規範 |
| 監控 | 設幾個基本告警 | 設計完整的 observability 策略 |
| Incident | 出事會緊張 | 冷靜處理、有系統的診斷和溝通 |
| CI/CD | 會寫 pipeline | 設計部署策略（canary、blue-green）、rollback 機制 |
| 安全 | 知道要注意 | 實踐 security hardening、定期掃描和更新 |
FAQ
Q1: DevOps 和 SRE 有什麼不同？
DevOps 是文化和實踐（打破 Dev 和 Ops 的牆），SRE 是 Google 提出的具體實踐方式（用軟體工程方法做運維）。SRE 更強調 SLO/SLI/Error Budget 的概念。在很多公司，這兩個角色的工作內容高度重疊。
Q2: 要考 AWS 認證嗎？
如果你在找工作，Solutions Architect Associate 是個不錯的敲門磚。但認證不等於能力。實際操作經驗比證照重要。建議：先做專案，再去考認證（這樣準備起來也比較快）。
Q3: 要學 Kubernetes 嗎？
如果你的目標是 Infra/DevOps，2026 年 K8s 是必修。但不要一開始就學。先把 Docker 用熟，理解 networking 和 Linux，再學 K8s 會快很多。直接跳進 K8s 你只會被 YAML 淹沒。
Q4: Infra 工程師需要會寫程式嗎？
需要。不一定要寫 production code，但你要能寫 script（Bash/Python）、IaC code（Terraform/Pulumi）、小工具。好的 Infra 工程師會用程式解決重複性的工作，而不是每次都手動操作。
Q5: 從後端轉 DevOps 需要補什麼？
主要補 Linux 系統管理、網路、雲端服務、IaC 工具。你的優勢是理解應用程式怎麼運作，這在 DevOps 非常有用。建議從幫自己的 side project 建一套完整的 CI/CD + 監控開始。
系列導航
- [01] 好的前端工程師需要什麼能力？
- [02] 好的後端工程師需要什麼能力？
- [03] 好的 Infra/DevOps 工程師需要什麼能力？ ← 你在這裡
- [04] 好的全端工程師：廣度和深度怎麼平衡？
- [05] 好的 Tech Lead 需要什麼？
- [06] Junior 和 Senior 的真正差距