乐趣区

关于devops:DevOps落地实践点滴和踩坑记录1

记录初衷

自己始终在从事企业内 DevOps 落地实际的工作,走了不少弯路,也致力在想方法解决面临的问题,期间也经验过不少人和事件,最近忽然有想法把经验过的,不论好的不好的都记录下来,分享给和我一样的一线实践者。
我会通过一个个典型故事或场景来叙述,不谈实践,不谈技术, 只谈遇到的人和事,我和我的团队搭档怎么解决实际中遇到的问题。

1)DevOps 如同很火,咱们也来做个搞吧

“DevOps 如同大厂都在搞,据说能进步效力,咱们的我的项目常常延期,要不咱们也搞吧~”可能这是很多企业领导施行 DevOps 的初衷, 这个初衷本没有错,可是真的筹备好了吗?想分明做什么了吗?没关系,能够请内部专家讲下,听下来感觉就是一大堆工具的组合,不就是开发一个一体化平台吗?
如果只是看到了他人的成绩,没有分明两头付出的艰苦和改良,没有好的方法论领导,很容易照猫画虎,外部的改良“走形”!

2)买了你们的平台,多久能有成果进去?

在企业 DevOps 实际初期,对于自研和内部洽购还存在一些犹豫,一方面感觉如果本人投入资源研发,周期比拟长,本人等不了,所以心愿可能尽快通过成熟的内部工具疾速达到本人的冀望的指标。于此同时,内部的 DevOps 平台厂商或者征询就会看到机会开始染指,对本人的产品和计划进行推广。对于内部的征询和厂商,领导常问的问题就是“我买了你们的平台,多久能出成果?”,或“你们过来的案例个别须要多久?”,“是不是咱们买了你们的平台,团队能够马上用了”,诸如此类的问题往往令内部的征询和销售无法回答,因为真正做过落地实际的人都分明,不可能给出一个明确的答案。
其实,这种景象也反映了组织内领导没有真正分明这个事件到底要怎么做,他们感觉工具能解决问题。这是对于 DevOps 的一个误区。

3)“DevOps”应该从管理层认可开始

DevOps 呈现之后,大家兴许已经提出或者听到过一个很要害却又广泛的问题——“DevOps 转型应该从哪里开始?”
工作中,并非所有人都信赖 DevOps,通常遇到的第一个难题是失去管理层的认可与反对,因为 DevOps 的外围含意可能会掀起公司的大改革。
然而即便有管理层反对,如果管理层没有懂 DevOps 的带头人,往往也会呈现“事倍功半”的状况,管理层基于失去后果,漠视了这是一次改革,不是某一个团队就能够进行的。

4)通过工具平台接入率来掂量改良成果?

在领导的反对下,企业开始打造自研效力平台,然而怎么推广呢?往往会陷入一个误区,就是开发了,大家接入应用就好了,接入应用效力天然就进步了。可是真的这么简略粗犷吗?
接入率能阐明什么呢?接入好坏成果怎么评估?什么算接入?创立一条流水线,跑通了整个流程就算接入了,就能进步效力了?
企业为了推广本人的平台,让团队接入原本无可非议,可是办法错了,如果为了团队的 KPI,团队天然会投入人力接入,可能团队本人没有意识到这个事件的价值,只是因为领导须要咱们这么做。能够接入完了,团队持续依照本人过来的搞法玩,竹篮打水一场空。

5)找出问题比空喊口号更有用!- 价值流剖析

你感觉你们团队能给团队带来哪些效力晋升 ?”有次和下层散会,领导的这个灵魂拷问让我历历在目,说切实的,作为深谙 DevOps 实践和实际的一线实践者居然不知如何答复。下来求教了很多行业内大咖,“找出问题就根本胜利一半了”,这是一个专家的答复。忽然我意识到,这不是就刚开始来找团队做的“价值流剖析”吗,找到问题所在,走着走着迷失了方向~

尽管各家企业 DevOps 落地计划各不相同,然而有一个根本的共识就是到底要解决什么问题,只有真的弄清楚问题,能力想方法解决。
在施行初期,咱们个别会抉择比拟有代表性的我的项目,进行调研和剖析。咱们会从需要治理、开发、代码治理、构建、测试、部署、公布这几个方面进行调研和剖析,判断我的项目是否适宜迁徙到 DevOps 平台,我的项目研发过程的某些环节是否须要进行改良和欠缺。

  • 需要治理:需要管理工具、用户故事、工作、迭代等
  • 开发:开发语言、开发工具、技术框架、运行环境、组件划分及依赖关系等
  • 代码治理:代码及文档管理工具、代码库分支及用处、分支策略、代码品质检测工具及质量指标等
  • 构建:构建工具、构建过程及构建策略、构建介质策略、两头介质及最终介质治理等
  • 测试:用例和 Bug 治理、自动化测试工具、验收规范等
  • 部署:环境规划、环境配置、部署形式、依赖的中间件和公共组件等
  • 公布:上线交付物、公布流程、利用及数据备份形式、回滚形式等

本阶段产出文档:调研问卷、晋升倡议和改良计划。

6) 寻找“反抗军”因为他们真的痛

我的项目试点是十分重要的环节,也是后续是否进行推广的重要评判根据。通过后期的我的项目改良,以及流程标准的遍及推广,试点我的项目作出适当调整,试点我的项目的迁徙是对之前所有工作的一个重要测验。
在试点阶段,一方面是要通过试点我的项目的规范化革新,打造同类我的项目的流程标准,造成可复制的流水线模式;另一方面看迁徙前后给试点我的项目带来哪些好的成果,是否合乎预期,是否还有须要改良的空间,平台能力是否须要晋升等等。我的项目试点阶段产出的文档和手册是后续推广的重要资源。当试点我的项目的迁徙达到预期成果,就能够进行 DevOps 平台的遍及推广
但往往启动阶段,就会面临谁是第一个“吃螃蟹”的团队,这个时候寻找适合的“反抗军”是至关重要的,因为他们真的“很痛”,受研发效力底下困扰已久,他们迫切需要扭转。这个初心比任何的行政命令更无效,这是发自他们心田的!
在和这些团队一起合作的时候,也须要次要投入产出比,上来不要找一些高大上的,不切实际的最佳实际。先让他们看到成果苦头,他们才违心投入资源进行革新。当然,过程中必要的沟通技巧,和团队 leader 的集体关系也要搞好。

7)平台建设思路

在 DevOps 施行过程中,工具链的买通必然波及各种工具的整合。除了 DevOps 平台自身曾经集成的 Jira、Gitlab、Jenkins、Nexus、SonarQube 等工具,比拟常见的是对客户已有工具等集成,如客户自建的项目管理平台、CMDB 平台、自动化测试平台等等。
对于用户自建工具的整合,首先须要去理清整合的真正目标是什么,能为用户带来哪些价值。比方,对项目管理平台的整合,DevOps 平台能够对我的项目等迭代、需要、工作等信息进行收集和汇总,最终我的项目的进度、老本高深莫测。再比方,对 CMDB 的集成,对于 CD 过程中应用的资源(主机、容器),间接从 CMDB 拉取数据即可,无需在 DevOps 平台中重新配置一遍。

这里倡议,对已有工具的整合,整合的是数据,目标是让数据流转和汇总起来,而非做性能的整合。
规范化、统一化
我的项目迁徙到 DevOps 平台,各个我的项目能够在一个对立的 DevOps 平台进行 CICD,无需各自搭建继续集成平台。通过制订正当的标准,不同的我的项目恪守统一的标准,防止了代码库、CICD 流程的管理混乱和不标准。制订度量指标和标准,对软件开发成绩和开发过程的测量和剖析,帮忙对软件开发过程继续进行改良,无效进步软件交付品质和效率。

研发效力晋升
可视化和可编排,无需编写 pipeline 脚本,一次配置,屡次执行。提交或合并代码登程、定时触发或手动一键执行构建和部署,进步研发人员效率。无效缩小零碎变更部署上线的工夫,疾速响应业务变动。

报表展现、可度量
从效率、品质、进度三个维度展现工作、代码、构建、部署相干数据,联合我的项目看板、报表和度量指标,各环节干系人能够对进度、品质等进行判断和干涉。
DevOps 的建设是难以短期内实现的,须要进行总体规划,而后分阶段施行。无论是工具的整合,还是度量体系的施行,都须要循序渐进、循序渐进,逐渐实现建设,最终实现预期指标。

8)以终为始,确立对立的指标,防止各自为政

下面一点提到了工具的整合,在企业组织外部,工具可能会散布在不同的部门里,次要波及到项目管理,需要治理,代码治理,构建部署,测试等,DevOps 效力平台的指标是拉通所有的工具,进行数据的整合。尽管说是工具的整合,其实不如说是工具背地部门间合作形式,和如何建设独特指标。
过来一段时间,笔者经验过各工具背地的部门间思维没有对立,大家名义上都在为一个指标服务,然而不足无效的对立指标和计划,说白了各自为政,这给前期的平台度量整合带来很大的麻烦,有可能零碎要从新设计,各零碎间的数据模型须要花大力量去适配和调整。
所以,其实在 DevOps 建设团队的外部也须要通过虚构的组织和明确的领导模式来单干,防止资源节约和抵触。一个明确的建设体系和组织,至关重要,本人都是涣散的,怎么整合数据,怎么压服研发团队?

9)标准在哪里?防止停留在“纸面上”的标准

代码库标准 :包含分支和标签命名标准、分支治理标准(治理流程、hotfix 流程、分支策略)、代码提交标准。
以分支开发、骨干公布为例,治理流程标准中会波及代码库筹备、开发集成、验收测试、公布环节,每个分支的用处,每个环节中波及的角色,角色的操作流程都有具体标准。

CICD 流程标准:命名标准:组件、介质仓库、构建定义、构建产物别名、公布定义。流水线标准:开发流水线、用户验收测试流水线及回滚流水线、公布流水线及回滚流水线、hotfix 流水线。
通过制订流水线的标准,造成不同类型我的项目的 CICD 流程模版,能够作为组织级标准进行审计。

除了以上标准外,还包含项目管理标准,麻利开发标准,测试治理标准,平安标准,公布标准,版本号标准等等。有的组织可能之前有了相似的标准,然而大多都停留在“纸面上”,理论落地很难,除非在研发过程有严格的卡点审核,否则团队很难落地执行。另一方面,标准后行很有必要,否则自研平台的开发就会造成无水之源,无本之木。
标准的建设,须要联合企业理论状况,须要流程制订部门和研发团队独特制订,并且基于能够落地的形式,而不是空口实践和动作,来到工具的规范,标准几乎就是“白纸一张”!

10) 基于现状进行自研平台的开发,防止脱离团队理论

对于流水线的定义和设计,须要思考客户的环境规划和网络策略。个别状况下,会设计和定义开发测试流水线、用户验收测试流水线、公布流水线这些惯例流水线,对应开发测试环境、用户验收环境、生产环境。开发测试流水线通过屡次执行,业务零碎造成稳固版本,交付到用户验收测试流水线,通过用户验收测试之后,再转到公布流水线进行公布上线;这个过程也设计到代码分支和标签的保护。

有的客户,阶段交付物是某个版本的工件介质,并且介质库能够多环境共享或者同步,这种状况下须要在开发测试流水线中设计构建环节和部署环节,在用户验收流水线和公布流水线不须要构建环节,因为交付介质像下一个环境同步即可。流水线设计如下:

有的客户阶段交付物是代码,且各个环境有网络策略限度。这种类型的流水线,不同环境须要依据对应的代码分支或标签将介质构建进去,而后再进行部署。

这里想强调的是,自研平台的开发不能来到业务研发团队的理论场景,必须和他们进行沟通交流,如果单靠借鉴业界的通用流程,很可能最初会发现,团队须要的基本不是这样的。即不要来到业务场景去开发平台,须要和业务团队进行严密的沟通和面谈,理解他们的需要,这也须要投入人力去梳理造成计划。如图所示,通过团队沟通造成交付流水线流程图,能够清晰的让单方达成共识。

11)工具并不能解决问题, 必须依附残缺的 DevOps 体系

  • 立项:务必获取高层领导的反对与推动;
  • 指标:分阶段建设,明确年度指标,不宜贪大求全;
  • 组织:联合建设指标和现状,明确牵头部门,关注跨部门协同的难点;
  • 落地:规定束缚,可先研究、线下验证,再线上束缚、逐渐调整,且不宜初期就设置过于粗疏的规约;
  • 文化:切勿重零碎、轻文化,肯定要关注人文关心,器重组织文化建设,保障一个绝对温和的实际环境。
  • 残缺的 DevOps 体系建设,不仅仅是新工具、新规定,更是新文化,而且在文化改革打头阵的状况下,很可能获得更好、更长久的成绩,让组织具备自我纠偏的能力。

企业的 DevOps 实际相对不是自研一套平台或者买一套商用平台,不足标准指引,团队赋能和培训,指标疏导等因素会举步维艰,这真的不是夸大,而是来自一线的实在感触。这也是为什么 DevOps 落地如此之难的起因!

工具拉通,以平台为抓手,标准为领导,度量为方向,推动落地

12)建设虚构的工程效力改良组织

如图所示,右边须要建设虚构的研发效力组织,包含项目管理,平台研发,经营推广,标准审计,麻利教练,工程教练等诸多部门和角色,右侧对接业务开发团队,须要建设定期沟通机制,理解团队平台需要,同时提供最佳实际的培训和赋能。于此同时,度量指标联合标准一起制订,帮忙团队继续改良。

13)度量 - 效力晋升永远绕不开的痛

度量,这是研发效力永恒的话题。抛开度量的业务和技术自身,探讨度量的所见所闻和所思。
企业管理者之所以关注效力晋升,指标就是心愿能看到度量数据,这是他们的刚需,其实并不是研发团队的刚需。如果真的把度量数据曝露在领导背后,研发团队的一举一动就摆在明面上了,所有以数据谈话。这就是度量的两面性的本源。

那么在做自研效力平台时候,如何思考度量的建设呢?我把之前发问专家的回复贴出来。

  • “如果做 DevOps 自研平台,什么时候引入度量适合?”
    无论是用 devops 工具平台主动收集度量数据,还是通过手工收集,正当的度量越早引入越好。因为度量数据的收集,须要经验一个较长的过程,能力看到供改良参考的数据。
  • “可不可以边做,边设计指标收单点部分指标数据?”
    能够,而且 DevOps 自研平台,也应该是小步迭代地实现度量数据的收集。不要一上来就设计和实现大批量的度量数据。因为大批量交付度量指标,会让这批度量指标很晚能力交付,不利于尽早度量。
  • “如果问题很显著了,有必要做度量,去裸露问题吗?感觉既然很显著了,就先改良解决问题”
    问题很显著了,也有必要做度量。一方面能通过度量数据,让领导和团队看到现状。另一方面,在改良问题期间,收集度量数据所造成的变化趋势,能让大家看到改良动作是否能有所功效。

目前,真正进行外部度量体系的建设,快被搞解体了。后期的根底数据筹备相当重要,业务之简单远超工程畛域,前面再独自写文章聊。

未完待续

先写这些,前面遇到更多的坑,再分享进去。

退出移动版