共计 5726 个字符，预计需要花费 15 分钟才能阅读完成。
记录初衷
自己始终在从事企业内 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 自研平台，也应该是小步迭代地实现度量数据的收集。不要一上来就设计和实现大批量的度量数据。因为大批量交付度量指标，会让这批度量指标很晚能力交付，不利于尽早度量。 - “如果问题很显著了，有必要做度量，去裸露问题吗？感觉既然很显著了，就先改良解决问题”
问题很显著了，也有必要做度量。一方面能通过度量数据，让领导和团队看到现状。另一方面，在改良问题期间，收集度量数据所造成的变化趋势，能让大家看到改良动作是否能有所功效。
目前，真正进行外部度量体系的建设，快被搞解体了。后期的根底数据筹备相当重要，业务之简单远超工程畛域，前面再独自写文章聊。
未完待续
先写这些，前面遇到更多的坑，再分享进去。