众人参与其中的变革之旅 在施耐德 DevOps (众人参与的成语)

为什么施耐德决定走向 DevOps

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

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

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

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

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

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

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

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

变革的理由

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

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

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

人人参与的变革

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

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

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

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

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

一路以来的坎坷

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

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

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

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

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

应用 DevOps 的方法

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

原文链接：

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

相关阅读：

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