大多数人都难于沟通DevOps的文化和期望的结果，解决办法是使用本指南。
对于IT领导者来说，DevOps的哪些方面构成了最大的挑战？正如我在DevOps手册的作者Gene Kim，最近的一个系列活动中与数百位领导人讨论的DevOps一样，我听到了一个清晰的答案：这就是文化的变化。混合或分担责任的概念，无可指责的事后分析，以及速度与稳定性，往往与你所教授的指导原则背道而驰。你意识到未来的业务将高度影响你更快地交付软件的能力(通过新功能、新产品和新市场路线)，但你很难找到和你的团队交流的语言或框架(同行)如何实现DevOps和这些结果。
我们经常要求IT领导人学习精益生产的语言或W. Edward Deming教授的原则。虽然这些方法是有价值的，并且可以在实物商品的工厂和21世纪的工厂之间进行平行分配，但在组织变革发生之前还需要另一条学习曲线。
因此，考虑到这一点，我认为将一个流行的业务框架，Steven Covey的“高效人员的七种习惯”调整为一种可供企业领导者试图将DevOps文化引入其组织的模式是有益的。 让我们来看看这是否能帮助你解决你的困境。
1.积极主动
让我们从IT中不断变化的人开始：不断变化。如果你20年前开始，客户端服务刚刚开始发展。如果你十年前开始，iPhone几乎没有被引入，AWS有两个服务。如果你五年前开始使用，Linux容器的使用过于复杂，网络规模的公司并没有开放采购重要的框架。
过去50年来，我们看到了哪些公司领导各自行业的巨大变化，以及哪些细分市场是最有价值的（提示：今天是技术）。企业领导者必须认识到，技术正在以更快的速度推动这些变革，并积极准备迎接下一轮变革。成为业务需求的变革推动者。对行为，结果和成长负责。
2.从头开始
没有一位业务主管会醒悟，并说：“我们有DevOps问题！”相反，你会因为缩短新功能的上市时间而降低睡眠时间，降低安全风险以及其他可能与顶线或底线直接相关的指标。 这就是为什么我相信“将软件投入运行的信心”是最重要的DevOps指标。
这个指标的核心是从头到尾：我们能否安全可靠地将软件投入生产？ 从那里开始，你可以反向研究这种情况发生的频率，从而检查现有技能（人员），管理部署频率（文化）的能力，以及是否有适当的工具和平台（技术）。把时间和精力放在可以控制的事情上。
3.重要事情放在首位
你需要执行最重要的业务优先事项。虽然很容易想象，一个组织会怎么做才能使“DevOps”成为默认的技术文化，但实际情况是，这对于大多数组织来说并不是现实。他们的组织结构图针对昨天的商业模式和分销战略进行了优化。他们有很多应用程序平台，往往不同的业务线。他们需要调整其应用程序，使其成为移动原生应用程序，以解决新兴客户的期望。
首先要做的事情是，这些核心要素必须到位，才能使企业迅速将软件投入生产。
自动化，在应用程序和基础架构的自动化重复性任务所需的技能和工具中建立核心能力至关重要。对于许多公司来说，开始专注于现有的应用程序（包括Linux和Windows）和基础设施（如网络，存储，DHCP / DNS），然后发展到自动化新的应用程序和服务是非常有价值的。
CI / CD管道 ，就像工厂（自20世纪初以来）围绕装配线建造一样，构建现代软件的过程是由集成源代码库，自动化测试，代码分析和安全分析的自动化管道驱动的。管理管道和围绕频繁软件更新的过程的建立技能对于构建管理经常更新的软件应用程序的框架至关重要。
应用程序平台，应用程序一旦建成，就需要部署到生产环境中。在当今世界，客户希望经常更新软件（例如，每周更新手机应用程序），因此重复部署应用程序更新和扩展以满足应用程序的业务需求至关重要。管理应用程序的日常活动是应用程序平台的角色。多年来，公司试图建立和维护他们自己的应用平台，但是这种方法正在迅速变化，因为公司意识到他们的增值是在应用中，而不是在平台上。
一旦这些元素到位，许多IT团队就可以开始容纳现有的和现代的应用程序。
4.思考双赢
DevOps的讨论经常被视为开发和运维团队之间的紧张和脱节。我经常把它称为开发人员推动新代码的速度与运营商可以接受更新的速度之间的“阻抗不匹配”，并确保生产环境已经准备就绪。
在我们把操作上的所有问题归咎于太慢之前，重要的是要看看为什么相信开发者如此之快。从2017年DevOps状态报告中，我们看到Gene Kim（和团队）在开发人员将代码推送到源代码控制（例如Git，GitHub）时测量速度。
他们没有衡量设计和开发的速度。即使在微服务环境中，实际开发软件功能也可能需要几周或几个月的时间。
那么团队如何才能达成双赢的局面呢？这里有几点建议：
对于采用自动化工具和基础架构即代码原则的运营团队（例如使用自动化剧本的源代码控制），开发和运维都开始使用常见的实践和流程。
对于开发团队来说，坚持把安全人员嵌入到开发过程和代码审查中。安全不应该是一个流程结束的步骤，而是嵌入在日常的开发和测试中。
对于这两个团队来说，要求自动化测试成为正常更新的一部分。尽管许多组织为新应用程序宣传“云优先”或“移动优先”政策，但他们也应该采用“自动化永远”政策。
5.先求了解，然后理解
六七年前，几乎每个CIO都表示，他们希望在运维效率（每个工程师1000台服务器）方面尝试和模拟像Google这样的网络规模巨人的产出，并且对开发人员和业务更加敏感。不幸的是，当时很难找到硅谷以外的公司可以实际执行类似水平的例子。 Google使用的技术并没有公开。但是在过去的几年中，时代发生了巨大的变化。 Google的技术（例如Kubernetes）不仅可以通过开源项目轻松获得，而且实现类似成功的企业公司的例子也非常丰富。
所以，在你派出几位架构师到硅谷学习大师之前，对你自己的公司进行类似的研究可能更有价值。这将体现特定行业，特定地区和用例相似的经验。这也将有助于回答这样的问题：“但是，如果不聘用100多名博士级工程师，或者100多万名带薪员工，我们怎么能这样做？”有时候，正确的答案是要利用广泛开发流行开源软件的工程师项目。
6.协同
我经常说，一个人需要用一年级学到知识来帮助DevOps中取得成功。 例如，“和他人一起玩”，“分享”和“用你的举止”。挑战在于开发团队和行动团队之间的组织结构图和经济激励（如薪酬，奖金和晋升）往往不一致 为了完成这些基本目标。
康威法则的一些知识派上用场。 如果目标是特定的产出（例如更快地将软件部署到生产中），确保组织模型不是实现目标的最大障碍。 思想交叉传播变得至关重要。 团队需要与其他团队分享他们的目标，挑战和资源可用性。 你想创新和解决问题的人有不同的观点。
7.多实战
很容易说，IT组织需要确保他们的团队掌握最新的培训和新技能。 但是，往往这成为一个有时会被忽略的预算项目。 解决“技能提升”需求的正确方法不是将其视为“培训”（也许参加课程，获得认证），而是将其纳入实际的工作活动中。
我们正在进入一个IT时代，在这个时代，所有在过去15到20年里都保持稳定的规则和最佳实践正在被重写。 这意味着利用现代方式学习新技能是至关重要的。 鼓励员工寻求最好的学习方式（比如项目，聚会和在线学习），然后让他们把这些新技能带回到团队的其他部分。 将其作为关键绩效指标来提高整个团队的技能水平和技能多样性，激励个人和整体团队变得更好。 底线：寻求专业和个人的持续改进和更新。
讲故事的重要性
7习惯框架已被证明是成功地帮助个人和团体提高人际交往能力。 这些技能是任何文化转型的核心。
除了7种习惯之外，还应该在每个领导者的脑海中再加一个技能。 IT领导者推动转型的最重要的技能之一就是能够讲述成功和变化的故事。 讲故事的技巧可以激发情绪，并有助于从小组传播成功。 讲故事也有助于团队个性化挑战，并适应解决方案，以适应群体的特殊文化差异。
