通俗理解DevOps

DeVops是什么

❝DevOps维基百科定义 DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。❞

这里先给出维基百科的定义,没指望你一下子看懂,先有个概念了解一下。

devops概念提出

单体架构+瀑布模式

单体应用架构

瀑布开发模式

以电商系统为例,单体应用架构为 LNMP,这个时候只有 DEV 没有 OPS,DEV 就是全栈,就跟我们上大学玩的 demo 一样,项目开发好,找台服务器安装好环境,把 jar 包 scp 到远程服务器,放上去开启服务就可以。

这个时候服务监控也简单,服务出了问题,直接去线上看一下运行日志,为了解放双手监控服务,开发者会写一些脚本分析日志,服务器少,部署简单,通常开发就可以完成运维的工作,不需要专门的运维来做部署,所以开发模式很简答,直接按照瀑布流方式开发就可。

分布式架构+敏捷开发模式

分布式架构

敏捷开发模式

随着业务体量发展越来越大,一台机器扛不住,那么就加机器,单机变多机,业务架构也开始加入了 nginx,cdn,缓存等通用基础服务,业务变多肯定会招人,就涉及到多人协同开发,多人多机器模式。

多人协同开发问题:

先说说多人协同开发问题,人员一多,为了更好的分工,大多会将项目进行拆分,每个人负责专注于一部分,有点包干到户的感觉,敏捷开发的核心理念就是既然我们无法充分了解用户的真实需求是怎样的,将一个大的目标不断拆解,把它变成一个个可交付的小目标,然后通过不断迭代,以小步快跑的方式持续开发。。另外,一个项目是很大的,为了保证项目质量,测试环节不可减少,为了加快速度增大开发效率,QA的工作最好是和开发同步交替进行的,需要将测试环节从后面注入到整个开发环节当中,每次可交付的都是一个可用的功能集合,对开发交付的内容进行持续验证。这样开发产品的可控性也更强,遇到了sb甲方的时候,阶段性的让他检验一下项目成果,防止画鸡成鸭。

打架吗?

多机器问题:

再说说多机器问题,之前机器很少架构简单的时候,开发就可以干运维的活,就算加了几台服务器,那也是脚本将 JAR 包同时发布到这些机器上,好像也挺简单,但是会有两个人同时上线部署被覆盖的问题,所以大家在上线之前可能会去群里吆喝一声,”我要上线了,大家先别上线哈“,可想而知这样效率也很低下。

公司业务一大,像大公司的动不动就是几千台服务器,就需要专门的运维介入了,一方面是因为开发分工每个人都专注于自己的事情,不会那么用心进行维护,另一方面是运维的学习成本确实变高了,开发人质量参差不齐,服务器要是每个人都可以上估计领导每天晚上都要做噩梦。但是这个时候也不是 DEVOPS,而是 DEV+OPS,这时 Ops 的主要职责就是:硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等,运维们擅长写各种部署,监控脚本,减少机械的重复工作,开发模式变成了敏捷开发模式。

开发和运维角色的天生对立问题:

加入运维,就要协调人员配合,运维的宿命就是维稳,他们是很讨厌变动的;开发的天职确是不断地推代码上线,进行代码变动,更替迭代,这两个工种天生就是对立的。

很多大公司有那种,开发人员想要上线,需要提交各种审批,层层签字画押,多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。所以,敏捷开发解决了协同开发和多机器部署开发问题,但是没有解决内部人员的矛盾,留着这个矛盾在公司,开发和运维随时都可能约‘生死架’。

微服务架构+DEVOPS

微服务架构

DevOps

❝wiki定义微服务: 微服务(英语:Microservices)是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模块化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic)的API集相互通信。❞

上面是我摘自wiki对微服务的定义,注意几个关键词:软件架构风格,小型功能区块,模块化,语言无关。

第一,公司发展到BAT这种体量,会招很多人,JAVA,PHP,GO 技术栈都会有,需要协调技术栈;第二,项目到后期往往会变得很大,全部都兑到一个项目里,最直接的后果就是项目变得很大,上线项目启动时间变长,一个BUG可能导致整个业务全线崩溃,最终的后果就是项目变得越来越难以维护,加一个改一个东西几乎搞不动,而且还越来越难重构,牵一发而动全身。

所以,拆分解耦是最终的出路,将项目拆成一个个小的服务单独部署,以电商项目为例如图,将整个项目拆分为用户服务,商品服务,订单服务,积分服务......每个服务单独部署,之间通过互相调用的方式来交互,而且可以将一些基础服务例如上传图片,发送短信等很多服务都需要的基础东西,抽象到一个单独的服务,也就是前些年鼓吹的很厉害的‘中台服务’。

拆分部署催生出DEVOPS 再看看这种架构下的开发模式DEVOPS,运维需要做的上线工作,主要就是将代码部署到对应的机器里面,微服务有那么多的服务,每个大点的公司几百个服务不算多,而且还可能随时搞一个服务出来,如果还按照原始的脚本部署方式,可能最后连是哪个脚本都找不到。而且,如果每个服务上线都需要运维来同意,开发也太卑微了,估计要天天求着运维同意发布,运维也会烦不胜烦。

那么为何不能再远程部署一些机器,专门用来管理代码,进行上线工作,由运维事先把上线的规则都给定义好了,开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布,自己上线呢,能用代码自动完成的事情就绝不要手动解决,这是每个开发人员都在想的东西。运维需要做的事情,慢慢的都沉淀到了各个平台上面,例如监控,有专门的监控组件和可视化,基础服务例如服务器,CDN,负载均衡等基础服务可以外包到云服务厂商,日志也有专门的日志工具,链路追踪也有专门的组件和可视化,还有网关等,渐渐的,只要这些都配置好了,开发也可以做运维的部分工作,毕竟开发才是最了解代码的人,哪里出了问题看看监控日志,可以最快速度定位到问题,于是DEVOPS开发模式诞生了,开发也是运维。

devops深度理解

我们知道,一个软件从零开始到最终交付,大概包括以下几个阶段:产品规划、开发编码、构建、QA测试、发布、部署和维护。

最初大家说到DEVOPS,都是指的‘开发运维一体化’,如下图:

现在大家说的 DevOps 已经是扩大到“端到端”的概念了,如下图:

广义上的DevOps

DevOps 的三大支柱之中,即人(People)、流程(Process)和平台(Platform)。即

DevOps = 人 + 流程 + 平台

人 + 流程 = 文化

流程 + 平台 = 工具

平台 + 人 = 赋能

devops实现相关工具

人自然不用多说,开发前后中涉及到的所有人,流程前期是产品出原型,UI出设计,然后前后端代码开发,QA测试,最终部署上线,下图是部分流程图:

流程图

这里重点来看看devops平台搭建工具,工具很多,组件很多,百家争鸣,这里我列举的大多数是我公司用的,也是大部分公司都在用的。

devops平台搭建工具

项目管理(PM):jira。运营可以上去提问题,可以看到各个问题的完整的工作流,待解决未解决等;

代码管理:gitlab。jenkins或者K8S都可以集成gitlab,进行代码管理,上线,回滚等;

持续集成CI(Continuous Integration):gitlab ci。开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

持续交付CD(Continuous Delivery):gitlab cd。完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。

镜像仓库:VMware Harbor,私服nexus。

容器:Docker。

编排:K8S。

服务治理:Consul。

脚本语言:Python。

日志管理:Cat+Sentry,还有种常用的是ELK。

系统监控:Prometheus。

负载均衡:Nginx。

网关:Kong,zuul。

链路追踪:Zipkin。

产品和UI图:蓝湖。

公司内部文档:Confluence。

报警:推送到工作群。

有了这一套完整的流程工具,整个开发流程涉及到人员都可以无阻碍的进行协调工作了,开发每天到公司,先看看jira,看看线上日志,出了问题看看监控日志,运营同学反馈问题不着急的去JIRA,着急的群里吆喝,产品和UI的图直接蓝湖看,运维关注监控着大盘,改革春风开满地,互联网人民真高兴~

这一篇有点姗姗来迟的意味,之前一直陷入了迷茫不知道该写什么,于是低调的修炼,有了这一篇,有问题欢迎指正,关注我的公众号’阿甘的码路‘,即可联系到我,很开心你能看到这里,共同努力,共同进步。

转载:

 一文理解什么是DevOps,通俗易懂白话文_devops的理解-CSDN博客

<think>嗯,用户之前问了怎么在GitHub上学习Linux,现在接着问DevOps是什么。看来他可能对Linux系统管理或者软件开发流程感兴趣,现在想扩展到DevOps领域。需要先确认用户对DevOps理解程度,但问题直接问“是什么”,所以应该从基础概念开始解释。 用户可能是刚接触这个概念,或者想系统了解。需要明确DevOps的定义、核心思想、主要组成部分,以及和传统方法的区别。可能还需要举一些实际例子,比如工具链或者实践案例,让用户更容易理解。 要考虑到用户可能已经通过GitHub学习Linux,所以可以结合之前的上下文,比如提到持续集成/持续部署(CI/CD)工具如GitHub Actions,或者配置管理工具如Ansible,这些都属于DevOps的范畴。这样用户能联系起来,之前学的内容如何应用到DevOps中。 还要注意用户可能的实际需求,比如想转型到DevOps角色,或者优化现有工作流程。所以需要强调DevOps带来的好处,比如加快交付速度、提高协作效率等。同时,避免使用过于专业的术语,保持解释通俗易懂。 另外,用户可能需要知道如何开始学习DevOps,所以在介绍中可以推荐相关资源,比如书籍、在线课程,或者GitHub上的开源项目,这样延续之前的学习路径。比如提到在GitHub上搜索DevOps相关的仓库,或者参与相关项目来实践。 需要确保回答结构清晰,分点阐述,让用户能逐步理解。可能的结构包括定义、核心理念、关键实践、常用工具、优点以及学习资源。这样用户能有一个全面的认识,并知道下一步如何深入学习。</think>--- ### **DevOps 是什么?** **DevOps** 是 **Development(开发)** 和 **Operations(运维)** 的组合词,代表一种**软件开发和运维协作的文化、方法论与实践**。它旨在通过**自动化工具、流程优化和团队协作**,打破传统开发与运维的壁垒,实现软件**快速构建、测试、发布和运维**的全流程高效协同。 --- ### **一、核心目标** 1. **加速交付** - 缩短从代码提交到生产环境部署的周期(从“天/周”级到“分钟/小时”级)。 2. **提升质量** - 通过自动化测试和监控,减少人为错误和系统故障。 3. **增强协作** - 开发、测试、运维团队共享责任,减少“甩锅”现象。 --- ### **二、关键原则** 1. **持续集成(CI)** - 代码频繁合并到主分支,自动触发构建和测试。 - 工具示例:`Jenkins`、`GitHub Actions`、`GitLab CI`。 2. **持续交付/部署(CD)** - 自动化将代码部署到测试/生产环境。 - 工具示例:`Argo CD`、`Spinnaker`。 3. **基础设施即代码(IaC)** - 用代码定义服务器、网络等资源(如`Terraform`、`Ansible`)。 4. **监控与反馈** - 实时监控系统状态,快速响应问题(如`Prometheus`、`Grafana`)。 --- ### **三、典型工具链** | **类别** | **代表工具** | **用途** | |----------------|----------------------------------|----------------------------------| | 版本控制 | `Git`、`GitHub`、`GitLab` | 代码管理 | | 自动化构建 | `Maven`、`Gradle` | 编译打包 | | 容器化 | `Docker`、`Kubernetes` | 环境隔离与集群管理 | | 配置管理 | `Ansible`、`Chef`、`Puppet` | 批量配置服务器 | | 日志管理 | `ELK Stack`(Elasticsearch等) | 日志收集与分析 | --- ### **四、与传统模式的区别** | **对比维度** | **传统模式** | **DevOps模式** | |------------------|----------------------------------|----------------------------------| | 团队协作 | 开发与运维独立,易“踢皮球” | 跨职能团队,共同负责全流程 | | 发布频率 | 数月一次大版本 | 按需高频发布(每日多次) | | 自动化程度 | 手动操作多,易出错 | 全流程自动化(CI/CD流水线) | | 故障恢复 | 依赖人工排查,耗时长 | 自动化监控告警,快速回滚 | --- ### **五、实际应用场景** 1. **微服务架构** - 用`Kubernetes`管理数百个容器化服务,实现弹性伸缩。 2. **云原生开发** - 结合`AWS`/`Azure`云平台,通过IaC快速部署资源。 3. **故障自愈** - 监控系统检测到异常后,自动触发修复脚本或替换故障节点。 --- ### **六、如何入门DevOps?** 1. **学习路径建议** - 基础:Linux操作、Shell脚本、Git版本控制 - 进阶:Docker容器化、CI/CD流水线设计、云平台使用(如AWS) 2. **实践项目** - 在GitHub搜索`DevOps projects`,例如: - `awesome-devops`(⭐12k+):$$https://github.com/AcalephStorage/awesome-devops$$ - 部署一个完整的CI/CD流水线(从代码提交到自动上线)。 --- ### **七、经典书籍推荐** - 《凤凰项目:一个IT运维的传奇故事》 - 《持续交付:发布可靠软件的系统方法》 - 《DevOps实践指南》 --- **总结**:DevOps 不是单一工具或职位,而是通过**文化变革+技术实践**,实现软件交付的“又快又稳”。核心逻辑是:**自动化一切能自动化的,监控一切需要监控的,协作一切需要协作的**。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值