高效 DevOps 的7个习惯

很多人在 DevOps 文化和目标导向上过度纠结。请使用这个指南。

如果你问IT行业的高管，DevOps 对你的工作挑战最大的是哪方面?最近和 DevOps 手册的作者 Gene Kim 一起访谈了数百位高管后，我听到最响亮清晰的回答是:文化挑战。融合的概念、共享责任、无问责检查、还有(交付)速度与稳定性，经常挑战了这些IT领导者们长期被灌输的原则。

当你意识到更快交付软件的能力将高度影响你未来的生意，(通过新特性、新产品、 新的市场进入路径)但你同时挣扎在无法找到一种语境或者框架来与团队和同事们沟通——如何实现 DevOps?如何达成目标呢?

每次都是老生常谈，我们要求IT界的高管们学习精益制造的语言或者 W.Edward Deming 教导的原则。在实体工厂和21世纪的比特工厂(软件业)之间，似乎存在一条平行线。虽然工业的指导原则是有价值的，但要想在组织的产生变化和实行起来，他 们(IT)还需要另一条学习曲线。

所以，我认为将一种流行的商业框架——《高效能人士的7个习惯》应用到想要转型 DevOps文化的组织里，会是一种有效的模型。让我们看看它是否能解决你的沟通困境。

1、积极主动

让我们先拥抱一个IT行业不变的事实:唯一不变的就是变化。如果你20年前入行，客户端-服务器模式刚刚进入主流。如果你10年前入行，几乎没人看得上 iPhone，AWS 只有2项服务。如果5年前入行，Linux 容器仍然过渡复杂难用，大型互联网公司也没有开源重要的框架。

无论行业里多么令人尊敬的企业，无论创造过多大价值的细分市场，过去50年(它 们)发生了翻天覆地的变化，如今都是科技的天下了。商业领袖必须认识到科技正以超越以往更快的速度驱动着变革，而且在下一轮变革中，我们必须积极主动拥抱变化。商业需要对行为、对结果、对增长负责的改革领袖。

2.以终为始

没有业务负责人睡醒了说，“我们有个 DevOps 问题”。相反，为了新功能及时上线，降低安全风险，你常常牺牲了睡眠时间，更不要说完成那些和高层或底层挂钩的业务指标了。这就是为什么我相信“发布到生产环境的信心”是DevOps实践的最重要指标。

问题的核心是在头脑中以终为始考虑问题:我们能将软件安全稳定地发布到生产环境 中吗?从那一刻起，多久考虑一次这个问题，其中哪一项正考验着我们的现有能力 (人的因素)，管理部署频率的能力(文化因素)，是否有合适的工具和平台(技术因素)。把你的时间和精力集中在可控的事情上吧。

3.要事第一

把执行力聚焦在最重要的商务要事上。尽管想象中空白文化的组织采用 DevOps 文化是很容易的事，现实是对多数组织来说是不能马上实现的。它们的组织架构是为过时的商业模式和分销策略优化的。它们有太多应用平台，各平台为不同产品线独立运营。而且它们需要将应用移动化为了适应客户紧急需求。

要事第一是指核心元素需要在商业预期成功前到位，例如快速部署软件到生产环境。

• 自动化 —— 需要核心构建的能力是自动化实现重复性任务，既包括应用层，也 包括基础设施层。对很多企业来说，聚焦在现有系统(Linux和Windows)和基础 设施(例如带宽、存储、DNS上)上更有价值，其次才是新应用和服务的自动化。
• 持续集成/部署的流水线 —— 就像19世纪的工厂建立起了组装流水线一样，驱动 当代软件业的流水线需要集成代码仓库、自动化测试、代码检查和安全分析功 能。为了满足软件持续迭代的需要，构建起管理流水线能力和流程的一整套框 架是至关重要的。
• 交付平台 —— 一旦编译构建完成就，就需要部署到生产环境。当今世界，客户 要求软件迭代更频繁(例如移动应用的周更)，所以通过重复性的方式部署应 用更新和规模化满足客户需求就十分重要。管理每日众多应用的不同任务，是 交付平台的事。多年以来，许多公司试图打造并维护自有的交付平台，但当它 们意识到只是快速增加了交付的能力，而非平台的能力。

一旦这些要素到位，许多IT团队就着手开始容器化他们的新旧应用了。

4.双赢思维

关于DevOps的讨论太多集中在开发和运维团队之间的紧张和疏离关系上了。我通常称之为开发提交新代码的速度与运维接受更新和确保生产环境就绪的速度之间，发生了“阻抗不匹配”。

在我们把所有问题怪罪于运维太慢前，审视一下为什么我们认为开发太快了是很有必要的。从2017年度 DevOps 状态报告中，我们看到 Gene Kim 和他的团队度量了开发者提交代码到版本控制软件的速度。

他们并没有度量设计和开发过程的速度。即使采用微服务架构，开发新特性实际还需要几周甚至数月时间。

那么团队如何营造潜在的双赢局面呢?这有一些建议:

• 对于采用自动化工具的运维团队，开发和运维要开始使用通用的实践和流程。
• 对于开发团队来说，要坚持安全人员嵌入到开发流程和代码检查中。安全不是流程的最后一步，而是在每日的开发和测试中。
• 对两个团队来说，需要将自动化测试变成日常迭代的一部分。当很多公司的新产品开始采用云优先或者移动优先的策略时，他们也该拥抱“经常自动化”策 略。

5.知己解彼

大概6、7年前，几乎每个 CIO 都想尝试评估互联网巨头的运维效率，例如Google一人 管理一千台服务器，对于开发者和业务响应更好。很遗憾那时硅谷很难找到达到类似层次的企业样板。Google 的技术(例如Kubernets)也不是公开的。但过去几年发生了显著的变化，不仅 Google 的技术开源了，能达到同样层次的企业样板也多如雨后春笋。

与其把架构师派往硅谷向大师学习，向同类公司学习更有价值。这会提炼出特殊行业、专业领域和相似公司的案例经验。这将给那些雇不起100个以上博士级工程师的公司们一个有力的回答。有时恰当的答案就在撬动一大票正在为流行的开源项目工作的工程师们身上。

6.协同

任何想在 DevOps 中取得成功的人，他们需要从一年级开始学习。例如，“”和别人合作愉快”、“分享”、“礼貌”。挑战来自于开发和运维的组织架构和财务动机在这些基本目标上常常没有对齐。

这里有一些柯维原则奉上。如果目标是明确的产出(比如更快部署软件到生产环境) ，确保组织的模型不是完成目标的首要障碍。互相渗透的理念十分重要。组织之间需要共享目标、挑战和资源可用性。你要和不同观点的人一起发现并解决问题。

7.不断更新

IT组织需要确保他们的团队在培训和新技术上紧跟潮流，这种话说来容易。但这事变成预算忽略的项目太司空见惯了。正确的方式是宣布技术提升的需求作为实际工作的需要，而不是考虑作为培训(例如报门课程，拿个证书)

我们正在步入一个过去15-20年IT行业的成功的原则和最佳时间被颠覆的时代。这就意 味着利用现代方式学习新技能变得至关重要。鼓励员工追求最好的学习方式(例如副业、聚会、在线学习)，并将这些新技能教给团队其他人。为整个团队设置一个技术等级和多样性提升的KPI吧，鼓励个体和团队向上进取。底线:在专业化和个性化方 面可持续的发展。

END