🚀 从DevOps到AIOps

60分钟看清现代交付的来龙去脉

听完能带走：

• 为什么要演进：交付瓶颈、线上风险、业务压力
• 怎么起步：流水线/IaC/度量的优先级排序
• 如何向前：把GitOps、可观测、AIOps接到现有体系

今日行程

• 演进概览 (10m)：历史+动因
• 基础篇 (10m)：敏捷、协作、度量
• 核心篇 (15m)：CI/CD、容器、K8s、IaC
• 进阶篇 (10m)：GitOps、DevSecOps、可观测
• 前沿篇 (5m)：平台工程、AIOps趋势
• Q&A (5m)

🙋 破冰 & 现状盘点

请举手或在弹幕答：

• 发布频率：一周几次？是否有自动回滚？
• 平台：是否在用Kubernetes/容器？还是VM为主？
• 交付链路：有CI/CD吗？测试覆盖率大概多少？
• 观测：是否有日志+指标+链路的统一入口？
• 安全：密钥/镜像/依赖扫描是否自动化？

(根据反馈决定讲解深度与案例)

📅 演进时间线

2001-2024：从流程革命到智能化运维

🗺️ 演进路线图

flowchart TB
    A[2001 敏捷宣言\n以变应变] --> B[2009 DevOps\n拆墙+自动化]
    B --> C[2013 Docker\n一次打包]
    C --> D[2014 Kubernetes\n调度与弹性]
    D --> E[2017 GitOps\n声明式拉取]
    E --> F[2020+ AIOps\n数据驱动运维]

    style A fill:#e1f5fe,stroke:#90caf9
    style B fill:#fff9c4,stroke:#fbc02d
    style C fill:#e0f7fa,stroke:#4dd0e1
    style D fill:#e1bee7,stroke:#ab47bc
    style E fill:#c5e1a5,stroke:#8bc34a
    style F fill:#ffccbc,stroke:#ff7043

💔 传统开发的痛点

┌─────────────────────────────┐
│        开发团队 👨‍💻           │
│   "代码写完了！"              │
└──────────────┬──────────────┘
               │
               ▼
        ┌──────────┐
        │   墙 🧱   │  ← 对立与冲突
        └──────────┘
               │
               ▼
┌─────────────────────────────┐
│        运维团队 🔧           │
│   "这周末不能部署！"          │
└─────────────────────────────┘

常见症状 (真实工程团队现状):

• 周末上线窗口、回滚流程临时找人
• 测试/预发/生产环境配置不一致，问题难复现
• 缺乏自动化测试，质量靠加班和人工巡检
• 需求、开发、运维分摊责任，MTTR/Lead Time没有负责人

🔄 敏捷开发 (Agile)

DevOps的文化和节奏基础

对工程师最直接的四件事

• 小批量迭代：1-2周一个可运行版本
• 持续反馈：业务/运维加入评审，提前暴露约束
• 可工作的软件：文档和流程为代码落地服务
• 拥抱变化：自动化和可观测性是频繁变更的安全网

Scrum vs Kanban

🏃 SCRUM                  🌊 KANBAN
┌────────────────┐       ┌────────────────┐
│  Sprint 1      │       │ To Do │ Doing │Done│
│  ┌──┐┌──┐┌──┐  │       │ ┌──┐  │ ┌──┐  │┌──┐│
│  │任││务││列│  │       │ │  │  │ │  │  ││  ││
│  │务││  ││表│  │       │ └──┘  │ └──┘  │└──┘│
│  └──┘└──┘└──┘  │       │ ┌──┐  │       │┌──┐│
│  Sprint 2      │       │ │  │  │       ││  ││
│  ...           │       │ └──┘  │       │└──┘│
└────────────────┘       └────────────────┘
  时间盒迭代                持续流动
  1-4周为单位              无固定周期

选择建议

• Scrum：特性开发团队，需要节奏感和仪式感
• Kanban：平台/运维团队，追求吞吐与在制品可控

🌉 DevOps革命

共同目标：稳定地更快交付价值

CALMS（落地解读）

C - Culture：一个跨职能团队对SLO和业务结果负责 A - Automation：流水线、测试、IaC、自动回滚 L - Lean：减少等待/返工，限制在制品 M - Measurement：用DORA指标、SLO、错误预算做决策 S - Sharing：经验、工具、运营手册可被复用

♾️ DevOps无限循环

flowchart LR
    A[Plan] --> B[Code]
    B --> C[Build]
    C --> D[Test]
    D --> E[Release]
    E --> F[Deploy]
    F --> G[Operate]
    G --> H[Monitor]
    H --> A

    style A fill:#667eea
    style B fill:#764ba2
    style C fill:#f093fb
    style D fill:#f5576c
    style E fill:#4facfe
    style F fill:#00f2fe
    style G fill:#43e97b
    style H fill:#38f9d7

解读

• Plan→Test：左移质量，开发阶段就收敛风险
• Release→Deploy：流水线标准化，支持蓝绿/金丝雀
• Operate→Monitor：用观测数据驱动下一轮迭代

🔄 CI/CD流水线

flowchart LR
    subgraph CI[持续集成]
        A[📝 代码提交] --> B[🔨 构建]
        B --> C[🧪 单元测试]
        C --> D[🔍 代码检查]
    end

    subgraph CD[持续交付]
        D --> E[📦 打包]
        E --> F[🧪 集成测试]
        F --> G[🚀 部署测试环境]
    end

    subgraph PROD[生产]
        G --> H[✅ 人工审批]
        H --> I[🌐 生产部署]
        I --> J[📊 监控]
    end

    J -.->|反馈| A

各阶段关注点

• CI：快速失败，10分钟内反馈；静态检查、单测覆盖度可见
• CD：自动化到可验证环境；部署策略和回滚脚本同样版本化
• Prod：受控审批，发布后监控基线+自动回滚钩子

🏗️ 微服务架构

从单体到分布式：收益与代价

何时拆分

• 业务域清晰、接口稳定，团队能承担运维复杂度时
• 前提：自动化测试+CI/CD+观测到位，否则故障面更大

🌐 微服务架构图

flowchart TB
    Client[📱 客户端] --> Gateway[🚪 API Gateway]

    Gateway --> User[👤 用户服务]
    Gateway --> Order[📦 订单服务]
    Gateway --> Pay[💳 支付服务]

    User --> DB1[(用户DB)]
    Order --> DB2[(订单DB)]
    Pay --> DB3[(支付DB)]

    Order <-->|消息队列| Pay

    subgraph Infra[基础设施]
        Monitor[📊 监控]
        Config[⚙️ 配置中心]
        Registry[📋 服务注册]
    end

    User & Order & Pay --> Infra

关键构件

• API Gateway：鉴权、限流、路由、A/B
• Config/Registry：让服务启动即发现同伴
• MQ：解耦高耦合流程，削峰填谷
• 观测：调用链跨服务，便于定位

🐳 容器化革命

Docker的三大价值

┌─────────────────────────────────┐
│         传统部署问题            │
│  "在我机器上能运行啊！" 😱      │
└─────────────────────────────────┘
              ↓
┌─────────────────────────────────┐
│         Docker解决方案          │
│  "打包一次，到处运行" 😊        │
│  ┌─────┐ ┌─────┐ ┌─────┐       │
│  │App │ │Deps │ │Conf │       │
│  └──┬──┘ └──┬──┘ └──┬──┘       │
│     └───────┴───────┘          │
│        📦 Container            │
└─────────────────────────────────┘

• 一致性：镜像不可变，Dev/QA/Prod同一包
• 可移植：运行时标准化，换云/换机器无痛
• 效率：层缓存+镜像仓库，发布速度秒级
• 安全：最小镜像、只读文件系统、按需运行时权限

☸️ Kubernetes架构

flowchart TB
    subgraph Master[Control Plane]
        API[API Server]
        ETCD[(etcd)]
        Sched[Scheduler]
        CM[Controller Manager]
    end

    subgraph Node1[Worker Node 1]
        Kubelet1[Kubelet]
        Pod1[Pod 🐳]
        Pod2[Pod 🐳]
    end

    subgraph Node2[Worker Node 2]
        Kubelet2[Kubelet]
        Pod3[Pod 🐳]
        Pod4[Pod 🐳]
    end

    API --> Kubelet1
    API --> Kubelet2
    API <--> ETCD
    Sched --> API
    CM --> API

K8s解决的问题

• 调度：把Pod放到合适的节点，保证资源隔离
• 弹性：副本、滚动升级、自愈/重建
• 服务抽象：Service/Ingress屏蔽IP漂移，支持流量策略
• 可移植：声明式API，换云保持一致

📦 Helm - K8s包管理

flowchart LR
    Chart[📦 Helm Chart] --> Values[⚙️ values.yaml]
    Values --> Template[📄 Templates]
    Template --> Release[🚀 Release]
    Release --> K8s[☸️ K8s Resources]

价值

• 可复用包：一套Chart服务多个环境
• 参数化：values.yaml承载环境差异
• 版本化：Release历史=回滚方案

🔄 GitOps

Git = 唯一真相来源

为什么更稳

• 声明式：环境所需状态清晰可读
• 可审计：每次变更都有记录、代码评审
• 拉取式：集群自己同步，避免管道推送导致漂移
• 自愈：真实状态偏离时自动对齐或告警

🔄 GitOps工作流

sequenceDiagram
    participant Dev as 👨‍💻 开发者
    participant Git as 📁 Git仓库
    participant Op as 🤖 GitOps Operator
    participant K8s as ☸️ Kubernetes

    Dev->>Git: 1. 提交配置变更
    Git->>Op: 2. Operator检测变更
    Op->>K8s: 3. 拉取并应用配置
    K8s->>Op: 4. 报告状态
    Op-->>Git: 5. 更新状态

    Note over K8s,Op: 持续协调：检测drift自动修正

对比传统CI/CD

• 从Push改成Pull；CI负责构建镜像，CD由Operator拉取配置
• 回滚=git revert；版本对齐靠tag/分支策略

🔒 DevSecOps

安全左移 + 全链路

传统方式                DevSecOps
开发 → 测试 → 安全 → 上线   开发+安全 → 测试+安全 → 上线
              ↑                ↑             ↑
          最后检查           持续检查       持续检查

发现问题：晚期               发现问题：早期
修复成本：高                 修复成本：低

目标

• 把安全测试嵌入流水线，不做末端闸门
• 让开发看得懂风险；安全团队提供策略和工具

🛡️ 安全工具链

flowchart LR
    subgraph Code[代码阶段]
        SAST[🔍 SAST]
        Secrets[🔑 密钥扫描]
    end

    subgraph Build[构建阶段]
        SCA[📦 依赖扫描]
        Image[🐳 镜像扫描]
    end

    subgraph Test[测试阶段]
        DAST[🎯 DAST]
        Pentest[🔓 渗透测试]
    end

    subgraph Runtime[运行时]
        RASP[🛡️ 运行时保护]
        Monitor[👁️ 威胁监控]
    end

    Code --> Build --> Test --> Runtime

常用工具示例

• SAST: SonarQube / CodeQL
• Secrets: gitleaks / git-secrets
• SCA/镜像: Snyk, Trivy, Anchore
• Runtime: Falco, WAF, EDR

👁️ 可观测性

从“知道挂了”到“知道为何、提前预防”

监控 Monitoring              可观测性 Observability
┌──────────────────┐        ┌──────────────────┐
│ 已知问题的告警   │        │ 探索未知问题     │
│ 预设阈值触发     │        │ 任意维度查询     │
│ "发生了什么"     │        │ "为什么发生"     │
└──────────────────┘        └──────────────────┘

落地要点

• 统一上下文：trace id贯穿日志/指标
• SLO/错误预算：把告警与业务体验挂钩
• 自助查询：一线工程师能自行诊断

📊 可观测性三支柱

┌─────────────────────────────────────────────┐
│              系统理解                        │
├─────────────┬─────────────┬─────────────────┤
│   LOGS      │  METRICS    │    TRACES       │
│   📋        │     📈      │      🔍         │
├─────────────┼─────────────┼─────────────────┤
│ 发生了什么   │ 系统健康吗  │  请求路径       │
│ 事件详情    │ 数值指标    │  调用链         │
├─────────────┼─────────────┼─────────────────┤
│ ELK/Loki   │ Prometheus  │ Jaeger/Zipkin  │
└─────────────┴─────────────┴─────────────────┘

实践组合

• 日志：结构化+采样；敏感信息脱敏
• 指标：RED/USE 方法；通过Exporter标准化
• 链路：入口打trace id；关键信息放Span Tag

🤖 AIOps

AI + IT Ops = 数据驱动的运维助手

传统运维                    AIOps
┌──────────────────┐       ┌──────────────────┐
│ 静态阈值告警     │       │ 动态基线学习     │
│ 人工分析日志     │ →     │ 自动关联分析     │
│ 被动响应故障     │       │ 预测性维护       │
│ 手动执行修复     │       │ 自动化修复       │
└──────────────────┘       └──────────────────┘

前置条件

• 干净的观测数据、清晰的告警语义
• 自动化执行通路（Runbook/Workflow）
• 用例从小到大：先做告警降噪，再做预测/自愈

🧠 AIOps核心能力

flowchart TB
    subgraph Input[数据输入]
        L[📋 Logs]
        M[📈 Metrics]
        T[🔍 Traces]
        E[🚨 Events]
    end

    subgraph AI[AI/ML处理]
        AD[异常检测]
        RCA[根因分析]
        PA[预测分析]
    end

    subgraph Output[智能输出]
        Alert[🔔 智能告警]
        Auto[🔧 自动修复]
        Insight[💡 洞察报告]
    end

    Input --> AI --> Output

团队协作模式

• 平台团队维护数据和模型治理
• 业务团队提供规则/上下文，负责回滚策略

🔮 2024-2025趋势

1️⃣ 平台工程 / IDP

• 自助式流水线、模板、环境配额
• 目标：减少上下文切换，降低认知负担

2️⃣ FinOps

• 可观测的成本：按团队/服务分账
• 结合弹性/自动关停，形成治理闭环

3️⃣ AI原生开发

• 代码/测试生成、文档问答
• Guardrails：合规、数据隔离、审计

4️⃣ WebAssembly & 边缘

• 轻量沙箱、冷启动快，适合边缘/插件场景
• 仍需结合K8s/Service Mesh治理

🎯 核心要点回顾

演进脉络（怎么走）

flowchart LR
    A[Agile] --> B[DevOps]
    B --> C[CI/CD]
    C --> D[微服务]
    D --> E[容器化]
    E --> F[K8s]
    F --> G[GitOps]
    G --> H[DevSecOps]
    H --> I[可观测性]
    I --> J[AIOps]

    style A fill:#e1f5fe
    style J fill:#ffccbc

实践顺序建议

1. 先把CI/CD与基础监控打牢
2. 引入容器+K8s+IaC，确保可重复
3. 上GitOps+DevSecOps，提升稳定与治理
4. 加强观测与自动化，再考虑AIOps/IDP

🌟 实施五原则

1. 🧠 先统一目标 以SLO/DORA对齐，跨职能共担指标

2. 🐾 小步快跑 设“最小可用流水线”，每月验证改进

3. 📊 度量驱动 部署频率、Lead Time、MTTR、变更失败率可视化

4. 🤖 自动化优先 把重复手工变更写成脚本/IaC，先覆盖高频风险点

5. 📚 持续学习 复盘每次事故/发布，沉淀Runbook与模板

❓ Q&A时间

常见问题（简答版）

Q1: 小团队值得做DevOps吗？ A: 是。先建基础流水线+自动化测试，减少人肉值守和夜间上线。

Q2: 微服务适合所有项目吗？ A: 不。先用模块化单体+清晰接口；当团队/域边界清晰且规模需要弹性时再拆。

Q3: GitOps和传统CI/CD冲突吗？ A: 不。CI负责构建镜像，CD部分由GitOps Operator从Git拉取声明式配置。

Q4: AIOps会取代运维吗？ A: 不。它是降噪和自动化助手，策略、风险兜底仍由人定义。

🙏 感谢聆听

DevOps是长期的工程化练习，不是一次性的项目

• 让发布更快：自动化 + 度量
• 让线上更稳：可观测 + 演练 + 回滚
• 让团队更好协作：统一目标、知识共享

📚 资料获取

扫码获取研究文档、工具对比、落地清单

📝 基础设施即代码

┌─────────────────────────────────┐
│         手动配置 ❌             │
│  - 登录服务器                   │
│  - 手动安装软件                 │
│  - 手动配置参数                 │
│  → 易出错、难复现、无历史       │
└─────────────────────────────────┘
              ↓
┌─────────────────────────────────┐
│         代码配置 ✅             │
│  infrastructure.tf / playbook.yml│
│  - 版本控制                     │
│  - 可重复执行                   │
│  - 完整审计历史                 │
└─────────────────────────────────┘

落地提示

• 代码放Git，审查变更，配合状态管理（如Terraform state）
• 与CI/CD集成：变更预览(plan)、审批、自动apply
• 模块化：网络、计算、数据库拆开，便于复用