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工具和方法，提高个人开发工作中的效率，并将工作内容可视化。