一、DevOps：
什么是DevOps？WikiPedia上说："DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。
想实现DevOps相关解决方案，以下三方面需要关注：
评价和鼓励改变文化
改变文化和激励系统从来不是一件易事。但是，如果你不改变企业文化，兑现DevOps的承诺将非常困难。考察一个企业的主导文化时，你需要紧密关注如何评价和判断企业业绩。评价的内容将影响和刺激行为的发生。开发-运维生命周期中的所有当事方需要明白，在更大的企业流程中自己只是其中一部分。个体和团队的成功都要放在整个开发-运维生命周期内来进行评价。对于许多机构来说，这是一个转变，不再是孤立的来进行业绩评价，每一个团队不再是基于自己的团队来评价和判断业绩好坏。
统一标准化的流程
这是DevOps的一个重要主题，整个开发-运维生命周期必须被看作一个端对端过流程。流程的不同阶段可以采取不同的方法，只要这些流程可以被组合到一起创建一个统一的流程。与评价和激励的问题相似的是，实现这个统一的流程时每个组织可能会有略微不同的需求。
统一的工具
这是大多数DevOps讨论一直在关注的领域。这一点不令人吃惊，因为当技术专家在考虑解决一个问题时，第一反应往往就是直接跳转到工具讨论上。如果你关注Puppet、Chef或ControlTier等工具社区，那么你可能已经意识到人们对在开发和运维工具之间建立桥梁的重大关注。“基础设施即代码（Infrastructure as code）”、“模型驱动自动化（model driven automation）”和“持续性部署（continuous deployment）”都是可以划归DevOps旗下的概念
敏捷基础设施
敏捷基础设施到底是干嘛的呢？能给我们提供什么价值呢？
那我们先说说基础设施运维的阶段：
第一阶段：纯手机阶段。
全部人肉，物理机安装软件，有专门的运维团队负责部署。A物理机是给订单用的，B物理机是给登录用的，绝对不能互相干扰。常常因为敲错命令，导致故障。标准化通过规范约束，效果甚微，效率十分低下。
第二阶段：脚本阶段（半自动）。
内部制定规范，要求必须严格执行。通过部分脚本实现部署、启停。部署还是要通过运维人员操作、配置，半自动化方式，仍然需要敲命令。使用虚拟机隔离，虚拟机数量很多，运维人员在窗口中来回切换，可能看错窗口，执行了错误的命令。申请机器需要提前，每年都要做服务器需求计划。中间加机器非常麻烦。
第三阶段：工具阶段（自动化）。
少数运维人员，通过私有云管理虚拟机。通过CI工具实现持续部署。运维人员通过虚拟机镜像来封装常用依赖环境。但是开发环境和测试环境、生产环境差距很大，可能会出现开发人员本地测试通过，测试人员说有问题，测试人员在测试环境测试通过，一上线就有问题。
第四阶段：敏捷基础设施。
无需运维人员，全部自动化，通过容器封装环境，开发人员可以直接将所有软件和依赖直接封装到容器中，打包成镜像，生产环境直接部署镜像。可以实现所有环境都一样。容器调度平台管理容器，资源利用率更高，通过配置文件描述环境，例如我要部署8台Nginx，端口是什么，镜像用哪个，日志放在什么地方，配置文件用哪个，部署在什么地方等等，都可以直接描述出来。注意，这个描述文件以前是运维干的，现在开发就能搞定。
划重点！！！
敏捷基础设施实际上并不是一个全新的术语，是指使用脚本或文件配置计算基础设施环境，而不是手动配置环境的方法。
敏捷基础设施也可称为基础设施即代码（Infrastructure as Code）或者可编程基础设施（Programmable Infrastructure），基础设施即代码可以将基础设施配置完全当作软件编程来进行。实际上，这已经开始让编写应用和创建其运行环境之间的界限变得逐渐模糊起来。应用可能包含用于创建和协调其自身虚拟机或容器的脚本。这是云计算的基础，并且对DevOps至关重要。
为了解决开发和运维之间的矛盾，催生了DevOps，DevOps使运维人员的职责发生了巨大的转变，快速构建环境必须通过自动化实现，基础设施即代码就是快速构建环境的基础。运行业务应用和配置基础设施在统一的CI/CD平台执行。
