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