笔者有幸与100多家企业进行了交流。在这些讨论交流中，了解到“Phoenix Project”实施以来收获的经验教训，以及衡量DevOps是否成功的最重要指标。我们还了解到，对于企业领导者，DevOps可能很难实现。
我们在参加DevOps活动的企业领导者身上注意到一件事，他们在文化方面的困境往往超过其他任何方面。协调责任或分担责任、非指责性的事后调查、速度与稳定性的考量等各种概念都与他们过去学到的管理企业的原则相违背。他们意识到，是否具备更快提供软件的能力（通过新特性、新产品和新的上市途径）将对他们未来的业务带来巨大的影响，但他们很难找到一种语言或框架来与他们的团队（或同行）交流怎样才能具备这种能力。我们过于频繁地要求他们学习精益制造的语言或是W. Edward Deming传授的原则。虽然这些方法很有价值，并且可以在实体商品工厂和新世纪的数字工厂之间建立关联，但是在企业发生变革并稳定下来之前，他们仍将需要另一种学习曲线。考虑到这一点，我认为将一种流行的业务框架——Steven Covey的“高效率人士的7种习惯”进行适当的调整，将其转换为可以被企业领导者用来将DevOps文化融入到其企业中的一种模式，这将是很有帮助的。
1 积极主动
对行为、结果和增长负责。
让我们先来看一下IT行业中永恒的趋势——变化永不停歇。20年前，客户端服务器才刚刚开始发展壮大。10年前，iPhone才刚刚推出，AWS还只有2个服务。5年前，Linux容器用起来还过于复杂，网络规模的企业还不曾将重要的框架开放源代码。
过去50年中我们经历了巨大的变化，造就了某些技术企业在各自的行业中取得领先，也使技术市场成为今天最具价值的市场。对于企业领导者，至关重要的是认识到技术正在以更快的速度推动这种变化，并且需要积极主动地为下一轮改变做好准备。要主动迎接业务需要的改变。
2 以终为始
将时间和精力集中在可以控制的事情上。
没有哪个企业高管一觉醒来会说，“我们遇到一个DevOps问题！“ 相反，都是缩短新功能上市时间、降低安全风险以及到达他们底线的其他指标问题让他们睡不着觉。 这就是为什么我说过“将软件投入生产的信心”是最重要的DevOps指标。其核心正是以终为始——我们能否安全可靠地将软件投入生产？以此为出发点反向思考，以确定其可能发生的频率，从而对现有技能（人员）、管理部署频率的能力（文化）以及正确的工具和平台（技术）进行检查。
3 要事第一
先做最重要的事情。
一个从零开始的企业如何使“DevOps”成为他们默认的技术文化，说起来很容易，但实际上对于大多数企业来说并非如此。他们的组织图的优化针对的是过去的业务模式和分销策略。他们有许多应用平台，经常被用于不同的业务线。他们需要调整自己的应用程序，使其成为移动应用，以满足新兴客户的期望。
要事第一，在将软件快速部署至生产并取得业务成功之前，需要实现以下核心要素。
自动化 – 对于自动执行重复任务所需的技能和工具（例如Ansible），无论是针对应用程序还是基础设施，开发相关的核心竞争力至关重要。对于许多企业来说，开始时专注于现有应用程序（Linux和Windows）和基础设施（例如网络、存储和DHCP/DNS）很有意义，然后再发展到将新的应用程序和服务自动化。
CI/CD管道 – 正如工厂一直都是围绕着装配线建立的（自20世纪初以来），现代软件的构建都是由自动化管道驱动，它们可以集成源代码存储库、自动化测试、代码分析和安全分析。掌握管理管道的技能和频繁的软件更新的相关流程至关重要，因为这样就能拥有管理频繁更新的软件应用的框架。
应用平台 – 当应用程序创建后，就需要将其部署到生产环境中。在当今世界，客户希望频繁地更新软件（例如每周更新移动应用），因此重要的一点是有一种可以重复部署应用程序更新和扩展的方式，以满足应用程序的业务需求。管理应用程序的日常活动是应用程序平台（例如OpenShift）的作用。多年来，很多企业都试图建立和维护自己的应用程序平台，但这种方式正在迅速发生变化，因为企业意识到他们的增值是在应用程序而不是平台。
当这些要素都已满足后，许多IT团队就可以开始将其现有的先进应用程序容器化。
4 双赢思维
与他人有效并且高效地合作，以达成最佳效果。
很多时候，关于DevOps的讨论会造成开发和运营团队之间的紧张和脱节的局面。我经常将“开发人员推动新代码的速度”和“运营人员接受更新并确保生产环境就位的速度”之间的关系称为“ 阻抗失衡”。
在我们将所有问题都归罪为运营太慢之前，我们要先看看为什么开发人员会这么快速。从2017年DevOps状态报告中可以看出，Gene Kim（和团队）对速度进行测量的时间点是在开发人员将代码送至源代码控制时（例如Git、GitHub等）。
资料来源： Gene Kim； DevOps手册
他们没有测量设计和开发的速度。即使在微服务环境中，实际开发出软件功能也可能需要数周或数月的时间。
那么，团队如何能够获得双赢的局面呢？ 以下是一些建议：
对于运营团队，采用自动化工具（Ansible）和基础设施即代码原则（例如使用自动化游戏手册的源代码控制），开发和运营都开始使用常规的做法和流程。
对于开发团队，坚持要求安全人员纳入到开发过程和代码审查中。安全性不应该是一个最终的步骤，而是应该纳入到日常开发和测试中。
对于两个团队，应要求自动测试成为正常更新的一部分。虽然许多群体呼吁新应用程序应采用“云端优先“或”移动优先“策略，但他们也应该采用”始终自动化“策略。
5 知己知彼
在企业所有级别建立有效的沟通。
六、七年前，几乎每个CIO都表示，他们希望在运营效率方面尝试效仿网络巨头谷歌公司（每一名工程师负责1000台服务器），并对其开发人员和业务做出更多的反应。但遗憾的是，在硅谷之外很难找出能达到相同水平的企业。而且谷歌使用的技术并没有公开提供给这些CIO。但在过去几年中情况已经发生了重大变化。不只是谷歌（和其他网络技术巨头）通过开源项目实现高效率，其他类型的企业都取得了类似的成功（例如这家、这家、这家、这家、这家、这家等许多企业）。
因此，在CIO将一些架构师送到硅谷去向大师学习之前，了解类似公司的方法可能会更有价值。这可以使他们获得行业特定的、区域特定的和案例相似的经验。这也有助于回答“如果我们没有雇佣100多名博士级工程师或是年薪上百万美元的员工，我们该怎么办？”有时候正确的答案是利用大量的使用受欢迎开源项目的工程师。
6 统合综效
与持有不同观点的人进行创新及解决问题。
我经常说，在DevOps中取得成功所需的一切都是在一年级学到的。例如“与人为善”、“分享”、“礼貌待人“。在这方面我们面临的挑战是，为了实现这些基本目标，组织图和财务奖励（例如工资、奖金、升职）通常在开发团队和运营团队之间并不一致。康威定律在这里就很有用了。如果目标是具体的成果（例如更快地将软件部署到生产中），请确保组织模型不是实现此目标的最大障碍。为了实现这一点，想法的交叉传播至关重要。团队需要与其他团队分享他们的目标、挑战和资源可用性。
7 不断更新
在专业方面和个人方面不断完善和更新。
IT企业需要确保他们的团队保持最新的培训和新技能，这说起来很容易，可往往这一点会成为被忽视的预算外项目。满足“技能完善”需求的正确方法不是将其视为“培训”（例如参加课程、获得认证），而是将其纳入实际的工作活动中。我们正在进入IT时代，过去15到20年里所有稳定的规则和最佳做法都正在被重写和改变。因此，重要的是利用现代化的方式学习新技能（例如在线、云端、结构化的情境）。鼓励员工寻求最好的方式来学习（例如随项目学习、社交学习、在线学习等），然后让他们把这些新技能带回给团队的其他成员。让提高整个团队技能水平和技能多样性成为一个关键绩效指标，激励个人和整个团队向前发展。
7种习惯框架已经被证明可以成功地帮助个人和团队提高他们的人际关系技能。这些技能是任何文化转型的核心点。