解讀神書《鳳凰項(xiàng)目》，帶你跳出DevOps轉(zhuǎn)型的所有坑

《鳳凰項(xiàng)目》是DevOps界神書，雖然內(nèi)容表現(xiàn)形式是小說，但是依然是敏捷開發(fā)及DevOps領(lǐng)域的必讀書籍。很多知名的咨詢師都是通過此書開啟了DevOps及敏捷之旅，書中故事均來源于運(yùn)維的日常工作，正是體現(xiàn)了藝術(shù)源于生活、高于生活的本質(zhì)。筆者間隔兩年時(shí)間，閱讀此書兩次，希望可以講書中了解到的一些經(jīng)驗(yàn)分享給大家。

小說主人公比爾，臨時(shí)接任了IT運(yùn)維經(jīng)理的職位，然而此時(shí)，公司已經(jīng)經(jīng)歷了多輪裁員，生產(chǎn)線上故障不斷。董事會(huì)指望鳳凰項(xiàng)目重啟拯救公司，然而面對(duì)的著層層困難，比爾開始不停的應(yīng)付突發(fā)的線上故障，身心俱疲。為了生存及公司的正常運(yùn)轉(zhuǎn)，嘗試出一套適合該公司的IT轉(zhuǎn)型方案，整個(gè)轉(zhuǎn)型過程就像我們從傳統(tǒng)開發(fā)模式轉(zhuǎn)型DevOps的開發(fā)模式一樣，踩過很多坑，總結(jié)出很多道理，小說的內(nèi)容我不過多敘述，了解精彩的故事可以直接去購(gòu)買圖書，下面會(huì)給大家總結(jié)一下書中的一些重要的經(jīng)驗(yàn)。

1，  IT的四種工作形態(tài)

在故事中，主人公比爾在接替IT部經(jīng)理后，通過一系列的故障處理與人際交流的過程中，得出了這個(gè)結(jié)論。IT的工作無非就是如下四種類型：

l  IT部門內(nèi)部項(xiàng)目

l  業(yè)務(wù)組項(xiàng)目

l  變更工作

l  救火工作

其實(shí)上述四種工作類型與我們目前運(yùn)維部門的狀態(tài)基本一致，我們需要開發(fā)自己的運(yùn)維與監(jiān)控平臺(tái)，要參與到業(yè)務(wù)部門的開發(fā)測(cè)試中，要進(jìn)行所有基礎(chǔ)設(shè)施及應(yīng)用版本的變更與升級(jí)。而這些都是屬于正常的工作，我們往往最不愿意處理的就是救火工作，比如線上的突發(fā)故障導(dǎo)致的所有用戶的功能無法使用，往往運(yùn)維人員會(huì)在技術(shù)vp、cto、甚至ceo的注視下一行一行敲著命令，修復(fù)問題。大量運(yùn)維人員應(yīng)該都有過類似經(jīng)歷，回想起來一定是慘不忍睹，所以我們要減少這種救火工作，并把前三種工作合理分配。

2，  加強(qiáng)變更管理，減少救火行為

從IT的四種工作形態(tài)中，我們引申出一個(gè)問題，如何減少救火行為呢，我們先看運(yùn)維圈里的兩個(gè)定律

l  著名的二八定律：線上 80% 的故障來自于2 0% 的變更。

l  GoogleSRE理論： 大概 70% 的生產(chǎn)事故由某種部署的變更而觸發(fā)

我們不去糾結(jié)8 0% 與7 0% 的差異是怎么產(chǎn)生的，但是結(jié)論是統(tǒng)一的，大量的線上的故障都是由于變更導(dǎo)致的，變更包括對(duì)應(yīng)用程序、數(shù)據(jù)庫(kù)、操作系統(tǒng)、網(wǎng)絡(luò)或硬件進(jìn)行的物理、邏輯或虛擬操作?？梢钥吹?，這些內(nèi)容覆蓋了大量的運(yùn)維工作了，為什么運(yùn)維容易背鍋呢，就是因?yàn)槠綍r(shí)要處理這些高風(fēng)險(xiǎn)的變更操作，才容易引起線上的故障。而外人看來，運(yùn)維就是在制造麻煩，之后開始救火工作、解決故障。為了避免種情況，該怎么處理呢？文章中給了我們很重要的方法，就是用看板的方法，規(guī)范化所有變更的管理，有計(jì)劃的進(jìn)行每一次變更，評(píng)估每次變更帶來的風(fēng)險(xiǎn)點(diǎn)，就算出現(xiàn)故障，也可以快速修復(fù)。

3，  加強(qiáng)技術(shù)儲(chǔ)備，避免個(gè)人英雄主義

在解決所有變更導(dǎo)致的故障的時(shí)候，小說中出現(xiàn)了一個(gè)重要的人，杜倫特，這是運(yùn)維團(tuán)隊(duì)中的一個(gè)英雄角色，沒有他解決不了的問題。但是就是這么厲害的一個(gè)人，所有開發(fā)人員都喜歡找他進(jìn)行變更，所有的系統(tǒng)故障都需要他去處理，所以這么厲害的人，每天都從事的是救火工作。這個(gè)角色就變成了我們運(yùn)維規(guī)范化過程中的一個(gè)瓶頸點(diǎn)。只要他的工作無法被其他人員替代，就無法讓他去做運(yùn)維團(tuán)隊(duì)更重要的事，比如自動(dòng)化的建設(shè)，比如重要的監(jiān)控建設(shè)。小說里為了解決這個(gè)問題，比爾設(shè)置了故障處理分級(jí)機(jī)制，把杜倫特保護(hù)起來，不允許開發(fā)人員直接與杜倫特溝通，同時(shí)安排其他工程師接觸杜倫特原來的工作，讓杜倫特的工作重心在自動(dòng)化建設(shè)與監(jiān)控建設(shè)上。這樣在關(guān)鍵位置上增加了技術(shù)儲(chǔ)備的同時(shí)，也將核心技術(shù)人員用在了最重要的位置上。

4，  限制在制品數(shù)量，多做從0到1，減少0 .5 的數(shù)量（看板）

小說的名稱叫《鳳凰項(xiàng)目》，所以故事核心是圍繞著鳳凰項(xiàng)目來的，鳳凰項(xiàng)目是一個(gè)計(jì)劃了三年，經(jīng)過了三年的憋大招勉強(qiáng)上線的一個(gè)項(xiàng)目，當(dāng)然，準(zhǔn)備了這么久的項(xiàng)目最后以失敗告終，這個(gè)問題告訴我們什么呢。主人公在工廠車間意識(shí)到，如果工廠的人力是固定的，如果半成品積累的過多，就會(huì)導(dǎo)致最終成品交付給用戶會(huì)變慢，這也就是我們?cè)谲浖_發(fā)領(lǐng)域常說的在制品數(shù)量影響著交付的速度，如果開發(fā)團(tuán)隊(duì)同時(shí)迭代著過多的需求，那么必然需求交付到用戶的手中的時(shí)間要延長(zhǎng)。所以限制在制品數(shù)量是DevOps建設(shè)的一個(gè)核心內(nèi)容，我們應(yīng)該多做從0 -1 的事，而減少0 .5 的數(shù)量。書中總結(jié)的很好，一旦研發(fā)資本以半成品的形式鎖定超過一年而未向公司返還現(xiàn)金，他就幾乎不可能再為公司產(chǎn)生回報(bào)。

5，  三步工作法

小說的最后作者總結(jié)了三步工作法，包含：

1)  流動(dòng)原則

流動(dòng)原則是DevOps 建設(shè)的基礎(chǔ)，縮短滿足客戶需求的潛質(zhì)時(shí)間，建立自動(dòng)化工具鏈，減少人工干預(yù)過程，減小在制品數(shù)量，快速迭代，便可以有效地提高工作質(zhì)量和產(chǎn)量。

2)  反饋原則

在源頭發(fā)現(xiàn)問題，盡早發(fā)現(xiàn)問題，測(cè)試及安全左移，在生產(chǎn)的源頭就要保證質(zhì)量。

3)  持續(xù)學(xué)習(xí)與實(shí)驗(yàn)原則

把生產(chǎn)效率、工作流程上升到領(lǐng)導(dǎo)層，推進(jìn)DevOps文化的落地。

總結(jié)：還等什么，買書去看吧，《鳳凰項(xiàng)目》。

更多精彩內(nèi)容可以專注我們的在線課堂

微信搜索公眾號(hào)：jfrogchina 獲取課程通知