Devops是什么职位

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。[1][2][3][4]

可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。

传统的软件组织将开发、IT运维和质量保障设为各自分离的部门，在这种环境下如何采用新的开发方法（例如敏捷软件开发），是一个重要的课题。按照从前的工作方式，开发和部署，不需要IT支持或者QA深入的跨部门的支持；而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。[5]

需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求[6]──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署[7]，并且经常与精益创业方法联系起来。[8] 从2009年起，相关的工作组、专业组织和部落格快速涌现。[9][10][11][12]

DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

DevOps发布经理是一位经验丰富的专业人士，拥有3至4年的IT领域经验。对端到端软件开发和部署生命周期有着深刻的了解。他是一名优秀的沟通者，通常与参与项目的IT专业人员和管理专业人员进行互动。发布经理必须共同处理多个项目和截止日期。

2. DevOps领导

要在这份工作档案中表现出色，DevOps领导应该拥有正确的技能和证书。下面给出了许多可以实现成为DevOps Lead成功梦想的认证。

• JanBask AWS培训和认证，
• Microsoft Azure认证，
• 亚马逊等的AWS认证

DevOps领导在DevOps周期的顶端，负责任地执行所有DevOps流程。DevOps领导对不同的自动化工具有广泛的了解，也可供其他团队成员使用。

DevOps领导是一位经验丰富的人，拥有超过三年的经验，并且知道如何实施DevOps。他可以为项目确定合适的工具和技术。确保了生产和非生产环境的高可用性。

3. DevOps自动化专家

一套正确的技能和认证可以帮助您成为成功的DevOps自动化专家。下面给出了一些技巧(认证)：

• JanBask AWS培训和认证，
• JanBask Azure培训和认证，
• 亚马逊的AWS认证，
• Microsoft等的Azure认证

DevOps自动化专家是负责为生产和非生产环境创建自动化管道的人员。DevOps自动化专家有2到2年的IT经验，经常使用UNIX/LINUX机器。深入了解如何使用shell脚本，Python，PERL等自动执行任务，这些脚本被认为对CI/CD管道非常重要。

4. DevOps测试专业人员

如果想成为一名DevOps测试专业人士，那么应该有一个在这个领域表现出色的测试背景。DevOps测试专业人员的一些卓越认证如下：

• JanBask的Selenium认证，
• 由JanBask测试建筑师大师认证，
• JanBask的ETL测试认证等。

DevOps测试专业人员是负责为开发中的应用程序编写自动化测试用例的人员。至少有2 - 3年的测试领域经验。熟悉Selenium，Java，Python和不同类型的测试可以帮助您在此工作档案中实现增长。

5. DevOps架构师

DevOps架构师是DevOps专家最常见的工作档案之一，应该拥有以下一组认证来加速此工作档案。

= RHCE认证，

• Java认证，
• DevOps认证，
• AWS关联认证等

DevOps架构师是对维护和监控IT基础架构有深入了解的人。知道如何为生产环境或非生产环境创建容错系统。IT行业正在快速发展，因此DevOps工程师应该具备MySQL数据库，AWS，Azure，Java，Linux/Unix机器，Python，PERL等知识。

6. DevOps安全专业人员

以下是DevOps安全专业人员要求的一些广受欢迎的认证：

• DevOps培训和认证
• Linux/Unix认证
• AWS或云认证

DevOps安全专业人员是拥有2-3年IT基础架构安全经验的人。负责为基础设施提供安全保障。他们能够识别基础设施中的安全漏洞并制定计划来应对安全威胁。DevOps安全专业人员对网络安全系统，防火墙，IDS，云系统等有深入的了解。

工作职责1.负责测试环境搭建.运营.维护和监控；2.建立应用部署架构和自动化部署；3.负责测试环境运维体系的维护.运营，建立高效的测试体系；4.负责安全体系的维护.运营；任职要求1.两年以上DevOp相关的工作经验；2.掌握持续集成工具：Jenkin等3.掌握自动化构建和测试工具:Ant.Maven.Jmeter等4.掌握配置管理工具：Salttack.Anible等5.熟练掌握Python,PowerShell,Bat,LinuxShell等；6.熟练掌握Window.Linux的配置和管理；7.熟练掌握qlerver的配置.管理和维护；8.精通自动化运维，能够独立建立自动化运维(CI)和监控体系；9.了解代码安全.白盒测试。

运维分很多分支类别，linux 系统运维，云计算运维，大数据运维，应用运维，桌面运维，idc 数据中心运维等等。不同方向，对技能要求不同，门槛高低差异还是比较大的，待遇也不一样。当然很多简单的运维工作已经逐渐被自动化工具替代了，所以选择很重要。当下，运维门槛和知识广度是以前那些运维无法企及的了，这里重点指那些不愿意成长的摸鱼工具人。运维在接下来十年将发挥显著作用，毕竟已经 2020 年了，运维逐渐被重视起来了，这里说得准运维更多的是云计算时的运维，能够玩转 linux,懂架构规划,工具选型,容器化,微服务,监控报警,持续集成,动态发版,高可用,高并发,能搞定大集群大项目这些。时代已变，运维的春天正当时。请不要轻视自己，毕竟这是企业互联网的保驾护航岗位。待遇不会差，关键是自己得持续成长，面相未来成长，谢谢！

这话题有点大。在行业里，实践DevOps的人们有很多工作头衔。“DevOps工程师”、“DevOps架构师”、“产品发布工程师”、“自动化架构师”、“配置管理工程师”、“开发运维工程师”等等。但真正的挑战是，如何将DevOps作为一种方法论，而不是单纯的技术来深入理解。

DevOps让开发和运维团队互相协作，降低了团队响应变更的时间。借助一些工具、技术和流程就可以实现DevOps环境。它为软件的高效开发指明了道路。

根据Linux基金会的2017开源工作报告，DevOps工作技能（57%）位列最受欢迎技能前三，仅次于云／虚拟化技术（60%）以及应用平台开发（59%）。42%的公司热衷将DevOps技能列入招聘要求。

我们这两年经常看到DevOps这个词，也有很多专门以 DevOps 为主题的大会。大多数人可能对这个词的定义并不明确，其实即使整天口头 DevOps 的人，也不一定就完全理解 DevOps 的真正内涵，很有可能就是从字面上的简单理解。

为了更好地理解 DevOps 奥义，我们不妨先从 DevOps 的起源和背景开始说起。

随着计算机技术的发展，工作内容更细分化、专业化，所以工作职责也逐渐分出开发（ Development ）和运维（ Operations ）两个完全独立的角色，更多的也都是处于独立的部门。

运维人员看重的是保障系统的稳定性、可靠性和安全性，而开发人员则想着如何尽快发布新的版本，增加新的功能，这两者本身就是一种矛盾和冲突，尽管他们的共同目标都是为用户提供软件产品或服务。

10 几年前的软件开发模式也比较单一，基本上市瀑布模式，也有一些采用了螺旋模型。基本上一个项目基本设计两月，详细设计两个月，开发三个月，测试二个月，上线，总体下来，6 个月算是比较小的项目了，大的项目花费数年的时间也是屡见不鲜。

同时，随着云计算技术和平台的出现和迅速普及，基础设施变得更容易获得，也变得可编程化，所以开发者可以更容易的进行基础设施方面的工作，比如创建服务器、 RDS 数据库，部署应用等。拿 AWS 来说，就提供了非常方便的工具、API 和操作界面，开发者可以通过拖拖拽拽来部署一套网站系统，而不必进行任何底层系统工作。

进入互联网时代，唯快不破。

这时候软件开发的特点，就是快速迭代。feature1 开始，一周设计、一周开发，一周测试，之后上线；在第二周的测试的同时，开发人员已经进入第二轮 feautre2 的开发了。功能的交付间隔变小，交付速度变快；同时，因为能快速的从用户获得反馈，试错成本也变低。

正如《大教堂与集市》这本书提到过这么一句话：

也就是说，我们尽量提早发布、频繁发布，然后倾听用户的声音。

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用语），在数据中心或者基础设施工作中实施敏捷的案例。

在加州举办的 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 工程师的事情该怎么看呢？其实既然大家都有这个“误解”，也不必矫枉过正，就好比主角或角色的“角”，到底是念 júe ，还是念 jiǎo 一样，我们按照自己的习惯念就好了，到了现在，感觉这些字的念法已经没有对错之分了。

话说 AWS 有一个认证 DevOps 工程师（ Certified DevOps Engineer ，https://aws.amazon.com/certification/certified-devops-engineer-professional/ ），所以 DevOps 工程师这一职位/角色可能会一直存在下去吧。

DevOps 也不意味这 Dev 和 Ops 要归属统一部门，向同一领导报告。只要观念和认识没有变化，认识不到大家的共同目标，没有采取积极的沟通方式，即使在同一个团队，不同角色的人也很难做到统一思想、团结一致向前看。

根据维基百科上的定义，DevOps 强调开发人员和运维人员（IT人员）的合作，实现软件交付和基础设施变更的自动化。它旨在建立一种可以快速、频繁、可靠地构建、测试和发布软件的文化。

一句话来说， DevOps 其实是一种思想、一组最佳实践、以及一种文化。说得更冠冕堂皇一点，DevOps 是指开发人员和运维人员精诚合作，迅速为用户提供最新的功能，保持系统的稳定运行，为用户提供最大的商业价值。

大体来说，DevOps 可以认为是 一组工具 + 企业文化。

由于 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 理念打造的开发、运维一体化的企业级容器云平台 。

在企业文化方面，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 还是不够的。

其实在 《Agile Infrastructure & Operations》 中，Patrick Debois 就列举了三个角色（部门）：

• Developer（开发、测试）

• IT（基础设施、服务器、网络设备）

• Operation（ helpdesk、用户支持）

DevOps 虽然名字来源于开发和运维的缩写，但是无论从我们前面看到的两篇演讲内容，还是维基百科的定义，除了开发人员之外，还有一个角色是 IT ，当然很多传统的大公司可能会将运维算入到 IT 部门。

而现实中，其实 DevOps 的涵盖范围可能会更广：除了开发（包括测试）、运维和IT，还会涉及到项目经理、产品经理，甚至和销售、市场、HR以及财务等各个部门的人也会产生联系，跨职能部门互相合作，完成某一项目或任务。

DevOps 什么职位？

DevOps是运维吗？

DevOps到底是什么？