n久没写博客了，前面还有好几篇没有补上，最近也是刚刚弄完了考研上岸的后续工作，以及写好了毕业论文的初稿，后面慢慢补坑吧哈哈哈。然后DevOps技术这个东西其实不是新东西了，前两年就已经出现了，一直没有搞清楚这东西在干啥，实习的时候也只是泛泛的听过大家说什么“持续集成”、“敏捷开发”不拉不拉的，不知道前辈们都在说甚么东西，刚好图书馆最近新进了一本《DevOps入门与实践》，拿来学习学习，满足下我的好奇心。
一些我好奇的问题
下面主要是之前我所听过的一些关于DevOps的相关概念，我将会先对这些概念进行说明，然后再正式介绍DevOps这项技术(我觉得他更是一种思想，这个思想下诞生了一系列的工具集合)。
好好的为啥来了个DevOps？
其实确实本来是好好的。传统的开发模式主要分为两大板块：开发和运维，一个完整的产品的交付流程包含了如下的步骤：
1 | 计划 -> 需求分析 -> 设计 -> 实现 -> 测试 -> 发布 |
这样的流程其实是比较好理解的，首先去计划一个项目，包括这个项目要解决的问题、实现方案、人员分工、听客户说需求等等，然后根据客户描述的需求来进行方案设计，然后根据前期工作安排进行实现工作，代码写好了再去测试，最后发布上线，结束。这样的开发模式被称为瀑布模型。瀑布嘛，很好理解，直接从上到下一次性搞定。但是这样的模式放在现在或者以后，是会慢慢出现问题的。
瀑布开发模式所带来的的显著问题就是，一个步骤没有干完你很难继续下一个步骤，一个步骤可能就会卡你几个月，导致产品不能如期交付，在互联网快速发展的今天，举一个平常生活就能接触到的例子，我手机里的软件商店，几乎每天都会提醒我有新的更新让我去下载，而且每次的更新可能就只有那么一点点，版本号后面好几个小数点，什么2.8.0.1.23，其实这样的现象我认为就是敏捷开发的特点，用户很快的反馈需求、问题，产品供应商针对重要的几个问题，迅速的发布小版本更新，迅速的解决目前的问题，很长一段时间后可能才会出一个大版本。这样的开发特点就是来解决瀑布开发模式缺点的。
如果要用图来表示这两种开发模式的区别的话，可以用下面的图来表示：
可以看到敏捷开发模式并不是一次直接扔一个大版本，而是不断的发布小版本来解决客户的反馈问题，这样就极大的提高了产品交付的效率，不会出现瀑布模式的问题了。
那这只是说我们有这么一种构思---持续开发：通过这样的构思来不断的精进产品，增强产品的竞争力，如何实现这样的构思呢？这样的构思就没问题吗？有问题怎么解决呢？这就带来了DevOps，他就是这个解决这个构思落地中出现的问题的。
什么是持续开发？敏捷开发？
上面说到了传统瀑布开发模式的问题，并提到专家们提出了持续开发这样的观点，那么到底啥是持续开发？
其实上面就已经阐述了什么是持续开发了，持续开发(continuous development)，指的就是上面那张敏捷开发模式的开发方式，指的就是上面我说到的构思。而敏捷开发其实是持续开发中比较有代表性的开发方法。二者是从属的关系。所以这里我们讨论一下这种构思存在的问题。
现在的公司部门间都是独立的，搞运维的就搞运维，写代码的就好好写代码，不需要操心自己工作以外的问题，而这种构思就要求开发与运维需要携手一起工作。听起来挺简单的，就你俩合作就完事了，但是实际上并非听起来那么简单，而且双方也由于不怎么care对方的工作，互相甩锅，开发的就只会写代码，对部署中需要考虑的监控、冗余、备份、操作系统这些非功能的问题不怎么清楚；而运维的出于稳定性的考虑，也不怎么想频繁更新。导致这样的构思落地很难。这是其一。
其二，上述的持续开发方式，要求不断的开发、不断的发布(部署)，而传统的瀑布开发模式实际上是一次一个大版本，就部署那么几次，所以持续开发对开发人员与运维人员提出了更高的要求。
为了解决持续开发中频繁添加新功能所带来的麻烦，开发人员就弄出来了很多提高持续性与效率的开发工具，其中之一就是持续集成方法(这个概念下一章会介绍)。
为了解决运维的问题，出现了很多的provisioning(服务提供)工具，provisioning的架构图如下：
其中：
- 最下面的引导层就用来负责创建虚拟机或者安装操作系统；
- 配置管理层用来在完成了引导的服务器上进行一些配置的变更、中间件的管理等；
- 最上面的编排就负责将开发人员弄好的应用一次性地往多个服务器上部署，并对所有服务器进行统一管理。
那上面这个是最开始的，下面这个是最近的：
近年来上面这两层的边界慢慢地就模糊了，典型的比如一些工具(后面我会按照书里的教程展示这些工具的使用)：Puppe、Chef、Ansible，他们的出现实现了一个非常重要的功能----基础设施即代码。
啥意思？就通过上图中的Provisioning工具来把环境中所有的配置：虚拟机配置也好、中间件配置也罢，全部通过写个文本文件就可以实现了，能干啥？你就写代码？那没事，你能看懂字就行，上述这些工具会使用非常简单的领域专用语言(DSL)来描述基础设施(比如Ansible使用了YAML)，即用代码来构建环境，用文本来描述环境。
这样，在前述的构思(持续开发)下，开发人员的问题解决了，运维人员的问题也解决了，那好了，我们可以开始落地这个构思了，这个果实就是DevOps。
Dev(开发)Ops(运维)
PDCA循环（Plan->Do->Check->Act）
其实就是我们前面敏捷开发那个图，一个PDCA循环指把一个业务分为Plan到Do到Check到Act来进行，即计划、做、检查、处理，处理完了继续计划、做、检查...如此下去。在DevOps中，敏捷开发方法就是实现这个循环的方法之一。一个PDCA循环可以用下面这个图来表示：
而我们的DevOps的过程看起来就是这样的一个莫比乌斯环：
黑色就是开发了，绿色则是运维，可以看到这二者有机的结合在一起，一直持续下去(持续开发)。
DevOps技术栈
为了落地DevOps这个构思，我们需要让开发人员和运维人员充分的合作，为此相关专家设计了一系列的工具，《DevOps入门与实践》书中对这些工具所具备的元素进行了总结：
| 类型 | 具体内容 |
|---|---|
| 抽象化 | 对所有资源进行抽象化，消除不同平台间的差异，降低专业难度和复杂度 |
| 自动化 | 通过自动化的方式使用抽象化的资源，降低专业难度，减小开发、运维人员的工作压力 |
| 统一管理 | 通过统一的版本管理系统和沟通工具使信息可视化，构建开发和运维之间紧密的关系 |
| 持续集成 | 通过统一开发部门和运维部门的开发及构建方法，大幅提升系统改善的速度 |
| 监控 | 对资源信息进行集中管理和可视化，构建开发和运维的紧密合作关系 |
抽象化：虚拟化的意思，比如虚拟机、VLan(虚拟局域网)；自动化指由程序来进行一些列的重复性的操作；
统一管理：有三种：问题跟踪系统(如JIRA、Redmine、Trac等)，沟通工具(Skype、Slack、ChatWork等)，软件配置管理工具(Git，Subversion，Perforce等)
持续集成(Continuous Integration, CI)：指频繁并持续地实施代码构建和静态测试、动态测试等工作。最常见的、最常用的：Jenkins，这个工具的使用我会在后续文章介绍。
监控：主要是在Check环节中进行，同时也为Act环节提供重要依据。监控的内容包括内存使用、CPU情况等等，知名工具很多：Zabbix、Munin、JP1、Hinemos等，同时为了利用这些监控数据，通常会使用ELK套件（Elasticsearch(日志检索)、Logstas(日志收集)、Kibana(日志可视化)），后续我也会出ELK的文章，当然除了ELK也有其他的，比如Grafana也可以实现日志可视化，Fluentd也可以进行日志收集。
下图可以看到DevOps涉及到很多很多的技术，当然不需要全部了解完，知道常用的就可以了，下一篇文章我会出如何搭建一个个人的环境。
后续
下一篇文章我会记录如何搭建一个个人本地使用的DevOps环境，并介绍相关工具的使用包括比如vagrant、ansible等等。
参考学习
《DevOps入门与实践》-- [日]DevOps引入指南研究会 刘斌 译
