快速上線
——開發、運維和敏捷迭代
一）開發和運維不應該分離
在客戶的眼中，不存在開發和運維的區別，甚至也不存在誰是項目經理的說法，他最關心的就是他自己的事解決了沒有。換句話說，就是他的需求有沒有被滿足。
離客戶最近的是什麼？是線上的產品。就是那些對於客戶來說，看的見，“點”的到的按鈕。換句話說，也就是發佈。有些發佈，作爲客戶，能夠明確的感受到，典型的如改版，或者增加了功能；不容易感覺到的，如性能改進。
出於很多種的考量，現在的產品，發佈的週期越來越短，頻率越來越高。如亞馬遜，幾乎每一秒都在發佈。很顯然，這種情況下，傳統的人肉發佈，已經不太現實了。這裏已經發生了質變。
讓我們簡單分析下，爲什麼開發到發佈之間會存在一些障礙，導致快速發佈比較難。從開發的角度來看，首先產品依賴的操作系統可能不同，使用的各種語言、庫都有可能已經升級。甚至配置參數的格式都有可能導致程序啓動不了，而這些亂七八糟的各種內外依賴，可不是每個運維都能搞定的。如何接手這些燙手的山芋？
解鈴還需繫鈴人。開發最應該負責任。當初爲什麼把這個配置寫死，原因有可能是客戶說，其他的都不考慮，也有可能的確是忘了把它抽取到配置文件裏。
二）遊戲介紹
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的討論
這裏，王老師，引入了“八榮八恥”的概念，也就是引入了大討論，我們應該怎麼做，爭論比較大的是，“以微服務爲榮”，“以整體框架爲恥”，網友爲什麼這麼提，想表達什麼？
還有一個就是關於“遷移”的討論。這裏說的遷移，應該是指，數據中心內容，某個服務或組件失效的時候，應該由其他的組件來接替這個服務。是“高可用”範疇的討論，而不是指舊業務遷移到新業務的問題。
