-
簡介
這本書是我讀過唯一本關於計算機技術的小說，讀起來沒有無趣的編程語法和晦澀難懂技術詞彙，而是跟隨主人公一路過五關斬六將解決IT運維管理中的問題。書中講述了無極限零部件公司爲了重新佔有市場份額徹底擊敗對手，而啓動鳳凰項目，然而該項目上線一再延遲。我們的主人公”比爾“在這樣情況下臨危受命，由中型機技術總監提拔爲IT運營部副總裁，負責整個公司IT運營管理。主人公在高人指點下，加之主人公光環參透了IT運維工作的四大內容和”三步工作法“，用這些理論使公司IT部門更好的服務於業務，最終幫助公司擺脫危機並佔領市場，當然也再次升職加薪。
-
感同身受
下面我們就一起起看看這本書中暴露的IT運維的問題，想必都是搞運維的痛處：
1.IT預算和人員資源總是傾向於開發，不給運維資源，而只是派活。
2.運維人員培養一致是一個問題，工程師不會記錄故障處理方式，缺乏知識共享。
3.運維關鍵資源一直是瓶頸，一個運維大牛包攬一切。
4.變更管理流程形同虛設，運維工作處於失控狀態，經常由於變更產生生產問題，運維人員忙着救火。
5.運維人員超負荷工作，關鍵資源一直處於飽和狀態，而運營總監對運維人員工作內容與狀態不能掌控。
6.遇到故障，運維團隊缺乏信任，相互推卸責任，並且也沒有故障處理機制與預案。處理故障往往依靠一個人或某幾個人。
7.CEO或者整個IT團隊領導，直接干涉運維人員的工作，工程師被迫瞎忙。
8.運維團隊不參與項目架構評審和計劃會議，沒有團隊共享精神。
。。。。
以上是我在書中看到IT運維問題（可能你比我看到更多），這也都是都是我親身經歷過的，感同身受。想知道主人公如何破解這些問題還是認真讀讀這本書。
-
摘抄
摘抄幾條書中我印象深刻的語句：
1.”變更“就是對應用程序、數據庫、操作系統、網絡或硬件進行的物理、邏輯或虛擬操作，並且這樣的操作可能對相關服務產生影響。
2.流程是用來保護人的。我們得想出保護布倫特的辦法。
3.程序員們，乃至像我這樣的經理，每隔幾年要學的東西都幾近瘋狂。有時候完全是全新的數據庫技術，全新的編程或項目管理方法，或者全新的技術交付模型，比如雲計算。
4.你們需要把一些人稱爲’非功能性需求’的東西設計到產品當中。(比如質量、可擴展性、可管理性、安全性、可操作性等)
5.想要在團隊中達成相互信任你需要展現出自己脆弱的一面。
6.你剛纔描述的是未償還的技術債務。它來自於走捷徑，那在短時間也許行的通。但是就像金融債務一樣，久而久之，利息成本會越來越高。如果一個部門沒有付清它的技術債務，公司的每一努力都將以計劃外工作的形式來償還那些技術債務的利息。
7.我們給你們付工資，是爲了讓你們思考，而不只是執行。
8.你們應該對所有東西都進行版本控制。所有東西，不只是代碼。。。。
。。。。。。。。
書中”約束點“這個概念也讓我記憶猶新，可以說本書主線也是一個主人公不斷突破”約束點“的過程，第一約束點是技術大牛”布倫特“，所有問題都繞不開他；第二約束點運維與開發的壁壘；第三約束點外包的系統。
-
書中重點概念
下面是書中核心內容四種工作類型和三步工作法（基本摘自原文）：
四種工作類型：
- 業務項目:業務部門發起的項目，由項目管理辦公室管理。
- IT內部項目：包括可能由於業務項目衍生出的基礎架構或IT運維項目，以及內部生成的改進項目（例如部署自動化）。這些項目經常非集中跟蹤，屬於預算所有者（例如數據庫經理、分佈式經理）。
- 變更：經常由上述兩種類型的工作引起。
- 計劃外工作或者救火工作：操作事故和操作問題，由上述三種類型的工作導致，而且往往以犧牲其他計劃內工作爲代價。
三步工作法：
- 第一工作法是關於從開發到IT運維再到客戶的整個自左向右的工作流。爲了使流量最大化，我們需要小的批量規模和工作間隔，絕不讓缺陷流向下游工作中心，並且不斷爲了整體目標（相對於開發功能完成率、測試發現/修復比率或運維有效性指標等局部目標）進行優化。必要的做法包括持續構建、集成以及部署，按需創建環境，嚴控半成品，以及構建起能夠順利變更的安全系統和組織。
- 第二工作法是關於價值流各階段自右向左的快速持續反饋流，放大其效益以確保防止問題再次發生，或者更快地發現和修復問題。這樣，我們就能在所需之處獲取或嵌入知識，從源頭上保證質量。必要的做法包括：在部署管道中的構建和測試失敗時“停止生產線”；日復一日地持續改進日常工作；創建快速的自動化測試套裝軟件，以確保代碼總是處於可部署的狀態；在開發和IT運維之間建立共同的目標和共同解決問題的機制；建立普遍的產品遙測技術，讓每個人都能知道，代碼和環境是否在按照設定的運行，以及是否達到了客戶的目標。
- 第三工作法是關於創造公司文化，該文化可帶動兩種風氣的形成：不斷嘗試，這需要承擔風險並從成功和失敗中吸取經驗教訓；理解重複和練習是熟練掌握的前提。嘗試和承擔風險讓我們能夠不懈地改進工作系統，這經常要求我們去做一些與幾十年來的做法大不相同的事。一旦出了問題，不斷重複的日常操練賦予我們的技能和經驗，令我們可以撤回至安全區域並恢復正常運作。必要的做法包括營造一種勇於創新、敢於冒險（相對於畏懼或盲目服從命令）以及高信任度（相對於低信任度和命令控制）的文化，把至少20%的開發和IT運維週期劃撥給非功能性需求，並且不斷鼓勵進行改進。
夜深了😪！