核心内容摘要
大数据预处理必学：7种常用降维方法对比
DevOps是什么
1 定义DevOpsDevelopment开发Operations运维DevOps是一套方法论、文化理念和工具实践的集合旨在打破开发团队和运维团队之间的壁垒通过自动化、协作和持续改进实现软件的快速、可靠、高质量交付。
2 三层理解┌─────────────────────────────────────┐ │ 文化层Culture │ │ - 协作与沟通 │ │ - 共同目标 │ │ - 打破部门墙 │ ├─────────────────────────────────────┤ │ 流程层Process │ │ - 持续集成 CI │ │ - 持续交付 CD │ │ - 持续部署 │ │ - 持续监控 │ ├─────────────────────────────────────┤ │ 工具层Tools │ │ - 代码管理: Git/GitLab │ │ - CI/CD: Jenkins/GitLab CI │ │ - 容器化: Docker/K8s │ │ - 监控: Prometheus/Grafana │ └─────────────────────────────────────┘
3 核心目标更快的交付速度从几个月缩短到几天、几小时甚至几分钟更高的部署频率从每季度部署到每天部署数十次更低的故障率自动化减少人为错误更快的故障恢复快速回滚、灰度发布更好的协作开发、测试、运维一体化
DevOps的
核心价值
1 业务价值
加速产品上市时间Time to Market传统模式需求 → 开发(1个月) → 测试(2周) → 运维部署(1周) → 上线 总计6周DevOps模式需求 → 开发(1周) → 自动化测试(1天) → 自动化部署(分钟级) → 上线 总计1周多实际案例某电商公司采用DevOps后 - 功能上线周期从4周缩短到3天 - 部署频率从每月1次到每天5次 - 故障修复时间从4小时缩短到30分钟
提高产品质量自动化测试每次提交都自动运行单元测试、集成测试持续集成及早发现代码冲突和Bug灰度发布小范围验证降低风险快速回滚出现问题可以秒级回滚到上个版本
降低运营成本成本对比项目传统模式DevOps模式节省人工部署成本4小时/次 × 10次/月 40小时自动化 5分钟/次95%故障处理成本平均4小时/次 × 5次/月 20小时快速定位自动回滚 30分钟/次
8
5%测试成本人工测试 2天/次自动化测试 1小时/次94%某互联网公司实际数据运维人员从20人减少到8人部署时间从4小时减少到5分钟年度节省成本约200万元
提升客户满意度功能快速迭代及时响应用户需求故障快速修复减少用户影响系统稳定性提升用户体验更好
2 技术价值
提高部署效率传统部署流程手动
开发提交代码到Git
构建人员手动打包mvn clean package
测试人员手动部署到测试环境
测试通过后运维人员手动部署到生产环境 - SSH登录服务器 - 备份旧版本 - 上传新版本 - 停止服务 - 替换Jar包 - 启动服务 - 验证服务
更新文档 总耗时
小时DevOps自动化流程
开发提交代码到Git
触发Jenkins自动构建
自动运行单元测试
自动打包Docker镜像
自动部署到K8s测试环境
自动运行集成测试
测试通过后审批发布到生产环境
K8s滚动更新自动健康检查
自动发送通知 总耗时
分钟效率提升部署时间从
小时 →
分钟提升95%人力成本从需要3人协作 → 1人点击按钮错误率从10% →
5%自动化减少人为错误
提高系统可靠性传统模式的问题❌ 环境不一致“我本地能跑线上为什么不行”❌ 依赖缺失“忘记安装某个依赖库”❌ 配置错误“配置文件写错了一个字符”❌ 版本混乱“不知道线上跑的是哪个版本”DevOps解决方案✅ Docker镜像开发、测试、生产环境完全一致 ✅ 配置管理统一的配置中心Nacos/Apollo ✅ 版本管理Git Tag Docker Tag清晰可追溯 ✅ 健康检查K8s自动检测服务健康异常自动重启 ✅ 日志监控ELK收集日志Prometheus监控指标可靠性对比指标传统模式DevOps模式系统可用性99%
9
9%平均故障恢复时间4小时30分钟部署成功率85%99%回滚时间1小时1分钟
实现持续改进DevOps的PDCA循环Plan计划 ↓ 制定迭代计划、技术方案 ↓ Do执行 ↓ 开发、测试、部署 ↓ Check检查 ↓ 监控系统指标、用户反馈 ↓ Act改进 ↓ 根据数据优化系统、修复问题 ↓ 回到Plan持续循环监控指标驱动改进响应时间增加 → 性能优化错误率上升 → Bug修复资源使用率高 → 扩容或优化用户体验差 → 功能优化
3 团队价值
打破部门墙传统模式的扔墙式开发开发团队写完代码就扔给测试 ↓ 扔墙 测试团队测完就扔给运维 ↓ 扔墙 运维团队部署出问题就怪开发问题沟通成本高责任不清互相推诿效率低下DevOps模式的一体化┌────────────────────────────────┐ │ DevOps团队共同目标 │ │ │ │ 开发工程师 │ │ 测试工程师 共同负责 │ │ 运维工程师 → 代码质量 │ │ 产品经理 系统稳定性 │ │ 用户体验 │ └────────────────────────────────┘优势✅ 目标一致快速交付高质量产品✅ 责任共担开发关注运维指标运维参与开发流程✅ 快速响应问题可以快速定位和解决✅ 知识共享团队成员技能互补
提升团队效能自动化释放人力传统模式 - 运维工程师80%时间用于重复性部署和维护 - 测试工程师70%时间用于手动回归测试 DevOps模式 - 运维工程师80%时间用于架构优化、自动化建设 - 测试工程师70%时间用于测试框架开发、探索性测试技能提升开发学习容器化、CI/CD、监控测试学习自动化测试框架、性能测试运维学习编程、基础设施即代码IaC工作满意度提升减少重复性工作增加创造性工作技能多样化职业发展路径更广成就感更强快速看到成果上线
为什么需要DevOps
1 传统模式的痛点痛点1开发和运维割裂场景还原开发我的代码在本地跑得好好的 运维那为什么部署到服务器就报错 开发那是你们环境的问题 运维明明是你代码的问题 ...互相扯皮问题迟迟得不到解决根本原因开发环境和生产环境不一致开发不了解生产环境的配置和限制运维不了解代码的内部逻辑缺乏统一的协作平台痛点2部署慢、效率低某传统企业的部署流程周五下午3点开发完成功能开发 周五下午4点提交测试 周一上午测试通过 周二申请变更填写变更申请单需要审批 周三晚上10点运维窗口期部署避免白天影响业务 周四上午验证部署结果问题从代码完成到上线需要1周时间需要等待固定的部署窗口手动操作容易出错加班部署影响生活痛点3故障恢复慢某电商平台真实故障晚上8点用户反馈下单失败 晚上8:10客服通知技术团队 晚上8:20运维查看监控发现订单服务CPU100% 晚上8:30联系开发分析原因开发已经下班 晚上9:00开发赶到公司定位到SQL慢查询问题 晚上9:30修复代码打包 晚上10:00运维部署 晚上10:10验证修复损失2小时的服务异常预计损失订单5000单直接经济损失约50万元用户体验受损负面评价如果有DevOps晚上8点用户反馈下单失败 晚上8:01Prometheus告警通知值班人员 晚上8:02通过Grafana快速定位问题 晚上8:05通过K8s一键回滚到上个版本 晚上8:06服务恢复正常 晚上8:10验证完成优势10分钟内恢复服务损失降低到最小第二天再优化修复代码痛点4质量不稳定传统模式的质量问题代码集成不频繁集成时发现大量冲突测试滞后问题发现晚修复成本高环境差异导致测试通过生产出问题缺乏自动化测试回归测试成本高数据对比指标传统模式DevOps模式Bug发现时间集成测试阶段开发后
周编码阶段实时Bug修复成本高需要回忆上下文低立即修复回归测试覆盖率
%时间有限
%自动化线上事故率每月
次每月
次
2 业务发展的需求需求1互联网时代的快速迭代用户期望功能快速上线Bug快速修复持续的产品改进竞争压力场景某O2O外卖平台 竞品A每周上线
个新功能 我方每月上线1个新功能 结果用户逐渐流失到竞品ADevOps价值支持快速迭代快速响应市场变化快速验证新想法需求2云原生时代的技术变革技术栈演进单体应用 → 微服务架构 物理机 → 虚拟机 → 容器 手动运维 → 自动化运维 → AIOps挑战微服务数量多几十甚至上百个部署复杂度高监控难度大需要统一的管理平台DevOps解决方案Docker容器化标准化部署单元K8s编排自动化调度、扩缩容、故障恢复Service Mesh服务治理、流量管理可观测性日志、监控、追踪三位一体需求3合规和安全要求企业面临的挑战需要审计日志谁在什么时候部署了什么需要权限管理不是所有人都能部署生产环境需要变更管理记录所有变更支持回滚需要安全扫描代码漏洞、镜像漏洞DevOps实现代码提交 → Git记录谁提交的 ↓ 代码扫描SonarQube ↓ 安全扫描Trivy扫描镜像漏洞 ↓ 审批流程生产环境需要审批 ↓ 自动部署记录部署日志 ↓ 可追溯完整的审计链
3 真实
案例分析案例1某互联网金融公司背景业务快速发展系统变更频繁传统部署方式效率低风险高监管要求严格需要完整的审计日志实施DevOps前部署频率每月2次部署时间
小时部署成功率70%故障恢复时间
小时运维团队15人实施DevOps后部署频率每天
次部署时间10分钟部署成功率99%故障恢复时间10分钟运维团队8人其他人转向自动化建设收益业务上线速度提升30倍运维成本降低40%系统稳定性从99%提升到
9
9%年度节省成本约300万元案例2某电商平台背景促销活动频繁流量波动大需要快速扩缩容能力手动运维压力大容易出错实施DevOps前的问题双十一前准备 - 提前1个月申请服务器 - 提前2周手动部署应用 - 提前1周压测 - 活动当天工程师全员待命实施DevOps后双十一准备 - K8s根据流量自动扩缩容 - CI/CD快速部署新版本 - Prometheus自动告警 - 问题快速回滚成果扩容时间从2周 → 10分钟资源利用率从30% → 70%故障处理时间从1小时 → 5分钟双十一零故障GMV增长200%案例3某传统制造企业数字化转型背景传统制造企业开始数字化转型IT团队规模小经验不足希望学习互联网公司的最佳实践痛点开发、测试、运维流程混乱没有统一的部署规范线上问题频发影响业务DevOps转型路径第一阶段3个月 - 建立Git代码仓库 - 搭建Jenkins CI/CD - 容器化改造 - 建立基础监控 第二阶段6个月 - 完善自动化测试 - 引入K8s - 建立配置中心 - 完善监控告警 第三阶段持续 - 微服务拆分 - 持续优化流程 - 团队文化建设成果部署效率提升10倍线上事故降低80%团队技术能力显著提升为数字化转型打下坚实基础
DevOps的核心理念
1 文化层面
协作文化Collaboration打破部门墙传统组织架构 开发部门 ─ ✘ ─ 测试部门 ─ ✘ ─ 运维部门 各自为政 DevOps组织架构 ┌────────────────────────────┐ │ 跨职能团队Squad │ │ 开发 测试 运维 产品 │ │ 共同目标产品成功 │ └────────────────────────────┘实践统一的沟通平台Slack/钉钉定期的团队会议站会、回顾会共同的KPI不是开发完成率而是功能上线率Pair Programming结对编程知识分享会
责任共担Shared Responsibility传统模式开发只管写代码不管线上运行运维只管部署不管代码质量出了问题互相推诿DevOps理念You build it, you run it谁开发谁负责 开发工程师的职责 - ✅ 编写高质量代码 - ✅ 编写自动化测试 - ✅ 关注线上监控指标 - ✅ 参与on-call值班 - ✅ 优化系统性能 运维工程师的职责 - ✅ 提供稳定的基础设施 - ✅ 建设自动化平台 - ✅ 参与架构设计 - ✅ 提供最佳实践指导实际案例某公司实践 - 每个开发团队都有on-call值班 - 线上出问题谁开发的模块谁负责处理 - 激励开发关注代码质量和系统稳定性 - 结果线上故障降低60%
持续学习Continuous Learning学习型组织定期技术分享每周1次故障复盘会Postmortem无指责文化技术书籍学习参加技术大会内部Hackathon无指责文化Blameless传统文化 线上故障 → 找责任人 → 处罚 → 员工隐瞒问题 DevOps文化 线上故障 → 复盘分析 → 改进流程 → 避免再犯案例某公司故障复盘模板
故障时间线发生了什么
根因分析为什么发生
改进措施如何避免再犯
经验分享学到了什么 重点不追究个人责任关注系统改进
2 流程层面
自动化一切Automate Everything可自动化的领域代码层面 - ✅ 代码格式化Prettier, Black - ✅ 代码检查ESLint, SonarQube - ✅ 依赖更新Dependabot 构建层面 - ✅ 编译打包Maven, Gradle - ✅ 单元测试JUnit, PyTest - ✅ 代码覆盖率JaCoCo 测试层面 - ✅ 单元测试自动运行 - ✅ 集成测试自动运行 - ✅ API测试Postman/RestAssured - ✅ UI测试Selenium - ✅ 性能测试JMeter 部署层面 - ✅ 镜像构建Docker build - ✅ 镜像扫描Trivy - ✅ 部署K8s - ✅ 健康检查自动验证 监控层面 - ✅ 日志收集ELK - ✅ 指标监控Prometheus - ✅ 告警通知自动发送 - ✅ 自动扩缩容HPA自动化的ROI投资回报率手动部署成本 - 时间2小时/次 - 频率10次/月 - 人力成本200元/小时 - 月成本2 × 10 × 200 4000元 自动化后 - 开发自动化脚本40小时一次性投入 - 部署时间5分钟/次几乎忽略不计 - 回收周期40小时 / (2小时 × 10次/月) 2个月 结论2个月后就开始盈利
持续集成Continuous IntegrationCI的核心思想频繁集成 → 及早发现问题 → 降低集成成本CI流程开发提交代码 ↓ 触发CI Pipeline ↓ 代码检出Git Clone ↓ 代码检查Lint ↓ 编译构建Build ↓ 单元测试Unit Test ↓ 代码覆盖率检查Coverage ↓ 静态代码分析SonarQube ↓ 安全扫描SAST ↓ 打包Package ↓ 上传制品Artifact ↓ 通知结果Success/FailedCI最佳实践✅ 每天至少集成一次✅ 每次提交都触发构建✅ 构建要快10分钟✅ 自动化测试要充分✅ 构建失败要立即修复
持续交付/部署CDCD的两个概念Continuous Delivery持续交付代码随时可以部署但需要人工审批 ↓ 开发 → 构建 → 测试 → 【人工审批】 → 部署生产Continuous Deployment持续部署代码自动部署到生产环境无需人工干预 ↓ 开发 → 构建 → 测试 → 自动部署生产选择建议金融、医疗等关键行业持续交付需要审批互联网产品持续部署快速迭代CD Pipeline示例阶段1构建 - 编译代码 - 运行单元测试 - 打包Docker镜像 - 推送到镜像仓库 阶段2部署到Dev环境 - 自动部署 - 自动化测试 - 验证通过 → 下一阶段 阶段3部署到Test环境 - 自动部署 - 集成测试 - UI测试 - 验证通过 → 下一阶段 阶段4部署到Staging环境 - 自动部署 - 性能测试 - 安全测试 - 用户验收测试UAT - 验证通过 → 下一阶段 阶段5部署到Production环境 - 【可选人工审批】 - 灰度发布先部署10% → 50% → 100% - 实时监控 - 自动回滚机制
持续监控Continuous Monitoring监控的三个层次日志Logging - 记录发生了什么 - 工具ELK (Elasticsearch Logstash Kibana) - 用途问题排查、审计 指标Metrics - 系统状态的数值 - 工具Prometheus Grafana - 用途性能监控、容量规划、告警 追踪Tracing - 请求链路追踪 - 工具SkyWalking, Jaeger, Zipkin - 用途性能分析、依赖关系监控驱动的闭环监控发现问题 ↓ 告警通知 ↓ 快速定位 ↓ 修复问题 ↓ 部署上线 ↓ 监控验证 ↓ 持续循环
3 技术层面
基础设施即代码IaC传统方式 vs IaC传统方式运维人员手动操作
登录阿里云控制台
点击创建服务器
选择配置2核4G
选择镜像Ubuntu
2
04
配置网络、安全组
手动安装软件
手动配置 问题 - 不可重复 - 容易出错 - 无法版本管理IaC方式# Terraform代码 resource alicloud_instance web { instance_type ecs.t5-c1m
large image_id ubuntu_20_04_x64 instance_name web-server system_disk_category cloud_efficiency security_groups [alicloud_security_group.default.id] vswitch_id alicloud_vswitch.default.id } 优势 ✅ 代码化可版本管理 ✅ 可重复一键创建 ✅ 可审查团队协作 ✅ 可测试先在测试环境验证
不可变基础设施Immutable Infrastructure传统方式创建服务器 → 安装软件 → 配置 → 运行 升级时SSH登录 → 修改配置 → 重启服务 问题 - 服务器状态不一致配置漂移 - 难以追溯变更历史 - 回滚困难不可变基础设施Docker镜像一次构建到处运行 升级时构建新镜像 → 替换容器 → 销毁旧容器 优势 ✅ 环境一致性 ✅ 快速回滚切换到旧镜像 ✅ 易于扩展同一镜像启动多个实例
微服务架构单体 vs 微服务单体应用┌──────────────────┐ │ │ │ All in One │ │ │ │ - 用户模块 │ │ - 订单模块 │ │ - 商品模块 │ │ - 支付模块 │ │ │ └──────────────────┘ 部署全量部署牵一发动全身 扩展整体扩展资源浪费 风险一个模块出问题整个系统不可用微服务┌─────────┐ ┌─────────┐ ┌─────────┐ │用户服务 │ │订单服务 │ │商品服务 │ └─────────┘ └─────────┘ └─────────┘ ↓ ↓ ↓ 独立部署 独立扩展 独立升级 优势 ✅ 独立部署互不影响 ✅ 技术栈多样化可以用不同语言 ✅ 团队自治每个团队负责一个服务 ✅ 故障隔离一个服务挂了不影响其他DevOps 微服务 完美搭配CI/CD每个服务独立的PipelineDocker标准化部署单元K8s服务编排和管理Service Mesh服务治理
DevOps vs 传统模式
1 全方位对比维度传统模式DevOps模式组织架构开发、测试、运维部门分离跨职能团队共同目标协作方式扔墙式交接各管一段全流程协作责任共担部署频率每月
次每天多次甚至持续部署部署方式手动部署易出错自动化部署可靠稳定部署时间
小时
分钟回滚时间
小时
分钟测试手动测试为主周期长自动化测试实时反馈环境开发、测试、生产环境不一致Docker保证环境一致监控被动监控问题发生后才知道主动监控问题发生时立即告警故障处理平均4小时平均30分钟文档手动维护常常过时代码即文档实时同步变更管理繁琐的审批流程自动化审批合规可追溯系统可用性99%
9