一、DevOps 到底是什么不是什么?
DevOps 到底是不是一个职位，还是像敏捷、精益一样是一种思想、***实践?
如果我们看看最近的招聘信息，职位可谓五花八门：技术经理、架构师、布道师、开发总监什么的，当然也有比较新的职位名称，比如数据科学家、运维开发工程师。
不过总体说来主流的分类方式还是分为两大类：开发工程师(Development)和运维工程师(Operations)，即便是所谓的 DevOps 工程师，也更多是偏运维的成分更多一些。
不过大叔觉得，运维工程师的名字应该叫基础设施工程师( Infrastructure engineer )更合适一些。
我们这两年经常看到DevOps这个词，也有很多专门以 DevOps 为主题的大会。大多数人可能对这个词的定义并不明确，其实即使整天口头 DevOps 的人，也不一定就完全理解 DevOps 的真正内涵，很有可能就是从字面上的简单理解。
为了更好地理解 DevOps 奥义，我们不妨先从 DevOps 的起源和背景开始说起。
二、DevOps出现的背景
随着计算机技术的发展，工作内容更细分化、专业化，所以工作职责也逐渐分出开发( Development )和运维( Operations )两个完全独立的角色，更多的也都是处于独立的部门。
运维人员看重的是保障系统的稳定性、可靠性和安全性，而开发人员则想着如何尽快发布新的版本，增加新的功能，这两者本身就是一种矛盾和冲突，尽管他们的共同目标都是为用户提供软件产品或服务。
10 几年前的软件开发模式也比较单一，基本上市瀑布模式，也有一些采用了螺旋模型。基本上一个项目基本设计两月，详细设计两个月，开发三个月，测试二个月，上线，总体下来，6 个月算是比较小的项目了，大的项目花费数年的时间也是屡见不鲜。
同时，随着云计算技术和平台的出现和迅速普及，基础设施变得更容易获得，也变得可编程化，所以开发者可以更容易的进行基础设施方面的工作，比如创建服务器、 RDS 数据库，部署应用等。拿 AWS 来说，就提供了非常方便的工具、API 和操作界面，开发者可以通过拖拖拽拽来部署一套网站系统，而不必进行任何底层系统工作。
三、从敏捷开始
进入互联网时代，唯快不破。
这时候软件开发的特点，就是快速迭代。feature1 开始，一周设计、一周开发，一周测试，之后上线;在第二周的测试的同时，开发人员已经进入第二轮 feautre2 的开发了。功能的交付间隔变小，交付速度变快;同时，因为能快速的从用户获得反馈，试错成本也变低。
正如《大教堂与集市》这本书提到过这么一句话：
| Release early. Release often. And listen to your customers. |
也就是说，我们尽量提早发布、频繁发布，然后倾听用户的声音。
2008年的时候敏捷开发已经相当流行了，而在开发之外，比如运维、IT或者销售等部门，敏捷的认知程度还很低。
DevOps 出现的一年之前，2008 的加拿大多伦多，举办了 Agile 2008 conference ，比利时的独立咨询师 Patrick Debois ( http://www.jedi.be/blog/ )发表了题为 《Agile Infrastructure & Operations》 的演讲，可以认为，正是从大概这个时间点开始，DevOps 的概念逐渐开始萌芽。
***份 paper 《Agile Infrastructure & Operations》：
http://www.jedi.be/presentations/agile-infrastructure-agile-2008.pdf
Patrick Debois 本人即做过开发，也做过运维，更了解两种角色的异同。因此，他在本次敏捷大会上，介绍了让开发部门做 Product Owner(Scrum用语)，在数据中心或者基础设施工作中实施敏捷的案例。
四、DevOps概念的萌芽
在加州举办的 O’Reilly Velocity 2009 上，Flickr 的工程师 John Allspaw 和 Paul Hammond 发表了题为《10+ Deploys per Day: Dev and Ops Cooperation at Flickr》的演讲，虽然没有直接提出来 DevOps 这一叫法，但是一般都认为这时候 DevOps 的思想已经诞生，这次演讲也成为 DevOps 这一称呼出现的契机。
O’Reilly 主办的 Velocity 大会知名度非常高，但是其大会内容相对于开发来说，更多的是侧重于运维的内容。其实这个大会本身也是我们所说“开发和运维的分离(割裂)”的证明之一。
Flickr 的这个演讲，主要介绍了开发和运维围绕着共同目标，如何紧密合作，实现 1 天之内完成 10 次以上的软件发布，这也和维基百科上对 DevOps 的定义
是一致的。该演讲也同时指明了，由于开发和运维在组织上的割裂，会导致互相之间的利益冲突，而冲突则会导致大家偏离组织最初的、统一的、整体的目标。其实销售和开发、销售和运维之间也有类似问题存在。销售要快速满足客户需求，开发偏保守，一般不敢轻易承诺;同样，运维对开发也像开发对销售一样保守，更看重稳定性，不愿轻易改变。
利益冲突导致的问题愈演愈重，一定会发生各种狗血的剧情，完全超出开发或者运维本职工作范围之内。
Patrick Debois 也观看了这场演讲的视频，并在这之后发起了 Devopsdays ( http://www.devopsdays.org/ )活动，这也标志着 DevOps 的开始普及。DevOps 这一叫法真正出现，也是源于 2009/10/30 在比利时举办的 DevOpsDays Ghent 2009 活动。
第二份 paper 《10+ Deploys per Day: Dev and Ops Cooperation at Flickr》： http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
五、DevOps不是什么
先说说 DevOps 不是什么，以此来和大家探讨一下之前很多人可能存在的对 DevOps 的误解。
DevOps 不是一种职位，因此所谓的 DevOps 工程师到底是什么?是不是就是具备很强编码能力的运维(或者叫基础设施工程师更合适)。
DevOps 也不是一个部门，不是 DevOps 工程师的集合。
那面对招聘信息或者自称 DevOps 工程师的事情该怎么看呢?其实既然大家都有这个“误解”，也不必矫枉过正，就好比主角或角色的“角”，到底是念 júe ，还是念 jiǎo 一样，我们按照自己的习惯念就好了，到了现在，感觉这些字的念法已经没有对错之分了。
话说 AWS 有一个认证 DevOps 工程师( Certified DevOps Engineer ，https://aws.amazon.com/certification/certified-devops-engineer-professional/ )，所以 DevOps 工程师这一职位/角色可能会一直存在下去吧。
DevOps 也不意味这 Dev 和 Ops 要归属统一部门，向同一领导报告。只要观念和认识没有变化，认识不到大家的共同目标，没有采取积极的沟通方式，即使在同一个团队，不同角色的人也很难做到统一思想、团结一致向前看。
六、DevOps到底是什么
根据维基百科上的定义，DevOps 强调开发人员和运维人员(IT人员)的合作，实现软件交付和基础设施变更的自动化。它旨在建立一种可以快速、频繁、可靠地构建、测试和发布软件的文化。
一句话来说， DevOps 其实是一种思想、一组***实践、以及一种文化。说得更冠冕堂皇一点，DevOps 是指开发人员和运维人员精诚合作，迅速为用户提供***的功能，保持系统的稳定运行，为用户提供***的商业价值。
七、DevOps的基础
大体来说，DevOps 可以认为是 一组工具 + 企业文化。
1. 工具集(toolchain)
由于 DevOps 涉及到各个部门以及软件开发的整个生命周期，所以我们需要使用多种软件来支撑我们的 DevOps 实践。比如至少在这些方面，我们已经有很多非常好用的工具可以选择了：
- 代码管理：编辑器、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 思维开发云原生的应用程序，也有一些像 Docker cloud 这样的提供基于 Docker 容器的管理平台，国内的灵雀云也是这样一个基于 DevOps 理念打造的开发、运维一体化的企业级容器云平台 。
2. 组织文化
在企业文化方面，DevOps 推崇尊重(Respect)、信赖(Trust)、正视失败(Healthy attitude about failure)、不埋怨(Avoiding Blame)等。当然，这几条只是 2009 年 Flickr 的工程师演讲中讲到的几点，实际上范畴还要更广泛的多，每个组织都需要自己定制。
其实这是一门管理学。DevOps 成功的关键在于文化，没文化真可怕，即使是开发、运维肩并肩坐着，一块吃饭、睡觉，开发也还是原来那个开发，运维也还是原来那个运维。
除了上面提到的工具和文化，我们还可以总结出很多 DevOps 的其他因素，比如人(People)的思想和思考方式、开发和运维的流程(Process)、精益(Lean)、自动化(Automation)、测量(Measurement，请参考 指标驱动开发(MDD) )、共享(Sharing)、沟通(Communication)、PDCA/OODA 等。
管理学的理论、工具也是多如牛毛，能利用的都该利用。
那这里可能大叔重点说一下同理心(Empathy)，也叫做换位思考，在沟通过程中，主动去了解他人的想法、理解他人的立场和感受，站在他人的角度思考和处理问题。同理心是一个双方向的对话，是一种解决冲突和满足双方需求的途径。
没有同理心、没有互相理解，即使我们强制采取 DevOps 的方法和实践，强制一天部署一次，强制自动化，也只能是暂时的，不能获得组织内的认同和理解，不能实现真正的 DevOps 。同理心让 Ops 认识到原来快速、频繁的发布并没什么大惊小怪的，也没什么好可怕的;让开发人员意识到自己写了多么愚蠢、性能低劣、安全漏洞多的软件。正是同理心的作用，才能让 Dev 和 Ops 团结起来为用户提供***的服务和产品。
八、DevOps不只有 Dev 和 Ops
DevOps 只有 Dev 和 Ops 还是不够的。
其实在 《Agile Infrastructure & Operations》 中，Patrick Debois 就列举了三个角色(部门)：
- Developer(开发、测试)
- IT(基础设施、服务器、网络设备)
- Operation( helpdesk、用户支持)
DevOps 虽然名字来源于开发和运维的缩写，但是无论从我们前面看到的两篇演讲内容，还是维基百科的定义，除了开发人员之外，还有一个角色是 IT ，当然很多传统的大公司可能会将运维算入到 IT 部门。
而现实中，其实 DevOps 的涵盖范围可能会更广：除了开发(包括测试)、运维和IT，还会涉及到项目经理、产品经理，甚至和销售、市场、HR以及财务等各个部门的人也会产生联系，跨职能部门互相合作，完成某一项目或任务。
【本文为51CTO专栏作者“徐磊”的原创稿件，转载请通过作者微信公众号devopshub获取授权】
