最近跟一个资深的运维工程师、AWS 专家老朱（人称叔），聊到了 DevOps 这个话题。
到底什么才是 DevOps？过去启动项目，10人规模左右的研发团队，总会配置一个 ”DevOps 的角色“，来负责搭建基础设施、CI 环境，负责产品包的部署和上线的一些工作。所以 DevOps 是一种新的角色么？是不是在以前的 Ops（运维工程师）的基础上，掌握了更多自动化运维的工具，就可以称为 DevOps 了？
老朱摇摇头，不对，DevOps 并不是一种角色。
“是更加自动化么？”
“与其说是自动化，倒不如说是软件交付的新的方式，或者说是一种文化。自动化就是自动化，以前运维工作也会自动化，并不是从现在开始的。”
随即在网上搜索了 DevOps 的定义，AWS 主站上的定义是我比较满意的一个：
DevOps 集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。
DevOps 是一种高速交付软件的一种方式。那么接着下一个问题就来了：高速交付的方法千千万，为什么会称之为 DevOps 呢？这个概念如何发展到现在的样子的？
在旧有的观念里面，Dev 和 Ops 是严格分离的，一般都归属于不同的部门，研发部和运维部，在工作中交集不多。一般只有需要产品上线或升级的时候，开发部门才会拿着开完测试完的产品包，交到运维部门运维工程师的手中（可能是个 U盘...），然后由运维工程师部署上线。在这种组织里，Dev 只负责开发 Feature，开发的越多越好，越快越好；而 Ops 负责运行维护开发好的软件，他们并不希望经常会有上线或者变更，所以越少越好，因为对运维工程师来说，每次的更新都是一次风险。
随着外界商业环境的加速变化，以及敏捷、云、容器化、持续交付的发展，从代码的提交，到代码上到真实产品环境的时间越来越短，开发和运维的工作也产生了越来越多的交集。一群野蛮人（一部分开发，以及一群想要改革经常背锅现状的 Ops），带着先进的流程和工具，冲进了运维团队，势必要进行一场轰轰烈烈的改造，建立一条自动化的管道，将程序员笔记本里的代码，像输血一样，运送到正在运行的产品中，并可以监控带来的变化和影响，及时获取各个环节的反馈，快速调整。DevOps 就是在这样的背景下，应运而生的理念。它试图融合开发和运维，打破部门的壁垒（避免互相甩锅），让大家能像一个团队一样来工作。
虽然开发和 Ops 沙文主义会告诉你，没有 DevOps 工程师这种角色。但很多公司都在招聘 DevOps，甚至在组建 DevOps 部门。 由于市场的存在，大家总需要一个名词来代指拥有这些技能的工程师，与传统的 Ops（运维工程师）区分开，所以大家还是习惯于使用 DevOps 来代指一个角色。这些工程师，习惯于与 Linux 打交道，与很多使用高级语言的应用开发不同，他们更习惯于使用脚本语言，比如 python、ruby，可以更灵活的进行自动化脚本片段的编写，以及往往会对某种云有深入的耕耘，比如 AWS，或者 Azure 等。
在这些工程师的工具箱里，也有很多趁手的工具可以用，后面会分章节，介绍下面这些工具和工具背后的理念。
- 配置管理 - Terraform
- 版本管理 - Git+Gitlab
- 包管理 - Docker
- 持续部署 - Jenkins
- 运行时环境管理 - AWS ECS
- 监控 - ELK + Grafana
未完待续
