导读：本篇文章首席CTO笔记来给大家介绍有关devops怎么传播的相关内容，希望对大家有所帮助，一起来看看吧。
不明白 DevOps 到底是什么意思
在业务敏捷化的需求背景下，传统的单体式架构及项目制瀑布开发模式已经无法满足业务快速开发交付及变更的需求。从企业IT部门的视角，为了更快速响应业务变化，实现应用的快速开发交付及迭代，敏捷开发（Agile）风靡一时，Scrum作为敏捷方法论被认为是全球最流行与最有效的敏捷项目管理理念与方法之一；
而以敏捷开发为基础的DevOps（Development和Operations），则进一步整合了开发测试和运维团队，通过组织、文化和工具，以及自动化“软件交付”和“架构变更”的流程，使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps可以有效提升软件交付效能，在实现更频繁更快速应用发布的同时，可以有效减少发布变更导致的故障及停机时间。
根据DORA公司与Google Cloud合作发布的《2018年DevOps现状报告》，实施DevOps的高效能团队在代码发布频率、代码提交至发布的速度、变更的故障率、事故恢复时间上的表现远远优于低效能团队：
代码发布频率高 46 倍
代码提交至发布的速度快 2555 倍
变更故障率少 7 倍
事故恢复时间快 2604 倍
而在所有参与调查的企业当中，在实施DevOps的同时采用PaaS、云原生、容器技术的企业有更高的概率是高效能精英团队。IT团队的敏捷化转型，为业务团队更快速响应市场变化提供了能力支撑。在企业数字化浪潮下，能否比竞争对手更快的发现和响应市场变化，是保持企业竞争力的重要因素。
完整阅读：Nebulogy纳比云原创文章《BizDevOps推动企业数字化转型与高速增长》
在devops方法下如何协调开发和运营职能
个人感觉，开发是未来，运营是当下。一个leader，既要关注当下，又要展望未来。具体到develops方法，估计应该是安排适当比例的人力、物力和财力在开发和运营部门，以保证运行良好的同时，也能着眼未来。
DevOps如何提升企业IT效率的
DevOps最基本的一个功能，或者说优势，就是它可以将产品的开发团队跟运营团队合并成一个具有凝聚力的“个体”，而这样就可以很大程度地提升工作效率。
devops加快交付速度
devops填补了之前的空白部分，devops通过建立一个完整的生命活动周期，devops关注如何更好地获取IT运维团队的反馈。devops将敏捷原则应用于管理领域，devops使得开发人员和管理员可以进行毫无障碍的沟通。
devops还有很多不足，devops导致代码交接容易出现延迟。devops同样的情况也会出现在重大bug的修复过程中。
devops运行时软件优化
devops可以在两个方面提升知识水平和程序质量。首先，devops对于许多较新的、面向对象的操作系统，比如Linux，devops很有可能不关机而一直保持运行状态。因此，devops容易出现问题，比如错误的垃圾回收机制以及不能正确重新组织关系型数据存储。
devops借鉴了大型机管理员积累的经验来重新认识软件平台类型，以及可能引起这些类型问题的开发和/或测试流程。devops开发团队可以使用嵌入式模式保护代码来部署代码库和测试环境。
devops的目标是在测试环境中，或者devops以代码的形式嵌入到应用程序自身当中以获取大型机复杂性的现有知识，devops不希望大型机管理员发现问题所在。devops并不仅可以使得开发人员和测试人员的工作更加轻松，同样可以简化管理员的工作。
devops提高大型机管理员工作效率
devops可以改善这种大型机管理模式，devops提高大型机管理员的工作效率。首先，devops通过实现标准配置和Linux相关任务的自动化，devops可以保证管理员拥有更多时间来“救火”。devops通过确保解决方案是长期有效和高质量的来减少对于处理紧急情况的处理需求。此外，devops让管理员也参与敏捷开发流程，和开发团队进行沟通，当开发团队拥有了一个能够快速定位问题并且修复运行时问题的测试工具或者代码库之后，devops就可以减少管理员修复bug以及与开发部门协调所花费的时间。
您可以关注servicehot这家公司，他们比较熟悉这块。
Docker生态会重蹈Hadoop的覆辙吗
一、Docker的兴起和Hadoop何其相似
2015年说是Docker之年不为过，Docker热度高涨，IT从业人员要是说自己不知道Docker都不好意说自己是做IT的。2016年开始容器管理、集群调度成为热点，K8s开始成为热点。但这一幕和2013年的Hadoop大数据何其相似，当年你要说自己不知道大数据，或是知道大数据不知道Hadoop，那必然招来鄙视的眼光。
云计算喊了这么久，从来没有像Docker这么火过，究其原因不外乎两条：
1、开发者能够用Docker，开发者要一个开发环境，总会涉及到种种资源，比如数据库，比如消息中间件，去装这些东西不是开发人员的技能，是运维人员的技能。而用Docker去Pull一个mySQL镜像,或是Tomcat镜像，或是RabbitMQ镜像，简易轻松，几乎是零运维。做好了应用代码，打一个Docker镜像给测试或是运维人员，避免了从前打个程序包给测试或是运维人员，测试或运维人员要部署、配置应用，还得反反复复来麻烦开发人员，现在好了，丢个Docker镜像过去，让运维人员跑镜像就可以，配置在镜像里基本都做好了。
这正好满足了DevOps的要求，所以DevOps也一下热起来了。开发者是一个巨大的市场，是海量的个体，通过类似于病毒式的传销，Docker一下在开发者中热起来了。
2、镜像仓库和开源，谁都可以用，Docker镜像库非常丰富，谁做好一个镜像都可以往公有仓库推送，开发人员需要一个环境的时候，可以到Docker镜像仓库去查，有海量的选择，减少了大量无谓的环境安装工作。而通过开源，又开始大规模传播。
我们再来回顾看看2010-2013年，大数据的名词火遍大江南北，各行各业都在谈大数据，但是落到技术上就是Hadoop，还记得2012年的时候，和Hadoop没啥毛关系的VMWare也赶紧的做了一个虚机上部署Hadoop的serengeti，谁家产品要是和Hadoop不沾点边，不好意思说自己是IT公司。Hadoop当年的热度绝对不亚于2014-2015的Docker。而且时间上有一定的连续性，2014年开始，Hadoop热度达到顶点，开始逐渐降温，标志事件就是Intel投资Cloudera。而Docker是从2014年开始热度升高的。
再看Hadoop为何在2010年前后开始热起来，之前的大数据都是数据仓库，是昂贵的企业级数据分析并行数据库，而Hadoop是廉价的大数据处理模式，通过开源和X86廉价硬件，使得Hadoop可以大规模使用，而互联网时代产生的海量数据虽然垃圾居多，但是沙里淘金，也能淘出点价值，Hadoop正好迎合了这两个需求，虽然Hadoop的无论是功能还是性能远比MPP数据库差，但做简单的数据存储、数据查询、简单数据统计分析还是可以胜任的，事实上，到目前为止，大多数的Hadoop应用也就是数据存储、数据查询和简单的数据统计分析、ETL的业务处理。
Docker和Hadoop的热起来的原因不同，但是现象是差不多，开源和使用者群体大是共同要素。
二、Hadoop从狂热走向了理性
Hadoop最热的时候，几乎就是要replace所有数据库，连Oracle也面临了前所未有的冲击，甚至Hadoop成了去IOE的Oracle的使命之一。在狂热的那个阶段，客户怎么也得做一两个大数据项目，否则会被同行瞧不起，各IT厂商也必须推出大数据产品，否则可能成为IT过时的典范，这不IBM成立了专门的大数据部门，打造了一个以Hadoop为核心的庞大的大数据解决方案。
Intel虽然是做芯片的，但是大数据必须掺和，成立大数据部门，做Intel Hadoop 。连数据库的老大Oracle也憋不住了，做了个大数据一体机。
任何曾经狂热的新技术都会走向理性，Hadoop也不例外，只不过，这个进程还比较快。随着大数据的大跃进，随着Hadoop的应用越来越多，大家发现在被夸大的场景应用大数据效果并不好，只在特定场景有效，Hadoop进入理性发展阶段，比如一开始Hadoop据取代MPP数据库，取代数据仓库，取代Oracle，完美支持SQL等等均基本成为泡影。这其实本来是一个常识，任何技术都有其应用场景，夸大应用场景，任意扩展应用场景只会伤害这个技术的发展。
“这和目前无限夸大Docker的应用场景有异曲同工之妙，比如Docker向下取代虚拟化，Docker向上取代PaaS之类，几乎成了云计算的唯一技术，这种论调一直充斥各种Meetup/论坛。虽然技术从夸大到理性需要时间，但是理性不会总是迟到。
Hadoop技术在发展，大数据的相关技术也在发展，Hadoop一直被诟病的处理速度慢，慢慢的被Spark/Storm等解决，特别在流数据处理领域。
所以，时至今日，人们对Hadoop的态度趋于理性，它只适合在特定场景使用，可是，当初那些在Hadoop不太适用的场景使用了Hadoop的客户交了学费的事情估计没人再提了。Docker估计也是一样的，总有在夸大的场景中交学费的客户，可是只是客户没眼光吗?和无限夸大某种技术的布道师无关么?
再反观大数据和Docker在全球的发展，在美国，无论是Hadoop和Docker并没有像国内这么狂热过。Hadoop技术来源于Google，成型于Yahoo(DougCutting)，而炒作却是在国内。同样，Docker也在走这么个流程，在美国没有这么多的Docker创业公司，主要就是Docker，然后各大厂商支持，创业公司和创投公司都知道，没有自己的技术或是技术受制于人的公司不值得投资，既然Docker一家独大，再去Docker分一杯羹会容易吗?
而国内二三十家的Docker创业公司，没有一家能对Docker/K8s源码有让人醒目的贡献(反倒是华为在K8s上有些贡献)，但是都在市场上拼嗓门，不是比谁的技术有潜力最有市场，而是比谁最能布道谁嗓门大，谁做的市场活动多，某Docker创业公司据说80%的资金用在市场宣传、Meetup上，而且不是个别现象，是普遍现象。反应了某些Docker创业者的浮躁心态。
DevOps之prometheus实现优雅的告警
目前prometheus的告警，常用的有grafana自带的告警和prometheus插件alertmanger的告警两种，这里测试下alertmanger的告警功能。
综合考虑，配合上prometheus operator，使用alertmanger，能够使监控告警这块的工作更加devops。
prometheus operator 在k8s中引入了自定义资源定义（CRSs）Prometheus、ServiceMonitor、PrometheusRule和Alertmanager。
所以在k8s中搭建好prometheus operator后，当我们需要监控一个项目时，我们的配置顺序是配置ServiceMonitor获取监控数据，配置PrometheusRule获取告警阈值，配置Alertmanager制定告警发送方式
如果我们已经完成了ServerMonitor的对象的编写，下面就要将监控好的重要数据，设置阈值，触发告警。
这里用spark 服务cpu使用率为例，介绍下PrometheusRule的写法
这样我们就完成一个PrometheusRule 资源对象的编写了，那么prometheus是怎么识别这个告警规则的呢。
我们先查看下prometheus的资源对象
kubectl get prometheus/k8s -n monitoring -o yaml
可以看到，prometheus会自动匹配标签为prometheus=k8s 和 role=alert-rules的prometheusRule的资源对象，这里我们可以体会到prometheus operator自动发现的魅力，我们只需要编写相应的告警规则yaml文件，然后apply一下，便可以制定告警。
在prometheus界面上面查看刚刚制定的告警规则
对于告警通知，需要考虑以下几点
及时性：邮件通知有时候不会注意，尤其是不在电脑面前，所以这里我们选择工作中使用的企业微信作为告警消息推送方式
简洁性：如果服务器性能等到达了一个warning值，会有很多相关的告警全部触发，所以这里我们需要配置分组、静默、抑制方案
容灾性：如果alermanger或者prometheus本身挂掉了，发不出告警怎么办，一般会采用另一个监控来监控prometheus，或者自定义一个持续不断的告警通知，哪一天这个告警通知不发了，说明监控出现问题了。很棒的一点是，prometheus operator已经考虑了这一点，本身携带一个watchdog，作为对自身的监控
创建一个alertmanger配置文件
删除之前的secret对象，并且创建新的
查看企业微信，这个时候会发现已经收到告警信息
这个watchdog便是对prometheus自身的监控。如果有需要，可以制定一条路由，匹配severity为none的告警，然后每24h重复一次，这样可以达到每天监控prometheus本身的效果，哪一天没收到watchdog，便可以知道prometheus挂了。
正常收到的告警信息
alertmanger也支持webhook告警，但是比如钉钉和企业微信机器人这类对消息头有特殊要求的，如果直接用webhook的话，需要安装一个插件封装下，才可以调用
Alertmanager还支持临时静默告警。有时候我们在处理告警，想要临时静默告警消息，或者测试环境中，进行压测，需要临时静默一段时间的告警，我们就可以直接通过Alertmanager的UI临时屏蔽特定的告警通知。通过定义标签的匹配规则(字符串或者正则表达式)，如果新的告警通知满足静默规则的设置，则停止向receiver发送通知
目前Alertmanager只支持在UI上面进行临时静默告警
当静默规则生效以后，从Alertmanager的Alerts页面下用户将不会看到该规则匹配到的告警信息，微信机器人也不会发送响应的告警消息
什么是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 工程师应该乐于为内部和外部客户提供支持,并在出现问题时进行故障排除。
结语：以上就是首席CTO笔记为大家整理的关于devops怎么传播的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～