顾黄亮
作者顾黄亮2022-01-06 14:41
技术总监, 畅销书作者

《DevOps权威指南:IT效能“新基建”》-认识DevOps(1.2)

字数 8413阅读 1948评论 0赞 0

作者:顾黄亮 (现任苏宁消费金融安全运维部总经理)

【声明】为了能让大家更好的学习Devops以及深入了解应用Devops的实践案例,《DevOps权威指南:IT效能“新基建”》作者顾黄亮先生授权twt社区进行该书部分内容连载。内容包括DevOps的基本概念,DevOps的工具集,支撑管理,敏捷开发,持续集成和测试,持续部署和持续交付,代码质量和安全,DevOps的度量体系,持续改进和反馈,DevOps最佳实践,以及DevOps的后续发展。

1.4 DevOps 文化

1.4.1 为什么需要 DevOps 文化

经过慎重考虑,作者决定把“ DevOps 文化”部分放在本章的中间。对于一个组织,文化起了地基的作用。 DevOps 是否能够按计划和规划实现,文化是一个重要因素。在企业的实践过程中,很多案例凸显了一个事实: DevOps 转型的第一个要素是实践 DevOps 文化,并通过文化建设促使 DevOps 进行实践和落地。

对于企业,文化具有统一思想和价值流向的作用。对于 IT 组织, DevOps 文化的作用更为聚焦和纯粹,促使组织成员不断进行知识沉淀和过程管理并将结果反馈至组织,从而提升组织级的效能和质量。

1.4.2 传统 IT 组织文化存在的弊端

1 .更多的惩罚

IT 组织文化中的惩罚源于传统行业。在制造业的信息化转型过程中, IT 组织的工作内容和权责与制造业中的流水线挂靠严重,赋予 IT 组织成员极少的权利, IT 组织成员更多时候以支撑的角色来作业,因此无法从日常工作中得到成长,更缺乏连续学习和创新的机会。相对应的, IT 组织成员对企业和 IT 组织缺乏相应的知识共享和传递精神。出现这种现象的本质是文化的缺失。在这种文化氛围下,惩罚是 IT 组织反馈的唯一方法,通过惩罚来促进优化和改进,以及进行考核和促进成员成长。

2 .有意识地进行隐瞒

IT 组织文化中的隐瞒存在于大部分企业,在组织文化层面,缺乏合理的复核和考核机制,在技术体系层面,缺乏相应的监控和度量机制,导致业务连续性风险。在很多企业中,随着业务的不断拓展和信息系统数量的不断增加,文化和技术的结合得不到及时跟进,于是 IT 组织的发展得不到文化的赋能,导致风险无法被管控。

在事件和问题管理中,一般有事前、事中和事后 3 个阶段,经过作者统计,约 80% 的问题是由于 IT 组织成员的失误造成的,因此,在事前进行管理,就显得非常必要。而在 IT 组织管理中,绝大多数问题的管理集中在事中和事后,事前管理更多集中于流程流转和资源输出,因此, IT 组织作为支撑,事前管理的缺失会导致最终价值输出存在极大风险,而在最终 KPI 考核层面,风险性较大的环节往往得不到重视,带“病”上线的情况经常出现。一个典型的现象:从架构设计、代码设计到性能和质量的把控,趋向于以流程为基准,漠视数据反馈和隐瞒风险成为大多数人的选择。

3 .缺乏分享精神

科技是第一生产力。从本质上来说,技术的提升是组织级的能力提升。为了辅助达成这个目标,文化的作用尤为重要。若体现在氛围方面,就会形成一个高度信任的环境,使得 IT 组织成员乐于提出意见,并进行信息无障碍传递和知识分享。在实际的日常流水线工作中,通过技术革新和文化加持,将风险提前暴露,并进行流程优化,促使新理念和新技术不断被尝试和优化,最终推广至整个 IT 组织,提升组织不断适应快速变化的环境的能力,将整体变得越来越敏捷,越来越集约,越来越可靠。

1.4.3 DevOps 文化具备的特点

下面介绍 DevOps 文化具备的 5 个特点。

1 .具备全局的系统思维

在 IT 组织内部,成员必须具备从全局系统的角度与业务进行结合的思维。全局的系统思维涵盖了链路级的系统范围,而不是自己负责的某个功能模块。践行 DevOps 理念,不能局限于自身,应从自身出发并沿着领域、团队级和组织级的脉络进行涵盖。

全局的系统思维意味着成员应了解其他成员、能力子域在价值交付流水线中承担的职责和工作范围,同时了解其可能造成的影响,如是否对全局的系统链路或业务造成影响,是否是业务连续性保障中的风险点。在持续交付的目标中,有一句话值得思考:交付的目标是将不同的实践、流程和程序进行高度协同,以抵消风险,高质量和高效率地完成交付。这句话其实也体现了 DevOps 的锚定价值,即提升组织级的效能和质量,达到最终的价值交付。

2 .关注业务需求是否契合 IT 组织文化

DevOps 需要达到端到端的价值交付,而交付的主体是业务组织,因此业务需求需要进行统一的扎口和事后复盘。尤其在 IT 组织文化层面,需要组织成员通过价值流向来梳理交付流程和确定交付核心节点,围绕价值流向来判定交付进度和交付过程中的风险点,并通过技术手段和管理手段进行规避和优化。

价值交付将业务需求从设计发展到产出,最终到终端交付。在这个过程中, IT 组织的文化起到了管理理念和管理方式的固化作用。价值的定义在组织内部是顶层目标,提升交付的效率和质量是具体方法。文化赋能能够促使团队成员随时进行业务价值的跟踪和反馈,并及时与业务部门、需求部门实现信息的传递和协调机制的建立。

3 .共担责任

共担责任是 DevOps 文化的根本,不能共担责任的文化意味着组织成员最终会“单兵作战”且主动关闭信息共享通道。在价值输出流水线中,具备共担责任的节点主要为交付速度和交付质量,交付质量更为突出。在质量环节,如果质量管理由某个能力子域独自承担,那么意味着违反了 DevOps 的模糊边界原则,在此期间,缺乏客观的数字化呈现,质量的管控体系会形成无法打破的“墙”。

在价值交付模式下,质量管理是关键节点,与质量相关的能力子域需要共担责任。在 DevOps 文化中,强调打破“部门墙”,建立互相信任的通道,交付速度和交付质量之间的矛盾需要通过模糊边界来解决。模糊边界的核心文化是共担责任。因此,必须通过流程和数据的管理方式和文化理念才能达到最终提升组织级质量的要求。负责质量的能力子域需要在其他能力子域的配合下,尽早发现和解决问题,从价值交付的角度来触发,更有助于流水线上各能力子域高效协作,促进整体质量提升。

4 .勇于“试错”

试错的成本包括学习成本、实验成本和总结经验的成本。试错也是达到最终目标的必备手段。在试错环节,信任是试错的基础,也是 IT 组织各能力子域通力合作的基础,尤其在 DevOps 价值输出流水线过程中,试错是检验信任的重要手段。

IT 组织各能力子域需要认清试错等同于最终成功的价值,并及时在 IT 组织内部进行分 享和信息传递。只有不断试错和勇于试错,才能暴露更多的风险和提升技术的赋能。

5 .善用数据,通过数据说话

数据是 DevOps 中的重要组成部分,这种趋势将一直延续。没有量化数据的管理,一切判断都是主观的。管理者需要客观地分析和解决问题。因此,没有数据思维,就不能持续地进行度量和反馈。

在 DevOps 的价值输出流水线中,整个交付周期的管理依赖各能力子域的节点数据的输出。无论是 IT 组织的管理者还是各能力子域的管理者,都需要输出数据、使用数据,并信任数据,通过数据的分析和输出,从全局的角度关注内部的优化和改进,促进信息流转和数据赋能。

1.4.4 DevOps 文化的目标

在企业文化中, DevOps 文化是面向 IT 组织和软件产品交付的独有文化,具备多重标签,包括内部管理、数据使用、信息传递和互相信任。对于 IT 组织,提倡免责、共担责任、高度信任、分享和协作,这种文化会改善 IT 组织内部的协作和管理方式。通过对 IT 组织各能力子域的文化赋能,能够有效地提升交付的效率和质量,并加快技术迭代和技术创新的速度,最终反馈至业务组织,实现更高的业务价值,助推企业发展。

1.5 DevOps 的工具链框架

1.5.1 DevOps 工具的发展特性

谈到 DevOps ,不得不提软件开发;谈到软件开发,不得不提工具。在 DevOps 实践落地的过程中,我们不难发现,方法论是一种思想,而工具是“骨架”。对于工具,其具备较为标准的使用特性和选型原则,而工具链则是通过流程规范和价值流向给予工具的赋能。

1 . DevOps 的发展历程

首先必须明确的是, DevOps 的受欢迎程度是随着软件工具的发展而不断上升的。我们重温一下 DevOps 的发展历程。

2009 年, DevOps 被定义为一组过程、方法和系统的统称,主要以打通“部门墙”的形式来跨越研发人员和运维人员的沟通鸿沟,促进信息的传递。

2011 年, DevOps 增加了相应的敏捷属性,具备快速响应业务的需求的特性,通过行为科学来改善 IT 组织各能力子域的沟通和信息传递方式,提高 IT 组织的交付效率,快速交付软件产品和软件服务。

2015 年, DevOps 提出了沟通、协作和工具一体化的概念,这是一种突破,表明将工具正式纳入 DevOps 文化的范畴,帮助 IT 组织快速进行软件交付,并涵盖了软件质量和产品稳定性需求,重点强调了通过工具来提升软件交付和变更的效能,建立一种组织级的文化,可以更频繁和更稳定地进行软件交付。

2016 年, DevOps 提出了“全链路交付”概念,同时增加了“全局的流水线”概念,将流水线嵌入业务交付的流程,具备稳定支撑业务发展的能力。在局部领域,通过业务属性的耦合帮助企业降本增效。

2018 年,技术运营横空出世, IT 组织不再是价值的贡献者,而逐步上升到价值的生产者。更多的理念被管理者接受。业务的高耦合使得业务目标更容易被实现。在 IT 组织内部,软件构建、软件集成、软件测试和软件部署正式成为标准的最小单元。

我们用一张图描述 DevOps 的发展历程,如图 1-10 所示。

2 .软件开发的发展路径

软件开发作为 DevOps 的能力输出载体,也有相应的发展路径,我们简单描述一下。

瀑布开发是发展最为温和的一种软件开发模型,不仅为软件开发人员带来了众多好处,还有利于大型软件开发过程中软件团队的管理,有利于软件开发方法和工具的研究,从而提高大型软件项目开发的质量和效率。在软件开发领域,软件开发具备完整的生命周期,具有起点和终点。在瀑布开发模型中,必须完整和谨慎地经历这个周期中的每一个关键节点阶段,通过对里程碑的应用,过程管理更容易被软件开发管理者和软件开发对象所识别。在瀑布开发的整个过程中,需求和设计有严格的管控,相关的文档也被纳入管控范围,在最大范围内符合软件工程学的分层设计,有效地确保软件产品的质量。但是,瀑布开发模型也存在一些缺点,如客户需求在中途发生变化,导致软件开发过程中产生不可靠的因素,成本和时间的估算较为困难且不可靠,软件的架构设计变更会随着项目的推进变得成本很高和异常困难。

图 1-10

敏捷开发是一种以人为核心,以迭代为方式,以循序渐进为理念的开发方式,也是互联网企业中常见的软件开发模型。敏捷开发最初是企业为了业务快速上线而促使软件开发团队具备快速工作和响应的能力而提出的,在互联网的开发实践中,形成了 Scrum 、特征驱动、动态系统开发和实用编程等不同分支和流派。与传统的瀑布开发不同的是,敏捷开发团队更扁平化且富有活力,能够适应开发过程中需求和设计的变化,更能输出高质量软件。在此期间,强调面对面的沟通,端对端的协作,因此更为注重团队成员的技术和文化。

DevOps 开发是更为激进且更具备过程管理和过程优化的敏捷开发模型,在追求合作和响应变化的基础上,更加追求价值。 DevOps 开发将软件开发过程转变为对协作管理的挑战,追求数据反馈的快速沟通,按照价值交付流水线的方式,将团队成员的成果形成合力。与敏捷开发不同的是, DevOps 开发更注重效能的度量和质量的管控,更加面向业务对象,需求的达成率和核准率的比例不再耦合,大大简化了文档的输出,采取智能式的推进手段给予管理者更大的帮助。

我们用一张图描述一下瀑布开发、敏捷开发和 DevOps 开发,如图 1-11 所示。

图 1-11

3 . DevOps 工具的发展路径

通过上面的描述,我们可以发现,软件工具、 DevOps 和软件开发是以线性方式进行发展的,三者呈现耦合的发展态势。因此,随着 DevOps 和软件开发模型的不断发展,工具的种类和功能也趋于规模化和复杂化。 DevOps 工具的发展路径大致如下。

( 1 )商业化的技术移植阶段,处于 DevOps 发展初期。由于缺乏相应的开源技术支撑,软件开发和交付流程较为宽松,因此,对于 DevOps 的需求,更多的是处在打通研发和运维的“部门墙”阶段。这个阶段的工具的选择面较为狭窄,一般采取商业化软件来进行支撑信息的传递和资源的交付,典型的特征是采用商业软件和运维脚本组合的方式。

( 2 )开源软件的“野蛮生长”阶段,处于 DevOps 的中期“爆发”阶段。由于 DevOps 文化的加持,开源环境进一步得到发展,相应的 DevOps 工具应运而生,尤其得到云计算发展的助推,呈现“野蛮生长”的态势,集中于持续构建、持续集成、持续交付和自动化测试领域。在这个阶段,开源软件层出不穷,版本迭代不断加快,但功能却趋于雷同。随着同种类的工具越来越多,加快了企业实践的 DevOps 过程,同样带来了弊端,如工具的选型缺乏合理性导致整个工具链的重构。

( 3 )趋于聚焦的精细化分工阶段,处于 DevOps 的中期稳定阶段。在企业的 DevOps 实践过程中,随着组织架构的不断合理和对文化认知的不断加深, IT 组织的价值输出呈现不一样的聚焦,主要集中在业务聚焦和科技聚焦层面。随着更多的技术革新,大数据、人工智能的技术赋能,使得企业在 DevOps 工具的选型上有了更深层次和更为持续性的考虑,因此 DevOps 工具也趋于聚焦的精细化分工,基于企业更聚焦的选择。

( 4 )继续“生长”和完善阶段,处于 DevOps 的后期稳定阶段。随着 DevOps 的转型和 Aiops 的逐步推进,精细化分工的工具聚焦点亟需技术的重新赋能。与“野蛮生长”阶段不同的是,该阶段的目标更为明显,工具的继续“生长”和完善更多遵循工具自身的发展趋势和价值输出范围。

1.5.2 DevOps 工具的选择

在工具的选择方面,作者经过大量的实践和调研,提出了工具选择方法论。这个方法论主要包含 4 个方面:工具的驾驭、工具的价值、工具的赋能和工具的本质,如图 1-12 所示。

图 1-12

1 .工具的驾驭

从本质上来说,工具的驾驭是工具的文化。在 DevOps 工具选型过程中,有些人存在一个误区,认为工具的选择和 DevOps 的实践是两回事,因此导致一种严重后果,那就是工具文化和 DevOps 实践脱节。在 DevOps 文化中,鼓励沟通和交流,这便于锚定价值输出,同时可以更快、更好地输出优质的产品和服务。

在工具的选择过程中,工具的驾驭更多地体现在根据现有团队的规模和 IT 组织成员的技术能力选择对应的工具。 DevOps 的实践是分阶段的,在不同阶段,要选择不同的工具,同时要做好衔接。对于工具,尽量使用我们熟悉且自动化程度高的工具,这样有利于我们尽快掌握工具的使用。

2 .工具的价值

工具的价值和软件开发的价值是相互促进的。如果 DevOps 是一种软件开发模式,或 者当企业的开发模式已经通过 DevOps 方法进行实践时,那么 DevOps 工具是价值输出时一 个不可或缺的载体。当交付风险管理、可视化、需求管理、成本复盘和审计控制成为价值输出链路中不可或缺的一部分的时候,就应该考虑工具的选择和工具的价值是否可以测算。

3 .工具的赋能

工具的赋能是一个新的命题。 IT 组织的各能力子域具备相应的职能,因此工具的赋能要实现多个能力子域之间的数据交互并解决冲突问题。站在运维的角度,运维的核心职能是维护系统的稳定,在更深层次方面,就是保证产品的稳定。项目管理的核心职能是推进产品尽快上线,更深层次地捕捉产品交付过程中的风险。因此,在工具的赋能方面,需要搭建技术、文化和信息的价值输送通道,工具的赋能取决于选型的高度。

4 .工具的本质

工具的本质是迭代,这一点可以通过“进化”来体现。因此,在选择工具时,不要被工具“绑架”。在企业规模和业态不断变化的今天,从一个团队负责一个产品的交付生命周期到多个团队共同负责多个产品的交付生命周期,这种突然的转变会带来新问题,高度的自动化、更快速的工具支撑和更好的无缝协作方式将会考验工具的迭代能力和解耦方式,因此,避免被工具“绑架”的快捷方式就是不断迭代工具。

1.5.3 DevOps 工具的种类

我们将在第 2 章详细介绍 DevOps 工具,在此仅列出工具类型。由于每种类型的工具涉及的工具较多,因此本书仅列出较为常见的工具,见表 1-1 。常见的工具组链方式如图 1-13 所示。

表 1-1


图 1-13

1.5.4 DevOps 工具的发展现状

《中国 DevOps 现状调查报告( 2020 年)》中关于 DevOps 工具的描述如下。

由此可见,通过 DevOps 工具选型,大多数企业在 DevOps 的实践和落地方面已经进入 中期稳定阶段。在工具的选择过程中,企业更多地关注工具的 自动化程度、功能的易用性和工具自身的安全性,并会对工具进行二次开发和工具链的整合管理。

1.5.5 工具链简介

工具链是工具的有机结合,更是工具价值的有机集合。工具链框架遵循 DevOps 的核心价值。

在工具链框架体系中,应该以全局的链路交付为基础,从产品和需求的管理开始,逐步进入架构、资源、开发、构建、测试、部署、交付和运维环节,而项目后评价和成本复盘作为后置介入方式构成全局的闭环,同时,在安全管理方面,采取核心节点或旁挂节点作为补充,具体流程如图 1-14 所示。

图 1-14

全局工具链以多个局部工具链为基础,以工具嵌入的方式进行局部工具链分段实施。局部工具链包含以下几种。

( 1 )信息流转工具链,主要实现 IT 组织各能力子域的沟通,以信息流转的方式促进信息的交流和传递,同时促使团队成员保持对信息的敏感和警惕,保证交付过程中的信息留痕和交付后的业务连续性。具体以对接 IM (即时通信)工具实现内外部信息流转,对接监控和用户反馈工具用于问题发现。

( 2 )持续构建、集成和部署工具链,主要实现制品的自动化交付。这是局部工具链中比较常见的一种,在实践和落地过程中,具有代表性。

( 3 )自动化测试工具链,主要实现制品的自动化测试,同样是具有代表性的局部工具链。随着和其他局部工具链的整合,服务范围与输出对象涵盖运营组织和项目管理组织等能力子域,更有利于自动化识别风险区域。

( 4 )资源交付工具链。在传统的软件工程理念中,资源交付是一个前置阶段,随着交付能力不断提升,资源交付成为交付链路上新的制约因素。资源交付工具链通过工具的集成,实现“基础设施即能力”,将计算、网络和存储等资源交付能力不断下沉。

( 5 )数据流转和汇聚工具链,采取数据处理工具对各局部工具链进行数据的采集、汇聚、处理和存储,并按照数据使用场景进行相应的数据输出。

( 6 )云原生工具链,以 Docker 和 Kubernetes 为代表的云原生工具,采取工具集成的方式,实现快速的服务交付,具备快捷接入的能力,是一种更为全面的服务化能力。

( 7 )度 量和反馈工具链是数据流转和汇聚工具链的下联工具链组织,包括 IT 组织和业务运营组织等职能部门的使用场景,能够及时地对信息进行分析,提供给管理者进行参考和判断。

( 8 )安全管理工具链,提供安全和审计闭环的自动化输出能力。

( 9 )可视化工具链,同样是数据流转和汇聚工具链的下联工具链组织,以无编码的方式进行数据的汇聚展示,所见即所得。

## 全部连载

《DevOps权威指南:IT效能“新基建”》-前言
《DevOps权威指南:IT效能“新基建”》-认识DevOps(1.1)
《DevOps权威指南:IT效能“新基建”》-认识DevOps(1.2)
《DevOps权威指南:IT效能“新基建”》-认识DevOps(1.3)
《DevOps权威指南:IT效能“新基建”》-支撑管理(3.1)
《DevOps权威指南:IT效能“新基建”》-支撑管理(3.2)
《DevOps权威指南:IT效能“新基建”》-支撑管理(3.3)
《DevOps权威指南:IT效能“新基建”》-DevOps的度量体系(8.1)
《DevOps权威指南:IT效能“新基建”》-DevOps的度量体系(8.2)
《DevOps权威指南:IT效能“新基建”》-DevOps的度量体系(8.3)

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广