人工智能时代前沿技术社区

首页 > 热点

快速上线—— 开发、运维和敏捷迭代(DevOps工作坊总结)

一)开发和运维不应该分离在客户的眼中,不存在开发和运维的区别,甚至也不存在谁是项目经理的说法,他最关心的就是他自己的事解决了没有。

作者: | 2016-12-22 16:52:10

一)开发和运维不应该分离


  在客户的眼中,不存在开发和运维的区别,甚至也不存在谁是项目经理的说法,他最关心的就

是他自己的事解决了没有。换句话说,就是他的需求有没有被满足。


  离客户最近的是什么?是线上的产品。就是那些对于客户来说,看的见,“点”的到的按钮


  换句话说,也就是发布。有些发布,作为客户,能够明确的感受到,典型的如改版,或者增加

功能;不容易感觉到的,如性能改进。


  出于很多种的考量,现在的产品,发布的周期越来越短,频率越来越高。如亚马逊,几乎每一

秒都在发布。很显然,这种情况下,传统的人肉发布,已经不太现实了。这里已经发生了质变。


  让我们简单分析下,为什么开发到发布之间会存在一些障碍,导致快速发布比较难。从开发的

度来看,首先产品依赖的操作系统可能不同,使用的各种语言、库都有可能已经升级。甚至配

参数的格式都有可能导致程序启动不了,而这些乱七八糟的各种内外依赖,可不是每个运维都

搞定的。如何接手这些烫手的山芋?


  解铃还需系铃人。开发最应该负责任。当初为什么把这个配置写死,原因有可能是客户说,

的都不考虑,也有可能的确是忘了把它抽取到配置文件里。


二)游戏介绍


1.人员与角色


  现场分组的情况是,每组8人,其中1人角色是PO, 1人的角色是ScrumMaster,1人的角色是

Tester,其余的是Developer。


  对于PO ScrumMaster,是否也做Develop的工作,没有限制。


  发布组人员,从各组抽取一人,角色分别是


  Platform管理 1人


  Security管理 1人


  Release管理  1


  客户这个角色,由专人扮演,(也就是江湖人称无敌哥的王立杰老师,这次社区活动的培训

师)


2.“开发任务”


  很简短有趣,就是拿Lego(乐高)积木搭建一些小玩具(“产品”),如飞机、鱼、蛇等。


  “开发”的时候,需要到Platform管理那里领取一个“开发平台”。

 

3.“交付规则”


  每组不同的“产品”,有不同的价值,也有批次的要求,如飞机的话,需要每次交给客户两

个。另外每次的交付物,需要打包,并且打上以下标记:

  • 产品名

  • 标号(批次号)

  • 开发团队编号

  • 文档

  • 迭代号


 这么看的话,像不像一次真正的产品研发的交付物?


三)游戏过程


  这个游戏,我们玩了三个循环(迭代),每一次都遇到了不同的情况。


  1.第一次迭代(SP1

  这次几个小组遇到的主要的问题是,不熟悉规则,团队的分工和运作也不是很清晰。


  先看看外部表现,那就是每组都很混乱,声音很杂。再看看游戏的结果,除一个组有成功交付

外,其他的组的交付,都被拒绝了。


  这个迭代原来设计的时候,有一个Platform的限制,也就是,每组需要去领取平台,只有平台

到了,才能开工。并且平台只能由一个人来搭建。


  现场的情况是“哄抢”,甚至自己动手做了。


  由于,“产品”需要发布组的人员认可才有效,因此我们从交付过程中遇到的“Issue”来观

下:


  a)被拒1:安全限制,交付的时候,才发现,积木上都有一个小的数字标签,安全组要求,不

带某些数字。


  b)被拒2:有些交付,里面包含的产品,略有不同,如有的是一个大的方块,有的是用两个小

方块来代替一个大方块的。


  c)被拒3:产品打包的数目不对,如要求3个蛇,作为一个批次交付,那么6个蛇,应该分成

批次,不能一次都交给客户。


  d)被拒4:少了标签,或者某个产品上少了标记,等。

  每次被打回去的产品,就是“浪费”了,不能再交付了。

  反观这些结果,可以想见,每组的准备情况。

  当然遇到问题不可怕,重要是总结,然后计划下次怎么做。这就是“回顾”。


  2.第二次迭代(SP2


  我把我们组的回顾放在这里描述,是因为这个SP1的回顾输出,其实就是SP2开发的要点。


  首先,我们还是计划了下,要做哪些产品,也就是哪些“最贵”。


  针对上次的混乱,我们决定有个人,专门做“backlog的管理”,也就是无论谁,要做什么,

都要先到这个管理人那里去领一个标签,上面写明迭代号,产品,组编号,数量等。


  开发人员搭建好了后,放在平台(A4纸一张)上,带上标签,一起去找Tester验证。


  针对发布过程中,遇到的安全等等问题,我们组的PO非常积极主动,这轮游戏一开始,去先去

规则要了回来。


  果然,这轮游戏下来,我们斩获不菲。


  其实,仔细分析下,我们回顾出来的要点是:

  • 流程清晰,分工明确;

  • 规则优先,避免重复

  3.第三次迭代(SP3


  这个迭代比较有意思,因为发生了两个变化,


  一个是打散了发布组人员,发布组人员,虽然角色和任务还在,但是,回到了各组,也就是没

专职的“发布人员”了。


  这样,就是客户直接收这些产品了。


  另一个,就是针对每组交的产品,标准不一,如有的组,做的小飞机非常精致,有的比较粗

糙,客户制定了标准,也就是给出了标准的小飞机长什么样,都得照着做。


  还是直接说下这轮游戏交付时候,遇到的状况吧。


  首先,可以明确看到的是,各组的产量大增,这肯定得益于流程改进,配合都很好了。


  客户只要4组蛇,其中一组,迅速提交了第4组蛇的产品,另外一组的蛇,虽然做好了,但

是,由于客户的需求已经满足了,也就“浪费”了。


  四)关于DevOps的讨论


  这里,王老师,引入了“八荣八耻”的概念,也就是引入了大讨论,我们应该怎么做,争论

比较大的是,“以微服务为荣”,“以整体框架为耻”,网友为什么这么提,想表达什么?


  还有一个就是关于“迁移”的讨论。这里说的迁移,应该是指,数据中心内容,某个服务或组

失效的时候,应该由其他的组件来接替这个服务。是“高可用”范畴的讨论,而不是指旧业务

移到新业务的问题。


文章来源【敏捷一千零一夜】