DevOps就是开发抢了运维的工作？
2022-06-11 17:03:30 0 举报AI智能生成
DevOps就是开发抢了运维的工作？ 产品规划 开发编码 构建 QA测试 发布 部署 维护 单体架构——瀑布模式？ 分布式架构—+敏捷开发模式？ 微服务架构+devops
作者其他创作
大纲/内容
devops是什么
DevOps维基百科定义
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。
透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。
透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
devops概念提出
单体架构+瀑布模式
单体架构+瀑布模式
单体架构
1、服务部署
以电商系统为例，单体应用架构为 LNMP，这个时候只有 DEV 没有 OPS，
DEV 就是全栈，就跟我们上大学玩的 demo 一样，项目开发好，
找台服务器安装好环境，把 jar 包 scp 到远程服务器，放上去开启服务就可以。
2、服务监控
这个时候服务监控也简单，服务出了问题，直接去线上看一下运行日志，
为了解放双手监控服务，开发者会写一些脚本分析日志，服务器少，
部署简单，通常开发就可以完成运维的工作，
不需要专门的运维来做部署，所以开发模式很简答，直接按照瀑布流方式开发就可。
以电商系统为例，单体应用架构为 LNMP，这个时候只有 DEV 没有 OPS，
DEV 就是全栈，就跟我们上大学玩的 demo 一样，项目开发好，
找台服务器安装好环境，把 jar 包 scp 到远程服务器，放上去开启服务就可以。
2、服务监控
这个时候服务监控也简单，服务出了问题，直接去线上看一下运行日志，
为了解放双手监控服务，开发者会写一些脚本分析日志，服务器少，
部署简单，通常开发就可以完成运维的工作，
不需要专门的运维来做部署，所以开发模式很简答，直接按照瀑布流方式开发就可。
瀑布模式
设计 =》 开发 =》 测试 =》部署
分布式架构+敏捷开发模式
分布式架构
敏捷开发模式
随着业务体量发展越来越大，一台机器扛不住，那么就加机器，单机变多机，
业务架构也开始加入了 nginx,cdn,缓存等通用基础服务，业务变多肯定会招人，就涉及到多人协同开发，多人多机器模式。
业务架构也开始加入了 nginx,cdn,缓存等通用基础服务，业务变多肯定会招人，就涉及到多人协同开发，多人多机器模式。
多人协同开发问题:
先说说多人协同开发问题，人员一多，为了更好的分工，大多会将项目进行拆分，每个人负责专注于一部分，有点包干到户的感觉，
敏捷开发的核心理念就是既然我们无法充分了解用户的真实需求是怎样的，将一个大的目标不断拆解，把它变成一个个可交付的小目标，
然后通过不断迭代，以小步快跑的方式持续开发。。
另外，一个项目是很大的，为了保证项目质量，测试环节不可减少，为了加快速度增大开发效率，
QA的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，每次可交付的都是一个可用的功能集合，对开发交付的内容进行持续验证。
这样开发产品的可控性也更强，遇到了sb甲方的时候，阶段性的让他检验一下项目成果，防止画鸡成鸭。
敏捷开发的核心理念就是既然我们无法充分了解用户的真实需求是怎样的，将一个大的目标不断拆解，把它变成一个个可交付的小目标，
然后通过不断迭代，以小步快跑的方式持续开发。。
另外，一个项目是很大的，为了保证项目质量，测试环节不可减少，为了加快速度增大开发效率，
QA的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，每次可交付的都是一个可用的功能集合，对开发交付的内容进行持续验证。
这样开发产品的可控性也更强，遇到了sb甲方的时候，阶段性的让他检验一下项目成果，防止画鸡成鸭。
项目研发的阶段
多机器问题:
再说说多机器问题，之前机器很少架构简单的时候，开发就可以干运维的活，
就算加了几台服务器，那也是脚本将 JAR 包同时发布到这些机器上，
好像也挺简单，但是会有两个人同时上线部署被覆盖的问题，所以大家在上线之前可能会去群里吆喝一声，
”我要上线了，大家先别上线哈“，可想而知这样效率也很低下。
就算加了几台服务器，那也是脚本将 JAR 包同时发布到这些机器上，
好像也挺简单，但是会有两个人同时上线部署被覆盖的问题，所以大家在上线之前可能会去群里吆喝一声，
”我要上线了，大家先别上线哈“，可想而知这样效率也很低下。
公司业务一大，像大公司的动不动就是几千台服务器，就需要专门的运维介入了，
一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，
另一方面是运维的学习成本确实变高了，开发人质量参差不齐，服务器要是每个人都可以上估计领导每天晚上都要做噩梦。
但是这个时候也不是 DEVOPS，而是 DEV+OPS，
这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，
运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式。
一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，
另一方面是运维的学习成本确实变高了，开发人质量参差不齐，服务器要是每个人都可以上估计领导每天晚上都要做噩梦。
但是这个时候也不是 DEVOPS，而是 DEV+OPS，
这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，
运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式。
开发和运维角色的天生对立问题：
加入运维，就要协调人员配合，运维的宿命就是维稳，他们是很讨厌变动的；
开发的天职确是不断地推代码上线，进行代码变动，更替迭代，这两个工种天生就是对立的。
开发的天职确是不断地推代码上线，进行代码变动，更替迭代，这两个工种天生就是对立的。
很多大公司有那种，开发人员想要上线，需要提交各种审批，层层签字画押，
多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。
所以，敏捷开发解决了协同开发和多机器部署开发问题，但是没有解决内部人员的矛盾，
留着这个矛盾在公司，开发和运维随时都可能约‘生死架’。
多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。
所以，敏捷开发解决了协同开发和多机器部署开发问题，但是没有解决内部人员的矛盾，
留着这个矛盾在公司，开发和运维随时都可能约‘生死架’。
微服务架构+DEVOPS
微服务架构
wiki定义微服务:
微服务（英语：Microservices）是一种软件架构风格，
它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，
利用模块化的方式组合出复杂的大型应用程序，
各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。
wiki定义微服务:
微服务（英语：Microservices）是一种软件架构风格，
它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，
利用模块化的方式组合出复杂的大型应用程序，
各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。
业务变大，多技术栈，项目变大带来的问题
第一，公司发展到BAT这种体量，会招很多人，JAVA，PHP，GO 技术栈都会有，需要协调技术栈；
第二，项目到后期往往会变得很大，全部都兑到一个项目里，最直接的后果就是项目变得很大，上线项目启动时间变长，
一个BUG可能导致整个业务全线崩溃，最终的后果就是项目变得越来越难以维护，加一个改一个东西几乎搞不动，而且还越来越难重构，牵一发而动全身。
第二，项目到后期往往会变得很大，全部都兑到一个项目里，最直接的后果就是项目变得很大，上线项目启动时间变长，
一个BUG可能导致整个业务全线崩溃，最终的后果就是项目变得越来越难以维护，加一个改一个东西几乎搞不动，而且还越来越难重构，牵一发而动全身。
所以，拆分解耦是最终的出路，将项目拆成一个个小的服务单独部署，以电商项目为例如图，
将整个项目拆分为用户服务，商品服务，订单服务，积分服务......每个服务单独部署，
之间通过互相调用的方式来交互，而且可以将一些基础服务例如上传图片，发送短信等很多服务都需要的基础东西，
抽象到一个单独的服务，也就是前些年鼓吹的很厉害的‘中台服务’。
将整个项目拆分为用户服务，商品服务，订单服务，积分服务......每个服务单独部署，
之间通过互相调用的方式来交互，而且可以将一些基础服务例如上传图片，发送短信等很多服务都需要的基础东西，
抽象到一个单独的服务，也就是前些年鼓吹的很厉害的‘中台服务’。
拆分部署催生出DEVOPS
再看看这种架构下的开发模式DEVOPS，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，
微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，
如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。
而且，如果每个服务上线都需要运维来同意，开发也太卑微了，估计要天天求着运维同意发布，运维也会烦不胜烦。
再看看这种架构下的开发模式DEVOPS，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，
微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，
如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。
而且，如果每个服务上线都需要运维来同意，开发也太卑微了，估计要天天求着运维同意发布，运维也会烦不胜烦。
那么为何不能再远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，
开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，
能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。
运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，
基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，
日志也有专门的日志工具，
链路追踪也有专门的组件和可视化，
还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，
毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，
于是DEVOPS开发模式诞生了，开发也是运维。
开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，
能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。
运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，
基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，
日志也有专门的日志工具，
链路追踪也有专门的组件和可视化，
还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，
毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，
于是DEVOPS开发模式诞生了，开发也是运维。
DevOps
devops深度理解
我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：
产品规划、开发编码、构建、QA测试、发布、部署和维护。
产品规划、开发编码、构建、QA测试、发布、部署和维护。
最初大家说到DEVOPS，都是指的‘开发运维一体化’，如下图:
现在大家说的 DevOps 已经是扩大到“端到端”的概念了，如下图：
DevOps 的三大支柱之中，即人（People）、流程（Process）和平台（Platform）。即
DevOps = 人 + 流程 + 平台
人 + 流程 = 文化
人+流程=文化
流程 + 平台 = 工具
流程+平台=工具
平台 + 人 = 赋能
平台+人=赋能
devops实现相关工具
人自然不用多说，开发前后中涉及到的所有人，
①、流程前期是产品出原型，UI出设计，
②、然后前后端代码开发，QA测试，
③、最终部署上线，下图是部分流程图：
①、流程前期是产品出原型，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/Eureka/Dubbo/Nacos/Etcd
脚本语言：Python
日志管理：Cat+Sentry，还有种常用的是ELK。
系统监控：Prometheus。
负载均衡：Nginx。
网关：Kong/zuul/ gateway
链路追踪：Zipkin。
产品和UI图：蓝湖。
公司内部文档：Confluence。
报警：推送到工作群。
收藏
0 条评论
下一页
