[关闭]
@Rays 2018-07-08T07:56:39.000000Z 字数 4757 阅读 2101

跨越业务与技术间的鸿沟:与UBS、LBG和ITV人士的对话

DevOps


摘要: 在今年的DevOps Enterprise Summit伦敦大会召开之前,InfoQ主办了一次由IT Revolution赞助的视频研讨会。研讨会特邀了三位DevOps Enterprise Summit的演讲者,分别是:UBS的Jelena Laketic、Lloyds Banking Group的Mark Howell和ITV的Tom Clark。本文是对研讨会发言情况的总结。

作者: Helen Beal

正文:

在今年的DevOps Enterprise Summit伦敦大会召开之前,InfoQ主办了一次由IT Revolution赞助的视频研讨会。研讨会特邀了三位DevOps Enterprise Summit的演讲者,分别是:UBSJelena LaketicLloyds Banking GroupMark HowellITVTom Clark。下面给出研讨会发言情况的总结。

InfoQ: TargetAlaska AirDomino's Pizza等一些组织站出来宣称自己是一家科技企业。各位是否认为自身所在的企业也是科技企业。

Mark Howell:我们(即UBS)虽然以英国零售银行的品牌而闻名,但却聚焦于技术。企业近期更多地聚焦于工程品牌。在刚刚完成的战略重组中,企业具有了一个以工程为品牌的工程功能。在当前的环境下,技术正在吞噬世界,我们必须全力以赴地保持领先。对于Monzo和Facebook等企业而言,我们所具有的250年品牌历史毫无意义,它们想要从我们这里分一杯羹。

Jelena Laketic:瑞士已有多家银行实现了相当程度的数字化,我们(即Lloyds Banking Group)一直在努力做得比同行更好,保持在全球业务中的领先地位。当前,技术是我们唯一的依靠方式。对于我这样一位软件工程师当然如此,但是能看到技术变得如此重要,这依然是一件十分美妙的事情。为了在未来占有一席之地,即便是那些并不被人们看成是科技企业的公司,也必须成为一家技术企业。

Tom Clark:ITV很早就经历了金融危机。对我们来说,那是一个非常困难的时期。因为在当时,我们95%的收入来自于电视广告。金融危机期间,那些打广告的企业收紧了预算,因此我们不得不做出一些非常艰难的决定,即部分裁减和缩支。为了挽救公司,我们的确削减了系统中的一些松懈和不实之处。现在我们挺了过来,比以往任何时候都更强大。由于采取了一些精简措施,企业得以在同等收入下增大了利润。但我认为,我们在这个过程所失去的是那些松懈之处,以及那些可以停下脚步考虑未来五年发展的空间。如果你不做自我反省,那么别人就会令你反省。

自1955年成立以来,ITV一直是一家广受欢迎的商业广播公司和制作企业。但是我在ITV工作期间,Netflix已经从一家DVD提供商成长为世界上最大的媒体制作商和流媒体服务公司之一。ITV存在很多遗留系统,很多业务正在慢慢消亡,但这些新兴技术企业却没有这样的问题。我认为这就是为什么我们要谈论DevOps、谈论敏捷性的原因所在。我们谈论这些技术的好处在于,这意味着当一些新兴技术企业出现时,我们实际上可以推动我们的业务,并说:“好吧,我们需要转向,我们需要这样做,我们需要更好地做到这一点“。

InfoQ:各位在时间和预算上是否达成了业务所需的承诺,或是正在推进中?

Howell:我们是一家大型组织,我们力图转向于此。我们正试图为经营权继续提供资金。因此,我们将在某个地区投资部分资金、获取部分价值,并收益更多的资金。在这样的推进过程中,我们需要对第一笔用于做实事的资金有一点信心,但在投资中必须确保这笔资金将为企业带来价值。这对企业来说是真实的,因为它要回答“这究竟对我有什么用?”的问题。最终,一旦这个问题得到解答,将会在组织中树立可信度和股票价值,最终为企业提供运营许可并继续推进。

Laketic:在每一天结束时,人们都希望能看到自身从中受益。我们会随着企业自身的发展而建立自己的信誉。我们受到信任,是因为我们提供的业务别无二家。之后,我们证明了我们可以实际完成交付,并且我们就是人们所需要的技术专家。我们一直在从事黑客马拉松的业务,现在人们对我们的看法不再是我们要休息两天,而是希望我们有更多的休息时间。“哦,我们支付了两天的工作,竟然收获了这么多?”

InfoQ:各位有没有碰上一些业务尚未真正开展、但的确具有挑战性的事情?

Laketic:有时在开始快速推进之前,你必须要将脚步放得非常慢。如果这样做,你将会带领更多人员加入,使他们相信你的前进目标。在向人们展示我们的长期事业之前,我很高兴能有一段时间放慢自己的脚步。

Clark:我认为“20-60-20”就是这样的事情。当你想要做出改变时,有20%的人员完全会直接加入你的行列。这些人将真正喜欢你的主意,真正想要支持它。中间的60%会保存沉默的。他们想要当骑墙派,静观事情如何发展。此外还有20%的人非常抵触,他们立场坚定地反对你,不想要做出改变,因为他们对新事物充满恐惧。通常,人们总想要聚焦于抵制变革、充斥杂音的20%。但我认为,我们是否可以做通中间60%的工作,这样就有80%的人支持你。对于拖后腿的20%,要么争取到他们,要就干脆放弃他们。

Howell: 我们想要在组织内发展的文化就是这样的事情,它可归为组织内的人员和信仰体系,包括我们与合作伙伴打交道的方式。我们一直致力于建立人与人之间的关系,并允许人们以不同的方式获得许可。从那时起,我们逐渐看到了改变心态和以身作则的真正优点所在,因为人们喜欢看到一些加入改变和以不同方式做事的实例。没有人喜欢繁文缛节,没有人喜欢挫败感,这最终归结为对获得许可的要求。企业不再是一个孤立(siloed)的组织。我们希望人们能直接相互交流,最终将合适的人员纳入到团队构建中,以便他们能够以更高效和快捷的方式实现改进。

InfoQ: 按Simon Sinek的说法,各位是否具有一些文化资产、组织层面的“为什么”问题,或是对组织目的的描述?

Howell: 作为一家银行,从组织层面看,我们的使命就是为英国的繁荣发展提供帮助。当我为企业的18000名员工介绍DevOps时,我会使用一些已定义的关键信息,并给出这些信息在Lloyds Banking Group中的具体含义。我们知道,如果你提问十个人,那么你会得到十二种定义。所以我将对话围绕着“为什么”、“如何做”以及“是什么”的框架展开。其中,“为什么”相关问题是希望帮助员工安全、可靠、快速地交付技术和改进。然后据此驱动“如何做”以及“是什么”的问题,即我们将如何做到这一点,以及我们将如何实现它。我们正在建立一个标准,以便我们能同舟共济时,可对我多年来开发的这些神秘事务具有同样的观点,并具有可识别的内容。

Clark:回顾历史,技术只是推动者和成本中心。现在我们按ITV的理念共事,同时技术本身也在努力发展出自身的内部文化。ITV曾有五个业务部门,在各个业务部门间技术方法是相当孤立(Siloed)的,刻意的且不适当的孤立。在部门内部非常好的一件事情是,技术与我们的业务非常接近,因为各部门看到了比以往更多的技术。当前我们面临的挑战是,我们的技术结构终究还是略显分散。现在,我们需要确保各部门能保持一致,同时也能与业务保持一致,这需要一种矩阵式管理。这种结构曾经颇受非议,现在似乎已经完全重新轮回,我们正在研究如何按适合我们业务部门和技术功能的方式,将这种矩阵结构应用于21世纪。

Laketic:我们花了一段时间才掌握了这种矩阵结构。我已经看到,随着时间的推移,我们尝试首先采用更多的池式IT管理方式将IT与业务联系起来。将技术用于整个企业中的同时,朝着目标努力,这种组合是最有效的。

InfoQ:对于了解客户想要交付什么,以及客户需要的具体内容,为缩短这一过程的时间,各位采取了哪些做法?

Laketic:就我们而言,我会将所有人、业务代表和技术代表召集在一起,让大家畅所欲言开展讨论,提出想法,确定实现想法所需的努力。 如果你将所有人召集在一起,那么不仅实现了一次交流,而且每一方都可以告诉对方自己想要的是什么,以及如何实现这一目标。

Howell: 我们的组织遍布全球,我们使用离岸供应商,因此让人们聚在同一房间并不容易。所以我们一直在做的是,围绕价值流观察我们的可交付产品。这里并非是项目价值流和程序价值流,而是抵押价值流究竟是什么(例如,我们出售的产品)。然后我们尽可能让业务贴近交付,这可使我们具有抵押价值流的产品负责人,由其定义和优先排序,进而与工程负责人开展合作,在敏捷的场景中切实率先解决最近积压(backlog)问题。我们使用MVP方法,将每隔一周做一次Sprint,交付一些商业价值,让各个角色间更紧密地相互合作。

Clark:从历史上看,我们曾存在许多不同的孤岛(silo)。CTO在大约四五年前开始了一项大规模的现代化计划,通过产品团队从上到下转向敏捷,该计划现在即将结束。我们为团队提供了一个空间,如播客安排,人才支付或灯光,并说:“这里是产品负责人”。产品负责人有时是来自我们的业务人员,有时来自于技术人员。各团队像小型创业公司一样运营,并与整个投资组合保持一致的路线图,但管理着他们自己的路线图和自己的积压工作(backlog),在整体上作为一个自给自足的单位运作。从历史上看,全部内容都有一个非常大的共享基础架构。如果有人想要做出更改,那么他必须做一些协调,包括必须去CAB、必须得到许可,以及必须做出提问。我在设计通用平台时,所做的一件关键事情就是我们的云敏捷托管通用平台,其中加入减少爆炸半径的理念。因此,产品团队在通用平台上部署一个实例。该实例是非常通用的,而非共享的。每个产品团队都具有自己的独立实例。这意味着如果你是产品负责人,并且你想在星期五下午发布一个版本,如果你的团队已经参与其中并出现了错误,那么唯一受到影响的是托管在实例中的特定产品。

InfoQ:从业务与IT如何协同工作的角度看,各位认为未来几年中针对DevOps的运营模式将如何发展?

Clark:将不会再有DevOps功能。我认为,我所提到的这些产品团队对我来所就是DevOps的演变。DevOps是与人们的工作并存的。我认为就像我之前提到的那样,ITV已经实现了这样的机制。在线业务、我们的产品团队以及技术产品团队在历史上曾是组织的组成部分,并且我认为这种趋势将会持续下去。人们将在同一功能中共事,成为技术人员、开发人员、平台工程等。DevOps一词将成为常规业务。

Howell:对我来说,DevOps是一个模糊地带。我认为我们并不会有专门的运营团队或专门的开发团队,我们拥有的是产品团队和功能团队中的所有人员。实际来自开发组织的工程师将不断发展,并具有更多的运营思维。我认为我们做得很好的一件事情,就是对成长过程中的问题、变革和事件管理。我们仍然会具有这些学科,他们仍然非常重要。但在我看来,同样重要的还有要确保开发和运维人员真正成为一个团队。我和Tom Clark的观点一致,我不会再看到我们继续谈论DevOps一词了。

Latekic:实际上我并不喜欢使用定义和术语,我真的不在乎我们如何称呼DevOps。如果我们称DevOps为其它名字,对我来说无关紧要。回顾历史,我们在并不知道一些工作可称为DevOps的情况下完成了这些工作。因此对我而言,DevOps只是在逻辑上得以推进。

研讨会的完整视频可在线观看

查看英文原文: Spanning the Business and Technology Divide: A Talk With UBS, LBG and ITV

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注