言之无物

我说的一切都是错的

译文——如何拥抱“谁构建,谁运行”

《译文——如何拥抱“谁构建,谁运行”》

前言

持续交付2.0中提到了“you build it ,you runt it”的概念,网上相关的中文文章很少,找了几篇英文看了下。本来想自己写篇总结,碍于理解肤浅,久久没有成文。就随机抽一篇翻译下,保证公众号有在更新,哈哈。

译文只是作为练习用,根据个人理解重新做了调整,并没有忠于原作者的意图。各位且这么一看,如想更准确的了解,请查看原文

https://techbeacon.com/enterprise-it/how-embrace-you-build-it-you-run-it

译文部分

21世纪初期,亚马逊的应用臃肿不堪,服务经常性的中断。贝索斯受够了这一切,强行规定应用之间必须通过web service接口来交互,同时推行新的原则“谁构建,谁运行”。团队的职责除了构建应用,还得让应用在生产环境中跑起来。而不是像过去那样,应用构建好了就扔给其他团队。

亚马逊通过快速的应用规模化来支撑业务的发展,期间打造出了一套web service服务标准(AWS)。其他公司也想复制它的成功,但这并不件容易的事。需要处理一系列的问题,如组织架构大幅的调整,面对可能延迟交付的风险,团队重组等等。但回报也是明显的,最终团队会比以前更快的实现交付。

那么,组织如何来拥抱“谁构建,谁运行”呢?

“谁动了我的奶酪?”:组织架构变更

构建云应用的第一步就是创建跨部门,多功能产品团队。没有专门的角色区分开发,测试,运维,系统管理员,dba等,产品团队拥有所有这些技能。团队之间的依赖是最让人头痛的,想象一下,团队完成了所有的工作,准备发布了,却发现数据库的脚本还需要数据团队来验证运行,你除了干等,别无它法。多功能团队消除了这样的瓶颈,团队成员可以自己来运行脚本,从此告别等待。

消除依赖是好事,发布devops年度报告的团队研究表明,如果由外部团队来审查代码质量,还不如不审查,因为并不会带来任何的质量改进。 一种有效的审查方式是结对审查,可以带来更好的交付质量。因此,审查团队需要走进产品团队,变成团队的一员,这样的审查才能带来效果。

不要拖延客户的功能

Zynga是一家社交游戏公司,它的产品Farmville在facebook上发展非常迅速。但公司没有专注于快速满足用户需求,反而选择优先完善基础IT架构。他们决定放弃使用AWS,构建自己的云平台。不幸的是最终没有成功,又重新选择了AWS。 这么一折腾,公司失去了手机端业务爆炸性增长的最佳时机。

打造面向产品团队的组织并不意味着要从头开始构建基础云架构。 首先,用web service来构建云应用被证明是可行的,云服务平台关注的是如何为软件提供良好的运行环境,而不是软件本身。其次,产品团队可以专注于软件功能,加快创新的速度。

企业应聚焦于外部用户需求而不是内部架构需求,以实现用户功能的快速交付。

当你的巨无霸应用需要添加新功能时,试着单独构建这部分功能,并且提供web service接口,巨无霸应用通过服务调用方式实现新功能。让团队关注自己擅长的事–构建应用。应用运行环境则交给云平台去处理。别试图自己去搭建云平台,那样会耽搁用户功能的交付,导致用户不满,从而影响你的商业目标。

改变是可怕的

让组织持续有效的改变,唯一办法是让改变本身变得有吸引力。 改变是不可避免的,重点不是如何改变,而是怎样让团队信服需要改变。办法也很简单,就是给投入并且驱动改变的人给与奖励,那些唱反调的或者旁观者看到成效后会做出合适的选择。

成功需要驱动力,一旦识别出团队正采取新的方式构建、交付应用,立即高调的发放奖励。奖励可以驱动偷懒的人前进。

但这终究不是长久之计。团队需要认识到他们还能做的更好,更快。 相比其他奖励方式,“自我实现”是一套更有效的系统。当团队看到自己的产品发布越来越快,而且麻烦更少了,会全身心投入到“谁构建,谁运行”的实践中来。

亚马逊从01年开始实践“谁构建,谁运行”哲学,经历了痛苦的转变。包括组织架构调整,直面延迟交付付的恐惧,说服员工拥抱变化。如果你像amazon一样也学会了有效处理这些问题,会更容易向云应用转型,并且获得更多的回报。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注