【开发经验】之 DevOps

目录

• 一、理解 DevOps
• 二、实现 DevOps 的相关工具

一、理解 DevOps

---

1、什么是 DevOps

DevOps（Development 和 Operations 的组合词），翻译过来就是开发运维一体化，是一种重视 软件开发人员（Dev）和 IT运维技术人员（Ops） 之间沟通合作的文化、运动或惯例。透过自动化 软件交付 和 架构变更 的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

2、如何理解 DevOps

总的来说就是：DevOps 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

2-1、运维的催生

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

在单体应用架构的时候只有 DEV 没有 OPS，DEV 就是全栈，这个时候服务监控也简单，服务出了问题，直接去线上看一下运行日志，为了解放双手监控服务，开发者会写一些脚本分析日志，服务器少，部署简单，通常开发就可以完成运维的工作，不需要专门的运维来做部署。

但随着业务体量发展越来越大，一台机器扛不住，那么就加机器，单机变多机，业务架构也开始加入了 nginx、cdn、缓存等通用基础服务。服务也从单体发展到分布式微服务，这时就需要更多的人共同开发，此时就进入到了多人多版本协同开发、多人多机器的模式。

当服务器发展到一定数量时就需要专门的运维介入了，一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，另一方面是运维的学习成本确实变高了，开发人质量参差不齐。

加入运维，就要协调人员配合，运维需要的是维稳，他们是很讨厌变动。而开发的天却确是不断地推代码上线，进行代码变动，更替迭代。

2-2、DevOps 开发模式的催生

在分布式微服务架构下，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，但微服务有那么多的服务，有时甚至几百个服务，如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。并且，如果每个服务上线都需要运维来同意，那这个流程就会太过影响效率了。

那么为何不能再远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，最后自己上线呢。

能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等。

渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是 DevOps 开发模式诞生了，开发也是运维。

二、实现 DevOps 的相关工具

---

正常的开发流程是这样的：前期产品出原型，UI出设计，然后前后端代码开发，QA测试，最终部署上线。这个过程需要各种各样的 DevOps 工具来进行组织联调和配合。下面我列举一些常用搭建 DevOps 平台的相关工具。

常用的搭建 DevOps 平台的工具：

• 项目管理（PM）：jira，运营可以上去提问题，可以看到各个问题的完整的工作流，待解决未解决等；
• 代码管理：gitlab，管理项目中的所有代码仓库；
• 持续集成/持续交付/持续部署（CI/CD）：Jenkins，代码提交上去之后可以直接一点构建和部署。
• 镜像仓库：VMware Harbor，私服 nexus；
• 容器化管理：Docker；
• 服务编排：K8S；
• 服务治理：Consul；
• 脚本语言：Python；
• 日志管理：Cat+Sentry，还有种常用的是 ELK；
• 系统监控：Prometheus；
• 负载均衡：Nginx；
• 网关：Zuul、Gateway；
• 链路追踪：Zipkin；
• 产品和UI图：蓝湖；
• 公司内部文档：语雀；
• 服务警告：钉钉。

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