又是一个火得一塌糊涂的概念，最早看到这个词汇的时候是在2015年。
彼时距离「DevOps」这个术语诞生已有六年之久，后知后觉的我，开始意识到DevOps的先进性和重要性。
现如今（2017年），DevOps已诞生了8年了，与此同时，一年一度的“DevOpsDays”盛会也在北京顺利举办，而且身为DevOps之父的Patrick Debois也亲自参加了。
可见国内的DevOps圈子已相当活跃了，致力于DevOps实施落地的公司也会越来越多了，这方面， ThoughtWorks算是业界的领跑者了。
1、Definitions and History
这一切还要从敏捷开发说起。
2008年的时候敏捷开发已经相当流行了，所以才会是不是有关于敏捷开发的大会，其中有一场在加拿大多伦多举办的Agile Conference，来自比利时的Patrick Debois发表了题为 《Agile Infrastructure & Operations》 的演讲，可以认为，正是从大概这个时间点开始，DevOps 的概念逐渐开始萌芽。
时隔一年，在加州举办的 O’Reilly Velocity 2009 上，Flickr 的工程师 John Allspaw 和 Paul Hammond 发表了题为《10+ Deploys per Day: Dev and Ops Cooperation at Flickr》的演讲，虽然没有直接提出来 DevOps 这一叫法，但是一般都认为这时候 DevOps 的思想已经诞生，这次演讲也成为 DevOps 这一称呼出现的契机。
Flickr 的这个演讲，主要介绍了开发和运维围绕着共同目标，如何紧密合作，实现 1 天之内完成 10 次以上的软件发布，这也和维基百科上对 DevOps 的定义是一致的。
同年，Patrick Debois便发起了名为「DevOpsDays」的活动，这也标志着 DevOps 的开始普及。
DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality. ——from wikipedia
根据维基百科上的定义，DevOps 强调开发人员和运维人员（IT人员）的合作，实现软件交付和基础设施变更的自动化。它旨在建立一种可以快速、频繁、可靠地构建、测试和发布软件的文化。
一句话来说， DevOps 其实是一种思想、一组最佳实践、以及一种文化。
说得更冠冕堂皇一点，DevOps 是指开发人员和运维人员精诚合作，迅速为用户提供最新的功能，保持系统的稳定运行，为用户提供最大的商业价值。
这么说起来，DevOps其实是敏捷开发时代的一个产物。
人们需要这么一个理念，能够在敏捷开发时代里快速响应，加快迭代、部署的节奏。
可能开发技术足够好了，然而运维能力却无法跟上。但运维能力提升了，却未必能与开发技术很好的融合。当两者经历了磨合期之后，我们又该考虑所造就的产品的质量是否达标。
2、Toolchain
这部分的是被谈及到最多的内容，毕竟这也是DevOps落地的重要环节之一。
你稍微关注一下Puppet，Chef，ControlTier 等社区，就不难理解为什么人们会把这些工具认为是开发和运维之间的桥梁。
再比如「Infrastructure as code」「Continuous Integration」「Continuous Delivery」等概念/工具，都是和DevOps息息相关的。
由于 DevOps 通常是跨部门的工作模式，所以单一的工具并不能足以完成日常工作，而需要使用多种工具来支撑。
整个工具链贯穿了开发和运维的整个生命周期，每个节点都分布了一个或者多个工具，工具的选择或者自实现都需要考虑对整个生命周期的影响。
代码管理：代码编辑器、Code Review工具、版本管理工具等。
打包和构建：npm、maven、Docker、Jenkins 等，最近都是很火的工具。
CI/CD：各种 CI 工具和服务，比如 DroneIO、Wercker、Travis CI、CircleCI、Codeship等。
配置管理（或 Automated infrastructure ）：实现基础设施即代码（Infrastructure as Code），比如 Ansible、Chef、Puppet 等。
监控：各种开源组件，ELK 全家桶、InfluxDB、Grafana、Graphite 等。
发布系统：Codeship、Jenkins 等都可以使用。
ChatOps： Slack、HipChat，以及国内的 bearychat 等。
其他可能需要的工具需求也很多，比如灰度发布、A/B 测试、滚动更新等。
除了上面说的这些开源工具、SaaS 服务，也有一些管理平台服务，比如 AWS ，提供一套服务、流程来方便我们基于 DevOps 思维开发云原生的应用程序 。
3、Culture
如果说工具链是DevOps的血肉，那么文化则是DevOps的灵魂。
这部分也是本文要着重阐述的内容。
这两天看过太多关于开发人员与运维人员撕x的文章，因为这对于解释DevOps在实际工作中的好处是非常有利的证据。
首先，我们说说著名的“Wall of confusion”。附上一张经典的图片：
实际上确实存在一个矛盾点：
站在开发人员的角度考虑，BOSS们的商业宏图需要靠这帮人去实现，在这个商场如战场，险恶丛生，瞬息万变的社会，产品的形态是不会一成不变的，在发展的道路上，多少会有一些调整。这是一个求变的过程，怎么变？那还得靠程序员哥哥们咯！所以，他们的思路是产品随时会变，所以在设计系统架构的时候额外小心，万一有什么没考虑到，酿成大错就不好了。
正所谓：客户虐我千百遍，我待客户如初恋。
站在运维人员的角度考虑，那又是另外一番场景了。有变动，就意味着需要重新打包，部署，这个过程不能保证每次都百分百成功，当这种意外发生了，运维人员是很操心的。
最怕Dashboard突然弹出一条通知，邮箱里突然躺着一封告警邮件，手机突然收到一条短信，还有运维经理突然的关心。。。
正所谓：小改怡情，大改伤身，强改灰飞烟灭。
更糟糕的是，万一这是一家跨国企业，开发和运维部门分散在世界不同的位置，这就更加深了彼此之间的隔阂了。
除此之外，开发和运维两个部门的「甩锅事件」也是时有发生的。
开发人员认为应用完成开发了一个版本，接下来就是运维人员的工作了。
专业点的开发人员会写好脚本，做好配置，写好REAME，传给对应的运维人员。
当运维人员接下这个部署任务后，可能跟开发人员用的不是同一套环境，或者不是一样的工具，拿着脚本随手就是一改，没有脚本的话，就按之前的工作，重新走一遍流程。
上图非常形象的反映了「甩锅事件」的过程。
最好的情况是运维人员在重复之前的工作，最坏的情况是运维人员之间搞出了bug，最后还把锅甩给QA部门。
DevOps的目标是工程效率最大化，它本身也只是一种方法论，是为了实现工程效率最大化的目标而存在的。
简单来讲，就是打破“Wall of Confusion”，并寻找到新的“制衡点”。
DevOps理念的可贵之处在于可以让我们从产品的整个生命周期考虑，或者说是从一个更高的视角（公司层面）考虑问题，先上一张图：
上图将整条业务线（Business Process）分解成了三个步骤：
- Biz，即业务部门。
- Dev，即开发部门。
- Ops，即运维部门。
他们仨彼此之间都有一堵墙。
业务部门与开发部门的隔阂可以用敏捷开发（Agile Development）打破。在商业驱动的前提下，敏捷开发其实是一种以低成本且有效的快速适应市场环境变化的能力。
当然，在开发人员看来，部署的次数增加了，release版本的错误率降下来了，线上fix的时间缩短了等等，都是敏捷开发的现象。
因为敏捷开发不是本文的重点，故不再展开阐述。
开发部门与运维部门的隔阂则可以用DevOps打破。
首先需要解决的就是上述提及的「甩锅」问题，Patrick Debois在《Devops from a sysadmin perspective》一文中主张了两种文化：Culture of collaboration、Culture of sharing。
开发部门和运维部门是事实上的两个部门，但是应该让他们走得更近。
instead of separating developers and operations as we used to do, we need to bring them together more closely.
目的就是去了解彼此的工作，更具体一点，就是了解各自的工作流程，以及用到的一些辅助实现手段，并试图去达成一致。
开发人员辅助运维人员建立持续交付模型，运维人员辅助开发人员搭建运行环境，将开发，测试，UAT，生产等多个环境保持一致。
Patrick Debois甚至主张开发人员和运维人员结对工作，运维人员在部署之前，会与对应的开发人员进行讨论评估影响，以免造成更严重的后果。
对于各种Metrics，运维部门也不能藏着掖着，要将它们分享给公司的其他部门，以便让其他部门的人也能从中学到一些东西。与所有利益干系人一起做事后检查，并进行改进。
与此同时，这也改变了度量和监控的焦点，从运维人员的快速修复变成了及时反馈到整个组织。目标就是从整体上进行优化，而不仅仅是局限在自己工作的部分。
关于尊重（Respect），信赖（Trust），不埋怨（Avoiding Blame）等更高层面的组织文化，本文就不一 一叙述了。
4、DevOps is a title or not
既然DevOps这么重要，那就成立一个「DevOps」部门，然后招聘一帮DevOps工程师。
这么做也有一定的道理，毕竟Amazon还专门出了一个「DevOps工程师」的认证（Certified DevOps Engineer），想必这个title会一直存在下去。
当然，大多数还是反对的声音，最起码Patrick Debois不认为DevOps是一个职位或者部门。
Damon Edwards有一段经典的话：
This makes DevOps someone else’s problem.
You’re a DBA? Don’t worry about DevOps, that’s the DevOps team’s problem.
You’re a security expert? Don’t worry about DevOps, that’s the DevOps team’s problem.
DevOps涵盖的内容实在太多了，可以覆盖整个产品的生命周期，已经不是一般意义上的「全栈」了。
归根结底，我们要招的不是DevOps工程师，而是了解DevOps方法论的相关人员，他们可以是开发人员，项目经理，测试人员，运维人员等等。
每日干货分享，传递互联网世界有价值的讯息，尽在「技术汇」
