快速上线—— 开发、运维和敏捷迭代(社区活动总结)

时间:2020-12-18 21:53:49


快速上线

——开发、运维和敏捷迭代

 

 

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

在客户的眼中,不存在开发和运维的区别,甚至也不存在谁是项目经理的说法,他最关心的就是他自己的事解决了没有。换句话说,就是他的需求有没有被满足。

快速上线—— 开发、运维和敏捷迭代(社区活动总结)

离客户最近的是什么?是线上的产品。就是那些对于客户来说,看的见,“点”的到的按钮。换句话说,也就是发布。有些发布,作为客户,能够明确的感受到,典型的如改版,或者增加了功能;不容易感觉到的,如性能改进。

出于很多种的考量,现在的产品,发布的周期越来越短,频率越来越高。如亚马逊,几乎每一秒都在发布。很显然,这种情况下,传统的人肉发布,已经不太现实了。这里已经发生了质变。

让我们简单分析下,为什么开发到发布之间会存在一些障碍,导致快速发布比较难。从开发的角度来看,首先产品依赖的操作系统可能不同,使用的各种语言、库都有可能已经升级。甚至配置参数的格式都有可能导致程序启动不了,而这些乱七八糟的各种内外依赖,可不是每个运维都能搞定的。如何接手这些烫手的山芋?

解铃还需系铃人。开发最应该负责任。当初为什么把这个配置写死,原因有可能是客户说,其他的都不考虑,也有可能的确是忘了把它抽取到配置文件里。


二)游戏介绍

1.人员与角色

现场分组的情况是,每组8人,其中1人角色是PO 1人的角色是ScrumMaster1人的角色是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的讨论

快速上线—— 开发、运维和敏捷迭代(社区活动总结)

这里,王老师,引入了“八荣八耻”的概念,也就是引入了大讨论,我们应该怎么做,争论比较大的是,“以微服务为荣”,“以整体框架为耻”,网友为什么这么提,想表达什么?

还有一个就是关于“迁移”的讨论。这里说的迁移,应该是指,数据中心内容,某个服务或组件失效的时候,应该由其他的组件来接替这个服务。是“高可用”范畴的讨论,而不是指旧业务迁移到新业务的问题。

 

快速上线—— 开发、运维和敏捷迭代(社区活动总结)