[很差分類]《鳳凰項目》讀後感

【版權聲明】如需轉載請聯繫做者。

《鳳凰項目》是一個偶然的機會讀到的，是從朗讀新概念英語朋友的QQ那兒看到的這本書。春節期間看到圖靈上有電子書促銷，我就下手買了回來。總體說來，這是一本有趣的書，感謝圖靈社區；也感謝做者爲咱們描寫的那個Eric老頭、那個車間和那個項目。

這本書主要講的是Bill帶領的團隊在Eric協助下如何改進IT運維、促進業務提高，並最終使得公司起死回生的故事。讀徹底書，我開始嘗試着回答下面這些問題，並給出一些初步的見解。有一些見解可能還須要繼續打磨，有一些答案也可能會有些重疊，由於一樣的答案能夠解決不一樣的問題。

第一：如何改進IT，可以下降IT系統帶來的業務風險或中斷故障？

第二：項目建設與運維如何銜接，可以確保IT系統在運維時期可以高效？

第三：IT對於業務的價值到底在哪裏？或者說每一年花了很多錢，能不能說一說公司爲什麼要持續投入到IT？

第四：IT安全如何與IT融合到一塊兒，再也不有「拖後腿」的感受？

對於問題一，我想能夠從如何開展變動標準化、如何開展預防性維護、如何改進約束點對變動的制約、如何將DevOps理念應用到團隊中等方面來改進和思考。

關於變動標準化，書中主要是從Bill提高爲運維副總裁後，開始處理工資覈算故障開始的。

以前無極限零部件公司也實施過「變動流程」，但你們都很抵觸。如何讓團隊成員易於接受「變動流程」呢？

爲何帕蒂曾經在IT運維團隊內部推進過「變動流程」改進沒有成功呢？

Bill促進變動流程的過程分爲以下幾步：

一、從易到難：使用紙筆等簡易工具，要求團隊成員開始僅記錄「」核心要點：

「我但願每一個工做組都把計劃內的變動所有寫下來，一張索引卡片上寫一個變動。我但願看到三條信息：變動計劃的制定者、將要實施變動的系統以及一條一句話的概述。」

二、化繁爲簡：使用80/20法則應對員工們提交的「過多」的變動。

--「咱們應該重點關注最有風險的變動。」我繼續說，「80/20 法則在這裏彷佛一樣適用：80%的風險是由 20%的變動形成的。」

--咱們要預先定義好高風險變動目錄，在目錄中的變動項目不只必須提交變動申請，並且必須在經過審批後才能安排實施。

三、分級分類管理變動：

--重大變動（含一些影響業務的脆弱性程序，如無人支持的舊程序）須要CAB審批。變動人員須要提交報告供CAB審查。

--低風險變動，ITIL 稱之爲‘標準變動’，批准便可。對於以前已屢次成功實施的變動，咱們只須要提早批准就行。它們仍然須要提交，但能夠不通過咱們批准就安排操做日程。

--對於‘複雜的中等變動’，咱們決定，變動提交者有責任向可能受到影響的人員進行諮詢並獲得其承認。作完這些以後，他們就能夠把變動卡片交給咱們審覈並安排操做日程。」 

四、利用變動時間線輔助診斷故障：在故障時，分析變動記錄、查看故障點前的變動時間線，來輔助故障分析。(p156）

五、嚴格遵照變動流程：禁止任何人經過變動流程之外，實施變動。

六、合理選擇變動時間點：實施變動時，須要避開相似「鳳凰項目」發佈的重大節點。

七、變動受到約束點制約，沒法按時完成，則要保護好「約束點」，任何針對約束點以外的改進都是無效的：

--「很好，」他說，「你在把布倫特的工做標準化，讓其餘人可以執行。並且，因爲你最終把那些步驟記錄下來了，因此能在必定程度上保證穩定 性和質量。你不只減小了須要布倫特的工做中心數量，還生成了一些未來可以讓其中一些工做中心自動化運行的文檔。」

--你得列出一張清單，代表有哪些變動須要布倫特（約束點）作哪些事，並設法讓那些 3 級工程師知足清單上的要求。若是作不到這一點，那就試着肯定它們的優先級，分類交給布倫特處理。

八、變動帶來的好處：

夥計們，今天早上，新的變動流程保住了咱們的飯碗。 今天，有兩組人同時對物料管理數據庫及應用程序服務器開 展變動。他們都不知道對方的事。 拉吉夫在變動牆上看出了潛在的衝突。咱們決定，先做個人 變動，咱們這邊完成後再給他打電話。 咱們本來會把事情搞得一塌糊塗的。

九、計劃外工做對變動的影響：儘可能保護約束點不受計劃外工做的打擾。

十、讓變動關注重點業務：

「哦，我沒告訴過你嗎？咱們在用不一樣的顏色區分不一樣種類的卡片，一旦項目凍結解除，這能幫助咱們作好準備。咱們必須 想辦法確保你們都在作最重要的工做。所以，紫色卡片是支持五大最重要 業務項目的變動，支持其餘項目的變動卡片則是黃色的。綠色卡片是內部 IT 改進項目，咱們正在嘗試，劃撥 20%的工做週期專門用於這些項目，就 像埃瑞克建議咱們作的那樣。只要看一眼，就能確認工做中紫色和綠色卡片取得了正確的平衡。」 她繼續說：「粉色的即時貼表示一些卡片因爲種種緣由卡住了，所以 咱們會天天檢查兩次。咱們還把全部這些卡片都放回變動跟蹤工具裏，這 樣就能給每張卡片也都設置變動標識（ID）。這件事有點兒繁瑣，但至少 如今有一部分跟蹤是自動化的。」

 

對於第二個問題，項目建設（開發）和運維如何有效集成，我以爲能夠從如下幾個方面改進：讓兩個團隊及早充分接觸、團隊領導以前增進互信、採用DevOps要確保開發環境、測試環境與生產（運維）環境一致、在開發測試階段作好測試儘可能不把缺陷帶入生產（運維）環節、作好版本控制、將系統安全融入每一個前期開發測試過程。

 

對於第三個問題，IT團隊的確要始終關注業務，也能夠說讓IT內化成爲公司的一種理念。

讓咱們先看看約翰一蹶不振以後重出江湖時，對迪克提出的六個問題。我以爲這六個問題不只僅是對迪克有效，也值得IT職場人士和IT團隊思考。（P234）固然，更重要的是你能夠在與業務部分溝通時使用。

一、"爲了確保我沒有理解錯誤或者先入爲主，能否先請你跟咱們講講，你在無極限零部件公司究竟是作什麼的？你的確切職能是什麼？"

二、「你怎樣區分美好的一天和糟糕的一天？」

三、「你今年的遠期目標、近期目標以及評估指標是什麼？」

四、「這些評估指標中，哪些是最有風險的？」

五、「這裏的每個項目和評估指標，分別是由哪幾位經理負責的？」

六、「咱們的時間快到了。此次會面實在太棒了。謝謝你抽出時間，和咱們談了你的平常工做狀況。有什麼咱們能夠幫到你的嗎？」

迪克針對遠期目標、近期目標展現的兩張幻燈片，分別展現了從財務角度以及公司總體角度出發的目標。迪克不只僅關注局部目標，也按照第一工做法要求關注總體目標。

第一張幻燈片：

CFO 的遠期目標：

公司情況

收入

市場份額

平均訂單金額

盈利能力

資產回報率

財務情況

從訂單轉化爲現金的週期

應收賬款

準確及時的財務報告

借貸成本

第二張幻燈片：

咱們有競爭力嗎？

瞭解客戶的需求和指望：咱們知道要建立什麼嗎？

產品系列：咱們有正確的產品嗎？

研發效能：咱們能有效地建立產品嗎？

上架時間：咱們能儘快把產品推向市場並佔有一席之地嗎？

銷售機會渠道：咱們的產品能帶來感興趣的潛在客戶嗎？ 咱們的效率高嗎？

按時交貨：咱們遵照了對客戶的承諾嗎？

客戶保留：咱們是在得到客戶，仍是在流失客戶？

銷售預測準確率：咱們能夠把銷售預測準確率歸入銷售計劃流程嗎？

 

以後約翰和比爾訪談了迪克團隊的經理，肯定了IT價值鏈，讓IT可以關注到業務的關注點，並分析出IT故障與業務風險之間的關聯度。而後通過與迪克的再次會談，因爲IT與業務之間有了關聯，更容易爭取到了迪克對於IT團隊獲取更多資源的支持。

--「一旦你創建起價值鏈，把迪克的目標任務與 IT 對這些目標任務的影響關聯起來，你就作好和迪克會面的準備了。收集之前 IT 問題如何影響那些目標的具體案例。確保你本身準備就緒。」

此外，對於防止故障而言，IT預防性工做要作在哪裏呢？其實也就是那些影響核心業務運行的地方。

 

對於第四個問題，安全要融入開發、測試、運維的全過程，安全也須要關注如何保護業務，而不是僅從IT安全自己角度提出一大堆改進措施。

這方面能夠參考約翰關於安全與IT的五條建議：

「爲了將咱們與安全性相關的工做量減小 75%，我要提出五條建議。」 P258

 

書中還提到了三步工做法，這個工做法會在做者的新書《DevOps handbook》進行更進一步的闡述。你能夠先參考這裏：the-three-ways-principles-underpinning-devops。做者用了三張圖生動的說明了三步工做法。

 

 

我這裏僅列舉一下我讀書時思考的關於三步工做法的部分問題：

一、如何在凍結工做流後，解凍項目，保持適當的工做流量，不會過多，也不會太少：

「是的。」他繼續說，「咱們先從你的第一個問題開始。項目凍結解除 後，發佈哪些項目是安全的？知道了工做如何流經某些工做中心，以及哪些工做中心須要布倫特，哪些工做中心不須要他，你認爲答案是什麼？」 我把埃瑞克剛纔說的話慢慢地重複了一遍，設法拼湊出答案。 「我知道了。」我微笑着說，「發佈那些不須要布倫特的備選項目是安全的。」

二、如何確認是否能夠接受新的工做任務：

「好吧，更確切地說，你實際上是在構建一份資源清單。也就是材料清單以及所需工做中心和工藝的清單。一旦有了這個， 再加上工做訂單和你的資源，你最終就可以理解你的生產能力和需求是什麼。這將讓你最終明白，是否能夠接受一個新工做並對其做出實際安排。」

三、如何讓工做流最大化：

「‘第二工做法’的一個關鍵部分是讓等待時間可視化，那樣就能知道你的工做什麼時候在某人那裏排了幾天的隊— —或者還有更糟的狀況，工做必須日後退，由於沒有完成全部的部件，或 者須要返工。」 「記住，咱們的目標是使流量最大化。」

四、如何肯定項目優先順序？

給我三份清單。第一份是須要布倫特參與的項目清單， 第二份是能夠提升布倫特生產能力的項目清單，還有一份是其餘項目的清 單。在每一份清單裏，都肯定最重要的幾個項目。別花太多時間給它們排 序——我不但願咱們整天只是爭論。最重要的是第二份清單。咱們須要通 過減小壓到布倫特身上的計劃外工做量，來不斷提高他的工做能力。」

五、如何縮短項目或任務的處理時間？

我告訴他們，埃瑞克在 MRP-8 對我說過，等待時間取決於資源使用率。 「等待時間是‘忙碌時間百分比’除以‘空閒時間百分比’。也就是說，若是一個資源的忙碌時間是 50%，那麼它的空閒時間也是 50%。等待時間就 是 50%除以 50%，也就是一個時間單位。就說是一個小時吧。因此平均來 說，一個任務在處理前的排隊等待時間爲一個小時。」 「另外一方面，若是一個資源 90%的時間是忙碌的，等待時間就是‘90% 除以 10%’，也就是 9 個小時。換言之，咱們的任務排隊等待的時間，將 是資源有 50%空閒時的 9 倍。」 我得出結論：「所以，對這個鳳凰任務來講，假設咱們有 7 個交接步 驟，並且每個資源都有 90%的時間是忙碌的，那麼任務排隊等待的總時 間就是 9 小時乘以 7 個步驟……」

這本書中，我也看到了如何有效溝通的一些不錯的案例。選一些和你們分享。

一、約翰和比爾用一個精彩的問句打開了採訪對象的話匣子。

「你怎樣區分美好的一天和糟糕的一天？」約翰繼續問。

當我問他，他以爲糟糕的一天是什麼樣的，他的話匣子真的打開了。

二、對於一些須要開拓思路的方案，試試那根無所不能的魔杖。

「假如你能揮舞魔杖，你會怎麼作？」我問。

 三、若是多個目標衝突時，如何平衡、確保團隊利益？書中的史蒂夫，採用了第二優秀資源去知足另外一個目標。這是個好辦法。並非任何目標都非得第一優秀的資源去支持。

「布倫特是獨一無二的。獨角獸須要一個受到開發人員尊重，對咱們全部 類型的 IT 基礎架構都有足夠深刻的經驗，並能描述開發人員應該構建什麼 樣的東西才能在投產後真正管理和操做的人。這些技能是罕見的，目前， 沒有第二我的可以勝任這個特殊的角色。」  「那麼，若是你把第二優秀的人派去加入迪克的特別工做組，會怎麼樣？」他問。 「我猜測，拆分方案會不那麼精確，但仍然能夠順利完成。」我回答。

 

【更多資源】

一、Phoenix Project英文原版部分章節節選（前16章）

二、Phoenix Project英文原版朗讀 AUDIOBOOK：soundcloud上面搜索便可聽到節選部分（前16章）。

三、讀書過程看到的一些好的理念：

--你應該知道，與實現企業目標息息相關的是什麼，不論它是項目、運營、戰略、 法律法規合規、安全性，仍是其餘別的什麼。」 他繼續說：「記住，重要的是結果——而非過程、管理，或者你完成了哪些工做。

--‘改進平常工做比開展平常工做更重要’。（意思是養成持續改進的習慣很重要）

--「邁克·羅瑟說，改進的內容幾乎是可有可無的，關鍵是你要不斷改進。爲何？由於若是沒有改進，無序狀態必將使狀況惡化，也就不可能達到零失誤、零工做相關事故以及零損失的狀態。」

 --「工做流只朝一個方向移動：向前。在 IT 部門建立一個向前的工做系統。 記住，目標是單一工做流。」

 四、關於DevOps：一天十次部署如何實現？

--咱們把四個工做中心合而爲一，排除了三十多個容易出錯的人工步驟，使整個工做週期徹底實現了自動化，造成了單一工做流，而且去掉了全部的準備時間。生產能力一飛沖天

--「阿爾斯帕瓦教導咱們，只要開發部和運維部協 同工做，連同 QA 和業務部門一塊兒，這個‘超級部落’就可以成就各類難以想象之事。他們也知道，在代碼投產以前，實際上並未產生任何價值， 由於那只是困在系統裏的半成品。他不斷縮減批量規模，實現快速功能流。 從必定程度上說，他確保了部署環境時刻準備就緒，按需投產。他把建立 和部署流程自動化，而且認識到，能夠把基礎架構看成代碼同樣對待，就像開發部推出的應用程序同樣。這讓他得以構建一步到位的生產環境和部署流程，就像咱們想出一步到位的噴塗和烘乾方法同樣

--去和克里斯一塊兒想辦法，如何才能保證在敏捷開發流程的每一 個階段，不只有可推出的代碼，還能具有可以部署這些代碼的工做環境