DevOps是一个复杂的多维话题。这是上下文相关的。那些试图了解和实施DevOps的人将他们的角色和文化观点带入了流程。意见和专业知识的多样性可能是重要的优势。但是，这也可能导致开发DevOps共识产生摩擦和争论。按我的个人经历，在团队里，想要推动DevOps发展和落地是很痛苦的，特别是在小团队里，因为这将是一场颠覆的变革。你可以喷我，但我不赔钱。
为什么需要DevOps达成共识?
需要共识，因为DevOps不仅是一回事。这是一整套解决广泛问题的想法。任何共同解决问题的团队必须首先同意：
- 我们要解决什么问题?
- 解决指定问题的最佳工具是什么?
- 我们如何衡量改进(或缺乏改进)?
想要使用DevOps回答这些问题的企业和团队必须首先就以下两个问题的答案达成共识：
- 什么是DevOps?
- 我们如何使用它来改善软件交付?
每个企业想要完善或升级自身的运维体系，都必须问自己这些问题才能开始使用DevOps，并且每个企业的答案都不同。进行自我询问和回答的过程可以知道什么有效，什么无效，以及可以采取哪些措施来促进有效的变革。
首先，DevOps讨论
正在考虑DevOps的企业应首先讨论什么是DevOps以及如何使用它。有很多关于DevOps的学习资源(有关更多示例，请找度娘或者关注并私聊我)如果你承担着促进讨论的任务，那么你很幸运，有许多有效的方法可以引导对话。你的第一步是研究。对基本概念的理解将使你能够将其介绍给各种各样的利益相关者。
“领导对话”并不一定意味着“向同事介绍DevOps。”要达成DevOps共识，你的首要任务是打下基础，然后让讨论有效地进行。作为协作的“发现”会话，第一次对话将更加有效。对话负责人往往更有效地作为教练和裁判，而不是教育者。介绍基本思想，然后通过聆听和提问来促进对话。
如果你准备在DevOps上做演示，我建议你在简介的开头限制使用“ DevOps”一词。这个词可能充满了成见，特别是如果你的听众对DevOps接触很少。重点关注基本原则，重点在于如何将其用于解决特定问题。尝试避免和阻止对DevOps的简化定义。你会听到类似的声音：
- DevOps就是自动化
- DevOps确实是过程改进
- DevOps工程师是配置管理方面的专家
这些是快速形成意见的示例，但并未完全理解DevOps的广度和深度。DevOps涉及自动化，流程改进和配置管理等等。使用严格规定的处理方式，不应将DevOps视为正统观念。应该将其视为用于实现业务目标的一组工具。
随着对话的进行，记录关键问题。最关心的业务是什么?列出这些问题的优先顺序。该过程将使小组专注于最关键的业务挑战。一旦达成共识，即可将DevOps评估为解决这些问题的工具。
如果你的企业正在考虑对DevOps进行大规模战略采用，则你的DevOps共识讨论将需要跨多部门的领导团队参与：
- 执行管理(首席执行官，首席财务官，CSO(安全)，CIO / CTO)
- IT运维管理
- 软件开发管理
- 项目管理
这些角色各自具有独特的视角。确保代表每个角色，并有机会表达关切和提出问题，这一点至关重要。公开的讨论将使这个跨职能团队可以考虑所建议方法的折衷方案，并平衡所有角色之间的关注点。该团队应该在工作会议上一起学习DevOps，以开发对你的企业有意义的DevOps定义。
那么，什么是DevOps?
DevOps不仅是一回事，因此很难编写一个单一的，包含所有内容的单句定义。DevOps有很多东西，而且这些东西还可以解释。这并不意味着尝试定义DevOps是徒劳的。恰恰相反，DevOps建立在一些非常成熟的概念上。这些想法和原则为DevOps的实施方式提供了依据，但它们并不是通往“ DevOps必杀技”的路线图。它们是指南，是思考问题和解决方案的方式。
在团队中达成DevOps共识的第一步是以通俗易懂的语言向同事介绍这些基本思想。为了使讨论首先围绕目标而进行，然后再讨论方法，请以这些基本思想为重点开始介绍。
以下是一些DevOps的首要原则，可帮助你达成DevOps共识：
简短的反馈循环：敏捷使用诸如站立式的仪式来确保开发人员和利益相关者之间的定期沟通。DevOps还强调缩短和放大反馈回路。
精益IT：精益IT的原理主要集中于消除生产中的浪费。DevOps是在控制过量生产和提高生产流程效率方面发挥了作用。
约束理论：约束理论提供了一种通过识别和“打破”(消除)约束的连续过程来提高吞吐量的方法。约束定义为多步骤生产过程中的任何“瓶颈”步骤，其中工作变慢并开始积压。敏捷实践将工作流程可视化，有助于揭示工作障碍。DevOps将这种想法从软件开发生命周期扩展到整个软件交付生命周期。
价值流图：所有服务都是通过不同复杂的过程生产的。一个人很少了解复杂的过程。每个步骤(在制造中称为“工作站”)通常由具有专门技能的员工来处理。软件开发工作站包括开发，测试，部署和维护。
理想情况下，创建价值流图是一个协作过程。每个团队汇聚一堂，讲述他们在生产中的故事，这将有助于达成DevOps共识。整个故事源于价值流图的过程。此练习通常会暴露整个过程的效率低下。DevOps使用“价值流图”将生产工作与战略性企业目标保持一致。
持续改进：持续改进是一种寻求并消除过程中效率低下的科学实践。持续改进团队不断评估生产团队的过程和结果。关于约束或其他低效率如何影响生产的理论得到了发展。然后，团队对流程进行细微的更改，并测量改进(或缺少改进)的过程。这个过程永无止境，一直在寻找消除浪费和提高生产率的机会。DevOps从业人员使用持续改进作为一种整体测量和改进软件交付过程的方法。
你将学到的大多数关于DevOps的知识都植根于这些基本概念中的一个或多个。在DevOps讨论中采用“自下而上”的方法将使人们对第一个原则产生共同的共识。共同的理解是下一步的强大平台：弄清楚如何使DevOps适应企业的独特需求。
企业如何适应DevOps?
你已经向跨职能团队介绍了DevOps的基础知识。你已经共同确定了最重要的业务目标和挑战。现在，你准备好将它们配对，并开始谈论DevOps如何解决这些挑战，并且你正在逐步达成DevOps共识。对话已准备好从抽象过渡到方法，最后过渡到实施计划。这仍然是一项复杂的工作，因此，此时最好的方法是“分而治之”。
DevOps可以分为三个主要领域：
- 文化/人
- 处理
- 技术
这些领域之间当然存在一定的相互依存关系，但是可以由不同的利益相关者分别并行地解决它们。前面列出的每个角色都将在这些主要领域中占有一席之地。但是，每个人都有一个自然的重点领域。
DevOps文化
“ DevOps”始于开发和运营部门之间关系的功能失调状态。开发人员想要快速行动，运营部门需要放慢进度以保持稳定性。在这种体制下，双方不能同时获胜。
DevOps旨在将软件交付中的开发，运营，安全性和其他利益相关者召集在一起，共同承担使命。开发人员应赞赏并了解他们生产的软件的操作要求。运营需要了解开发路线图，以便为新版本做好准备。在整个过程中，安全人员必须坐在桌子旁。软件交付的全部目的是向客户交付业务价值，这最终由执行管理层代表。
在向DevOps的文化转变中，每个人都可以发挥作用。但是，高级管理人员应最终负责转变后的消息传递。高管人员的交流可以领导高层的变革。
DevOps流程
DevOps的过程部分基于敏捷软件开发方法。如果你的组织已经使用敏捷，那么你将处于领先地位。你可能会发现一些敏捷实践应该改变的领域，以适应更大的DevOps实践。如果你不练习敏捷，那么这是开始你的DevOps旅程的好地方。关于DevOps的一个常见问题是：“可以在没有敏捷的情况下实践DevOps吗?”简而言之，是的，但是，如果将DevOps作为敏捷实践的更大一部分来实施，你的工作回报将会更大。
持续改进也是一个主要主题。IT运维和开发人员可以与项目管理和业务分析师合作，以识别软件交付所涉及的所有流程中效率低下和浪费的领域。价值流映射在此领域可能会有所帮助，以可视化整个端到端过程。
技术
DevOps方法论的技术领域集中于一个主题：自动化。任何可以自动化的东西都必须自动化。这包括持续集成，基础架构即代码，自动化部署，测试，用户接受度等等。正如工业革命期间的自动化改变了行业和制造业一样，软件交付的自动化从根本上改变了软件交付的过程。
自动化任务使它们更具可重复性和可靠性。自动化测试是自动化带来巨大价值的一个领域。当关键时间早于发布日期时，测试通常会延迟，有时会完全跳过。自动化的测试过程使其可重复，并降低了成本。尽早进行测试的过程通常被称为“左移”，如将质量转移到软件交付过程中的最早步骤。
自动化还改善了一个关键指标：速度。速度本质上是软件发布的频率。较小的频繁发布要比较大的不频繁发布要好。这与另一个精益原则有关：小批量。当功能作为小更改的一部分发布时，它们的风险就较小。回滚和重新处理小的更改并不像回滚巨大，复杂的版本那样具有破坏性。
IT运维和软件开发团队最有能力专注于DevOps的技术领域。
DEVOPS如何落地?
DevOps可以提供工具来应对与软件交付相关的许多业务挑战。首先，组建利益相关者跨职能团队。围绕一小部分你认为可以用来解决DevOps的业务挑战，建立DevOps共识。这些挑战很可能属于DevOps支柱中的一个或多个支柱：文化，流程和技术。确定一个关键挑战，然后在最适合它的DevOps支柱的背景下进行构架。现在你可以考虑实施了。
关于实施，请从小做起。DevOps的改编是一项持续改进工作。采取科学的方法。不要尝试一次更改太多，否则会混淆实验。在问题，工具和表明改进的指标上达成一致。在这种情况下，“失败”不是灾难。正在学习。继续尝试进行一些小的更改，直到你看到要改进的目标为止。有了耐心，持久性和专注力，DevOps可能是适合你企业的工具箱。
