♾️ 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:受控审批,发布后监控基线+自动回滚钩子 monorepo , 多个服务代码仓 + gitops仓库。
📖 DevOps一句话
- 融合Dev/QA/Ops/安全的文化与实践,通过自动化+协作缩短交付周期并保持高质量
- 不是岗位或买工具:核心是文化、流程、度量(CALMS),工具只是实现
🧩 敏捷宣言四价值
- 个体和互动 > 流程和工具
- 可工作的软件 > 详尽的文档
- 客户合作 > 合同谈判
- 响应变化 > 遵循计划
落地:Scrum/Kanban,小步快跑+短周期反馈,为后续DevOps节奏打底
✅ 收益 & ⚠️ 常见坑
- 收益:发布更频繁、缺陷更早暴露、变更粒度更小、协作以流水线为中心
- 坑:只自动构建不测试;流水线耦合过高;安全合规后置;反馈超过10分钟
- 建议:从核心服务开始,逐层引入单测/接口测/安全扫描和回滚演练
🧭 CI/CD澄清
- CI:频繁合并主干,自动构建+测试,10分钟内反馈
- CD(Delivery):随时可部署,生产需要人工确认
- CD(Deployment):测试通过自动直达生产
- 流水线即代码:Jenkinsfile/GitLab CI/GitHub Actions
- 左移安全:依赖/镜像/密钥/策略扫描进入流水线
🌉 DevOps革命
共同目标:稳定地更快交付价值
CALMS(落地解读)
C - Culture:一个跨职能团队对SLO和业务结果负责
A - Automation:流水线、测试、IaC、自动回滚
L - Lean:减少等待/返工,限制在制品
M - Measurement:用DORA指标、SLO、错误预算做决策
S - Sharing:经验、工具、运营手册可被复用
🔄 敏捷开发 (Agile)
DevOps的文化和节奏基础
对工程师最直接的四件事
- 小批量迭代:1-2周一个可运行版本
- 持续反馈:业务/运维加入评审,提前暴露约束
- 可工作的软件:文档和流程为代码落地服务
- 拥抱变化:自动化和可观测性是频繁变更的安全网
💔 传统开发的痛点
┌─────────────────────────────┐
│ 开发团队 👨💻 │
│ "代码写完了!" │
└──────────────┬──────────────┘
│
▼
┌──────────┐
│ 墙 🧱 │ ← 对立与冲突
└──────────┘
│
▼
┌─────────────────────────────┐
│ 运维团队 🔧 │
│ "这周末不能部署!" │
└─────────────────────────────┘
🚀 从DevOps到AIOps
今日行程(60m)
- 演进概览 10m:历史 + 动因
- 基础篇 10m:敏捷、协作、度量
- 核心篇 15m:CI/CD、容器、K8s、IaC
- 进阶篇 10m:GitOps、DevSecOps、可观测
- 前沿篇 5m:平台工程、AIOps 趋势
- Q&A 5m
🧭 演进关键解读
- 2001 敏捷宣言 → 2009 DevOps → 2010s CI/CD、IaC、微服务、SRE、可观测
- 2016 AIOps:AI+运维,异常检测/根因分析/降噪
- 近年:GitOps、平台工程、AI驱动交付成为云原生默认姿势
- 共同目标:更快、更稳、更安全的价值交付,而非堆叠 buzzword
🎯 听众 & 主题定位
- 听众:开发/测试/运维/架构/产品,对DevOps/微服务有耳闻但理解零散
- 主题:从DevOps到AIOps,交付与运维的进化路径
- 目的:让听众看到价值流、落地优先级,避免“买工具=有DevOps”的误区
🗺️ 演进路线图
flowchart TB
A[2001 敏捷宣言<br/>以变应变] --> B[2009 DevOps<br/>拆墙+自动化]
B --> C[2013 Docker<br/>一次打包]
C --> D[2014 Kubernetes<br/>调度与弹性]
D --> E[2017 GitOps<br/>声明式拉取]
E --> F[2020+ AIOps<br/>数据驱动运维]
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
😣 典型痛点 & 新要求
- 发布周期长,夜间上线+手工回滚
- 多环境漂移:测试/预发/生产配置不一致
- Dev/QA/Ops互相甩锅,[[MTTR or Lead Time]]没有负责人
- 业务要频繁试错:大促、活动、AB测试
- 架构复杂:微服务、多集群、多云
- 安全监管抬头:供应链、管道安全进入合规清单
🧠 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
团队协作模式
- 平台团队维护数据和模型治理
- 业务团队提供规则/上下文,负责回滚策略
🤖 AIOps
AI + IT Ops = 数据驱动的运维助手
传统运维 AIOps
┌──────────────────┐ ┌──────────────────┐
│ 静态阈值告警 │ │ 动态基线学习 │
│ 人工分析日志 │ → │ 自动关联分析 │
│ 被动响应故障 │ │ 预测性维护 │
│ 手动执行修复 │ │ 自动化修复 │
└──────────────────┘ └──────────────────┘
前置条件
- 干净的观测数据、清晰的告警语义
- 自动化执行通路(Runbook/Workflow)
- 用例从小到大:先做告警降噪,再做预测/自愈
📊 可观测性三支柱
┌─────────────────────────────────────────────┐
│ 系统理解 │
├─────────────┬─────────────┬─────────────────┤
│ LOGS │ METRICS │ TRACES │
│ 📋 │ 📈 │ 🔍 │
├─────────────┼─────────────┼─────────────────┤
│ 发生了什么 │ 系统健康吗 │ 请求路径 │
│ 事件详情 │ 数值指标 │ 调用链 │
├─────────────┼─────────────┼─────────────────┤
│ ELK/Loki │ Prometheus │ Jaeger/Zipkin │
└─────────────┴─────────────┴─────────────────┘
实践组合
- 日志:结构化+采样;敏感信息脱敏
- 指标:RED/USE 方法;通过Exporter标准化
- 链路:入口打trace id;关键信息放Span Tag
👁️ 可观测性
从“知道挂了”到“知道为何、提前预防”
监控 Monitoring 可观测性 Observability
┌──────────────────┐ ┌──────────────────┐
│ 已知问题的告警 │ │ 探索未知问题 │
│ 预设阈值触发 │ │ 任意维度查询 │
│ "发生了什么" │ │ "为什么发生" │
└──────────────────┘ └──────────────────┘
落地要点
- 统一上下文:trace id贯穿日志/指标
- SLO/错误预算:把告警与业务体验挂钩
- 自助查询:一线工程师能自行诊断
🎯 核心要点回顾
演进脉络(怎么走)
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
实践顺序建议
- 先把CI/CD与基础监控打牢
- 引入容器+K8s+IaC,确保可重复
- 上GitOps+DevSecOps,提升稳定与治理
- 加强观测与自动化,再考虑AIOps/IDP
🧷 供应链安全 & 合规
- Pipeline本身是攻击面:依赖、镜像、密钥最易被投毒
- 必做:SCA/SAST、镜像签名、密钥管理、SBOM/签名溯源
- 策略即代码:准入、权限、合规检查写进流水线,留审计轨迹
🤝 AIOps趋势 & Agent
- 全栈可观测+AI:异常聚类、根因分析、容量预测
- AI Agent进入DevOps:生成/优化流水线,看日志/监控给出回滚或扩容决策
- 成功前提:数据治理+自动化执行通路,否则AI无用武之地
🛣️ 渐进式落地路线
- 基础:统一Git规范,CI+单测跑通
- CD与环境一致:自动部署测试/预发,IaC管理资源
- GitOps+治理:核心服务改为拉取式发布,配套服务治理/观测/熔断限流
- SRE/DevSecOps/AIOps:设SLO+错误预算,供应链安全与策略即代码,先做告警降噪再逐步自动化
Deep Dive into LLMs like ChatGPT - YouTube
pre-train 预训练
最终生成base model基础模型,也就是一个 互联网文档模拟器。只具备预测下一个token的能力,基本没有指令遵循的能力。
所以下一步要通过post-train 把base model 训练成 assistant,能遵循人类的指令Instruct。
post-train 后训练
先用SFT,让模型能否理解人类指令并遵从。这里就需要用到大量的人类标记员。人类标记员就是提供问答对,给base model。
SFT 只是模仿人类专家
RL 让模型自己不断迭代进化,从而超越人类。

比如alphago和李世石的对战中的第37手,人类专业棋手下出那一手的概率几乎为0,但是alphago下出来了,这是RL的魅力。
大模型通过RL,以后也许也会出现需要人类目前做到的洞见、惊艳表现等。
之后再进行 RLHF。
- 对问题集,进行人为排序打分,human feedback。
- 基于以上问题集及其评分,额外训练出奖励模型,这个模型充当了人类模拟器的作用。
- 此时,对待模型对同一个问题生成的成千上万条回答,使用上一步的奖励模型打分,奖励其中答得最好的,以此强化模型选择这一条最佳的回答。
与SFT的最大不同点在于,这里的奖励,是奖励模型自己回答出的最佳答案,而不是人类标记员提前写好的所谓标准答案。

SFT
可以简单粗暴地理解,4o等模型,着重的就是SFT,虽然它也带做了一些RL
RL
可以简单粗暴理解,o1,r1等reasoning推理模型,着重的就是RL。
RLHF
RL着重于答案可验证的领域。但比如诗歌创作,写段子等,没有所谓标准答案,就需要人工标注介入,所以有了RLHF。
这里的human feedback,不再像之前的SFT需要人类专家给出专业的问题的答案。这里只需要给模型给出的结果,进行优劣排序既可,所以这里的,就是我们听说的打标员的工作。
这个阶段的训练,很依赖human feedback。所以我显著地感觉到deepseek r1写段子的能力很强,估计是因为中国人更懂中国人吧。
RLHF更像是一种 fine tune微调,因为奖励模型总有漏洞,导致改进失败。所以RL的存在,能让围棋能力无止境上升,但RLHF无法让LLM模型的能力无限上升。
🌟 实施五原则
-
🧠 先统一目标 以SLO/DORA对齐,跨职能共担指标
-
🐾 小步快跑 设“最小可用流水线”,每月验证改进
-
📊 度量驱动 部署频率、Lead Time、MTTR、变更失败率可视化
-
🤖 自动化优先 把重复手工变更写成脚本/IaC,先覆盖高频风险点
-
📚 持续学习 复盘每次事故/发布,沉淀Runbook与模板
🌈 🥚 彩蛋
X上优质中英文博主分享 https://x.com/hylarucoder
🔗 端到端示例(订单服务)
- 需求:Scrum/Kanban拆分,业务与技术共建
- 开发:微服务按领域建库建仓,代码托管Git
- CI:PR触发构建、单测、Lint、安全扫描
- CD+GitOps:镜像推送→更新部署配置→ArgoCD/Flux自动同步多环境
- IaC:集群/网络/存储以代码管理,环境一致
- 可观测&SRE:埋点日志指标接入平台,SLO+告警
- AIOps:异常检测、告警降噪,必要时自动回滚/扩容
🔒 DevSecOps
安全左移 + 全链路
传统方式 DevSecOps
开发 → 测试 → 安全 → 上线 开发+安全 → 测试+安全 → 上线
↑ ↑ ↑
最后检查 持续检查 持续检查
发现问题:晚期 发现问题:早期
修复成本:高 修复成本:低
目标
- 把安全测试嵌入流水线,不做末端闸门
- 让开发看得懂风险;安全团队提供策略和工具
🔄 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/分支策略
🔄 GitOps
Git = 唯一真相来源
为什么更稳
- 声明式:环境所需状态清晰可读
- 可审计:每次变更都有记录、代码评审
- 拉取式:集群自己同步,避免管道推送导致漂移
- 自愈:真实状态偏离时自动对齐或告警
📝 基础设施即代码
┌─────────────────────────────────┐
│ 手动配置 ❌ │
│ - 登录服务器 │
│ - 手动安装软件 │
│ - 手动配置参数 │
│ → 易出错、难复现、无历史 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 代码配置 ✅ │
│ infrastructure.tf / playbook.yml│
│ - 版本控制 │
│ - 可重复执行 │
│ - 完整审计历史 │
└─────────────────────────────────┘
落地提示
- 代码放Git,审查变更,配合状态管理(如Terraform state)
- 与CI/CD集成:变更预览(plan)、审批、自动apply
- 模块化:网络、计算、数据库拆开,便于复用
📦 Helm - K8s包管理
flowchart LR
Chart[📦 Helm Chart] --> Values[⚙️ values.yaml]
Values --> Template[📄 Templates]
Template --> Release[🚀 Release]
Release --> K8s[☸️ K8s Resources]
价值
- 可复用包:一套Chart服务多个环境
- 参数化:values.yaml承载环境差异
- 版本化:Release历史=回滚方案
🛡️ 安全工具链
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
📐 GitOps四原则(CNCF)
- 声明式:期望状态写成配置
- 版本化且不可变:全部放Git,审计可追溯
- 自动化调和:Controller持续对比并收敛
- 可观测:实际状态与期望差异可视化
🧭 SRE核心
- 目标:用工程化方法守住可靠性,平衡迭代速度与稳定
- 指标:SLI(成功率/延迟)、SLO(目标)、Error Budget(可用失败额度)
- 实践:与产品/研发共担,基于预算决定发布节奏、演练、回滚
🚀 GitOps在2025
- Kubernetes场景的主流发布方式之一
- 变更=Pull Request,回滚=git revert,审计/合规天然具备
- 特别适合多环境/多集群,替代零散脚本+手工kubectl
☸️ 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,换云保持一致
🏗️ 微服务架构
从单体到分布式:收益与代价
何时拆分
- 业务域清晰、接口稳定,团队能承担运维复杂度时
- 前提:自动化测试+CI/CD+观测到位,否则故障面更大
⚖️ 微服务收益与成本
- 优点:独立部署/扩缩容,按业务域拆团队,支持技术异构
- 成本:运维复杂度、调用链变长、数据一致性难题
- 前提: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同一包
- 可移植:运行时标准化,换云/换机器无痛
- 效率:层缓存+镜像仓库,发布速度秒级
- 安全:最小镜像、只读文件系统、按需运行时权限
[[集装箱改变世界(修订版)-马克·莱文森]]