devops培训

DevOps是IT服务管理的一种模式。过去的数十年间，IT运维发展经历了数个阶段。从早期的手工运维到标准化运维、自动化运维，到如今的DevOps、AIOps。

简言之，DevOps试图打通开发和运维的部门墙，从而打通整个IT价值交付的全生命周期，从产品需求到上线运维的全过程实现效率的提升。

DevOps最显著的作用是提高了企业产品的交付质量、缩短开发周期、减少故障。而降本增效是每一个公司在数字化转型之后的很大的挑战，DevOps无疑直击痛点。

而作为一名DevOps 工程师，除了要具备软件工程师基本的编程能力以外,还需要特定的人际交往、工具使用等技能。换句话说,DevOps 工程师需要“软”、“硬”技能兼备,具体如下:一、沟通与协作技巧

DevOps 是一种横跨软件开发、测试和部署的协作方法。它将原本具有不同目标的开发、测试和运维小团队聚集在一起,以实现更高效和高质量的代码发布,这就要求 DevOps 流程中的不同角色之间不能有任何交流障碍。因此,良好的沟通技巧(无论是口头还是书面)对于优秀的 DevOps 工程师来说是必不可少的。

协作能力也很重要。DevOps 是团队合作的开发模式,每个工程师都是团队成员,需要在整个软件迭代过程中支持其他同事的工作。这不仅仅要求我们成为一名优秀的队友,还要在适当的时候给新人一些建议,包括但不限于指导和建议团队成员交付代码的最佳方式、编码时使用哪些工具以及如何测试最新功能。这就要求我们自身也要对这些 DevOps 流程中的必要技能有所了解。二、熟悉和理解 DevOps 工具链除了协作和沟通这样的“软”技能之外,DevOps 工程师还必须知道如何使用各种复杂工具协同工作以支持软件交付目标,这是成为一个优秀的 DevOps 工程师所必备的“硬”技能。DevOps 工程师需要知道如何使用和理解以下类型工具的作用:

版本控制工具

详细地说,集合了代码审查、合并功能的版本控制工具是能让多个开发人员之间完美协作的主要DevOps 工具。由于 DevOps 流程汇集了来自各个部门的专家,所以他们需要了解源代码控制系统,以及系统跟踪不同应用程序中的更改。此外,它还维护应用程序的多个版本。目前 DevOps 流程中常用的版本控制系统都基于开源分布式版本控制系统 Git,例如 GitHub、Gitee、GitLab 以及各大厂商基于 Git 定制的内源协作工具。持续集成工具持续集成(CI)是 DevOps 的关键技能之一,它是构建 pipeline 的重要部分。DevOps 要求运营和开发团队使用统一的系统。因此,持续集成所做的就是将开发人员的代码与 master 合并在一起。有了这样的技巧,就可以有效地合并数据。因此,DevOps 工程师一定要知道如何使用一些常用的 CI 工具,例如 GitHub Action、Jenkins、Bamboo、TeamCity、Travis CI 等。

容器与编排工具

容器作为现代微服务与云原生架构的核心技术,提供了关于 DevOps 的三个基本功能,包括持续的实验、流动和反馈。容器技术的不可变基础设施实现了操作系统层虚拟化,不仅方便运维程序升级和部署,还升华成了向应用代码隐藏环境复杂性的手段,成为推广分布式服务的必要前提。

目前,Docker 仍然是应用最广泛的容器技术,而以容器编排引擎 Kubernetes 为核心的云原生技术栈则是各大互联网企业构建容器技术基础设施的事实标准。

自动化工具

自动化是软件开发过程中必不可少的要素之一。几乎所有的手工任务都可以使用各种脚本语言自动完成。例如,Ruby、Bash、Python、Node、Shell 等等。可以说,使用自动化开发工具已经成为了很多 DevOps 团队加快开发和部署过程的关键。想要成为 DevOps 工程师,掌握自动化工具很有必要。监控和报警工具

DevOps 持续集成和持续部署的实现离不开持续监控的辅助作用。许多微服务都是由数百个组件组合而成,其中一个服务的故障可能导致整个系统崩溃。当然,手动找到核心故障问题是很复杂和耗时的。其中一个解决方案就是持续监控关键特征,如 RAM 使用、请求数量、异常数量和存储空间。因此,需要根据系统的关键特性设置一个警报系统。例如,当存储空间使用率达到 80% 时应该触发警报,以便 DevOps 运维开发人员可以在整个系统崩溃之前解决问题。

三、具有成熟编码标准的特定编程技能

然编程能力是每个开发者最基本的能力,但 DevOps 工程师在这方面仍然有一些更特殊的要求。

通常来说,DevOps 工程师需要在专精 1-2 门编程语言的基础上熟悉多种语言,例如 Java、JavaScript、Ruby、Python、PHP、Go 等,这是由微服务时代同一系统不同服务可以由不同语言、不同框架实现的特性而决定的。DevOps 工程师至少需要了解这些语言的特性并具备在操作系统环境中编写和调试它们的能力。

四、技术支持和维护技能

优秀的 DevOps 工程师不仅需要开发方面的技能,有时还需要为客户提供维护和技术支持。这意味着 DevOps 工程师应该乐于为内部和外部客户提供支持,并在出现问题时进行故障排除。

互联网赋能的相关企业“人人都可以学"，尤其是项目经理、开发和运维相关岗位。 DevOps几乎“贯穿”了从业务到开发到运维进而到客户所有环节。DevOps可以说是适合这些环节中的所有人学习。DevOps认证培训首选的是艾威培训，艾威源于美国，始于1998，国内最早从事DevOps 培训的机构之一，经过多年的DevOps认证培训，艾威已经掌握了DevOps考试的脉络，通过率也是最高的。感兴趣的可以去艾威咨询看看。

在2008年多伦多举办的敏捷大会（Velocity Conf 2008 ）上，Patrick DeBois 和AndrewClay Shafer 先生首次提议讨论“敏捷基础架构”这个话题。在第二年的敏捷大会上有一个具有里程碑的意义技术分享，来自Flickr公司《每天部署10次》的分享，它激发了随后Patrick DeBios在同年十月，在比利时的根特市举办的首届DevOpsDays活动，这个活动是两天的日程，为了大家方便在twitter上的传播，人们把DevOpsDays这个词简写为 “#DevOps” 。 此后，“DevOps”一词问世了，这个词所包含的理念和实践一时在越来越广大的人群中产生了共鸣，随后成为全球IT界在各种大会和论坛里热议和讨论的焦点话题，很多大型IT论坛也都开设出了DevOps专题讨论。这就是DevOps这个词的由来。 DevOpsDays活动随后在Patrick DeBios等相关核心发起人的推动下，在全球范围内蓬勃发展了起来。2010年在美国山景城(Mountain View) 举办的DevOpsDays 活动中，Damon Edwards先生使用“CAMS”这个缩写，高度概括和诠释了DevOps，即文化（Culture）、自动化（Automation）、度量（Measurement or Metrics）和分享（Sharing）。随后Jez Humble先生将“L”精益 (Lean) 原则也加入其中，最终变成了CALMS。 ♣ Culture（文化）- 是指拥抱变革，促进协作和沟通 ♣ Automation（自动化）- 是指将人为干预的环节从价值链中消除 ♣ Lean（精益）- 是指通过使用精益原则促使高频率循环周期 ♣ Metrics（指标）- 是指衡量每一个环节，并通过数据来改进循环周期 ♣ Sharing（分享）- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进 “CALMS”完全吻合Patrick DeBois先生所一向倡导的“DevOps is a human problem” (DevOps 是关于人的问题) 的理念 。 从DevOps概念的产生，到如今它在全球范围内的蔓延和认同，已经经历了9个年头的时间。它的火爆推广也伴随着IT行业的迅速变迁和发展，现在已经到了移动互联网时代的后半场，国内的信息化建设已经完成了很多年；如今各行各业的企业也都亟待完成全方位的数字化转型。IT信息技术的先进程度标志着一个企业的核心能力，任何一个成功的企业，敏捷高效的软件开发创新实力和IT管理综合能力不只是门面而已，而是实实在在的市场竞争能力。DevOps倡导打敏捷、持续交付和ITIL三种实践的组合拳，同时应用精益生产理念为基础的管理思想，这正在逐渐地被广泛的接受和认可。 在过去的几年中，国内的各种IT大会也蓬勃发展，其中DevOps相关的专题和分会场也颇受人们的关注。各种云计算、运维等IT技术的社交媒体也都非常重视DevOps这个话题的分享。一个专属于DevOps社群的、国际性的、有影响力的DevOps大会正呼之欲出。在这样的时代背景下DevOpsDays大会北京站在2017年的3月18日来到中国，在同年的8月18日上海，还要举办DevOpsDays Shanghai站的大会。 下面列举一些DevOpsDays大会的相关数据，数据来源于 网站。从2009年到2016年，已经在全球的61个城市/国家成功地举办了117场。 下图是在过去九年中DevOpsDays大会在各个城市/国家的分布和举办次数。 今年也就是2017年预计举办30场，其中已经有18场确定了举办城市和日期；还有12个城市的召开日期待定；这不包括年内还可能会提出申办的城市。以上数据的统计时间在2017年三月。 随着国内BAT等互联网巨头的崛起，互联网公司的开发运维经验也越来越多的在国内的各种技术大会上传播。从最近这两年（2016年和2017年）的技术活动日程中可以看出，国内互联网从业人员也不约而同的用DevOps来定位和分享自己的优势和经验。他们是传播和分享运维侧DevOps实践的先头部队。 出了技术论坛的分享之外，很多线上线下的大会、论坛和讨论组也都越来越热议DevOps这一专题。国内其它相关流派的人群，例如敏捷和精益等，也对DevOps的蓬勃发展表示比较惊讶，DevOps与老牌的敏捷和精益等阵营也产生过一些争论。但这一切的发生也都增加了人们对于DevOps的更深入的兴趣。 在培训认证这方面，Exin DevOps Master是一个国际认证的培训；其它公司和组织也正在举办关于DevOps工具链的培训，这些培训则注重于技术实操，关注在构建端到端的流水线的搭建方面。从DevOps的职位招聘方面，可以看到DevOps工程师相关的职位越来越多了，在职位需求中DevOps这个技能成了加分项，DevOps相关工具的技能也或将成为简历的亮点。在IT行业内不管是开发还是运维团队的人，都开始了学习和接受的过程。 据我观察DevOps方面的厂商在最近3年呈现爆炸式的发展。我把他们分为三类： 目前国内大部分企业慢慢地开始关注了DevOps，大型传统企业也开始逐渐地从各个角度做试点和尝试。试点的角度和方向各不相同，有的从底层基础架构的容器化开始，有的从交付部署流水线的自动化开始；总的来说还处于初级的尝试阶段，还没有大规模成体系的推广。 综上所述，目前国内DevOps发展的阶段还属于起步阶段。就像是ITIL/ITSM在2003年左右的状态。由于DevOps是去中心化的，所以没有唯一、权威的上游厂商的存在，各种理论实践的争执和PK都将终止与解决问题和提高效率的话题上，因此它具有百花齐放百家争鸣的发展条件。个人认为DevOps的实施和落地也不会完全依赖于传统的大型咨询厂商的咨询工作，由于它应该是在企业的内部，在内驱的作用下，自生长出来的；它必须是服务于企业的业务价值流的优化，加速业务价值产出的；而与之相关的工作和责任的担当，外部力量是很难以等量替换和承担的。 在谈这个话题前先看一下DevOps相关工具集的全貌，如下图所示： 最上面的箭头流程图表示了一个业务服务的全生命周期：开发协作、软件构建、质量测试、交付部署和投产运维。前三个阶段偏传统开发组织的工作内容，后两个阶段基本可以和运维组织的工作对应上。在每个阶段下可以看成是一个大分类，这些分类中还包含若干个小分类。这些工具可以粗放的划分为商业软件和开源软件两类；也可以分为SaaS服务类和企业内部部署型。大部分开源工具都有活跃的用户社区和群众基础，这给企业入手这些工具带来了很大的便利。在需要商业支持的场景里还可以选择使用这些开源软件的企业版。 Docker容器技术在最近三年中异军突起，持续交付的技术门槛因此被降到最低，软件生产供应链的格局和效率被彻底提升；基于Docker的微服务架构实践的热度和成熟度也与日俱增。因此，国内的传统企业纷纷试水DevOps和容器技术，在最近两年的各种技术大会中，我们可以看到国内各个行业出现了在不同维度上的DevOps先行者。他们分享的主题大多集中在自动化运维、容器化和PaaS平台的等项目经验。 从国内众多DevOps实践中，我们能看到下面三个技术尤其重要和火热： 以上三种技术相辅相成，有着比较深刻的关联。首先微服务和持续部署各自解决了特别多的传统IT的问题，这些问题都是长期以来制约企业业务发展的难题。容器技术由于它的快速、轻量、微服务化的天然特性，很好的从不同侧面支持了持续交付和微服务架构。容器可以为持续交付提供弹性和高速的系统资源，环境管理和利用率提高了很多；容器的不可变性的特点也更好地支持了微服务架构。 我把DevOps的按照不同的技术特征做了从到 到的时代划分，并尽量通过以下维度比较与传统方式的差异。 我比较认可和接受的企业实践DevOps参考框架如下，其中包含了所需的最佳实践，如下图所示。 （上图来源于：Exin DevOps白皮书） 下面简要描述一下这四大支柱型最佳实践： 由此可见DevOps在企业，特别是大规模传统企业的落地和推广还是比较复杂的。虽然相关的最佳实践都是已经存在了很多年的；但是，通过DevOps的价值观重构企业从研发到交付到运维的价值流谈何容易。基于我的IT从业经验，我似乎感觉到DevOps不能单独依靠自顶向下的推广，当然高层领导的支持依然是重要的和必备的支持条件之一。 可能还需要中层的带动和底层的创新；借鉴生产制造业已经久经考验的精益制造实践也是势在必行。总之DevOps运动会在近几年给IT行业带来较大影响。