[standards/05] 好的基礎建設需要什麼？從 CI/CD 到災難恢復

結論先講

基礎建設是那種做得好沒人感謝你、做得爛所有人罵你的東西。你的程式碼寫得再漂亮，infra 垮了就是全部掛掉。

好的 infra 有一個核心精神：可預測、可重現、可恢復。不是用手動 SSH 進機器改設定，而是每一個環境都能從零用程式碼建起來。這篇列出 12 個基礎建設的檢查點。

體檢清單

1. CI/CD Pipeline

這是現代軟體開發的基本，沒有 CI/CD 的團隊基本上還活在石器時代。

# GitHub Actions 基本範例
name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm run test
      - run: npm run build

每次 push 自動跑 lint + test + build
PR 有預覽環境
主分支合併自動部署
有 rollback 機制

（詳細的 CI/CD 清單請看第 06 篇）

2. 容器編排（Container Orchestration）

# docker-compose.yml 基本版
services:
  web:
    build: .
    ports: ["3000:3000"]
    environment:
      - DATABASE_URL=postgres://db:5432/app
    depends_on: [db, redis]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      retries: 3
 
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
 
  redis:
    image: redis:7-alpine

用 Docker 容器化（不是直接跑在裸機上）
開發環境用 Docker Compose
生產環境用 Kubernetes 或 managed service（ECS、Cloud Run）
有 health check

3. 監控（Metrics + Logs + Traces）

三根支柱，缺一不可：

支柱	回答什麼問題	工具
Metrics	系統現在怎樣？	Prometheus、Datadog
Logs	發生了什麼事？	ELK、Loki、CloudWatch
Traces	請求經過哪些服務？	Jaeger、Tempo、Zipkin

基本系統指標（CPU、記憶體、磁碟）
應用程式指標（request rate、error rate、latency）
集中式日誌
分散式追蹤（如果是微服務）

（詳細的監控清單請看第 07 篇）

4. 告警（Alerting）

有告警規則（不是只看 dashboard）
告警分級（P1 立即處理、P2 上班時間處理）
有值班輪值
不要 alert fatigue（太多假警報會讓人麻痺）

5. 機密管理（Secrets Management）

# 不好：寫在程式碼裡
DATABASE_URL = "postgres://admin:password123@db:5432/app"
 
# 不好：寫在 .env 然後 commit 進 git
# .env
DATABASE_URL=postgres://admin:password123@db:5432/app
 
# 好：使用 secrets manager
aws secretsmanager get-secret-value --secret-id prod/database

工具	適用場景
AWS Secrets Manager	AWS 生態圈
HashiCorp Vault	跨雲、自架
GitHub Secrets	CI/CD 階段
Doppler	多環境管理
SOPS	Git-friendly 加密

機密不在程式碼或 git 裡
使用 Secrets Manager
機密可以 rotate（不用重新部署）
最小權限原則

6. Auto-scaling

# Kubernetes HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

CPU/Memory 超過閾值自動增加 instance
有最小和最大 instance 數量限制
有 cooldown period（避免頻繁伸縮）
伸縮事件有通知

7. Load Balancing

Application Load Balancer（L7）
Health check 自動移除不健康的 instance
SSL termination 在 LB 層
Session affinity（如果需要的話）

8. CDN

靜態資源走 CDN（圖片、CSS、JS）
有 cache invalidation 策略
有地理分佈（離使用者近的節點）

CDN	特色
Cloudflare	免費方案很夠用、DDoS 防護
AWS CloudFront	AWS 整合好
Fastly	Edge computing、即時清除快取
Bunny CDN	價格便宜、亞洲節點多

9. 備份與災難恢復

RPO (Recovery Point Objective): 可以接受損失多少資料？
  → 決定備份頻率

RTO (Recovery Time Objective): 停機多久可以接受？
  → 決定恢復策略

策略	RPO	RTO	成本
冷備份	24h	數小時	低
暖備份	1h	30min	中
熱備份	接近 0	分鐘級	高
多區域主動	0	秒級	很高

有定義 RPO 和 RTO
資料庫有備份（且定期測試恢復）
有 disaster recovery plan（寫下來的，不是在腦中的）
至少每年做一次 DR 演練

10. 環境分離

Production  ──→ 真正的使用者
Staging     ──→ 跟 Production 一樣的環境，QA 測試用
Development ──→ 開發者測試用

至少有 dev + staging + production 三個環境
環境間完全隔離（不同的資料庫、不同的 API key）
Staging 盡量跟 Production 一致

11. Infrastructure as Code（IaC）

如果你的 infra 不能用程式碼重建，那就不算 infra，那叫手藝。

# Terraform 範例
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
 
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}
 
resource "aws_rds_instance" "db" {
  engine         = "postgres"
  engine_version = "16"
  instance_class = "db.t3.medium"
  storage        = 100
 
  backup_retention_period = 7
  multi_az               = true
}

工具	適用場景
Terraform	跨雲、最通用
Pulumi	用程式語言寫 IaC
AWS CDK	AWS 專用
Ansible	組態管理

所有 infra 用程式碼定義
IaC 在版本控制裡
有 code review 流程
可以從零重建整個環境

12. Security Scanning

依賴套件漏洞掃描（Dependabot、Snyk）
Container image 掃描（Trivy）
SAST（靜態程式碼分析）
定期滲透測試

成熟度模型

等級	描述	具備項目
L1 基本	能跑	Docker、CI/CD、基本備份
L2 可靠	不容易掛	監控、告警、auto-scaling、IaC
L3 成熟	掛了能快速恢復	DR plan、multi-AZ、secrets management
L4 卓越	可觀測性完整	三根支柱、SLO、chaos engineering

大部分團隊在 L1-L2 之間。做到 L3 就已經很不錯了。

FAQ

Q1: 小團隊需要 Kubernetes 嗎？

大部分情況下不需要。Kubernetes 的學習曲線和運維成本很高。小團隊用 Docker Compose + managed service（AWS ECS、Google Cloud Run、Railway）就夠了。除非你有超過 10 個微服務要管理。

Q2: IaC 從什麼時候開始做？

越早越好。從第一台 server 就開始用 Terraform 或 Pulumi。一旦你開始手動建資源，後面要補 IaC 會非常痛苦（因為要 import 已存在的資源）。

Q3: 需要多區域部署嗎？

看你的 SLA 要求。如果你承諾 99.99% uptime，那需要。如果 99.9% 就好，單區域 + multi-AZ 就夠了。多區域的成本和複雜度會翻倍。

Q4: 用哪家雲比較好？

AWS 生態圈最大、功能最多；GCP 的 Kubernetes（GKE）和 AI/ML 很強；Azure 適合微軟生態圈的企業。小團隊可以考慮 DigitalOcean、Hetzner 這種比較便宜的選擇。

Q5: 災難恢復演練真的要做嗎？

一定要。Netflix 的 Chaos Monkey 就是這個概念。你不需要那麼極端，但至少每年做一次：把備份拿出來恢復、試著切換到備援環境、確認告警有正常觸發。很多團隊的備份其實是壞的，但到出事那天才發現。

系列導航

#	文章	狀態
01	好的前端專案該有什麼？一張體檢表
02	好的後端框架需要具備哪些功能？
03	好的 API 該長什麼樣？
04	好的資料庫設計需要什麼？
05	好的基礎建設需要什麼？從 CI/CD 到災難恢復	📍 你在這裡
06	CD Pipeline 需要什麼？
07	好的監控系統需要什麼？
08	好的開發者體驗（DX）需要什麼？

Terry Yao's Blog

分類

目錄