【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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:008329

评论 3 条评论

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

如何使用ChatGPT自带插件

楚少AI

ChatGPT ChatGPT4 chatgpt插件

Nautilus Chain上首个DEX PoseiSwap即将开启IDO,潜力几何?

股市老人

Nautilus Chain上首个DEX PoseiSwap即将开启IDO,潜力几何?

威廉META

Nautilus Chain上首个DEX PoseiSwap即将开启IDO,潜力几何?

鳄鱼视界

mac高质量图像浏览处理软件 GraphicConverter 12 v12.0.3(6140)中文直装版

Rose

GraphicConverter 12中文 GraphicConverter破解 mac图像浏览器 GraphicConverter下载

流批一体数据交换 etl-engine 融合查询语法

weigeonlyyou

数据迁移 ETL 云数据迁移 Kafka ETL 流批一体化

Windows 高效应用快捷键

Andy

干货 | IDaaS 身份即服务背后的基石

Authing

Focus Matrix for Mac(智能任务管理器) v1.6.1激活版

Rose

Focus Matrix Focus Matrix破解 focus matrix mac激活版 智能任务管理器

Nautilus Chain上首个DEX PoseiSwap即将开启IDO,潜力几何?

EOSdreamer111

网络安全面试题大全(整理版)500+面试题附答案详解,最全面详细,看完稳了

网络安全学海

黑客 网络安全 信息安全 渗透测试 WEB安全

Nautilus Chain上首个DEX PoseiSwap即将开启IDO,潜力几何?

大瞿科技

Nautilus Chain上首个DEX PoseiSwap即将开启IDO,潜力几何?

西柚子

Nautilus Chain上首个DEX PoseiSwap即将开启IDO,潜力几何?

BlockChain先知

synchronized和Lock有什么区别?

javacn.site

Go 语言流行 ORM 框架 GORM 使用介绍

江湖十年

后端 ORM框架 ORM Go 语言 gorm

Microsoft Remote Desktop下载,微软远程连接工具

Rose

microsoft remote desktop 微软远程桌面连接工具 mac远程链接

阿里大佬带你一周刷完Java面试八股文,比刷视频效果好多了!

Java你猿哥

Java 分布式 微服务 JVM ssm

来聊聊才离职就被拉黑禁用的这些事

HoneyMoose

怎么看阿里拆中台这件事

agnostic

中台架构

Xcode for Mac(开发工具)v14.3.1正式版

Rose

Xcode Mac版 Xcode中文版 Xcode破解版

Github标星78k,Alibaba最新发布的Spring Boot项目实战文档!太强了

Java你猿哥

Java spring Spring Boot mybatis ssm

从0到1:活动报名小程序开发笔记

CC同学

C语言编程-typedef

攻城狮Wayne

MongoDB源码学习:原子操作WriteUnitOfWork

云里有只猫

mongodb 源码刨析

开源字节 考研集训营小程序

源字节1号

开源 软件开发 前端开发 后端开发 小程序开发

授权码 + PKCE 模式|OIDC & OAuth2.0 认证协议最佳实践系列【03】

Authing

OIDC PKCE

Github百万收藏!这部《从零开始写分布式服务框架》称霸榜首!

Java你猿哥

Java 架构 分布式 ssm 分布式框架

模块七作业 - 王者荣耀商城异地多活架构设计

🐢先生

架构实战营

设计模式之不一样的责任链模式

越长大越悲伤

Java 设计模式

【1对1咨询】前端和后端,哪个更简单?转行程序员的捷径

程序员晚枫

前端 后端 转行

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