原文書名：The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
推薦指數：★★★★
通常在深度閱讀一本書以前，我會打開目錄，看看這本書章節的編排方式，接著翻到有興趣的章節做粗淺的略讀，快速理解這本書想講什麼？但是這種閱讀的技巧在這本書上，可能不適用。因為這本書採用小說的方式，闡述在 IT 產業裡發生的一個有趣故事。
這本書沒有目錄，所以在閱讀內容前，我真得不知道這本書的內容是什麼？翻到每個章節的第一頁，只會有很簡單的一個標題「第 12 章，9 月 12 日，星期五」，就像航海日誌一樣，簡單的把日期寫上去而已，而這個章節的內容，就是這一天發生的事情。因此，在閱讀這本書的時候，建議要從頭一頁一頁慢慢看，跟著故事的主角比爾，一起體驗每天發生的事情、團隊發生的化學效益、流程發生的轉變。
故事簡介
比爾是無極限零件公司的一名 IT 經理，週二早上，在驅車前往辦公室的途中，他接到 CEO 的緊急來電。
新的 IT 改造計劃，代號鳳凰專案，對無極限零件公司的未來至關重要，是組織能否起死回生的關鍵，然而，這個專案嚴重爆預算，進度大幅落後，CEO 要比爾接管相關 IT 事務，直接向他報告，並於九十天內收拾爛攤子，否則整個部門的工作就要全部外包。
就在此時，高人出現，一位未來的董事會成員，在他玄妙的「三步工作法」(The Three Ways) 哲學的加持下，比爾開始明白 IT 工作與工廠生產線的流程存在許多共通點，具有異曲同工之妙，遠遠超乎他的想像。在分秒必爭的情境下，比爾必須妥善組織工作流程，暢通跨部門的溝通管道，並且為公司的其他業務活動提供有效的服務與充分的支援。
故事開始
在製品危機
你或許聽過這些管理運動：約束理論（Theory of Constraints）、精實生產或豐田生產系統（Lean production/Toyota Production System）以及全面品質管理（Total Quality Management），雖然每個運動的起源各不相同，但全都贊同一個論點：在製品是隱形的殺手。因此，管理任何一家工廠的最大關鍵之一，就是任務與原料的發佈／釋出機制，沒有這項機制，就無法控制好在製品。
一間工廠裡假如有 20 個工作站，如果總是讓第一個工作站保持忙碌，這種選擇工作執行順序的作法似乎合情合理，類似先進先出的排程法。但是這樣的運作方式，在瓶頸處的庫存會不斷堆積，工作也從未能按時完成，每天都有緊急事件，幾乎每個禮拜我們都得連夜把好幾千棒的成品運送給憤怒的客戶。但現在，大家顯然都知道，不應該根據第一個工作站的效率來安排，而是根據瓶頸資源能夠支援的速度來安排工作。
在製品又稱為「沈默的殺手」，工廠控制在製品的能力不足，是造成常態性延誤與品質問題的根源之一。
三步工作法
一旦弄懂在製品對團隊造成的傷害，你就能踏上開始理解「三步工作法」（The Three Ways）的征途。
第一步工作法：幫助我們理解如何建立快速的工作流，讓工作順暢的從開發移動到 IT 運維部，因為那正是公司與客戶之間的銜接。
第二步工作法：告訴我們如何縮短及增強回饋循環，因而能夠從源頭開始解決品質問題，並且避免重工（rework）。
第三步工作法：告訴我們如何建立一種文化，既能鼓勵大家探索，從失敗中汲取教訓，又能理解反覆與練習是精通工作的先決條件。
工作的定義
比爾在救火的過程中，逐漸辨識出工作的類別，一共有四種。第一種是業務專案，例如，鳳凰專案。第二種是 IT 內部專案。為了支援業務或是 IT 內部專案，會有一些例行性的變更作業。然後，直到鳳凰專案失敗，比爾才明白最後一種，因為它阻礙了所有其他工作的完成，也就是最後一種 — — 救火工作，亦即，計畫外的工作。
目標：持續改善的流程
高德拉特博士的《目標》教導我們，在多數工廠，總有那麼一小部分的資源，不論是人員、機器或原物料，會決定整個系統的產出，我們稱之為約束點（contraint） — — 或瓶頸（bottleneck），兩者皆可。除非你建立可靠的系統，妥善管理通往約束點的工作流，否則，約束點經常是被浪費的，也就是說，約束點可能很大程度上未被充分利用。
比爾已經識別出這個叫做布倫特的人是回復服務的約束點，還發現他還約束了很多其他重要的工作流。所以我們可以從這個約束點開始，改善我們的流程。
團隊發展的五大障礙
比爾在一次與史蒂夫的爭論事件中離職了，因此，史蒂夫全面接管 IT 部門，回復到改善前的生產流程，造成毀滅性的災難。後來，史蒂夫發現自己的錯誤，將比爾找了回來，希望他重新開始改善計畫。史蒂夫找了各個部門的主管，進行了一次 Team Building 活動。
《團隊發展的五大障礙》，該書提及，想要在團隊中形成充分的互信，你必須展現出自己脆弱的一面，所以，史蒂夫要告訴大家一些關於他個人的事情，以及究竟是什麼讓他有動力走到今天，然後，史蒂夫請大家也那樣做。
技術債
未被償還的「技術債」源自於走捷徑，短時間內，那樣或許行得通，但是，就像金融債一樣，久而久之，利息越滾越多。如果一個組織沒有還清它的技術債，那麼，組織就必須一點一滴，耗費心力，以計畫外工作的形式來償還那些技術債衍生的利息。
正如你所知，計畫外的工作可不是免費的。恰恰相反，它們非常昂貴，因為處理計畫外的工作必須犧牲計畫內的工作。
計畫外的工作
計畫外的工作還有一個副作用，當你把所有時間都拿來救火時，自然就沒有時間和精力去制定妥善的計劃，而當你們只是被動地應付，就沒有足夠的時間進行繁重的腦力活動，徹底弄清楚是否可以接受新工作，於是，越來越多專案被塞進盤子裡，會有更多不良的多工處理，劣質程式碼的數量也會增加，這是 IT 的死亡螺旋。
當大家都習慣相信，說「不」是不被接受的回答，我們就變成百依百順的接單人員，盲目地按照既定的路徑辦事。
範疇錯誤
這傢伙就跟那個 QA 經理一樣，那個 QA 經理讓他的團隊為一個我們已經不再上市的產品撰寫幾百萬個新測試，然後針對一些不復存在的功能整理出一大堆的臭蟲報告，顯然，他犯了我們所謂的「範疇錯誤」。
目標連結
從來沒有人把 IT 部門的目標連結到高層的最高評估指標，作為達成組織目標的先決條件之一。傳統的組織架構裡，因為不知道彼此的部門目標，很容易造成「穀倉效應」，大家悶著頭，埋頭苦幹。但是從來都不知道完成事情以後，是否會對公司目標帶來正向影響。雖然書本沒有刻意提及目標管理，但是目前在矽谷很紅的 OKR，可以適時地幫助我們做目標管理。
自動化的 CI/CD
把建置和部署流程自動化，可以把基礎設施當作程式碼一樣地處理，就像開發部交付的應用程式那樣。那麼，為什麼要一天進行十次部署？我們的衝刺期（sprint interval）至少都還有三個星期，我們可沒那麼多東西讓你一天部署十次！但是如果我們以一天十次為目標，它可以更好的支持產品在不確定的環境中擁抱改變，例如：讓行銷部門修改他們自己的內容或業務規則，或者啟用更快速的實驗與 A/B 對比測試，看看怎樣做效果最好。
為什麼需要開發運維？
開發運維這種能力能夠創造巨大的競爭優勢，讓產品功能更快進入市場，並且提升客戶滿意度、市佔率、員工生產力以及工作幸福感，還能讓企業在市場上贏得勝利，為什麼？因為科技已經變成最主要價值創造流程，並且變成大多數公司開發客戶與維繫客戶的主要手段，而且重要性越來越高。相較之下，需要耗費幾週乃至幾個月來部署軟體的公司，在市場上往往處於不利的地位。
開發運維高度受益於「敏捷社群」開展的成果：高度相互信任的小團隊，小量批次規模以及較小範圍、更頻繁的軟體發佈，能夠大幅提升開發運維的生產力。事實上，在開發運維的歷史上，許多關鍵時刻均發生在敏捷開發的研討會，以及活力十足的 DevOps Day 活動中，這個活動於 2009 年首次舉行，此後便在世界各地展開。
四種工作類型
我們將 IT 部門的工作型態做了分類，一共有四種。但是，公司經理人大多時候只關注業務專案，長期忽視其他三種工作。
業務專案
這些大多數開發專案處理的業務計畫，通常隸屬於專案管理辦公室（PMO）。專案管理辦公室管理公司所有的正式專案。
IT 內部專案
這些包括可能由業務專案衍生處來的基礎架構或 IT 運維專案，以及內部生成的改善專案（例如，建立新環境和部署自動化）。這些專案經常未被集中管理，而是隸屬於預算所有者（例如，資料庫經理、儲存管理和分散式系統的經理）。
當 IT 開發運維形成瓶頸時，這會產生問題，因為沒辦法輕易查明到底已經在內部專案中投注多少生產能力。
變更
這些通常是由上述兩種類型的工作引起的，往往透過工單系統被追蹤（例如，IT 運維補救措施、JIRA、或者用於開發的敏捷計畫工具）。假如在價值流的兩個部分存在兩個工作追蹤系統，那會引起問題，尤其是在交接工作的時候。
偶爾，在某些兼負功能開發與服務交付責任的專屬團隊中，所有工作皆存在於同一個系統，這樣做有一些好處，因為運維層面的故障會跟功能缺陷及新功能一起被記錄在待處理工作清單中，並且呈現「處理中」的狀態。
計畫外工作或救火工作
這類工作包括運維的事故和問題，通常由上述三類工作導致，而且往往以犧牲其他計畫內工作作為代價。
為什麼需要以視覺化的方式呈現 IT 工作並且控管在製品（WIP）？
這張圖將「等待時間」（wait time）表示為工作中心之「資源忙碌程度」（resource busy）的函數，說明為什麼故事中「布倫特」的 30 分鐘簡單變更竟要耗費幾個星期才能完成，原因顯然是，身為所有工作瓶頸，布倫特的使用率一直是 100%，甚至超過 100%，因此，每次交辦給他的工作都只能在佇列裡枯枯守候，若不特意加速或升級，就無法處理。
圖表顯示：橫軸是工作中心的資源忙碌百分比，縱軸是大致的等待時間（或者，更確切的說，就是佇列長度）。根據曲線的形狀，當資源使用率超過 80% 時，等待時間就會直線飆升。
這張圖跟 Little’s Law 的概念很接近。在這張圖中，「等待時間」其實代表「佇列長度」，換言之，因為他不是使用經歷的時間，因此根本沒有時間單位。主要是想傳達，不同「資源忙碌程度」對於「等待時間」的急劇影響。
三步工作法（The Three Ways）
這是在 DevOps 裡著名的工作法，價值主張大多都已經涵蓋在敏捷開發裡。
第一步工作法（The First Way）
關乎從開發到 IT 運維再到客戶，從左到右的整個工作流（flow of work）。為了讓流量最大化，我們需要「小」的批次規模與「短」的工作間隔，絕對不讓缺陷流向下游的工作中心，而且，為了讓整體性目標持續最佳化（相對於局部目標，諸如開發功能完成率、測試發現率／修復率或者運維有效性指標等等）。
必要的實務作為包括連續建置、整合及部署，隨需建立環境，嚴控在製品以及建構能夠安全進行變更的系統和組織。
第二步工作法（The Second Way）
是關於價值流的各個階段中，由右至左持續流動的快速回饋，放大其效益，確保能夠防止問題再次發生，或者更快速地發現及修復問題，如此一來，我們就能在需要的地方建立或融入知識，從源頭開始確保品質。
必要的實務作為包括：當我們的建置與測試在部署管道中發生失敗時，「停止生產線」；每天持續改善日常生活；建立快速的自動化測試組，確保程式碼總是處於可部署狀態；在開發和 IT 運維之間建立共同的目標以及同甘共苦的文化；建立普遍性的產品遙測機制，讓每個人都能看到程式碼和環境是否按照設計運行，以及是否達到客戶的目標。
第三步工作法（The Third Way）
是關於創造公司文化，形成兩種風氣：持續不斷的實驗，這需要承擔風險並且從成功和失敗中汲取經驗和教訓；體認反覆和練習事達成精通的基本前提。
實驗與承擔風險讓我們能夠持續不斷地改善工作系統，這經常需要我們採用一些與過去數十年來大不相同的做法，一旦出問題，不斷的反覆與日常的操演便能提供足夠的技能和經驗，讓我們回復到安全區域並且恢復正常。
必要的實務作為包括：建立創新、勇於冒險（相對於畏懼或盲目服從命令）以及高度信任的文化（相對於低信任度的指揮控制文化），把至少 20% 的開發和 IT 運維週期分配給非功能性需求，並且持續強化及鼓勵大家進行改善活動。
後記：DevOps 到底是什麼？
這本書不是一本工具書，如果想要從書本中獲得工程實踐、管理方法，那你可能會有點失望。但是作者利用小說講故事的風格，描述故事主角比爾的一段奇幻旅程。在故事中慢慢帶出許多的概念，例如精實開發、看板、三步工作法、目標管理、開發維運等等。平易近人的文筆風格，讓讀者身歷其境感同深受，因為故事很真實，很容易可以映射到讀者身處的 IT 公司裡，發生共鳴。
故事最核心的概念是引導出 DevOps 如何改變開發部門和維運部門的關係，幫助公司提升產品的競爭力。筆者過去曾擔任 DevOps 工程師，對於這個主題相當熟悉。一般導入 DevOps 會有兩種做法，一種是在專案裡配置專職的 DevOps 工程師，另一種是專案團隊每個人共同分擔 DevOps 工作。
專職的 DevOps 工程師好處是對於專案的基礎設施、網路設定、服務監控、CI/CD 等等，會相當的熟悉。也因為是專職的關係，可以讓其他的工程師可以更專心的開發。
如果是由團隊成員分擔 DevOps 的工作，可以讓大家一起接觸到 DevOps 工作，讓大家理解開發與維運之間的關係，因此在系統設計上會考慮的比較全面。但是因為分攤的關係，也造成大家對於 DevOps 的深度比較不夠，也缺乏長期的規劃。
兩種方式各有優缺點，很多公司會在人力資源網站上招募 DevOps 工程師（當初我也是這樣被騙進去的），以為在團隊裡有 DevOps 工程師就是導入 DevOps。這種淺薄的方式，大多只是專注在自動化的 CI/CD。對於團隊來說，這的確是很大的進步，但是 DevOps 更多的是講公司的文化與團隊的合作。
很多人也不明白 DevOps 和敏捷開發間的關係，敏捷的概念比 DevOps 早了很多，在敏捷的實踐上，DevOps 不是必須的，但是我們需要理解的事，採用 DevOps 以後，可以更好的支撐敏捷的實踐。因此，我們可以把 DevOps 看成是敏捷的延伸。基本上，兩者很多的價值觀也是重疊且一致的。
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。
