写点什么

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

作者:Amanda Heintz

  • 2022-10-23
    北京
  • 本文字数:3479 字

    阅读完需:约 11 分钟

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 已死,平台工程才是未来

2022-10-23 08:008766

评论 3 条评论

发布
用户头像
sorry,我浅薄了,看了原文,我真的小瞧了物流公司了,我还以为只有施耐德这种500强电气公司才会玩这个
2023-01-30 19:17 · 北京
回复
用户头像
施耐德是法国的世界500强电气企业
2023-01-30 19:13 · 北京
回复
用户头像
施耐德怎么成了卡车物流公司了?明明是电气公司,施耐德就在望京,我每天散步都能从门口走过。
2023-01-30 19:11 · 北京
回复
没有更多了
发现更多内容

人民邮电出版社70周年庆暨异步社区8周年庆成功举办,和鲸Heywhale荣获异步社区“2023年度最佳合作伙伴”奖

ModelWhale

IT 数据科学 书籍出版 异步社区 人民邮电出版社

行业独家 | 腾讯云ES:PB日志查询大提速,自治索引查询裁剪详解!

腾讯云大数据

ES

第十五届全国交通运输领域青年学术会议,和鲸 Heywhale 携手龙船科技联合发布科研服务解决方案

ModelWhale

数据 服务 解决方案 交通运输 科研

云图说|分钟级构建业务大屏——Astro大屏应用

华为云开发者联盟

云计算 华为云 华为云开发者联盟 华为云云图说 华为云Astro

星河共创,开为科技加入飞桨大模型生态圈,共建营销应用新范式

飞桨PaddlePaddle

深度学习 飞桨 文心大模型

吴翰清《计算》重磅来袭,为了可计算的价值,写给所有人!

博文视点Broadview

AI系列产品来袭,用友招聘云换新上线

用友BIP

AI 招聘

合成数据对于机器学习模型至关重要

3D建模设计

人工智能 合成数据 虚幻合成数据

冯冠霖秘书长参加2023中国汽车软件大会并致辞

开放原子开源基金会

开源

赛题招募令:总投入超5000万元,诚邀您免费出题

开放原子开源基金会

基金会旗下铜锁/Tongsuo项目官宣密钥管理工具RustyVault正式开源

开放原子开源基金会

开源 铜锁

和鲸为神经计算建模及编程培训班提供支持,聚焦学术前沿,助力人才培养

ModelWhale

编程 培训 脑科学 建模 计算神经科学

华为云云容器引擎CCE产品文档带来4个升级,降低使用难度

华为云开发者联盟

云原生 华为云 华为云开发者联盟 华为云CCE容器服

TikTok 与 YouTube:哪个更适合您?

九凌网络

如何在HarmonyOS对数据库进行备份,恢复与加密

HarmonyOS开发者

HarmonyOS

国内首个电力物联操作系统正式发布,实现电力设备万物互联、海量数据互通共享

开放原子开源基金会

开源

外贸独立站谷歌seo优化的8大技巧

九凌网络

用友携手平安银行,加速数智化司库及财资体系建设

用友BIP

全球司库

合成数据的被需要的5 个重要原因

3D建模设计

人工智能 合成数据 虚幻合成数据

如何释放React Hooks的力量

树上有只程序猿

Hooks React Hooks

第二届开放原子开源基金会OpenHarmony技术大会圆满举行

开放原子开源基金会

开源 OpenHarmony

领跑中国APM市场,博睿数据蝉联第一!

博睿数据

运维 监控 可观测性

DevOps 在施耐德:众人参与其中的变革之旅_软件工程_InfoQ精选文章