1 - 关键问题

  • 如何向不具备相关基础知识的人说明和解释DevOps?
  • 如何在组织和团队中推广和实施DevOps?

2 - 在组织中实施DevOps

在全新的组织或服务开发中,没有既定规则和老旧的习惯,所以推荐采用自上而下的方式实施DevOps。
如果无法采用自上而下的方式实施DevOps,应该通过灵活的方式尽早开展DevOps的启蒙工作,增加志同道合者的数量,构建理想团队。

在既有组织中实施DevOps要相对不容易,普及和应用的过程中要遭遇更多的困难。
现有的业务系统、运维流程和知识体系都将产生很大的约束,可能根本无法改变原有方式,因此对现有组织,一般很少采用自上而下的方式进行重大变革。
如果没有上层的大力支持,推荐采用自下而上的方式,先在团队成员中普及DevOps背景知识和技能,阶段性推动成员向DevOps前进,然后再调整范围。
自下而上分阶段:自己使用DevOps工具,改变个人开发环境---》向成员普及---》改变团队规则和团队间的沟通方式--》持续改变和反馈。

无论采取采用自上而下,还是自下而上的方式,改善的只是工作方式和业务替罪,而不是对组织本身进行大幅变革。

2.1 - 确定目标

在采用自下而上的方式时,要考虑变革的范围,在最开始时设立具体目标。
随着DevOps的不断推进,变革的范围也会发生变化,与其一开始设立一个非常大的目标,不如采用逐步推进的方式会更好。

2.2 - 收集信息

了解现状,扩大看待问题的视野,思考在什么地方使用DevOps方法和以怎样的形式去使用。

  • 团队成员的工具使用情况
  • 团队内部规则:在哪里工作,承担什么角色
  • 团队之间如何沟通?责任范围如何划分?
  • 有哪些文档?操作步骤是怎样的?业务流程如何?
  • 当前面临什么问题?等等

2.3 - 现状分析

从收集的信息中,过滤出对当前工作步骤、任务和流程能起到根本作用的内容,明确需要改善的对象。
可以召集团队成员开展头脑风暴或者单独交谈,询问为什么该项工作是必要的,突破“历史因素”的影响,整理出当前团队所追求的质量或结果。

2.4 - 消除本质上不必要的工作和规则

基于客观事实,剔除不必要的各种工作和规则,并清楚地解释和耐心地说服团队成员。

2.5 - 寻找改变方法的切入点

从“必要工作内容列表”寻找一个切入点,使DevOps的工具、方法和体制可以应用在现有的开发流程或运维工作中,不能一次实施大量的改善。
这个切入点最好包括以下特点

  • 输入相同的内容,也能产生和以前相同的输出
  • 没有涉及跨团队协作的场景,易于操作
  • 实施效果好,优先级高:大幅消除重复性工作、降低工作沟通成本、缩短信息同步周期等

2.6 - 实施

引入新架构的障碍主要来自于团队成员对改变现有工作流程的抵触。
因此,保证输入和输出都没有变化,或者在有限的范围内实施DevOps,只改变具体的实现方式,而不改变原有的工作流程,团队成员的抵触就会有所减轻。
思考最终要达到什么样的效果,在保证最终得到相同结果的前提下,对原来的操作步骤进行替换,然后结合已有的方法和输出,重新思考替换步骤本身的流程。

2.7 - 启蒙

无论在DevOps的任何阶段,都应该积极地在团队内外宣传DevOps的效果,让团队成员和相关人员对新工具和方法有更加直观的印象,理解实施DevOps的重要性。
讲述技术趋势、DevOps背景、实施DevOps必要性及效果、自身在业界的位置等,帮助成员认识到当前组织的发展方向是否正确,以及今后应该如何去做。
培养出能够以较少人数完成大范围业务的DevOps人才,带领团队前进。
一个优秀的具体实例,可以起到很大的示范作用,可以让成员更加容易理解和支持。

2.8 - 检验效果并反馈给所有人

对引入DevOps工具和方法的效果进行定量或定性检验,并将这一效果以可见的形式传播给组织和团队成员,切实体会到改善的成效。

  • 损耗是否减少?减少了多少?
  • 业务风险是否变化?
  • 那些环节提升了效率?提升了多少?
  • 等等

2.9 - 全员参与,避免单打独斗

在DevOps实施过程中,孤军奋战不是一个好选择。
可以向团队成员进行DevOps的启蒙以及反馈实施效果来增加更多的同伴,集思广益,共同推进DevOps的实施。

2.10 - 在不偏离总体目标的前提下进入下一个实施阶段

确定一个DevOps化的整体目标,并设置各阶段的范围和目标,也就是定义了在什么节点和范围内对多少内容进行替换,最终想变成什么样,等等。
改善无止境,新工具新方法层出不穷,DevOps本身就是一个持续性的过程,必然需要一个持续不断的积累才能发挥最终的效果。

3 - 组织形式与DevOps

对应不同的场景和需求,DecOps的组织形式有很多种实现方法。
同时根据康威定律(设计系统的组织,其产生的设计等同于组织的沟通结构),通过引入DevOps的工具和文化,也能够使系统架构和组织结构同时发生变化。
无论采取自下而上,还是自上而下的方式,都需要根据DevOps目标来对组织形式进行思考,进而制定符合自身实际情况的组织形式。

3.1 变更现有组织形式

3.1.1 开发、测试、运维等团队之间紧密合作(Close-Knit Collaboration)

各个团队仍承担原有工作职责,但通过“DevOps协作的工具和方法”来最大限度地融合在一起。
优点是能以最低限度的知识背景和资源投入来实现某种程度上的DevOps,变更范围小;缺点也很明显,就是容易“流于形式”。

3.1.2 专职的DevOps团队(Dedicated DevOps Team)

实际上,很多DevOps环节的落地实施对非DevOps组织还是非常困难的,比如编写基础设施代码、进行版本控制、实现持续继承和持续交付、性能优化等。
因此,当前趋势是大多数公司已经或开始倾向于聚集专业的DevOps人才,组建专门的DevOps团队。
由具备DevOps相关知识和实践经验的专业工程师建立专门的DevOps团队,先以专家为中心组建雏形,然后组建扩展人员和规模。
优点是合适的人组建的专职团队,更有利于结合DevOps工具和方法实施自动化智能化,省时省力,极大地提高效率。
难点是要解决对专业人员的需求,如何找到或培养出合适的DevOps专业人员。

3.1.3 跨职能团队(Cross-functional teams)

召集包含业务全流程各领域的专家组成的跨职能的DevOps团队,由包含需求、设计、开发、测试和运维等团队的至少一个代表组成。
优点是可以有效降低各流程和团队之间的沟通成本和认识误差,有利于全领域的知识和信息共享,便于推动事项进展。
缺点是如果团队规模变得很大(人员过多、内容宽泛等),就会难以控制。

3.2 不改变现有组织形式

组建临时团队或者采取技术性的解决方案也可以实现DevOps。

3.2.1 小型的临时DevOps团队

构建一个横跨各团队的小型DevOps专用团队,集中实现基础设施即代码的配置管理、自动化部署以及持续集成环境的构建和监控等。
在DevOps普及过程中,各业务团队可以向临时DevOps进行咨询,完善知识背景和能力。
团队性质是临时的,基础环境构建完成后,团队可以随时解散,不影响原组织形式。

3.2.2 技术性的解决方案

通过技术性方案来加强团队之间的沟通,变革的只是工作方式。
根据DevOps中“基础设施即代码”的思想,所有的基础设置都朝着代码化的方向发展,实现基础设施的自由使用。
例如,构建一个通用的配置管理工具环境,或者以API为中介联通基础设置和团队业务流程。
各团队都基于统一的“操作手册”,这样原先的团队组织结构就可以保持不变。

4 - 团队整体的DevOps

可用于DevOps实施的工具众多、方法宽泛,工具与方法的组合也丰富多彩。
在实际工作中,很容易沉陷到工具的详细用法,方法的具体操作上,忽略了一些更重要的基础性工作,比如改善团队之间的关系和工作方式等。

实现DevOps的第一步就是培育能够让团队成员相互协作的土壤,改善团队和组织的合作氛围,提高信息的公开性和透明性,使团队成员朝着同一个目标前进。
在培育这一土壤的过程中所体现出来的态度和作出的努力,将会成为支撑我们对抗这种障碍和阻力的力量。

DevOps实施是一个持续改善和不断迭代的过程,如果一开始就设立实现DevOps这种宏大的目标,很可能会遭遇挫折。
过激的做法往往导致矛盾激化的结果。
实施DevOps的策略通常是先找到问题,设立相应的愿景,然后朝着这一愿景脚踏实地地从一个合适的切入点进行改善。
采用循序渐进的方式,先从小的地方开始实践DevOps,然后再调整范围。
从个人开始实践DevOps,然后在团队普及DevOps,最后面向DevOps的进行架构变革。
也就是说,先设法在个人或本地环境中应用DevOps工具和方法,提高个人开发工作中的效率,并将工作内容可视化。

05-14 19:17