计算机科学中的任何问题都可以通过创造一个概念来解决。如果一个不行,那就两个!

1 什么是DevOps

DevOps (a clipped compound of “development” and “operations”) is a
software development process that emphasizes communication and
collaboration between product management, software development, and
operations professionals. DevOps also automates the process of
software integration, testing, deployment and infrastructure
changes.[1][2] It aims to establish a culture and environment
where building, testing, and releasing software can happen rapidly,
frequently, and more reliably.
https://en.wikipedia.org/wiki/DevOps

DevOps是强调产品管理,软件开发和运营专业人员之间沟通和协作的软件开发过程。DevOps还可以自动化软件集成,测试,部署和基础设施变更过程。DevOps旨在建立一套快速、频繁、稳定地进行构建,测试,发布软件的文化与环境。
https://en.wikipedia.org/wiki/DevOps

DevOps as the intersection of development (software engineering),
operations and quality assurance (QA )

Gartner 2016 年应用开发成熟度曲线上,DevOps 已入顶峰。毫无疑问,DevOps
自 2009 年诞生以来,一路高歌猛进,目前已然成为软件行业的标准配置。

js9905com金沙网站,2 DevOp工具链

Code — Code development and review, version control tools, code
merging
Build — Continuous integration tools, build status
Test — Continuous testing tools that provide feedback on business
risks
Package — Artifact repository, application pre-deployment staging
Release — Change management, release approvals, release automation
Configure — Infrastructure configuration and management,
Infrastructure as Code tools
Monitor — Applications performance monitoring, end–user experience
https://en.wikipedia.org/wiki/DevOps#DevOps_toolchain

DevOps Tool Chain

The entire delivery pipeline

甚至近两年的IT招聘中,DevOps 工程师已成为最火的岗位之一,而熟悉 DevOps
也成为研发人员或运维人员的技能要求。

3 Devops is About CAMS

  • Culture
    People and process first. If you don’t have culture, all
    automation attempts will be fruitless.

  • Automation
    This is one of the places you start once you understand your
    culture. At this point, the tools can start to stitch together an
    automation fabric for Devops. Tools for release management,
    provisioning, configuration management, systems integration,
    monitoring and control, and orchestration become important pieces
    in building a Devops fabric.

  • Measurement
    If you can’t measure, you can’t improve. A successful Devops
    implementation will measure everything it can as often as it can…
    performance metrics, process metrics, and even people metrics.

  • Sharing
    Sharing is the loopback in the CAMS cycle. Creating a culture
    where people share ideas and problems is critical. Jody Mulkey,
    the CIO at Shopzilla, told me that they get in the war room the
    developers and operations teams describe the problem as the enemy,
    not each other. Another interesting motivation in the Devops
    movement is the way sharing Devops success stories helps others.
    First, it attracts talent, and second, there is a belief that by
    exposing ideas you can create a great open feedback that in the
    end helps them improve.

https://www.supinfo.com/articles/single/3652-what-is-devops

相应的,作为新兴技术概念繁荣的另一面,当我们谈论 DevOps
时,对其认识也呈现出多种多样的理解,并会按照自己的需要进行阐述:有的强调研发和运维流程改进,有的谈论自动化运维,有的试图建立起软件开发全生命周期管理;

4 Conclusion

DevOps provides organizations with a set of practices based on lean
and agile methods. With these methods, organizations reduce the risk
developing software that does not meet requirements, and increases the
effectiveness and efficiency of software development and deployment.
Organizations can deliver innovations to their customers in a timely
manner and rapidly apply customer feedback to enhance the innovations
being delivered. Most organizations rely on their capability to
deliver software to address their customers’ needs, balancing
stability of the business capabilities that customers need with the
innovations that the market demands. DevOps provides organizations
with the capabilities to achieve this balance.
https://www.supinfo.com/articles/single/3652-what-is-devops

还有些甚至在 DevOps
的基础上进行更为超前的扩展,比如,就某些具体的领域探讨 NoOps
或者是围绕人工智能建立 AIOps,等等,真是乱花渐欲迷人眼。

5 The DevOps body of knowledge

  • Disciplined Agile
  • Continuous Delivery
  • IT service management
  • TPS (Lean) concept as foundation

the DevOps body of knowledge Exin Whitepaper Success with Enterprise
DevOps

今天,无论是作为互联网行业的参与者,还是传统IT企业的从业者,在这场
DevOps 运动浪潮中,我们要如何拨开重重迷雾来理解 DevOps,了解各种不同
DevOps
主张间的异同,从中选择适合自己的方式落地,并最终建立起高效的研发运维体系?

6 Patrick Debois:DevOps, Improve from Collobration

DevOps 起源

1、DevOps切入点
1.1 怎么落地DevOps?
1.2 DevOps从什么地方开始?

2、DevOps四大改进方向
1)端到端交付
2)持续反馈
3)开发向运维
4)运维向开发

3、DevOps实践场景
3.1 配置管理
3.2 环境管理
3.3 监控与度量
3.4 On-Call
3.5 Chaos-Monkey
3.6 ChatOps
3.7 事故分析
3.8 游戏日

4、DevOps实施的五级精进
5、DevOps实施常见问题
1)我该如何开始

  1. 和其他的转型没有太大的区别
  2. 不要花费太多的时间在反对者身上,专注于寻找志同道合的盟友
    3.
    不要过于自负,要寻求管理支持,个人影响力有限,我们要与管理层进行非常好的合作
  3. 选一个小的项目并达成目标,成功最建立信心和信任的最佳方式。
    5.
    要选的第一件事情是一个大家都比较关注的痛点,做一些有意义的事情,但是一定要比较小,这样你自己就可以用有限的资源完成。这会提示大家改变的意愿
  4. 开始动手做,不需要做过多的解释,动手做就可以了。
  5. 做了再说
  6. 做出成果之后要及时沟通,可以有效建立信任
  7. 度量改进效果
  8. 持续改进
    2)我们应该设置独立的DevOps团队吗?
    3)如何衡量DevOps的效果
    4)DevOps宣言是什么?
    5)DevOps和ITIL的关系?

6、常用实践与工具

  1. 沟通你承诺的状态并监控
  2. 监控服务并暴露度量信息(API)
  3. 暴露内部信息(API)
  4. 关心其他人
  5. 暴露日志
  6. 明确错误信息
  7. 备份外部数据
  8. 更快的反馈
  9. 让内外部依赖更清晰
  10. 主动让别人保持承诺
  11. 让别人了解变更
  12. 建立技术博客
  13. 去大会演讲
  14. 让别人很方便的使用服务
  15. 给别人反馈
  16. 表达你在关注外部对你的依赖
  17. 告诉别人你在参与改进
  18. 告诉别人你的工程师们不怕与人交谈
  19. 对访问请求负责
  20. 让其他人参与进来

https://mp.weixin.qq.com/s/sIMsequUo–op1m9FtK86g

另一方面,我们如何从 DevOps
的发展中理出隐藏在背后的动机和目标,从而在实践过程中能够超脱具体器用的限制,在面对未知问题时可以灵活的处理,甚而发展出自己的流程、系统和生态?……

7 Jenkins 创始人:持续交付的 What、Why 及 How

主要内容
1、流程线已经改变过一次世界
2、软件正在吞噬世界
3、头号需求:业务连续性(不停机)
4、持续交付框架分析
5、生存还是毁灭,你可以选择
6、现状和方向
7、工程实践
7.1 架构与实现技术
7.2 基于Jenkins的CD/DevOps生态系统

DevOps转型策略

  1. 识别试点项目
  2. 组建跨职能团队
  3. 采用统一的技术
  4. 基于可度量的KPI和里程碑制定计划
  5. Go
  6. 度量,文档化,改进
  7. 规模化实践

http://mp.weixin.qq.com/s/HGU0WW4Cv-I_y1xnWxR5Vw

参考文献:
https://en.wikipedia.org/wiki/DevOps
https://www.supinfo.com/articles/single/3652-what-is-devops
https://blog.chef.io/2010/07/16/what-devops-means-to-me/

相关人物:
Patrick Debois
John Willis
Jez Humble
Kohsuke Kawaguchi

对这些问题的探讨正是本文目的之所在!但在开始我们的旅程前,我们需要先回答一个基本问题:DevOps
到底是什么?

DevOps是什么?

DevOps (a clipped compound of “development” and “operations”) is a
software engineering practice that aims at unifying software
development (Dev) and software operation (Ops).

The main characteristic of the DevOps movement is to strongly advocate
automation and monitoring at all steps of software construction, from
integration, testing, releasing to deployment and infrastructure
management.

DevOps aims at shorter development cycles, increased deployment
frequency, more dependable releases, in close alignment with business
objectives.

如上是 wikipedia 上关于 DevOps
的最新描述,聊聊数语,似乎并不能让我们建立对 DevOps
的清晰认知,而且也不能一窥DevOps已发展出的庞大体系。

为了要理解现今的
DevOps,我们最好顺着历史长河逆流而上,不过有别于关注那些发生在2009年左右的故事,这次让我们先走的更远些,看看那敏捷诞生时的事情。

2000年左右,软件行业的主要工作是交付客户定制的软件应用,而软件研发团队被推荐使用像
CMM/CMMI、RUP 这样的大型方法论来组织生产。

从事过大型交付项目的人应该对些方法论不陌生,抛开可能的操作差异——比如是瀑布还是迭代,它们有着一些共同的特征:

通过详细的流程规范软件开发的各个方面大量细节工作前置以预防后期变更将文档作为软件的产物和流程验证工具

这些大型方法论效果并不理想,一方面甲乙双方在需求变更上的扯皮不是影响交付日期就是交付后的产品不能真正解决客户的问题,另一方面研发团队又需要花费大量精力在准备流程需要的文档上面。

正因此,当时一些正在积极尝试不同方法的软件开发人员才会济济一堂,提出著名的《敏捷宣言》,如图1。

图1. 敏捷宣言

虽然敏捷宣言的提出者们委婉地肯定了一下右侧各项的价值,但我们依然能够从这些文字中体会出他们对大型方法论的不满——右侧各项都是与大型方法论紧密联系的实践。

可以这样说,敏捷方法的出现正是对大型方法论的反思和反抗。由于敏捷源自实践,在这个概念刚刚提出时,其对应的理论体系尚不完备,人们对其认知也并不统一,所以开始时,敏捷涵盖了与敏捷宣言相联系的多种方法论。

这里,我们提及敏捷的原因在于几点:

第一,作为 DevOps 的提出者,敏捷的视角和方法直接影响了早期
DevOps,我们需要理清这样的影响在何处。

第二,DevOps
和敏捷,以及更早些的精益生产,都是先实践,再形成理论,最后又以理论指导实践。因此,了解了敏捷的诞生和发展过程,我们再看人们对
DevOps 概念认知的发展就不会感到困惑。

最后,DevOps
的产生和整个大环境的变化有着直接的关系,从敏捷到DevOps,我们通过梳理历史发展的脉络来从侧面了解催生
DevOps 背后的原因。

图2. 敏捷与DevOps时间线

如图2,敏捷提出后其关注过程和质量,而其要解决的问题则是如何快速交付客户需要的软件,或者我们更高大上地说,如何快速地交付价值!

一开始,这里的交付有着相对狭窄的意义,也就是,它实际上指的是软件外包公司和软件需求方之间的软件研发和制品交付工作。

而后,随着敏捷在一般企业内部推广,其开始涵盖软件开发团队和业务团队之间的需求实现和软件交付关系。此时,整个软件的生命周期如图3,交付是开发的终点。

由于此时多数是企业级应用开发,业务的稳定性和需求的演进速度尚不是问题,加之开发和运维在物理上的分离,因此,研发和运维之间的矛盾并未凸显,需求频繁变更、研发效率低下才是甲乙双方头痛的问题。

图3. 传统软件生命周期

之后,如图4,在互联网高速发展的过程中,软件开发成为企业业务整体运营中的一环,开发团队阶段性交付软件后,并不能从总体上为业务立即带来任何价值,软件必须经过后续阶段,直到被部署到生产环境并真正带动业务运转起来后,整个软件研发工作才算交付了价值。

图4. 面向运营的软件生命周期

因此,在 DevOps 提出前,IT
行业中的主要问题不再仅仅是需求研发的问题,而且还有软件变更高质量、快速上线的问题。

要让业务快速产生价值,降低从需求到软件上线的整体时间才是关键,如图5,加之互联网业务高速运转的要求,这个效率对企业生存是至关重要的。

但是,由于传统研发和运维定位的问题,即便在同一个企业中,由于工作性质和考核的方式的不同,研发和运维之间的部门墙对效率的提高有着很大阻碍。

此时即便研发可以通过敏捷高效起来,但糟糕的交付过程依然会将业务交付整体拉回到低效的瀑布方式,甚至造成业务失败,而这正是促使咨询师
Patrick Debois 提出 DevOps 的关键所在。

图5. 原生 DevOps 定位

图6. 混乱之墙

图7. 糟糕的交付让敏捷回到瀑布

此时,让我们站在图1时间轴的2009年处,回看过去并眺望未来!向后看,敏捷已经有近10年的发展,围绕持续集成的实践已经比较成熟。

但传统运维侧的部署和运维领域里的工具都尚待繁荣,而整个社区内只有为数不多的经验可以用来指导
DevOps 实践。

如 Flickr 的《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。

而向前看,2年后的2011年,《持续交付》这部重要的著作才会上市,业界和社区此时对持续交付尚缺统一的指导思想。

4年后,探讨精益思想应用于开发运维工作中《凤凰项目》才出版。在这种情况下,作为擅长流程改进的敏捷方法论祭出沟通和协作的大旗就顺理成章了,而这也就反映在
DevOps 最初的图中,如图8。

另一方面,对文化的强调也得自于敏捷推广过程中的经验,自然地,这一部分也延续到了
DevOps上。

可以这么说,早期 DevOps
就是敏捷通过开发向运维侧延伸,它直接继承了来自敏捷的诸多理念和实践,尤其是许多年来精益思想在软件行业的实践,这一次在拉通整个价值流的过程中得到了更大的应用舞台,如图9。

图8. 面向沟通与协作的DevOps

图9. 来自IBM的DevOps

总结一下,在 DevOps
提出时,面对的问题从定制软件的交付变成支撑业务的自研软件的部署和运营,敏捷轻车熟路地将利益相关各方拉到一起,希望在统一业务目标的前提下,通过沟通和协作来消除部门间的隔阂,提高整个流程的效率。

有别于敏捷方法在处理软件研发时所面对的情况,应用部署和运维是一个硬技术领域,其非常依赖工具和自动化,尤其是对于规模稍大的公司而言,源自持续集成的有关技术完全无法达到大规模
DevOps 预期的目标。

因此,沟通和协作带来的效率提升在运维相关的工作上很快会达到天花板,接下来,一系列自动化工具的繁荣将会推动
DevOps 走到新的高度,同时,这也让自动化运维成为 DevOps 的一种形态。

行文至此,让我们再次回到最开始的问题,“DevOps是什么?”。

与敏捷类似,DevOps 也没有标准定义,我们只能对 DevOps
进行描述,这种描述或者如我们之前所做,陈述其发生发展的过程——从这一点上看,DevOps
就是一个运动;

或者是表述其预期的目标和作用的范围,如开始处引用的 wikipedia 的描述。

在诸多类似的描述中,来自《DevOps: A Software Architect’s
Perspective》的描述更为简单直接——只要能够在保证质量的前提下缩短代码提交到上线时间的实践都是
DevOps:

DevOps is s set of practices intended to reduce the time between
committing a change to a system and the change being placed into normal
production, while ensuring high quality.

当从目标和范围着手界定 DevOps 时,就会有所谓狭义 DevOps 和广义 DevOps
的区分。

狭义 DevOps,如图5所示,就是原生
DevOps,它只关心从代码变更提交到变更部署到生产系统并运行起来,其目标在于缩短这个周期时间;

而广义的
DevOps,如图10所示,它将整个软件生命周期纳入自己的范畴,其目标在于提高整个业务的连续性。

此时,DevOps
与敏捷的关系就变得微妙,这成为常常讨论的主题,两者的范围似乎都可以包含对方。

其实,DevOps
在具体工作层面上涵盖了敏捷管理和研发方法,但在整个理论基础上,敏捷思想可以作为DevOps
的理论基础,用来指导整个软件研发的全生命周期中的活动。

图10. 广义DevOps和全生命周期管理

2013年,Gene Kim、Kevin Behr和George Spafford 出版了《凤凰项目 :
一个IT运维的传奇故事》,这本书是敏捷和精益思想指导 DevOps
工作的里程碑式的著作。下面让我们简单回顾一下这本书。

《凤凰项目》

这本书通过小说的形式,讲述了无极限公司运维部的比尔在大神埃瑞克的帮助下,逐步将精益和
TOC 的诸多方法引入运维管理的过程。

这本书读之亲切的原因在于书中呈现的正是运维团队的日常:大量的变更工作,混乱的流程,人员瓶颈,忙于紧急工作,以及研发与运维团队糟糕的协同等等。作者通过一个个具体场景,为读者演示了:

通过看板可视化变更工作通过发现约束点找出流程中待改进部分通过缩小批量和发布间隔提高系统流动性通过聚焦业务目标打破局部优化通过减少在制品消除浪费通过早期关注质量及避免缺陷传递来提高质量、消除浪费通过分析问题根源来避免问题再次发生通过标准化流程和工作来提高效率通过区分工作性质来做合理的取舍通过自动化降低人为错误的概率……

更为重要的是,作者使用自创的三步工作法将这些套路组织在一个可以参考的框架内,并由此建立起一个从解决问题到建立反馈再到形成文化的整体流程。

毫无疑问,《凤凰项目》通过假想的场景将精益思想可能带给运维工作的变化描写得深入浅出,而且还给出了从具体工作到文化创建的建议途径,仅凭这几点,其启发意义和指导性就使本书很值得一读。

当然,从关注业务连续性和精益思想的普适的角度看,将其归于 DevOps
亦无不可,而且其方法完全可以作为过程改进型 DevOps 的典型代表。

但是,由于书中探讨的场景仅仅局限于运维组织内部而且通篇并无太多笔墨谈及研发部分的运作方式以及研发和运维的协同、沟通方法,因此显得美中不足。

之后,“凤凰项目”还被设计成一款沙盘游戏,以期让参与者能够在协作中切实地感知和体验书本中的方法在整个故事场景中所带来的作用。

虽然以游戏化的方式建立初始认知是不错的方法,但这样的体验对实际的操作有多大的指导作用则是见仁见智的事情了。

《凤凰项目》可以说是精益思想向运维侧扩展的代表。除此之外,研发和运维运维侧的进步也演化出了不同的
DevOps 形态。接下来让我们一起看看 DevOps
发展到今天形成了哪些不同的形态。

当前 DevOps 的几种形态

如图11,无论狭义 DevOps 还是广义
DevOps,要提高整体流动性——无论局部的代码提交到上线运行还是全局的业务,我们需要处理两种效率:

部门内部的效率部门之间的效率

图11. 软件生命周期中的部门墙

我们应该先优化哪一种效率呢?从《目标》和《凤凰项目》的经验,我们应该首先找出制约点,也就是瓶颈,然后在瓶颈处进行优化。

否则,局部优化有可能无法达到全局优化的目的。举个例子,如果研发团队已经可以高质量快速地生产,那么我们仍然一味地在研发部分投注资源去提高生产能力的话,只能造成更多的工作堆积到运维处,全局效率并不能得到提升。

然而,现实的情况是,很多被 DevOps
神奇功效所吸引的组织其自身研发还没有梳理清晰,因此,这自然而然地就要将敏捷纳入到
DevOps 的范畴之内。

也就是说,在研发自身还是问题的情况下,首先要处理研发内部的效率的问题,当研发效率提升后,瓶颈转移至研发与运维的结合处,此时再次运用敏捷来进行协调,这就是
DevOps 的第一种形态:由敏捷落地,而后从研发向运维侧扩展,如图12。

图12. 敏捷由研发向运维扩展

这种形态下,根据操作的方式的不同又可分成几种形式:

第一种,最为原生的形式,专注在流程方面。

图12. 敏捷导入前软件生命周期各阶段的问题

这种方式通常会采用一些成熟的敏捷实践,对于研发和运维的之间的部门墙,则以提高沟通和协作为目标,建议尝试《凤凰项目》中的一些方法。

这种 DevOps
方式其本质就是敏捷,其适用于开始时研发侧依然问题重重的情况,或者是运维被杂乱无章的工作束缚而使运维工作低效时。

这种方式的优点在于易操作、见效快,但缺点在于流程改进措施的天花板很快就会触达,此时,自然就需要借助第二种形态。

第二种,基于持续集成构建持续交付。

图13. 敏捷导入后,问题可能在于测试和运维部分低效

组织开始尝试这种方式时已在内部采用了敏捷开发实践,此时可能的问题常常在于测试团队低效,如测试团队仍然依赖大量人工进行回归测试,以及运维上线的低效。这种形式的主要指导思想是持续交付。

基于组织具体所处阶段,其对持续交付实现的程度可能不尽相同,如图14,对于小型互联网公司,基于
Jenkins 的 pipeline 就可以快速搭建起可用的简单持续交付环境。

图14. 基于 Jenkins 的 pipeline 的极简持续交付

但对于规模稍大、业务更为复杂的公司,可能就需要引入更多的开源工具,基于持续交付的理念来搭建整个持续交付工具链,如图15。

近两年环境和部署类工具的繁荣,使基于开源工具链的搭建越来越简单,而
Jenkins 和 Docker 是其中最重要的两个工具,目前,这是多数公司关注的阶段。

对于规模更大的公司或者一些有着不同理念的企业,可能会有自研工具链生态的诉求,这个我们之后讨论。

在此种形式下,有一点需要注意,即研发和运维团队在生产上线过程中的职责划分。

通常,出于安全和稳妥的考虑,会继续将生产上线的职责放在运维团队,并建立流程进行管控。

我们更建议尽量将整个应用运维的工作完全交给研发负责,包括生产环境的维护和上线,只要保证无关人员不直接登陆生产环境,以及保证数据安全性即可。

图15. 基于Jenkins、Docker等开源工具的交付工具链

第三种,DevOps 认证

图16. 证书的价值应该在于其能代表解决问题的能力

这是近两年兴起的事物,敏捷社区和大会上有关认证的讨论至今尚无定论,而
DevOps 的认证加入则让情况变得更为混乱,当然,这也从侧面反映出 DevOps
的火热程度。

不过,DevOps认证课程中源自《凤凰项目》的沙盘推演确实可以像敏捷工作坊中的游戏,帮助参与者了解套路后的理念、产生共鸣,但对于一个重技术的领域,这样快餐式的布道对实际工作的启发和指导究竟能有多大作用,确实有待考证。

因此,DevOps认证需要更多来自一线的真实实践数据的支撑,否则其不过是某种形式的安慰剂。而且据目前的了解,参与DevOps的认证者多数是运维人员。

但就个人的看法而言,为了达到软件全生命周期的最高效的运转,DevOps的出发点和落脚点最后都应该在于研发本身,运维应该成为幕后英雄。

今天,秉持类似理念的公司早已将研发团队打造成多能团队,做到近万系统的高效研发和运营,如果我们还在满足于玩这种家家酒,那可以认为是一种懒惰了……

除了敏捷从研发侧向运维侧的扩展,另一个的改进来自于运维侧的发展,如图17,这种情况常见于规模较大的互联网公司中,如腾讯的织云系统和阿里的运维平台,Google
的 Borg 系统及相配套的 SRE 制度多少也可以划归到这一类中。

通常,此类平台需要多年积累和打磨,其成本惊人。但近几年由于像
Puppet、Ansible 和 SaltStack 这类的配置管理工具及 Docker 和 K8s
这类环境管理和资源调度工具的成熟,普通公司也可以快速建立起一套可行的自动化运维平台。

此类平台通常要么是基于传统 CMDB 或
ITOM,将应用组成和环境信息的元数据管理起来,并根据这些元数据指导新的应用和环境的部署,要么是直接解决部署和资源调度自动化的问题。

这样的平台一旦成功,相应的流程和实现标准就都会围绕其设立。这种聚集作用会将研发侧的工作吸引到平台上,或者围绕平台构筑更为强大的工具生态。

图17. 运维侧的平台搭建可以将研发侧拉入

在这样的平台上,应用运维工作对于研发人员而言可以成为一种自助服务,运维人员就可以从此类事务性工作中脱身出来并将精力投注到更有挑战性的工作上。

如果运维团队还提供了监控平台,甚至是测试平台,可想而知,研发人员独自运营系统将并非难事,研发和运维在应用运营上将无需沟通和协调,正是所谓的,最高效的协作是无协作,最好的沟通是不沟通。