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本身就是一个持续性的过程，必然需要一个持续不断的积累才能发挥最终的效果。