系統管理員的工作十分重要，他們不僅需要技術方面的具體說明，更需要一般原則和方法的指導。《系統管理與網絡管理技術實踐(第2版)》源于作者在各種組織擔任系統管理員的經驗，論述了實踐中管理系統和網絡的應用經驗和方法，貫徹了實際工作中的6項重要原則：簡單、明確、通用性、自動化、交互性以及由簡入繁。在這些原則的指導下，《系統管理與網絡管理技術實踐(第2版)》講述了系統管理員的主要工作領域，還討論了改變管理模式、服務器升級、維護時間窗、Web服務、數據存儲文檔和轉換服務方面的問題。
《系統管理與網絡管理技術實踐(第2版)》內容獨特、針對性強，且表述方式生動有趣，是一本不可多得的系統管理和網絡管理參考書。《系統管理與網絡管理技術實踐(第2版)》適合系統和網絡管理人員閱讀，也適合計算機行業的從業人員參考。
《系統管理與網絡管理技術實踐(第2版)》第1版為系統和網絡管理員開創了新一代的IT管理方式。無論您使用的是Linux、UNIX還是Windows，《系統管理與網絡管理技術實踐(第2版)》描述了以前只是指導者向被指導者傳授的一些至關重要的實踐經驗。書中大量豐富而有趣的實例將新手引向對他們整個職業生涯都很有價值的高級框架，也可以幫助高級的專家渡過難關。 《系統管理與網絡管理技術實踐(第2版)》分為5個主要部分，幫助讀者全面了解系統管理的基本要素。講解升級和變更管理的最佳技巧，分類IT服務的最佳實踐，以及探討各種管理主題。每章都可分為“基本方面”和“更進一步”兩部分。完成了“基本方面”的工作，就會讓工作的所有其他方面變得更為輕松——例如首先適當地為某些工作設置自動化。“更進一步”中包含可以在基礎工作完成之后要做的所有高級事情，這些事情會讓客戶和經理們驚嘆不已。 書中包含了與如下主題相關的建議。 ·為了讓所有其他服務運行得更好，網絡和系統所需具備的關鍵要素。 ·構建和運行可靠、可擴展的服務，包括Web、存儲、電子郵件、打印及遠程訪問。 ·制訂和實施安全策略。 ·一次升級多臺主機，而不造成大面積停機。 ·規劃和執行完美安排的維護時間窗。 ·管理高級服務臺和客戶支持。 ·避免“臨時修復”陷阱。 ·構建改善服務器正常運行時間的數據中心。 ·針對速度和可靠性來設計網絡。 ·Web擴展和安全問題。 ·構建備份系統。 ·監控已有的東西，預測需要的東西。 ·面向技術的工人如何才能保持工作以技術為中心（避免擔任管理角色）。 ·技術管理問題，包括士氣、組織設立、培訓以及保持正面可見性。 ·個人技能技巧，包括每天如何完成更多的事情、做出兩難選擇、對付老板以及愛上自己的工作等方面的秘密。 ·系統管理薪水談判。
我們寫作本書的目的是，記錄下我們從導師那里學到的所有東西，再加上我們的實踐經驗，這些遠遠超出了使用手冊和一般系統管理書籍所涉及的內容。
本書源自我們在各種組織擔任系統管理員的經驗。我們最初在新成立的公司工作，幫助過站點成長，后來在小型公司和大學工作過，這些單位一般都缺少資金；在大中型國際公司工作過，這種公司常常因為合并和資產分派而面臨各種的挑戰；在快節奏的網絡商務公司工作過，高可用性、高性能和可伸縮性是這種公司的根本；在慢節奏的公司工作過，在這種公司，無繩電話就是所謂的高科技。從表面上看，這些是完全不同的環境，有著各自不同的困難，本質上，它們有相同的組成部分，應用著相同的原理。
本書將提供一種思考系統管理問題的方法，而不是簡單講解特定問題的解決方案。有了通用的方法，每次出現問題都可以自己解決，而不管涉及何種操作系統，何種品牌的計算機，何種類型的環境。本書與眾不同之處在于它從全局的角度來看待系統管理；而其他大多數面向系統管理員的書籍主要講述如何維護一個特定的產品，但經驗表明，高層次的問題和解決方案基本與平臺無關。本書將改變系統管理員的工作方式。
本書中的原理適用于所有環境，所描述的方法可能需要根據具體的環境進行變通，但基本的原理依然適用。在我們認為如何執行某些概念不是很明朗的地方，本書闡明了如何在各種規模的組織中應用這些原理。
本書不會介紹如何配置或調試特定的操作系統，也不會說明在有人誤刪了共享庫或DLL時如何恢復它們。一些已有的書籍介紹過這些知識，本書中多處提及到這些書籍。相反，我們討論從自己和他人的經驗中學到的好的系統管理原則，有基本的，也有高級的。這些原則適用于所有操作系統。很好地遵循這些原則可以使工作變得更輕松。如果改善解決問題的方式，那么會事半功倍。基礎工作做好了，后續的事情就會有條理。如果基礎工作沒做好，就會重復地浪費時間去修復相同的問題，客戶(本書中將系統的最終用戶稱為“客戶”，而不是“用戶”)就會不滿意，因為他們在有問題的機器上無法高效工作。
Thomas A.Limoncelli，Tom是系統管理、時間管理和基礎政策組織技術方面國際公認的作家和演講家。他從1988年就開始擔任系統管理員，在小型和大型公司都工作過，其中包括Google、Cibemet公司、Dean for America、Lumeta、AT&T、Lucent／Bell Labs和Mentor Graphics。在Google，他改進了在新辦公室部署IT基礎設施的方法。當.AT&T解體為AT&T、Lucent和NCR時，Tom領導團隊將Bell Labs計算和網絡基礎設施分解成3個新的公司。
除了本書的第l版和第2版，他出版的作品還包括Time Management for System Administration（2005），以及有關安全、網絡、項目管理和個人職業生涯管理方面的論文。他經常出席會議和用戶組，講授教程，實際指導系統管理工作，演示論文，或者受邀進行重要的演講。
除了工作，Tom還是公民權利方面的激進分子，獲得過美國和國際級別的獎項和認可。Tom發表的第一篇論文（Limoncelli，1997）中就宣揚了系統管理員可以從激進分子身上學習到的一些經驗教訓。Tom不太區分他的工作和激進分子生涯——兩者都是幫助別人。
他擁有Drew大學計算機科學系的學士學位。他居住在新澤西的Bloomfield。
由于他們的社團，Tom和Christina獲得了USENIX／SAGE頒發的2005年突出貢獻獎。
ChriStina J.Hoqan，Christina的系統管理職業生涯從都柏林trinity學院的數學系開始，她在那里差不多工作了5年。此后，她為尋求新的發展，搬到了西西里島，在一家研究公司工作了一年，然后又到加利福尼亞待了5年。
她曾在Synopsys擔任過幾年的系統架構師，然后就加入了朋友開的GNAC公司，她加入時，這個公司才成立幾個月。在這里，她接觸過剛成立的公司、電子商務站點、生物科技公司和大型的多國硬件及軟件公司。在技術方面，她主要關注安全性和網絡，跟客戶打交道，幫助GNAC建立數據中心和Internet連通性。她也參與了項目管理、客戶管理和人員管理。在GNAC工作了將近3年之后，她成為一個獨立的安全顧問，主要是在電子商務站點工作。
此后，她做了媽媽，轉變了職業生涯：她現在是BMW Sauber Formula 1 Racing團隊的空氣動力學者。她擁有倫敦.Imperial學院的空氣動力工程博士學位，都柏林Trinity學院的數學學士學位和計算機科學碩士學位，以及都柏林技術研究所的法律結業證。
strata R.Chalup，Strata是Virtual.Net公司的所有者和高級咨詢師，這是一家戰略和最佳實踐IT咨詢公司，專門幫助中小型公司在成長過程中擴展其IT實踐。在.com第一次大發展期間，Strata設計了可擴展的基礎設施，幫助一些團隊建立了項目，例如。talkway.net、Palm VII和mac.com。Virtual.Net在1993年成立時是一家獨資公司，2005年發展為合資公司。客戶已經包括Apple、Sun、Cimflex Teknowledge、Cisco、McAfee和Micronas LISA等公司。
Strata于1981年加入TOPS-20 on DEC大型機計算領域，然后于1983年開始管理UNIX，還加上VAX11一780上的Llltrix、Motorola 68K微系統上的Unisys以及Intel上的Minix。她對1981年以來的因特網服務的用戶和管理員有著與眾不同的看法，見證了我們所謂的現代網絡發展，有時候是從比較有利的位置看待這一切的。作為早期的采納者和連接者，她從1993年到1995年參加了早期的國家通信基礎設施管理（National Telecommunications Infrastructure Administration，NTIA）聽證會，1994年證實了出現Internet的可能性，召開了NTIA劃時代的虛擬會議。Strata是一個向前看的人，她隨時關注著新技術，以用于IT和管理。
她心里總是記得自己是一個新英格蘭人，卻與不喜歡雪的丈夫居住在加利福尼亞，Strata是一個勤勞的園丁、科幻小說的讀者以及業余無線電緊急服務志愿者（KF6NBZ）。她是SCUBA認證的，但是一般都是自由行動。Strata作為一個科技狂人，花了兩年時間開著RV在全國轉悠，第一次是在1990年，第二次是在2002年，一路上為大家提供技術咨詢。她曾經有一個業余愛好，就是研究能源高效的房屋構造和設計，包括舉辦自建業主學習班，真正為大家省錢。
跟她的那些著名的合著者不同的是，她大學肄業，大二就從MIT退學了。她管理了幾年“認知科學中心”，在EECS計算服務小組擔任咨詢師，其中有一年時間是作為郵件管理員的，最后進入硅谷。
第1部分 入門
第1章概述
1.1 從頭開始構建站點
1.2 擴展小型站點
1.3 面向全球
1.4 服務替換
1.5 遷移數據中心
1.6 搬遷到/開放新建筑
1.7 應對高頻率的辦公室搬遷
1.8 評估站點(盡職調查)
1.9 處理合并和收購
1.10 處理頻繁的計算機崩潰
1.11 克服大規模停機或工作中斷
1.12 每個SA小組成員應該使用的工具
1.13 保證工具歸還
1.14 需要文檔系統和過程的原因
1.15 需要文檔策略的原因
1.16 找出環境中的根本問題
1.17 為項目籌集更多資金
1.18 完成項目
1.19 始終讓客戶滿意
1.20 始終讓管理層滿意
1.21 始終讓SA滿意
1.22 防止系統變得過慢
1.23 妥善處理大批量的計算機
1.24 妥善安置大量的新員工
1.25 妥善安置大量的新SA
1.26 應對較高的SA小組離職率
1.27 應對較高的用戶群減員率
1.28 小組新成員的注意事項
1.29 團隊新管理人員的注意事項
1.30 尋找新工作
1.31 快速雇傭大量新SA
1.32 提高系統整體的可靠性
1.33 削減成本
1.34 增加功能
1.35 停止會造成損害的事情
1.36 建立客戶信心
1.37 建立團隊的自信心
1.38 改善團隊有始有終的作風
1.39 處理不道德的請求
1.40 洗碗機在杯子上留下了污點
1.41 保住工作的注意事項
1.42 獲得更多培訓
1.43 設置優先級
1.44 完成所有工作
1.45 緩解壓力
1.46 SA對管理人員的期望
1.47 SA管理人員對SA的期望
1.48 老板對SA管理人員的期望
第2章 擺脫困境
2.1 改進系統管理的幾個技巧
2.1.1 使用故障報告系統
2.1.2 正確管理快速的請求
2.1.3 采用3種省時的策略
2.1.4 啟動狀態已知的新主機
2.1.5 其他技巧
2.2 小結
練習
第2部分 基本原理
第3章 工作站
3.1 基本方面
3.1.1 安裝操作系統
3.1.2 更新系統軟件和應用程序
3.1.3 網絡配置
3.1.4 避免將動態DNS和DHCP一起使用
3.2 更進一步
3.2.1 對完成任務充滿信心
3.2.2 讓客戶參與標準化過程
3.2.3 標準配置的變化
3.3 小結
練習
第4章 服務器
4.1 基本方面
4.1.1 購買服務器專用的硬件
4.1.2 選擇著名廠商的可靠產品
4.1.3 了解服務器硬件的費用
4.1.4 考慮維護合同和備件
4.1.5 維護數據完整性
4.1.6 把服務器放在數據中心
4.1.7 客戶端服務器的操作系統配置
4.1.8 提供遠程控制臺訪問
4.1.9 鏡像引導盤
4.2 更進一步
4.2.1 增強可靠性和服務能力
4.2.2 另一種選擇：比較便宜的工作站
4.3 小結
練習
第5章 服務
5.1 基本方面
5.1.1 客戶要求
5.1.2 操作要求
5.1.3 開放式架構
5.1.4 簡單性
5.1.5 廠商關系
5.1.6 計算機獨立性
5.1.7 環境
5.1.8 限制訪問
5.1.9 可靠性
5.1.10 臺或多臺服務器
5.1.11 集中化和標準
5.1.12 性能
5.1.13 監控
5.1.14 服務的開展
5.2 更進一步
5.2.1 專用計算機
5.2.2 完全冗余
5.2.3 對擴展的數據流進行分析
5.3 小結
練習
第6章 數據中心
6.1 基本方面
6.1.1 位置
6.1.2 訪問
6.1.3 安全
6.1.4 電源和制冷系統
6.1.5 滅火系統
6.1.6 機架
6.1.7 布線
6.1.8 貼標簽
6.1.9 通信
6.1.10 控制臺訪問
6.1.11 工作臺
6.1.12 工具和物資
6.1.13 停留空間
6.2 更進一步
6.2.1 更多的冗余
6.2.2 更多空間
6.3 理想的數據中心
6.3.1 Tom夢想的數據中心
6.3.2 Christina夢想的數據中心
6.4 小結
練習
第7章 網絡
7.1 基本方面
7.1.1 OSI模型
7.1.2 簡潔的架構
7.1.3 網絡拓撲
7.1.4 中間配線架
7.1.5 主配線架
7.1.6 分界點
7.1.7 文檔
7.1.8 簡單主機路由
7.1.9 網絡設備
7.1.10 覆蓋網絡
7.1.11 廠商的數目
7.1.12 基于標準的協議
7.1.13 監控
7.1.14 單一管理域
7.2 更進一步
7.2.1 先進性與可靠性
7.2.2 多重管理域
7.3 小結
7.3.1 組網的不變內容
7.3.2 網絡設計中變化的內容
練習
第8章 命名空間
8.1 基本方面
8.1.1 命名空間策略
8.1.2 命名空間變更程序
8.1.3 集中管理命名空間
8.2 更進一步
8.2.1 巨大的數據庫
8.2.2 進一步自動化
8.2.3 基于用戶的更新
8.2.4 “下一級”命名空間普遍存在
8.3 小結
練習
第9章 文檔
9.1 基本方面
9.1.1 哪些內容需要歸檔
9.1.2 一個簡單的模板
9.1.3 容易的文檔來源
9.1.4 檢查清單的功能
9.1.5 文檔存儲
9.1.6 Wiki系統
9.1.7 搜索工具
9.1.8 推廣問題
9.1.9 自管理和顯性管理
9.2 更進一步
9.2.1 動態文檔存儲庫
9.2.2 內容管理系統
9.2.3 尊重的文化
9.2.4 分類與結構
9.2.5 其他的文檔使用方式
9.2.6 離線鏈接
9.3 小結
練習
第10章 災難恢復和數據完整性
10.1 基本方面
10.1.1 災難的定義
10.1.2 風險評估
10.1.3 法律義務
10.1.4 損害限制
10.1.5 準備工作
10.1.6 數據完整性
10.2 更進一步
10.2.1 冗余站點
10.2.2 安全性事故
10.2.3 和媒體的關系
10.3 小結
練習
第11章 安全策略
11.1 基本方面
11.1.1 詢問適當的問題
11.1.2 編制公司的安全策略文檔
11.1.3 技術人員應牢記的基本要點
11.1.4 管理和組織方面的問題
11.2 更進一步
11.2.1 讓安全性深入人心
11.2.2 保持最新：聯系和技術
11.2.3 制定衡量標準
11.3 組織概要
11.3.1 小型公司
11.3.2 中型公司
11.3.3 大型公司
11.3.4 電子商務網站
11.3.5 大學
11.4 小結
練習
第12章 道德規范
12.1 基本方面
12.1.1 事先通知征求同意
12.1.2 專業的行為規范
12.1.3 計算機使用指導方針
12.1.4 特權訪問的行為規范
12.1.5 遵守版權法規
12.1.6 和執法部門合作
12.2 更進一步
12.2.1 建立隱私和監視方面的預期
12.2.2 對被迫做的違法的不道德的事的處理
12.3 小結
練習
第13章 服務臺
13.1 基本方面
13.1.1 具有一個服務臺
13.1.2 友好的界面
13.1.3 反映公司文化
13.1.4 具備足夠的人員
13.1.5 定義支持范圍
13.1.6 說明如何獲得幫助
13.1.7 為服務臺人員定義流程
13.1.8 建立升級過程
13.1.9 書面定義緊急情況
13.1.10 提供請求跟蹤軟件
13.2 更進一步
13.2.1 統計的改進
13.2.2 下班時間以及24×7支持
13.2.3 為服務臺做好廣告
13.2.4 針對提供服務和解決問題有不同的服務臺
13.3 小結
練習
第14章 客戶服務
14.1 基本方面
14.1.1 階段A/第一步：問候
14.1.2 階段B：問題確定
14.1.3 階段C：計劃和執行
14.1.4 階段D：驗證
14.1.5 忽略某一步驟的危險
14.1.6 一個團隊
14.2 更進一步
14.2.1 基于模型的培訓
14.2.2 整體改進
14.2.3 增加與客戶的熟悉度
14.2.4 重要故障的特殊通知
14.2.5 趨勢分析
14.2.6 了解流程的客戶
14.2.7 符合流程的架構性決策
14.3 小結
練習
第3部分 改變過程
第15章 調試
15.1 基本方面
15.1.1 了解客戶的問題所在
15.1.2 找到問題的根源而不是癥狀
15.1.3 實現系統化
15.1.4 使用正確的工具
15.2 實戰指南
15.2.1 更好的工具
15.2.2 工具使用的正規培訓
15.2.3 全面理解系統
15.3 小結
練習
第16章 一次將問題解決
16.1 基本方面
16.1.1 不要浪費時間
16.1.2 避免暫時性修復
16.1.3 向木匠學習
16.2 理想情況
16.3 小結
練習
第17章 變更管理
17.1 基本方面
17.1.1 風險管理
17.1.2 交流結構
17.1.3 時間安排
17.1.4 流程和文檔編制
17.1.5 技術方面
17.2 實戰指南
17.2.1 自動化前端
17.2.2 變更管理會議
17.2.3 改進流程
17.3 小結
練習
第18章 服務器升級
18.1 基本方面
18.1.1 步驟1：編寫服務檢查清單
18.1.2 步驟2：確定軟件兼容性
18.1.3 步驟3：驗證測試
18.1.4 步驟4：編寫恢復計劃
18.1.5 步驟5：選擇一個維護時間窗
18.1.6 步驟6：在適當時機宣布升級
18.1.7 步驟7：執行測試
18.1.8 步驟8：拒絕客戶的訪問
18.1.9 步驟9：執行升級并進行監視
18.1.10 步驟10：測試所做的工作
18.1.11 步驟11：如果所有步驟失敗，則執行恢復計劃
18.1.12 步驟12：恢復客戶訪問
18.1.13 步驟13：通知客戶升級完成/恢復計劃
18.2 更進一步
18.2.1 同時添加和刪除服務
18.2.2 重新安裝
18.2.3 重用測試
18.2.4 記錄系統變更
18.2.5 練習
18.2.6 在同一臺機器上同時安裝新舊版本
18.2.7 減少基礎性變更
18.3 小結
練習
第19章 服務轉換
19.1 基本方面
19.1.1 最大限度地降低對客戶的影響
19.1.2 layer和pillar
19.1.3 通知
19.1.4 培訓
19.1.5 小組優先
19.1.6 快速切換：一次全部完成
19.1.7 恢復計劃
19.2 更進一步
19.2.1 迅速回滾
19.2.2 避免轉換
19.2.3 Web服務轉換
19.2.4 供應商支持
19.3 小結
練習
第20章 維護時間窗
20.1 基本方面
20.1.1 時間安排
20.1.2 規劃
20.1.3 飛行指導
20.1.4 變更建議
20.1.5 制定主控制計劃
20.1.6 禁止訪問
20.1.7 保證機制和協調
20.1.8 變更完成的最后期限
20.1.9 全面的系統測試
20.1.10 維護后通信
20.1.11 重新啟用遠程訪問
20.1.12 第二天上午按時上班
20.1.13 事后檢查
20.2 更進一步
20.2.1 指導一個新的飛行指導員
20.2.2 歷史數據趨勢分析
20.2.3 提供有限的可用性
20.3 高可用性站點
20.4 小結
練習
第21章 集中化和分散化
21.1 基本方面
21.1.1 指導原則
21.1.2 實現集中化的候選服務
21.1.3 實現分散化的候選服務
21.2 更進一步
21.2.1 合并采購
21.2.2 外包
21.3 小結
練習
第4部分 提供服務
第22章 服務監控
22.1 基本方面
22.1.1 歷史監控
22.1.2 實時監控
22.2 實戰指南
22.2.1 可訪問性
22.2.2 普遍的監控
22.2.3 設備發現
22.2.4 端到端的測試
22.2.5 應用響應時間監控
22.2.6 擴展
22.2.7 元監控
22.3 小結
練習
第23章 電子郵件服務
23.1 基本方面
23.1.1 隱私政策
23.1.2 命名空間
23.1.3 可靠性
23.1.4 簡單性
23.1.5 反垃圾郵件和防病毒
23.1.6 通用性
23.1.7 自動化
23.1.8 基本的監控
23.1.9 冗余
23.1.10 可擴展性
23.1.11 安全問題
23.1.12 通信
23.2 更進一步
23.2.1 加密
23.2.2 電子郵件保留策略
23.2.3 高級監控
23.2.4 大容量的列表處理
23.3 小結
練習
第24章 打印服務
24.1 基本方面
24.1.1 集中度
24.1.2 打印架構策略
24.1.3 系統設計
24.1.4 文檔
24.1.5 監控
24.1.6 環境問題
24.2 更進一步
24.2.1 自動失敗恢復和負載均衡
24.2.2 專人維護
24.2.3 粉碎紙張
24.2.4 對付打印機亂用
24.3 小結
練習
第25章 數據存儲
25.1 基本方面
25.1.1 術語
25.1.2 存儲管理
25.1.3 存儲服務
25.1.4 性能
25.1.5 對新的存儲解決方案進行評估
25.1.6 常見問題
25.2 更進一步
25.2.1 通過應用程序優化RAID使用情況
25.2.2 存儲限制：磁盤訪問密度差距
25.2.3 持續的數據保護
25.3 小結
練習
第26章 備份和恢復
26.1 基本方面
26.1.1 恢復的原因
26.1.2 恢復的類型
26.1.3 公司指導方針
26.1.4 數據恢復服務水平協議和策略
26.1.5 備份時間表
26.1.6 時間和容量規劃
26.1.7 耗材規劃
26.1.8 恢復過程的問題
26.1.9 備份自動化
26.1.10 集中化
26.1.11 磁帶清單
26.2 更進一步
26.2.1 故障演練
26.2.2 備份介質和異地存放
26.2.3 高可用性的數據庫
26.2.4 技術的發展
26.3 小結
練習
第27章 遠程訪問服務
27.1 基本方面
27.1.1 遠程訪問服務的需求
27.1.2 遠程訪問策略
27.1.3 服務等級的定義
27.1.4 集中
27.1.5 外包
27.1.6 認證
27.1.7 周界安全
27.2 更進一步
27.2.1 設在家中的辦公室
27.2.2 開銷分析及縮減開支
27.2.3 新技術
27.3 小結
練習
第28章 軟件存儲庫服務
28.1 基本方面
28.1.1 理解商業價值
28.1.2 理解技術需求
28.1.3 確定策略
28.1.4 選擇存儲庫軟件
28.1.5 制作處理指南
28.1.6 舉例
28.2 更進一步
28.2.1 不同主機的不同配置
28.2.2 本地復制
28.2.3 軟件存儲庫中的商業軟件
28.2.4 不常見的操作系統
28.3 小結
練習
第29章 Web服務
29.1 基礎知識
29.1.1 Web服務組件
29.1.2 Web站點管理員角色
29.1.3 服務水平協議
29.1.4 Web服務架構
29.1.5 監控
29.1.6 擴展Web服務
29.1.7 Web服務安全
29.1.8 內容管理
29.1.9 構建易于管理的中心Web服務器
29.2 糖衣
29.2.1 第三方Web主機服務
29.2.2 內容聚合應用程序
29.3 小結
練習
第5部分 管理實踐
第30章 組織結構
30.1 基本方面
30.1.1 規模
30.1.2 投資模型
30.1.3 管理鏈的影響
30.1.4 技能選擇
30.1.5 基礎設施團隊
30.1.6 客戶支持
30.1.7 服務臺
30.1.8 外包
30.2 更進一步
30.3 示例組織結構
30.3.1 小型公司
30.3.2 中型公司
30.3.3 大型公司
30.3.4 電子商務站點
30.3.5 大學和非盈利組織
30.4 小結
練習
第31章 理解和可見度
31.1 基本方面
31.1.1 良好的第一印象
31.1.2 態度、理解和客戶
31.1.3 使工作重點與客戶的期望保持一致
31.1.4 成為系統倡導者
31.2 更進一步
31.2.1 系統狀態網頁
31.2.2 管理會議
31.2.3 物理可見度
31.2.4 全體大會
31.2.5 業務通報
31.2.6 給所有客戶發送電子郵件
31.2.7 午餐
31.3 小結
練習
第32章 保持快樂
32.1 基本方面
32.1.1 堅持到底
32.1.2 時間管理
32.1.3 溝通技巧
32.1.4 提高專業能力
32.1.5 留在技術領域
32.2 更進一步
32.2.1 學會談判
32.2.2 熱愛本職工作
32.2.3 “管理”自己的經理
32.3 進一步閱讀
32.4 小結
練習
第33章 技術性管理者指南
33.1 基本方面
33.1.1 職責
33.1.2 與非技術性管理者相處
33.1.3 與員工相處
33.1.4 決策
33.2 更進一步
33.2.1 使團隊更強大
33.2.2 向高層管理部門推銷自己的部門
33.2.3 為自己的職業生涯做些工作
33.2.4 做些自己喜歡做的事情
33.3 小結
練習
第34章 非技術性管理者指南
34.1 基本方面
34.1.1 工作優先級和資源
34.1.2 士氣
34.1.3 溝通
34.1.4 員工會議
34.1.5 年度計劃
34.1.6 技術員工和預算流程
34.1.7 發展專業技能
34.2 更進一步
34.2.1 制定5年計劃
34.2.2 單點聯系
34.2.3 了解技術人員的工作
34.3 小結
練習
第35章 招聘系統管理員
35.1 基本方面
35.1.1 職責描述
35.1.2 技能級別
35.1.3 招聘
35.1.4 時間就是金錢
35.1.5 考慮團隊因素
35.1.6 面試團隊
35.1.7 面試過程
35.1.8 技術面試
35.1.9 非技術性面試
35.1.10 推銷職位
35.1.11 雇員保留
35.2 更進一步
35.3 小結
練習
第36章 解雇系統管理員
36.1 基本方面
36.1.1 遵循公司人力資源部門的規定
36.1.2 使用終止檢查列表
36.1.3 解除物理訪問權限
36.1.4 解除遠程訪問權限
36.1.5 解除服務訪問權限
36.1.6 擁有較少的訪問權限數據庫
36.2 更進一步
36.2.1 擁有單個認證數據庫
36.2.2 系統文件更改
36.3 小結
練習
附錄A 系統管理員的多種角色
A.1 一般角色
A.1.1 安裝者
A.1.2 修理工
A.1.3 維護者
A.1.4 問題預防者
A.1.5 英雄
A.1.6 中堅分子
A.1.7 基礎設施構建者
A.1.8 策略制定者
A.1.9 普通系統管理員
A.1.10 實驗室技術員
A.1.11 產品發現者
A.1.12 方案設計者
A.1.13 特殊方案發現者
A.1.14 非需求方案設計者
A.1.15 待命專家
A.1.16 培訓員
A.1.17 執法者
A.1.18 災難憂慮者
A.1.19 細心的計劃者
A.1.20 容量規劃者
A.1.21 預算管理員
A.1.22 客戶利益維護者
A.1.23 新技術論者
A.1.24 銷售員
A.1.25 供應商聯絡者
A.1.26 夢想者
A.1.27 母親
A.1.28 監視者
A.1.29 促進者
A.1.30 客戶/系統管理員
A.1.31 客戶支持
A.1.32 策略導航員
A.2 負面角色
A.2.1 新技術的盲目推崇者
A.2.2 新技術的阻礙者
A.2.3 喊“狼來了”的系統管理員
A.2.4 牛仔
A.2.5 奴隸、替罪羊或看門人
A.3 團隊角色
A.3.1 端到端專家
A.3.2 局外人
A.3.3 問題定位者
A.3.4 烈士
A.3.5 執行重復任務的實干家
A.3.6 社會工作主管
A.3.7 中途休息先生
A.4 小結
練習
附錄B 縮略詞
參考書目
嘗試擺脫困境的企業通常沒有大型的數據中心，但是有小型的計算機室，而且通常沒有散熱裝置。這些企業認為只要依靠建筑內的散熱裝置應該就足夠了，這對于一到兩臺服務器是沒有問題的。如果安裝較多的服務器，房間溫度升高，光靠建筑內的散熱裝置是不行的。沒人注意到，建筑的散熱裝置在周末是不打開的，因而到了周日房間會變得非常熱。長長的周末過去后，當周一發現所有的服務器都過熱時，周末留下的美好心情就會消失殆盡。在美國有一條不成文的規定，夏天是從5月底為期3天的Memorial Day（美國陣亡將士紀念日）周末開始的。因為這是一個長周末，而且通常也是一年中天氣變熱的第一個周末，所以人們經常在這時發現他們的散熱裝置不夠用。如果計算機在這個周末出現故障，那么整個夏天的情況也好不到哪里去。明智的做法是，在4月份對所有的散熱系統進行檢查。
花上不到400美元就可以安裝一個便攜式的散熱器，足夠讓一個不大的計算機室變得涼爽，并把熱量都排放到室外。這個不錯的臨時解決方案花費不大，不需要管理層的批準。如果空間比較大，租一臺5噸或10噸的散熱器不失為一個快速解決方案。
6.實現簡單的監控
盡管人們更愿意擁有一個具有很多額外功能且普遍適用的監控系統，但其實能夠ping關鍵服務器和通過電子郵件就問題向人們發出警告才是關鍵。在一些客戶的印象中，服務器往往是在周一早上崩潰的。而事實的真相是，由于缺少監控，各種問題累積了一周而導致計算機崩潰，只不過是在周一早上才發現而已。借助一些簡單的監控，就可以在客戶周一上班之前修復周末崩潰的問題（如果沒人聽到森林中有樹倒下，那樹倒下時是否發出聲音也就不重要了）。倒不是說應該把監控系統用于掩蓋周末停機的事實，在發出的郵件中始終聲稱問題已經修復，這才是優秀的PR。
2.2 小結
本書的余下部分將會關注SA企業更加高級的理想目標。本章描述了一個陷入問題泥沼的站點能夠實施的一些重大變化。
首先，要管理來自客戶的請求。客戶就是為之服務的人，通常稱為用戶。使用故障報告系統管理請求意味著，SA花在請求跟蹤上的時間將會更少，并讓客戶能夠更好地了解他們的請求的狀態。故障報告系統可以改善SA由始至終處理用戶請求的能力。
為了正確地管理請求，開發一個系統，以便阻礙其他任務的請求能夠更早地完成。兩邊交涉的盾牌可以讓SA不僅可以解決緊急請求，而且仍然有時間完成項目工作。讓SA根據客戶期望解決請求是一種企業結構。
一般說來，人們面臨的很多問題都源于對如何和何時獲得幫助的意見不合，或者期望存在分歧。要彌補這些不和諧的因素，通過編寫3條策略，即如何獲得計算機支持、SA的責任范圍，以及什么是IT緊急事件，來降低產生混淆的可能性。
啟動狀態已知的新主機很重要，這樣做可以使計算機部署變得更加容易，減輕客戶支持的壓力，并為客戶提供更加一致的服務。
新書資訊