DevOps怎么开展？
虽然DevOps工程师的角色多种多样，但是几乎所有DevOps工程师每天都会触及两件事——自动化和持续集成；且从思维角度时刻遵守以下准则：从体系到方法从过程到实践从工具到技术从组织到文化从体系到方法从过程到实践从工具到技术从组织到文化DevOps是当前的最新趋势，但是有很多朋友还是不知道DevOps工程师到底是做什么的?DevOps工程师以最纯粹的方式弥合了软件开发和运维团队之间的差距，以提高软件的交付率。
DevOps工程师带来了什么?传统的软件开发流程是软件开发人员花费数周和数月编写代码，然后将代码交给QA团队进行测试，然后将最终的发布版交给运维团队去布署。所有的这三个阶段，即开发，测试，布署，之间缺乏协作。开发者编写代码然后交给布署团队。现在由布署团队来解决代码布署过程中出现的问题，或将代码交给开发团队以修复bug。
所有这些都导致软件开发过程变慢。但是在DevOps模式下，这三个团队将不再相互隔离。大多数时候，这三个团队将合并成一个团队，工程师会在整个应用程序生命周期中工作，从开发和测试到布署到操作，并开发出一系列不限于单一功能的技能。安全团队也可以在整个应用程序生成周期中和开发和运维更紧密的合作。为什么DevOps工程师的角色会有所不同?DevOps工程师并不是一件新鲜事。
它是一类工程师的统称，如系统工程师，自动化构建工程师，软件工程师，Linux工程师等等。然而，DevOps工程师的工作性质因组件而异。在某些情况下，他们的工作是基础设施的自动化和维护。有些组件将他们的工作扩展到整个交付链。DevOps工程师的角色各不相同，因为他必须通过克服传统的协作障碍与开发人员和运维人员进行协作。
而且不同的组织在这个过程中会有不同的协作障碍。DevOps工程师日常工作中最重要的两个方面虽然DevOps工程师的角色多种多样，但是几乎所有DevOps工程师每天都会触及两件事——自动化和持续集成。自动化与维护基础设施相关的大多数任务仍然是手动的。公司更愿意使用传统的成熟的方法，并不是自动化的相同流程，因为它们不想冒任何风险。
但事实是自动化任务将有助于加快软件的开发和布署，这意味着从客户账户到公司账户更快的现金转移。要意识到这一点，例如，如果系统工程师的任务是每天两次手动备份所有服务器，它这是在浪费时间，因为通过编写脚本，在一些云设施中自动备份服务器可轻松实现这一点。通过自动执行备份过程，你可以让系统工程师更专注于关键问题，例如对由于某些VM问题而导致服务器关闭进行故障排除。
手动执行相同操作将导致系统工程师负担过重，其效率将大幅降低。这只是一个很简单的例子来说明不转向自动化而造成的资源浪费。DevOps可以看作是敏捷(Agile)的扩展，因为它可以降低由于开发团队，QA和布署团队之间的协作不良而可能出现的风险。DevOps通过认识到高质量软件需要包括QA和运维专家在内的所有利益相关方的持续参与和反馈的这一事实，扩展了敏捷原则的范围。
有许多事情可以通过自动化方式来完成，例如在发布时，使用新补丁更新Apache Web服务器，更新服务器上布署的开源软件的版本。DevOps工程师可以通过创建脚本环境来自动化配置服务器的过程。你可以在一个节点上运行脚本，但如果不是数以千计的节点，则在数百个节点上运行相同的脚本将变得不切实际。脚本在这里不是可扩展的解决方案。
因此，需要以可扩展方式，跨大量节点自动化软件供应，配置管理，和应用程序布署。这就是像Chef，Puppet，和Ansible这种配置管理工具在DevOps世界中派上用场的地方。持续集成DevOps的另一个重要的方面是持续集成(CI),它是一种软件实践，CI允许开发人员不断更新对单个仓库的更改，从而进行自动化构建和测试。
一个持续集成系统通常包含一个监控版本控制系统的工具。每当监测到版本控制系统的更改时，持续集成系统将会自动化构建和测试应用程序。如果构建或测试未通过，系统会立即通知开发人员去解决问题。持续集成可确保持续交付，因为所有的代码更改都会持续布署到构建阶段之后的测试和生产环境中。使用持续集成，开发人员可以从手动任务中解脱出来，提高他们的工作效率，现在可以在CI中以自动的方式完成;由于频繁测试，错误和bug将更容易被找到和减少;可以更快速，更频繁的提供对最终用户的更新。
有多种产品和工具可以帮你在组织中实现持续集成。有些工具可以让你在自己的网络基础架构中托管CI服务器。最流行的一个是Jenkins，它是由Sun公司的Hudson项目重新命名而来。还有一些其它的托管CI产品，例如CircleCI和Travis CI，它们是完全托管在云端的。这些托管CI产品正变得越来越流行，尤其是对于小型公司或组织，因为它可以让工程师团队尽可能快速的开始持续集成。
研发部门Devops转型应该注意哪些坑？
随着市场的竞争日益激烈，各企业纷纷加速数字化转型，通过创新，不断向市场推出新产品，新服务，在数字化转型的浪潮中，DevOps无疑是如今企业加速数字化转型的助推器。然而，DevOps在转型过程中并不是一帆风顺的，DevOps改变的不只是研发过程，还包含企业的组织和文化，因此转型也不是研发部一个部门的事，而是企业从上到下都要参与，都要推动的事情。
上图是转型的J型曲线，这个曲线出自于2018全球DevOps现状调查报告，但这个曲线在很多变革当中都会出现，DevOps也好，敏捷也好，都会经过这样的曲线，这中间有一个非常大的坑，经历过这个痛苦的过程之后，才会变得越来越好。1、文化的坑DevOps的敏捷文化讲起来很不错，但真正的要做好很难。敏捷实践里讲要将项目经理称为Scrum Master，需求替换为用户故事，用户故事再拆分为任务，每个迭代称为Sprint，每天都要站会，每个人都要说昨天干的啥，今天要干啥，有没有问题。
就拿需求任务线上化和站会来说，正如那个J型曲线一样，开始时会按照规范录入，按照要求开站会，但后来发现录入需要时间，开站会需要时间，如果此时开发任务繁重，人员不足时，这些被认为繁琐的事项就会被简化。因此，良好的文化需要配套的资源才能运转，效果才能凸显。2、工具的坑DevOps的工具链建设是实施DevOps的第一步。
但很多人认为，有了工具就有了DevOps。一般工具都是满足某一个阶段需求，比如，jenkins就是用来做持续集成的，Jira就是用来做项目管理的，gitlab算一个集大成者。有了工具就能实施好DevOps吗？答案是：不是，只能说这些工具有就比没有强，有了工具的确能提高某些阶段的效率。但DevOps是为了提高整个研发流程的效率和质量，让需求流动起来，并通过不断的反馈，持续改进，加速交付高质量的用户价值。
3、组织的坑很多人认为一个企业的信息中心或者科技部门是负责企业信息化建设的，因此，DevOps的转型也是科技部门的职责，跟业务部门没有关系，跟企业高管没有关系。这些想法都是错的。DevOps转型会使得之前的组织结构发生变化，将之前的大部队作战转型为一个一个的小团体作战，机动灵活。同时，DevOps在企业内部实施时，要形成以企业CIO，业务部门和科技部门共同组成的DevOps转型小组。
否则，只靠一两个DevOps开发人员推动整个企业的DevOps转型，难上加难。DevOps转型虽然会经历各种各样的痛苦，但风雨过后就是彩虹，并且DevOps转型已经是大势所趋，是关系到企业生死存亡的战略决策。因此，企业要想生存，必须、快速的加入DevOps转型的大潮之中，提前经历痛苦，提前享受幸福。以上只是个人的理解，欢迎留言交流。
DevOps究竟是如何改变开发和运维人员的？
如今，DevOps已经被越来越多的企业认可，DevOps不仅仅停留在开发和运维的范围，如今的DevOps是软件研发全生命周期管理的一整套方法论和最佳实践，是DevOps文化建设和人才培养。如果只涉及开发和运维人员，下面从实施DevOps之前和之后做个比较。1、强化共同目标之前，对于开发和运维来说，开发人员只负责编码，运维人员则确保其正常运行。
Ticketmaster的首席技术官Jody Mulkey在过去25年时间里，将开发（Dev）和运维（Ops）比作美式橄榄球比赛，其中，Ops是防守组，视图阻止对方得分；Dev则是进攻组，其目标是尽全力得分。当有一天，他意识到这个比喻并不恰当，因为Dev和Ops从来没有同一时间出现在球场上，因为他们实际上并不属于同一个团队。
如今，DevOps强调的是共同的目标，是通过建立彼此的信任共同完成目标。因此，此时的比喻是，Dev的工作是持球冲锋，而Ops的工作是保证Dev有足够的时间向前冲，他们同时出现在球场上，他们属于同一个团队。2、对开发人员的改变DevOps使得开发人员的任务更井然有序且快速交付。之前，开发人员都是按照需求说明书开发软件，需求说明书里需要提供什么功能，开发人员就开发什么功能。
在开发之前，还需要编写概要设计文档和详细设计文档，这些文档都被评审通过后，才能进行开发。功能开发完成后，还需要等待运维人员耗时一周左右的环境部署，最可怕的是，这些功能交付到用户手上或许并不是他们想要的，延期返工现象非常严重。如今，DevOps开发采用敏捷开发模式，基于Scrum、看板方法等工具，以MVP（最小可交付单元）作为价值单元交付给用户，用户试用后及时反馈，一起辅助开发人员设计系统。
正如敏捷宣言所提到的，个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。另外，DevOps持续集成，持续交付自动化工具链，使得开发人员只关心业务代码编写，提交后的代码自动进行构建、打包、部署，不需要依赖于运维人员，大大提高了软件部署的频率，快速交付用户价值。
3、对运维人员的改变DevOps对于运维人员的改变是最关键的，大大提高了他们的工作效率，甚至明显改变了现代敏捷运维团队的职责范围。之前，运维人员负责保证各个应用程序的正常运行。包括部署环境搭建，数据库服务器和web服务器安装和设置，应用软件的部署，应用软件的监控等。特别是当紧急需要一套环境时，当大规模安装、部署服务器软件和应用软件时，对于运维人员是一场噩梦。
如今，随着Chef、Ansible等工具的出现，DevOps实现了高标准化，仅需要几个简单的工具，就能通过自动化的方式安装、部署大批量的环境和服务。运维人员的职责也转变为部署和维护这种自动化的DevOps服务。DevOps使得开发和运维人员联系更加紧密，通过建立和强化彼此的信任关系，基于DevOps自动化服务，共同实现高效，高质量，稳定的交付用户价值的目标。
对于有志于从事devops相关职业的人，学东西的过程中要如何去实践？
这个问题很不错，自己从事DevOps有3年了，并且会一直从事下去，作为自己的事业深耕。这里不只是为了回答题主的问题，也是为了自己对以后如何去更好的实践DevOps有个梳理。从工具做起，培养DevOps思维做任何行业都会有起步阶段，起步的时候我们不可能看的远，理解的也不够深。可能听别人说过DevOps或者从网上看过类似的介绍，就认为DevOps就是把工具做好，让研发更快。
对于初学者的确是这样，就是为了把某个工具做好，或者利用现有的工具提高企业内部的研发效率。比如，搭建了一个jenkins就实现了自动化的持续集成，搭建了一个gitlab就能够将企业内部代码统一托管起来，搭建Nexus服务器，实现依赖包的统一管理，搭建Zabbix监控服务器，实现应用服务的监控和告警。这些都是具体的工具，对于初学者，不管是负责开发还是运维，这些工具的使用都是必须的。
另外，还要会开发语言，java，python，shell等，自己开发DevOps相关系统。通过具体工具的开发和使用，就会遇到用户的各种问题，这些问题是非常宝贵的财富，每一个问题都会引导你去思考这些工具在哪里没有满足用户需求，为什么？如何去满足？专注部分更要有全局视角DevOps的范围是非常广泛的，初始阶段的工具建设是基础，但也只是冰山一角。
在做DevOps实践时，我们要专注某一个领域，比如敏捷开发，版本控制，持续交付，运维监控等，每一个领域如果深究，都有很多东西需要学习，都有不断优化的地方。初此之外，我们还有对整个DevOps全貌有个了解，要清晰的知道自己所从事的这个阶段在整个DevOps里处于什么样的位置，我的未知领域是什么？这样我们看到的不只是冰山一角，而是整座冰山。
理论要联系实际实践出真知。在如今互联网各种知识泛滥的年代，我们缺少的不是获取知识，而是实践的机会。互联网发展20多年，作为软件开发人员的我们，架构师都是未来努力的方向，看过好多《如何成为一名合格的架构师》，对着技术的发展，新框架封装的越来越好，开发人员只需要几个简单的步骤就能使用强大的功能，对于哪些经历过从零打造一个框架的机会，经历过日访问量上亿的系统的改造的机会，经历过阿里双11的架构师又有几个。
DevOps也是一样，只有真正去做了，做过了，痛苦过了，回头再去读哪些DevOps书籍的时候才能与作者产生共鸣，里面的每一句话，每一个字才能彻底理解，因为这些都是日常工作中遇到的问题。DevOps认证，能力的证明认证是自己能力的证明。这个有肯定比没有好。我们说自己很牛，拿什么来证明呢？现实就是这样，拿着清华大学的毕业证去找工作就是好找。
DevOps也是一样，昨天看到一个文章，DevOps举办的一个活动，要求有DevOps相关的认证，这就是敲门砖。就跟上大学一样，既然去上了，拿个毕业证也算是给自己一个交代。DevOps是属于软件工程垂直领域，如今，都在讲长板原理，要把自己的优势变得越来越强，你就是成功者。以上是自己的理解，欢迎留言交流！。
