DevOps 在施耐德：众人参与其中的变革之旅

为什么施耐德决定走向 DevOps

要想真正认识到DevOps在施耐德的发展，我们需要先了解为什么施耐德会对 DevOps 有需求。

施耐德（Schneider）是北美一家大型卡车运输和物流公司。和许多现代企业一样，施耐德逐渐将其业务转向电子化，其应用程序的开发、部署及管理都是维持公司业务运转的重要资产。

在应用 DevOps 之前，每个基础设施和应用程序都是零散的孤岛。或许你会对此感同身受，将所有的服务器、应用程序、技术等等都当作是独立独特的“事物”，都需要热爱它们的特定人群来关爱这些应用。除此之外，施耐德还应用了瀑布式项目管理方法，将项目分为不同且连续的阶段，每个新阶段只在前一阶段完成后才会开始。

这些都曾是，或者说在某些情况下，仍是当前项目管理最传统的方法。 可以说，这样的项目管理效率并不高，通常需要几个月甚至更长的时间才能为企业带来价值。

这种方式也有其相应的挑战点：

• 需求不明确，分析瘫痪，畏于结束当前阶段，以致无法进入下一阶段

• 需求变更代价愈发高昂

• 项目耗时长久，提高失败风险

• 追赶进度时首先被牺牲的是测试时间

• 大部分项目都无法按期准时交付

随着对业务需求快速响应的要求迫在眉睫，2015 年施耐德还只是零星应用敏捷，2016 年施耐德的技术部门已经完成了全面的敏捷转型。但业务运转的速度仍然不尽如人意，敏捷优化了工作计划和优先级，也利用了仪式感，但到了测试和代码交付方面却仍是磕磕绊绊，因为这些流程依旧没有任何变化。快进到 2017 年，DevOps 这个词已经成为了施耐德的流行词，是人人都在谈论的话题。鉴于 DevOps 的流行程度，人们开始猜想，像是施耐德这样的运输公司为什么要采用 DevOps？是因为这东西很新潮，很酷吗？是人云亦云还是想解决实际问题并带来真正的影响？

与此同时，施耐德还有另一项构建实施新应用的大工程在进行中。施耐德借着这次机会，将参与工程的所有团队和任务都真正进行了可视化处理。以往都是由团队自行掌握工程进度，并不透明，从而导致外界很难真正认识到项目的工作量、参与团队以及交接事项。

为提高透明度，施耐德组织了一次演习，测试在环境中部署一个应用程序所需要的团队数量和工作量。这次演习的结果令人大开眼界，也正式推动了施耐德转型的开始。这次演习回答了以下这些问题：

1. 如何在不额外增加如人员数量等资源的情况下完成更多工作？

2. 如果提高效率？

3. 如何让开发人员尽其所长，为企业创造更高质量的价值？

4. 如何快速应对市场变化，保持竞争力？

变革的理由

让我们回到开始，对部分主要影响因素或根因进行分析，了解施耐德的产品交付质量和速度提升背后所采取行动的必要性。这些影响因素涵盖了大量跨团队、跨环境的工作磨合，解释了为何工作流程不透明和缺乏自动化等因素会造成工作不一致和低效率等问题。

在实践中，我们会尽可能展示当前项目状态的指标，并显示可能影响指标的因素。此外，引入利益相关者针对价值的意见，对能否成功达成预期功能非常重要。而施耐德的技术部门全力支持我们的转型也有很大帮助。

最重要的是，无论现况多么糟糕都要说出你的故事，掀开遮羞布、暴露出原始数据。尽管这个过程可能会让人有些不适，但这对推进变革是绝对必要的。花时间让变革不那么正式且具有实际意义，让人们能轻松参与其中。达成这点的最好方法是抛弃那些僵硬的模板，像故事一样设计转型案例，使出看家本领来宣传。利用简短的动画而不是枯燥的电子邮件或是一张 PPT；定期组织非正式全体会议来收集反馈，听取人们的对你要做、想推销的事的想法；为不习惯公开发表正式反馈的人们提供匿名问卷调查，类似的手段有很多，跳出思维局限，让你的转型变得更加有趣。

人人参与的变革

协作是需要重点关注的。我们首先着眼整体技术部门，明确关键影响因素及创建跨职能团队来推动转型的关键决策人。在他们的帮助下，我们得以获取技术部门下所有团队的输入、反馈和协调关系。此外，我们还成立了由技术主管组成的指导委会，这两支队伍都高度参与了整个转型过程。

以下是我们使用的一些策略：

• 通过不记名调查定期收集反馈；在转型案例和其他领导层演讲中引用调查反馈中原文，并以此作为转向过程中的整体基准线。

• 在新流程开发、概念论证及结果展示中，邀请技术部门经理、主管及其他同事共同参与。

• 定期开展学习和合作会议，概述下一步变动，收集当前反馈，并就原因、影响及收益展开公开且开放的讨论，回答“这对我有什么意义？”的问题。

以下是我们在选择应用自动化发布工具集时收集到的部分反馈原文：

下图是用于学习会中的一页 PPT：

在施耐德的转型中一个非常重要的点在于，作者并不是推动这项工作的唯一发言人。技术部门上下有足够多的人拥有同样的热情，他们作为这项转型的倡导者，会时不时在与领导的一对一会议上、和同僚的对话上、走廊闲聊中，或者其他与领导层的重要会议上提及这个话题。

一路以来的坎坷

施耐德的 DevOps 转型是非常成功的，这一过程也教会了我们很多。我们不断向前迈步，但在某些情况下，也不得不暂时后退。

例如，我们的目标之一是通过技术，然后是应用，有一个共同的部署过程，但要避免阶梯式。这在某些情况下说起来容易做起来难。当我们开始研究多个团队使用的技术时，我们发现他们在开发和部署这些应用程序的方式上有一些大的差异，但大多是小的。对于我们的一些老技术来说，为了达到一个标准而投入大量资金重写或重新配置这些应用程序，其实是没有意义的。在可能的情况下，我们围绕一个标准进行调整，在某些情况下，专注于将该标准应用于未来的一切新事物，并在稍后回来重新评估现有应用程序。最重要的收获是，我们学习、改进，并将继续这样做，不管一项工作是否被称为 "DevOps"，而且进步就是进步。改变不会在一夜之间发生，但在正确的方向上迈出一小步仍然是一种成功。

归根结底，变革是困难的，如果没有领导的支持，没有专门的时间让开发人员真正消化 "这对我意味着什么？"和 "我的工作如何改变？"以及持续的强化和对话，要取得成功将是一个挑战。

我们在旅途中所学到的东西

有几个关键的经验，可能看起来很简单，但我觉得非常值得注意。

1. DevOps 不是黑白分明的。你可以阅读关于如何做 "DevOps "的书籍和文章，但现实是，这可能不适合你的组织。DevOps 是否意味着精简？DevOps 是否意味着改变文化？DevOps 是否意味着实施一堆你一直想做的新技术或酷技术？这看起来很简单，但是要定义 DevOps 对你的组织意味着什么，然后把这个定义贴在走廊上，在每次谈话中提出来，并确保每个人，如果被问到 DevOps 对组织意味着什么，都会做出同样的回答。

2. DevOps 和 Scope Creep 是同义词--总是回到你的 DevOps 转型的 "原因"，并把你的目标和目的作为你的真正方向，在你开始的时候验证你的进展。

3. DevOps 何时完成？这是我经常被问到的问题，现实是 DevOps 永远不会完成，但我认为很多人没有谈论的是，这种正式的努力或旅程何时会成为我们工作的方式？我们什么时候才能停止玩弄花招，把这些理想和价值观融入我们的日常工作中？而当你达到这一点时，下一个问题是你如何最好地做到这一点？... 最后一个问题是我们仍在努力回答的一个问题!

应用 DevOps 的方法

我想为那些正在考虑应用 DevOps 的人提供以下两点建议。

1. 我们一定要叫它 DevOps 吗？想想这个问题，以及过去在你们的技术部门中引起如此骚动的所有其他流行语（*cough* 敏捷）。这些流行语是如此沉重，而且在一些组织中，伴随着巨大的猜测，特别是在某些级别的领导。当这些流行语变得沉重时，预算、所需资源、实施、形式等等也变得沉重。它需要如此沉重吗？它需要如此正式吗？在某种程度上是的，但我诚实的建议是，围绕你要实现的目标，创造你自己响亮的品牌形象。我不想承认我们花了多长的时间来协调和达成 DevOps 的定义。如果它不是一个朗朗上口的流行语，也没有大量的猜测，我真的相信我们所经历的旋风有一半会被消除，并且会更容易实现统一。

2. 在技术领域，我们经常花很多时间考虑如何营销我们正在开发或改进的产品，但当涉及到为技术而技术时，我们真的根本没有营销。营销科技产品，也就是营销你的技术组织用来为企业提供价值的技术、流程和实践，是非常重要的。没有人希望再收到一封无聊的电子邮件或文件，向他们介绍即将发生的变化。在你的技术部门内推广流程、工具集等方面的变化，不仅会引起人们的兴趣，也会增加人们的认同感，让人们兴奋地与他们的同事和经理谈论他们是多么期待这些变化，也会让人们参与进来，提出问题，并提供反馈。把你的技术部门看作是一个社区，花大量的时间制定一个计划，向这个社区推销你的 "DevOps "产品、流程和更多的东西--你不会后悔的!

原文链接：

Article: DevOps at Schneider: a Meaningful Journey of Engaging People into Change

相关阅读：

DevOps 已死，平台工程才是未来