本篇文章为Devops概念扫盲，内容来自网络，非原创，仅供学习。
文章目录
Devops诞生背景
Dev 和 Ops 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。
本质上说，早期程序员对所要开发的软件的所有环节都有透彻的了解，从规格说明书编写、到软件开发、到测试、到部署、再到技术支持。随着业务的扩大，程序员群体内部开始分化为：软件工程师、网络管理员、数据库开发者、网页开发者、系统架构师、测试工程师等等。而网页开发者又能很快进化成后台开发者，前台开发者，PHP开发者，Ruby开发者，Angular开发者等等。
在这随着时间的转移，各个工种开始在各自的领域中专精研究，而很少进行交流互动，只有在迫不得已的时刻才会进行沟通。这种情况就导致了一拖再拖的项目交付日期，昂贵的开发代价，甚至最终失败的项目，客户们开始对这种情况深恶痛绝。
偶尔，也会有人灵机一动的提供一种办法来解决上述问题。但很快，一如既往，客户又开始提出更多的诉求。客户希望能够更多地参加到整个软件的开发流程中来，不时的提出他们的建议，以此来增加客户方对于软件的掌控力，甚至在很晚的时候还提出改需求这种丧心病狂的事情来，结果就是过50%的项目最终都是以失败告终的。更可悲的是，人们对这种情况是束手无策。
而对于运维人员来说，就会遇到如下的问题：
1、这款优秀的产品在目前的底层平台上无法运行，因为这个平台（太古老了，空间不足，不支持某某版本）
2、这款产品的体系结构跟我们的（存储，网络，部署，安全）模型不匹配。
3、这款产品的（报告，安全，监视，备份，服务提供）我们搞不懂 ，所以没法把它做成实际可用的产品。
而 Dev 和 Ops 的具体矛盾点表现在以下两方面：
1、在价值流下游的 Ops 评审认为价值链上游的 Dev 软件非功能质量不满足要求，因此阻止变更。
2、在价值流上游的 Dev 无法获得价值链下游的 Ops 的真实运行环境，因此无法提升交付质量。
于是，逐渐陷入了“无法提升质量”和“非功能质量不满足要求”的死循环中。
简单地说，由于传统Dev和Ops两部分所关注的重点不一致，容易陷入“无法提升质量”和“非功能质量不满足要求”的死循环，同时客户也有参与进软件开发整体流程来增强对项目的掌控力的冲动，所以DevOps这一模式要做到：在项目内部信息能及时反馈、迭代和进行敏捷开发，提升软件交付的质量和效率。
DevOps工具
现在大家在DevOps领域最关注的还是在工具层面，主要侧重于自动化、监视、能力规划和性能、备份与恢复、安全、网络以及服务提供（provisioning）等等。
1、监控工具
比较老牌的就是Zabbix,Nagios，用Zabbix的感觉是最多的。国内的有小米开源的OpenFalcon。这类监控工具一般是对服务器、服务（中间件，数据库）做一些常用指标的监控。
2、性能分析/APM工具
APM很多时候被认为是监控的一个细分领域。但在现代复杂分布式系统架构下，APM工具往往更能准确、直接的帮助用户定位到性能瓶颈，比如哪一个URL访问慢、哪一个方法执行慢、哪一个SQL执行慢。在以往要想拿到这些数据，往往得需要比较资深的架构师、DBA一起合作才能拿到这些数据，而定位瓶颈的效率往往还不太高。现在通过APM工具能让普通技能的运维人员，也很高效的定位到这些深层的问题。现在商用的APM工具不少，国外的有Newrelic，国内知名的就有听云、Oneapm、透视宝这些。开源的也有Pinpoint（naver开源）、Zipkin（twitter开源）、CAT（大众点评开源）。
3、批量+自动化运维工具
这里就比较多了，知名的有Puppet、Ansible、Chef、Saltstack这些。这些在网上的资料也比较多，找比较新版本的官方文档看就行了。Puppet和chef是比较早期的工具，受众面也很大，不过这两个工具基于ruby实现，现在要找到熟悉ruby的人来做这块的二次开发可不容易。而ansible和saltstack则相对新生代一些，目前用户基数增长很快，基于python实现，要找做二次开发的人也相对容易的多。
4、集中日志分析工具
在一个服务器比较多的环境下，如何集中的管理和分析、查询日志，已经变成一个比较强的需求了。想象一下，如果发生了某个错误，你还得一台台机器去翻日志文件，是不是很蛋疼。在这个需求驱动下，就诞生了一些集中日志分析工具。在开源领域，比较知名的就是ELK这一套工具了，涵盖了日志采集、上报、搜索、展现这一类基本需求，现在比较多的上规模的企业都用这个，网上资料也大把。核心实现机制都是通过一些日志采集代理（类似Filebeat）去爬日志文件，将最新的部分提交到采集服务端，后端再对接搜索引擎，能支持很快速、准确的搜索即可。有一个国内不怎么知名的Sentry日志收集服务，比较轻量级，本身是Python做的，与各种语言的日志框架做了非常好的集成，可以很方便的集中收集异常日志，并分配给对应的开发人员。它在github上有10000多个star了，这在DevOps相关的软件里，都是排名非常靠前的了。
5、持续集成/发布工具
例如：Jenkins的。集成打包的过程其实一般都比较简单，配好版本库和打包脚本就行。但发布的过程就比较复杂，有些是全量发布，但也有非常多的IT团队采用增量发布。这个方面如果想用工具，还是得先分析清楚现有的发布流程，手工情况下怎么做，哪些能通过自动化工具来完成。
详情见另一篇博客 https://blog.csdn.net/qq_30154571/article/details/85088928
6、IaaS集成
最近两年的公有云推广比较迅速，很多新的服务器采购都被导入到云上去了。现在主流的公有云都提供了比较完备的API，基于这些API也可以做一些针对基础资源的自动化操作，比如游戏行业的快速开服。
其他来源的工具分类
编码：代码开发和审阅，版本控制工具、代码合并工具
构建：持续集成工具、构建状态统计工具
测试：通过测试和结果确定绩效的工具
打包：成品仓库、应用程序部署前暂存
发布：变更管理、发布审批、发布自动化
配置：基础架构配置和部署，基础架构即代码工具
监视：应用程序性能监视、最终用户体验
Docker和DevOps的关系
传统的DevOps
在传统的DevOps方法中，开发人员编写代码并将其提交给Git存储库，然后检查它在本地和开发环境中的工作方式。
我们会使用像Jenkins这样的CI工具启动代码的构建过程，该工具也在构建期间运行功能测试。如果测试成功通过，我们将更改合并到发布分支中。
运维会使用一些工具为应用程序部署生产准备脚本，并最终将更改投入生产环境（更新版本）。
传统DevOps的问题
第一个问题是运维和开发者使用不同的工具。例如，大多数开发人员不一定知道如何使用脚本工具，而准备发布的任务落在运维身上，但运维通常又不了解应用如何工作。
第二个问题是开发环境通常手动更新而没有自动化。结果导致开发环境非常不稳定，一个开发人员所做的更改可能会中断另一个开发者的更改，而解决这样的冲突问题通常需要花费很多时间，time-to-market变长也就不足为奇了。
第三个问题是开发环境可能与staging环境、生产环境有很大不同。这可能会导致开发人员准备的发行版可能无法在暂存环境中正常工作，或即使测试在暂存环境中成功通过，生产中也可能会出现一些问题，生产中的回滚过程也并非易事。
第四个问题是编写脚本非常耗时，而且容易出错。
利用Docker优化DevOps
Docker之于DevOps的主要优点是开发人员和运维都使用相同的工具——Docker。开发人员在开发阶段，在本地计算机上从Dockerfiles创建Docker镜像并在开发环境中运行。
运维使用相同的Docker镜像，使用Docker对staging和生产环境进行更新。需要注意的是，在更新到软件的新版本时，我们不是要对Docker容器进行patch，换句话说软件的新版本采用一个新的Docker映像和Docker容器的新副本，而不是对旧的Docker容器进行修补。
基于以上，我们可以创建不可变的开发、staging和生产环境。
使用这种方法有几个好处：首先，对所有更改都有很高的控制权，因为使用不可变的Docker镜像和容器进行更改，我们您可以随时回滚到以前的版本；与脚本工具相比，开发、staging和生产环境变得更加相似；使用Docker，我们可以保证如果某个功能在开发环境中有效，它也可以在staging和生产中使用，这也就是我们常说的一致性。
Docker和Kubernetes如何让DevOps变得更具效力
使用Docker创建包含多个相互连接组件的应用拓扑的过程变得更容易理解
由于内置的service和ingress概念，负载均衡配置的过程大大简化
由于Kubernetes的Deployments、StatefulSets、ReplicaSets等功能特性，滚动更新或是蓝绿部署的过程变得非常简单
更多强大的CI/CD工具可用
Kubernetes通过Service Mesh工具提供开箱即用的多云部署场景