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