快速上线
——开发、运维和敏捷迭代
一）开发和运维不应该分离
在客户的眼中，不存在开发和运维的区别，甚至也不存在谁是项目经理的说法，他最关心的就是他自己的事解决了没有。换句话说，就是他的需求有没有被满足。
离客户最近的是什么？是线上的产品。就是那些对于客户来说，看的见，“点”的到的按钮。换句话说，也就是发布。有些发布，作为客户，能够明确的感受到，典型的如改版，或者增加了功能；不容易感觉到的，如性能改进。
出于很多种的考量，现在的产品，发布的周期越来越短，频率越来越高。如亚马逊，几乎每一秒都在发布。很显然，这种情况下，传统的人肉发布，已经不太现实了。这里已经发生了质变。
让我们简单分析下，为什么开发到发布之间会存在一些障碍，导致快速发布比较难。从开发的角度来看，首先产品依赖的操作系统可能不同，使用的各种语言、库都有可能已经升级。甚至配置参数的格式都有可能导致程序启动不了，而这些乱七八糟的各种内外依赖，可不是每个运维都能搞定的。如何接手这些烫手的山芋？
解铃还需系铃人。开发最应该负责任。当初为什么把这个配置写死，原因有可能是客户说，其他的都不考虑，也有可能的确是忘了把它抽取到配置文件里。
二）游戏介绍
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的讨论
这里，王老师，引入了“八荣八耻”的概念，也就是引入了大讨论，我们应该怎么做，争论比较大的是，“以微服务为荣”，“以整体框架为耻”，网友为什么这么提，想表达什么？
还有一个就是关于“迁移”的讨论。这里说的迁移，应该是指，数据中心内容，某个服务或组件失效的时候，应该由其他的组件来接替这个服务。是“高可用”范畴的讨论，而不是指旧业务迁移到新业务的问题。
