senior-devops

高级 DevOps 工程师

概述

设计、构建和维护生产基础设施及部署流水线。本技能涵盖 Docker 容器化、Kubernetes 编排、使用 GitHub Actions 实现 CI/CD、使用 Terraform/Pulumi 实现基础设施即代码、使用 Prometheus/Grafana 进行监控、告警策略、零停机部署以及回滚流程。

阶段 1：基础设施设计

1. 确定部署拓扑（单服务器、集群、多区域）
2. 选择容器化策略（Docker、Buildpacks）
3. 选择编排平台（Kubernetes、ECS、Cloud Run）
4. 规划网络（负载均衡器、DNS、TLS）
5. 设计密钥管理方案

停止 — 在实施前向用户展示基础设施设计并征得批准。

基础设施决策表

规模	拓扑	编排	推荐方案
个人项目 / MVP	单服务器	Docker Compose	Railway、Fly.io
初创公司（< 100k 用户）	小型集群	ECS、Cloud Run	AWS ECS、GCP Cloud Run
成长期（100k - 1M 用户）	多可用区集群	Kubernetes	EKS、GKE
企业级（1M+ 用户）	多区域	Kubernetes + 服务网格	EKS/GKE + Istio
高合规要求	专用云 / 私有云	Kubernetes	自行管理的 K8s

阶段 2：流水线实施

1. 构建 CI 流水线（lint、测试、构建、安全扫描）
2. 构建 CD 流水线（部署到预发布环境、生产环境）
3. 配置特定于环境的设置
4. 设置制品注册表（容器镜像、软件包）
5. 实施部署策略（蓝绿、金丝雀、滚动）

停止 — 验证流水线配置语法，并提交审查。

阶段 3：可观测性

1. 部署监控技术栈（Prometheus、Grafana）
2. 配置告警规则和升级流程
3. 设置日志聚合
4. 实施分布式追踪
5. 为常见事件编写运行手册

停止 — 在宣布完成前，确认监控覆盖所有关键服务。

Dockerfile 最佳实践

# 1. Use specific version tags (not :latest)
FROM node:20-alpine AS base

# 2. Set working directory
WORKDIR /app

# 3. Install dependencies in separate layer (cache optimization)
FROM base AS deps
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile --prod

FROM base AS build-deps
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile

# 4. Build in separate stage
FROM build-deps AS builder
COPY . .
RUN pnpm build

# 5. Production image — minimal size
FROM base AS runner
ENV NODE_ENV=production

# 6. Don't run as root
RUN addgroup --system --gid 1001 app && \
    adduser --system --uid 1001 app
USER app

# 7. Copy only what's needed
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist

# 8. Health check
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s \
  CMD wget -qO- http://localhost:3000/health || exit 1

# 9. Expose port and set entrypoint
EXPOSE 3000
CMD ["node", "dist/server.js"]

Dockerfile 关键规则

规则	原因
多阶段构建	尽可能缩小镜像体积
.dockerignore 文件	排除 node_modules、.git、tests
非 root 用户	加强安全性
指定基础镜像版本	确保构建可复现
图层排序（依赖项在源代码之前）	提高缓存效率
HEALTHCHECK 指令	监控容器健康状况
构建参数 / 图层中不包含密钥	防止凭证泄露

Docker Compose 模式

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      target: runner
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgresql://postgres:postgres@db:5432/app
      - REDIS_URL=redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
      interval: 10s
      timeout: 5s
      retries: 3

  db:
    image: postgres:16-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5

  cache:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

GitHub Actions 工作流

name: CI/CD
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm typecheck
      - run: pnpm test -- --coverage

  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx audit-ci --moderate
      - uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          severity: HIGH,CRITICAL

  build-and-push:
    needs: [lint-and-test, security-scan]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Deploy to production
        run: echo "Deploying ${{ github.sha }}"

Terraform / Pulumi 模式

Terraform 结构

modules/
  vpc/
    main.tf, variables.tf, outputs.tf
  ecs/
    main.tf, variables.tf, outputs.tf
environments/
  staging/
    main.tf, terraform.tfvars
  production/
    main.tf, terraform.tfvars

IaC 关键规则

规则	原因
远程状态后端（S3 + DynamoDB）	共享状态、锁定
状态锁定	防止并发修改
特定于环境的变量文件	分离关注点
模块版本控制	确保共享基础设施可复现
在 CI 中运行 terraform plan	在执行 apply 前发现问题
按计划检测漂移	检测手动更改
为所有资源添加标签	标明所有权、分配成本

监控（Prometheus + Grafana）

USE 方法（资源）

资源	利用率	饱和度	错误
CPU	cpu_usage_percent	cpu_throttled	—
内存	memory_usage_bytes	oom_kills	—
磁盘	disk_usage_percent	io_wait	disk_errors
网络	bytes_total	queue_length	errors_total

RED 方法（服务）

• 速率：每秒请求数
• 错误：每秒错误率
• 持续时间：延迟分布（p50、p95、p99）

告警规则

groups:
  - name: app-alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
      - alert: HighLatency
        expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1
        for: 5m
        labels:
          severity: warning

告警最佳实践

实践	原因
针对症状而非原因发出告警	减少噪声，聚焦影响
每条告警都附有运行手册链接	便于快速响应
分级设置严重程度	critical=页面通知，warning=工单，info=日志
告警前先聚合	避免告警抖动
每季度审查并精简	防止告警疲劳

零停机部署策略

策略	工作原理	风险	回滚速度
滚动部署	逐个替换实例	低	中等
蓝绿部署	在两个环境之间切换流量	低	即时
金丝雀发布	将少量流量导向新版本，再逐步增加	非常低	即时
功能标志	部署未启用的代码，通过标志启用	非常低	即时

回滚流程

1. 自动回滚：健康检查失败 -> 自动回滚
2. 手动回滚：kubectl rollout undo deployment/app
3. 数据库：采用仅向前且向后兼容的迁移
4. 配置：通过密钥管理器版本回退

数据库迁移安全性

规则	原因
迁移必须向后兼容	旧代码与新架构必须能够正常运行
不要在同一次部署中重命名或删除列	需要分两个阶段进行更改
分两个阶段：添加列 -> 部署 -> 删除旧列	实现零停机架构演进
始终测试每次迁移的回滚	确保可以撤销

反模式 / 常见错误

反模式	错误原因	应采取的做法
手动部署到生产环境	没有审计记录，容易出错	通过 CI/CD 自动化
共用或硬编码密钥	存在安全漏洞风险	使用密钥管理器
部署前没有回滚计划	部署失败时会陷入困境	每次部署前记录回滚方案
将 latest 标签用于生产镜像	无法复现	固定具体版本标签
以 root 身份运行容器	存在安全漏洞	在 Dockerfile 中使用非 root 用户
无法采取行动的告警导致告警疲劳	真实问题会被遗漏	针对症状设置告警，调整阈值
跳过预发布环境	在生产环境中才发现错误	始终先部署到预发布环境
手动配置的雪花服务器	无法复现，也无法扩展	将基础设施作为代码管理
监控但不设置告警	无人会注意到问题	将告警接入监控

核心原则

• 基础设施即代码——不对生产环境进行手动更改
• 不可变基础设施——替换，而不是修补
• 服务器是牛，不是宠物——服务器可以随时替换
• 将安全左移——在流水线早期进行扫描
• 最小权限——所有地方都只授予最低限度的权限
• 对运行超过两次的所有操作实现自动化
• 定期测试灾难恢复计划

文档查询（Context7）

使用 mcp__context7__resolve-library-id，然后使用 mcp__context7__query-docs 获取最新文档。返回的文档优先于记忆中的知识。

• docker — 用于 Dockerfile 语法、compose 配置或多阶段构建
• kubernetes — 用于资源清单、kubectl 命令或 Helm 图表
• terraform — 用于提供程序配置、资源块或状态管理

---

集成点

技能	集成方式
deployment	提供更高层级的部署流水线编排
security-review	CI 流水线中的安全扫描阶段
planning	像规划功能一样规划基础设施更改
verification-before-completion	部署后验证关卡
finishing-a-development-branch	合并会触发部署流水线
mcp-builder	MCP 服务需要容器化和部署

技能类型

灵活 — 根据项目的云服务提供商、团队规模和运维成熟度调整工具与模式。原则（IaC、不可变性、可观测性）始终不变；具体工具可以互换。