第一章 信息系統運維概述

1.1 信息系統概述

信息的含義和類型

• 信息的含義：

  • 一般：人們關心的事情的消息或知識。
  • 香農（信息論創始人）：用來減少隨機不確定性的東西（標志著信息科學進入定量研究階段）。
  • 維納（控制論專家）：信息就是信息。
  • 一般2：對事物之間相互聯系、相互作用的狀態的描述。
  • 物質、能量、信息互相有區別，又相互依存，信息是人類了解自然及人類社會的憑據。
  • 

• 信息的分分類：

  • 按產生信息的客體性質分：

    • 自然信息:聲、光、熱、電等

    • 生物信息:遺傳信息，生物體內、動物種群內的信息交流

    • 機器信息:自動控制系統

    • 社會信息:人與人之間交流的信息

  • 按信息所依附的載體特征分：

    • 文獻信息、聲音信息、電子信息、生物信息等

• 信息的主要特征： （出題一般通過案例判定，理解性記憶）

  1. 可傳輸性：本質特征，可借助載體脫離信源傳輸，可轉換載體而不影響內容。
  2. 可存儲性：積累、加工、應用的基礎。
  3. 可加工性：擴充、壓縮、分解、綜合、排序等。
  4. 共享性：共享不會導致原有享用者失去部分或全部信息。
  5. 時滯性：有時間延遲。
  6. 再生與增值性：再生是信息價值耗盡后，出于某種目的又有新的用途（天氣預報案例）；增值是在量變的基礎上產生了質變（工廠信息案例）。
  7. 轉化性：物質、能量、信息的互相轉化。

系統與信息系統

• 系統的定義： 為了達到某種目的而互相聯系的部件的集合。

• 系統的特征： 整體性、目的性、關聯性、層次性（環境-系統-子系統，即一個系統必然被包括在一個更大的系統中）。

• 信息系統的定義： 由計算機硬件、計算機軟件、網絡和通信設備、信息資源和信息用戶組成的，以處理信息為目的的人機系統。人們構造信息系統來采集、處理、存儲和分發數據，為組織運營與決策服務。（可能選擇填空）

• 系統的分類

  • 按綜合復雜程度分:生物系統、物理系統、人類社會及宇宙系統

  • 按抽象程度分:概念系統、邏輯系統、物理系統

  • 按系統功能分:社會系統、經濟系統、軍事系統、企業管理系統

  • 按與外界關系分:封閉系統、開放系統

  • 按系統內部結構分:開環系統、閉環系統

• 信息系統的核心要素（常考）：

  1. 技術——基本支撐、物理構成：
     • 數據（信息、知識、智慧）
     • 硬件（中央處理器、存儲器、輸入設備、輸出設備）
     • 軟件（基礎軟件、信息系統軟件）
     • 通信網絡
     • 基礎設施
  2. 人
  3. 組織——隸屬并服務的主體
     • 信息機構在組織中的地位
       • 
       • 

• 信息系統的影響因素： （會考：做題時需要能歸類，哪個屬于內部，哪個屬于外部）

  • 內部因素：【站管用i現都是其內在】 戰略計劃、管理高層、用戶需求、IT部門、現行信息化基礎（遺留系統的不同步、信息孤島等現象，帶來的系統同步和集成問題）。
  • 外部因素： 技術（指的是外部飛速發展的技術，而非公司內部采用的現有技術）、供應商、客戶、競爭對手、經濟環境、政府。
  • 

1.2 信息系統運維

概念

• 信息系統運維： 基于規范化的流程，以信息系統為對象，以例行操作、響應支持、優化改善和咨詢評估等為重點，使信息系統運行時愈加安全、可靠、可用和可控，提升信息系統對組織業務的有效支持，實現信息系統價值。

• 傳統運維包含的觀點： （強調軟件發布這個時間節點，以運維明確為信息系統生命周期的最后一個階段，側重軟件的運維）

  • 泛化的觀點：軟件交付后圍繞它的任何工作。
  • 糾錯的觀點：軟件運行中錯誤的發現和糾正。
  • 適應的觀點：適應內外環境變化。
  • 用戶支持的觀點：為軟件最終用戶提供支持。

• 新的觀點： 認為信息系統運維于生命周期中的啟動時間被提前，貫穿于生命周期的始終。

不同視角下的信息系統運維

• 管理的視角（對于軟硬件的綜合管理）
• 服務的視角（以客戶為中心）
• 安全的視角（重在預防）
• 治理的視角（對IT繼續管控，管理控制，決策等）
• 實踐的視角（了解、熟悉、精通各類環節以便解決問題）

框架

• 
• 基本目標： （掌握基本目標、內容）
  • 安全
  • 可靠
  • 可用
  • 可控
• 內容：
  • 例行操作
  • 響應支持
  • 優化改善
  • 咨詢評估
• 運維對象：
  • 信息技術基礎設施（數據、基本網絡、網絡設備、硬件環境、基本環境）
  • 信息系統1, 信息系統2, 等
• 工具
• 流程
• 運維支持要素： （支撐運維工作的軟環境）
  • 運維管理部門
  • 運維管理人員
  • 運維管理制度
  • 運維管理設施

可維護性

• 定義： 對系統進行維護難易程度的度量。
• 影響系統可維護性的因素： 可理解性、可測試性、可修改性（注意區分第四章中，有5個可的要求）。
• 能間接衡量系統可維護性的特征：
  • 識別問題的時間、
  • 管理延遲時間、
  • 維護工具的收集時間、
  • 分析診斷問題的時間、
  • 修改設計說明書的時間、
  • 修改程序源代碼的時間、
  • 局部測試時間、
  • 系統測試和回歸測試的時間、
  • 復查時間、
  • 恢復時間。

系統維護工作的特點

1. 是否采用結構化開發方法對系統維護工作有極大影響。
2. 系統維護要付出很高的代價（非生產性活動，如理解代碼功能、接口、性能等。生產性活動，如分析評價、修改設計等）。
3. 系統維護工作對維護人員要求較高（整個過程、每個層次的了解）。
4. 系統維護工作的對象是整個系統的配置。
5. 系統維護經常遇到很多問題（例如，絕大多數問題是設計階段造成的，修改牽一發動全身；維護不具備挑戰性，吸引力不高等）。

信息系統運維的要求

• 銀行業： 可用性要求級別高（持續性、穩定性、不宕機、6個9的要求），安全性要求級別高，數據運維責任重大（實時、高并發，數據集中牽一發動全身）。
• 大型網站： 線上穩定、業務連續（邊開發邊運維，因此對穩定性、連續性造成挑戰），客戶體驗優先，迫切要求解決峰值運維問題，自動化要求高（業務應用的變更、創新開發、部署上線是相似度極高的重復勞動）。
• 電信行業： 以電信業務運營支持系統（BOSS，融合BSS和OSS）為核心。“全程全網性”的基礎設施運維（規模大、結構復雜、跨地域），數據利用和分析的需求強烈（差異化客戶服務），運維成本壓力大（基礎設施固定投資規模大）。
• 政府： 安全級別高，業務的不間斷運維需求高，例行運維亟需加強。
• 制造業： 集成運維需求強烈（涉及設計、生產、管理三方面，容易產生信息孤島，上下游供應鏈協同要求），運維管理亟待重視，安全運維不可忽視（內網暢通、技術資料保密、知識產權保護）。

1.3 信息系統運維的發展

發展現狀

• 三個“二八現象”（應該做到但未做到的）：
  • 從時間周期看，運維應占據80%。
  • 從信息系統效益看，信息系統的“用好”、優化占80%。
  • 從資金投入上看，（重開發輕服務）運維要占80%。

發展階段（重點）

• 信息技術基礎設施庫（IT Infrastructure Library, ITIL）是IT服務管理領域最佳實踐的國際標準。（順序，縮寫重點記憶）
  1. 網絡系統管理（Network System Management, NSM）： 包含IT基礎架構建設和以IT設備為核心的IT基礎設施管理，兩任務并行且融合。
  2. IT服務管理（IT Service Management, ITSM）： 解決以上缺乏智能互聯、資源浪費和效率低下的問題。是對業務信息化流程的梳理，依托于標準和制度。強調以客戶為中心，以流程為導向。
  3. 業務服務管理（Business Service Management, BSM）： 強調從業務目標出發優化IT服務，即IT和業務融合。

發展趨勢

• 理念層面——運維之道：
  • 服務（從技術支持范疇上升為業務服務）
  • 敏捷（敏捷運維，需要1自動化工具，2需要DevOps）
• 管理層面——運維之略：
  • 業務服務管理 BSM
  • IT運維成熟度
  • 外包
• 技術層面——運維之術：
  • 自動化
  • 虛擬化
  • 數據化
  • 綠色化（節能減排）

1.4 常見的信息系統

1. 財務系統：會計信息系統（訂單處理，庫存，會計應收/應支，總賬? 子系統） + 財務信息系統（內部審查，財務情報，輸出，預測，資金管理，財務控制? 子系統）。
2. 辦公自動化系統（OA）：
   • 三個階段：以數據處理為中心的傳統MIS系統 → 以工作流為中心 → 以知識管理為中心。
   • 特點：用戶界面簡單美觀易操作、流程控制靈活，便于擴展修改、安全措施全面，方便維護管理。
   • 組成：硬件是計算機及其外設，基本軟件是系統軟件，專用處理系統是文字、語音、圖像等處理系統
3. 業務處理系統（TPS）基礎業務人員使用：
   • 五個步驟：數據輸入、業務處理、文件和數據庫處理、文件和報告產生、查詢和處理活動。
4. 生產管理系統：
   • 物料需求計劃 MRP、閉環式MRP、制造業全面資源計劃與控制系統 MRP-II。
5. ERP系統/企業資源計劃系統：
   • 整合了客戶需求、企業內部制造活動、供應商制造資源。
   • 核心管理思想：體現對整個供應鏈資源進行管理的思想。
   • 體現精益生產、敏捷生產和同步工程的思想。
   • 體現事前計劃和事前控制的思想。
   • ERP運用成功的標志：系統運行集成化、業務流程合理化、績效監控動態化、管理改善持續化。
   • ERP的四項核心技術：軟件體系結構、企業建模（企業戰略規劃、信息系統戰略規劃、信息系統實現、信息系統運行維護）、集成框架與平臺、工作流。
6. 客戶關系管理系統（CRM）：
   • 包括：市場營銷管理子系統、銷售管理子系統、客戶服務和支持管理子系統、伙伴關系管理子系統。
7. 人力資源系統（HRIS）：
   • 輸入子系統（記賬子系統、人力資源研究子系統、人力資源情報子系統）
   • 輸出子系統（人力計劃子系統、招聘子系統、人力管理子系統、酬勞子系統、津貼子系統、環境報告子系統）。

第二章 信息系統運維的組織與管理

2.1 信息系統運維的管理

框架

本節首先給出了信息系統運維管理的框架圖，其中包含了主體、對象、流程、職能、目標等要素。

• 
• 主體： 信息系統運維外包商、信息系統運維管理部門、信息系統運維管理者。
• 對象： 運維部門和人員、信息系統供應商、信息系統用戶、信息系統數據、信息系統軟件、信息系統硬件。
• 流程： 資產管理、流程管理、監控管理、外包管理、綜合管理、安全管理。這些流程又可以進一步細化為事件管理、事故管理、問題管理、配置管理、變更管理、發布管理、知識管理等主要流程。
• 職能： 信息系統基礎設施運維、信息系統軟件運維、信息系統數據運維、信息系統安全運維。
• 目標： 安全、可靠、可用、可控、提升效率、降低成本。
• 管理： 通過管理標準、管理制度和管理規范來指導。
• 工具： 用于支持各項運維流程的實施。

流程的目的

• 標準化:通過流程框架，構件標準的運維流程。
• 流程化:將大部分運維工作流程化，確保工作可重復，并且這些工作能有質量地完成，提升運維工作效率。
• 自動化:基于流程框架事件與運維管理流程相關聯，一但被監控的系統發生性能超標或宕機，會觸發相關時間及事先定義好的流程，可自動啟動故障響應和恢復機制;此外，還可以通過自動化手段有效完成日常工作。

主要流程

流程的實現是基于運維管理系統的，且是閉環方式結束。利用運維管理系統固化運維服務工作流程，提供標準的、統一的服務規范，并提供靈活的流程定制功能。

主要流程包括：事件管理、事故管理、問題管理、配置管理、變更管理、發布管理、知識管理。

---

1. 事件管理

• 
• 概念： 引起或可能引起服務中斷或服務質量下降的不符合標準操作的任何活動。（事件相對事故，包括較為常見和廣泛的，包括故障，也包括用戶的查詢請求等。但事故管理一般針對比較嚴重的故障）
• 目的： 記錄、快速處理信息系統運維管理中的突發事件，并進行分級分類，詳細記錄事件處理的全過程，便于跟蹤了解事件的整個處理過程，并對事件處理結果統計分析。
• 涉及的流程： 事故管理、問題管理、變更管理。
• （事件相對事故，包括是較為常?和?泛的，包括故障，也包括?戶的查詢請求等。但事故管理?般針對?較嚴重的故障）
• 事件是指引起或可能引起服務中斷或服務質量下降的不符合標準操作的活動。
• 主要活動：
  1. 事件發生和通告： 事件發生后，配置項以輪詢（被動）和通知（主動）兩種方式產生通告信息。
  2. 事件監測和錄入
  3. 事件過濾：哪些事件才是我們要的。
  4. 事件分類：
     • 信息類——存入日志文件中
     • 告警類——提交給事件關聯進一步分析
     • 異常類——判定是否提交給事故、問題、變更管理中的一個或多個管理流程處理
  5. 事件關聯： （針對告警類）將告警類事件與一組標準和規則（業務準則）比較。
  6. 響應選擇： （針對告警類）自動響應 / 報警和人為干預。
  7. 事件關閉：
     • 信息類通常不存在關閉狀態。
     • 自動響應的告警類通常被設備或應用程序所自動觸發的另一事件關閉；人為干預的告警類通常在合適的人員或團隊處理完畢評估后關閉。
     • 異常類通常在成功啟動事故、問題或變更管理流程后評估關閉。
  8. 事件評估： 抽樣的方式，重點關注事件是否被正確移交并處理。

---

2. 事故管理

• 
• 概念： 針對比較嚴重的故障。（事故管理不包括與中斷無關的正常運營指標或服務請求信息，且找根本原因不是事件/事故管理的重點，只需要解決問題、恢復運營）
• 目的： 解決問題、恢復運營。
• 涉及的流程： 事件管理、問題管理、變更管理。
• 利用的工具/知識庫： KEDB (已知錯誤數據庫)、CMDB (配置管理數據庫)。
• 主要活動：
  1. 事故識別和記錄： 包括事故基本描述、事故狀態、事故類型、事故影響度、事故優先級。
  2. 事故分類和優先級處理： 根據緊急度、影響度決定優先級。
  3. 初步支持
  4. 事故升級：
     • 職能性升級（水平）： 將事故移交給更專業或更具備相關技術知識的同級支持人員或團隊。
     • 結構升級（垂直）： 將事故移交給更高管理層級或更具權限的人員。
  5. 調查和診斷
  6. 解決和恢復

---

3. 問題管理

• 
• 目的： 包括診斷事故根本原因和確定問題解決方案所需的活動，從而防止事故再次發生，減少事故的影響。
• 涉及的流程： 事件管理、事故管理、變更管理。
• 主要活動：
  1. 問題檢測和記錄： 包括問題描述、問題狀態、問題類型、服務信息、設備信息等。
  2. 問題分類和優先級處理
  3. 問題調查和診斷： 提到了時序分析法、KT 決策法、頭腦風暴法、石川圖法、帕累托分析法等方法用于分析問題原因。
  4. 創建已知錯誤記錄 (Known Error Record)： 記錄問題的根本原因和臨時的解決方案。
  5. 解決問題： 確定問題的最終解決方案。
  6. 關閉問題
  7. 重大問題評估： 對重大問題進行回顧和分析，吸取經驗教訓。

---

4. 配置管理

• 
• 概念： 負責管理服務生命周期過程中對配置項的變更。
• 目的： 維護配置項及其相互關系的準確信息，從而支持其他的服務管理流程。
• 涉及的流程： 事件管理、事故管理、問題管理、變更管理、發布管理。
• 主要活動：
  1. 管理規劃： 規劃配置管理的范圍、目標、政策和程序。制定一份總體計劃。
  2. 配置識別： 識別需要管理的配置項 (CI)，并分配唯一的標識符。
  3. 配置控制： 管理配置項的基線和版本，控制對配置項的修改。
  4. 狀態記錄和報告： 記錄配置項的狀態變化，并生成報告。
  5. 確認和審核： 定期驗證配置信息的準確性，進行配置審計。

---

5. 變更管理

• 
• 概念： 負責管理服務生命周期過程中對配置項的變更。
• 目的： 以受控的方式實施變更，降低變更帶來的風險，同時快速有效地響應業務需求。
• 涉及的流程： 事件管理、事故管理、問題管理、配置管理、發布管理。
• 主要活動：
  1. 創建變更請求 (RFC - Request For Change)
  2. 記錄和過濾變更請求： 對變更請求進行初步審查。
  3. 評審變更： 評估變更的必要性、可行性和潛在影響。
  4. 授權變更： 根據變更的類型和風險級別，由不同的角色或委員會進行批準。
     • 標準變更： 通常有預定的執行流程，不需要得到 CAB（變更咨詢委員會 Change Advisory Board）和變更管理者的授權，而直接轉交“請求實現”處理。
     • 次要變更： 無需 CAB，直接由變更管理者批準實施。
     • 實質性變更： 變更管理者根據變更風險、緊急度和影響度決定，是否征求 CAB 成員意見或召開 CAB 會議。
     • 重大變更： 必須事先得到 IT 執行委員會評審，再交由 CAB 討論具體實施方案。
  5. 變更規劃： 制定詳細的變更實施計劃。
  6. 協調變更實施： 協調相關人員和資源，執行變更計劃。
  7. 回顧和關閉變更： 評估變更實施的效果，記錄經驗教訓，并關閉變更請求。

---

6. 發布管理

• 
• 概念： 變更的后繼過程，指的是將變更實施到生產環境的過程。
• 目的： 交付、分發并追溯發布中的一個或多個變更（變了要通知發布，讓所有人知道）。確保只有經過測試的、正確無誤的信息版本才能發布到運行環境中，保證安全可靠，并控制發布風險，避免或減少失敗影響。
• 涉及的流程： 配置管理、變更管理、問題管理。
• 主要活動：
  1. 發布規劃： 規劃發布的范圍、時間表和策略。
  2. 發布設計、構建和配置： 設計發布包，構建和配置發布內容。
  3. 發布驗收： 對發布包進行測試和驗收。
  4. 試運行規劃： 規劃發布的試運行。
  5. 溝通、準備和培訓： 向相關人員溝通發布信息，進行必要的準備和培訓。
  6. 發布分發和安裝： 將發布包分發到生產環境并進行安裝。

---

7. 知識管理

• 
• 概念： 貫穿整個服務管理生命周期，是服務管理的基礎和重要組成部分。
• 目的： 積累和分享運維知識，提高解決問題的效率，支持決策，促進持續改進。
• 涉及的流程： 配置管理、變更管理、問題管理。
• 主要活動：
  1. 知識識別和分類： 識別需要管理的知識，并進行分類。
  2. 初始化知識庫： 建立知識庫系統。
  3. 知識提交和入庫： 收集知識并提交到知識庫（提交的知識存入臨時知識庫，待知識審核人員進行審批）。
  4. 知識過濾和審核： 對提交的知識進行審核。
  5. 知識發布和分享： 將審核通過的知識發布到正式知識庫，并分享給需要的人員（通過審核的知識轉移至正式知識庫）。
  6. 知識維護和評估： 定期更新和評估知識的有效性。

---

管理流程考法

考查方式主要為概念，但現在越來越多的結合實際使用場景。

運維管理制度

文檔列舉了常見的運維管理制度，包括：網絡管理制度、系統和應用管理制度、安全管理制度、存儲備份管理制度、故障管理制度、技術支持工具管理制度、人員管理制度、質量考核制度。并詳細說明了網絡中心管理制度和運行管理制度（包括日常運行記錄制度）的主要內容。

2.2 信息系統運維的組織

任務

運維組織的任務主要包括日常運行管理、運行日志記錄和運行情況的檢查與評價。

(a) 日常運行管理

日常運行管理是運維組織最基礎和核心的任務，涉及對信息系統各種資源的有效管理和維護。

1. 數據資源管理：
   • 涉及數據收集、數據校驗、數據錄入、數據處理等活動。
   • 數據資源是信息系統最重要的資源。
2. 軟件資源管理：
   • 包括軟件采購、軟件保存、相關文檔保存。
   • 軟件的分發與安裝配置。
   • 運行技術支持。
   • 對軟件的評價與性能檢測。
   • 對用戶的軟件使用培訓。
3. 硬件資源管理：
   • 硬件設備的日常檢查和維護。
   • 硬件故障的分析和排除。
   • 硬件的更新、擴充、修復。
   • 硬件的適應性維護。
4. 系統安全管理：
   • 確保系統的可用性（指系統處于可工作狀態的時間比例，常以“幾個 9”來量化）。
   • 確保系統的完整性。
   • 確保系統的保密性。
   • 確保系統的可控制性。
   • 確保系統的可靠性（指系統在一段時間內不發生故障的能力）。
5. 信息服務需求管理：
   • 管理用戶對信息服務的各種需求。

(b) 運行日志記錄

• 記錄內容包括工作數量、工作效率、質量、維護修改情況、故障情況等。
• 必須重視正常運行時的情況記錄，主要靠人工方式記錄。

(c) 運行情況的檢查與評價

對信息系統運行情況進行檢查和評價時，需要考慮以下三個方面：

1. 系統是否達到預定目標： 評估系統是否滿足了最初設定的目標，并判斷是否需要修改這些目標以適應新的情況。
2. 系統的適應性、安全性評價： 評估系統對環境變化的適應能力以及系統的安全性。
3. 系統的經濟效益評價：
   • 評估系統的經濟效益。
   • 評估系統的社會效益（通常是潛在的）。

---

職責

可以從運維流程和運維對象兩種角度劃分職責。

• 流程視角下的信息系統運維管理職責： 列出了事件管理、事故管理、問題管理、配置管理、變更管理、發布管理、知識管理等流程中涉及的人員及其職責。

  • 運維流程	人員/角色	職責
    事件管理	技術和應用管理人員	制定、設計各項規章制度，確保控制事件管理
    	IT 運維管理人員	事件監控、響應，事故創建
    事故管理	事故管理者	監控、管理、開發維護（管理流程）、生成（報告）
    	一/二/三線支持人員	執行（事故的調查、診斷、解決和恢復等具體任務）
    問題管理	問題管理者	組織聯絡（協調解決問題），開發維護 KEDB（已知錯誤數據庫）
    	問題解決小組	制定解決問題的方案
    配置管理	配置管理者	執?標準、制定、評估（配置管理策略和計劃），監督配置管理實施
    	配置管理實施人員	實施（配置識別、配置控制、狀態記錄和報告等具體任務）
    變更管理	變更管理者	接受變更（請求），評估變更，組織召開 CAB 會議（協調評審和授權）
    發布管理	發布管理者	協調（發布活動），確保（發布成功），更新知識庫
    	發布團隊	設計構建配置（發布包），驗收，測試（發布包）
    知識管理	知識提交人員	提交、初步歸類（知識）
    	知識管理者	識別、建立、維護、轉移（知識）
    	知識審核人員	審核（提交的知識）

• 對象視角下的信息系統運維管理職責： 列出了系統管理、數據、軟硬件等對象涉及的人員及其職責。

  • 運維對象	人員/角色	職責
    系統管理	系統主管人員	組織各方面人員協調完成系統管理任務。
    數據	數據收集人員	收集數據。
    	數據校驗人員	在邏輯上保證數據的正確。
    	數據錄入人員	錄入數據。
    軟硬件	軟件和硬件操作人員	按照工作規程進行日常運行管理。
    	程序員	在系統主管人員的組織下，完成軟件的修改和擴充，為滿足臨時要求編寫程序。

人員的管理內容（重要）

人員管理的內容比較重要，上下午考試都可能涉及。主要包括：

1. 明確規定每個人的工作任務和職權范圍，即要有明確的授權。
2. 對每個崗位的工作要有定期的檢查及評價，要有定量和客觀的評價指標，即要有檢查和評價。
3. 對工作人員進行培訓，以便提高能力、改善工作質量，從而提高整個系統的效率。

職責任務和績效評價原則

列出了系統主管人員、數據收集人員、數據校驗人員、數據錄入人員、硬件和軟件操作人員、程序員等的評價標準。

• 系統主管人員的評價標準： 整個應用系統在管理中發揮的作用及其效益。
• 數據收集人員的評價標準： 數據是否準確、完整、及時。
• 數據校驗人員的評價標準： 在系統內部發現的不正確數據的數目及比例。
• 數據錄入人員的評價標準： 錄入的速度和差錯率。
• 硬件和軟件操作人員的評價標準： 系統是否安全運行。
• 程序員的評價標準： 編寫程序的速度和質量。

運維人員管理的意識

服務意識、主動意識、團隊意識、學習意識、專業意識、創新意識、安全意識（管理、技術兩方面）。

信息系統運行管理制度的建立和實施

網絡中心管理制度

• 目的：
  1. 給網絡設備和中心服務器創造良好運行環境，保證信息系統安全運行。
  2. 防止非法人員進入，保證程序數據安全。
• 管理機房的主要內容：
  1. 進入人員的資格審查。
  2. 環境要求。
  3. 數據安全的環境要求。
  4. 明令禁止的活動。
  5. 材料設備進出的管理要求。
  6. 機房和設備整潔。
• 制度的主要內容：
  1. 操作人員的操作行為。
  2. 出入機房人員的規定。
  3. 機房電力供應。
  4. 機房溫度、濕度、清潔度。
  5. 機房安全防火。
  6. 建立計算機病毒預防和處理機制。
  7. 對非熱插拔設備，禁止帶電熱拔插。
  8. 專用機房專人負責。

運行管理制度

• 數據備份是保證系統安全的重要措施。
• 重要修改前也要備份。

日常運行記錄制度 (比較重要，上下午都考過)

• 運行日記內容：
  1. 時間
  2. 操作人
  3. 運行情況
  4. 異常情況（發生時間、現象、處理人、處理過程、處理記錄文件名、在場人員等）
  5. 值班人簽字
  6. 負責人簽字
• 必須重視正常運行時的記錄，主要靠人工方式記錄。
• 專用機房、非專用機房 機器的運行都要做好運行日記。

運維模式

• 自主運維模式：
  • 優點： 容易管控，可根據自身需要進行人員培訓。
  • 缺點： 人員數量有限，無法對并發的運維提供支持；培訓時間長，無法滿足工作要求。
• 完全外包運維模式：
  • 優點： 充分利用外部經驗，快速提供運維能力；人數擴充容易，可應對大規模運維。
  • 缺點： 外部人員管控難度大，信息泄露風險高。
• 混合運維模式：
  • 優點： 能充分發揮自主運維和外包運維的優勢。
  • 缺點： 存在兩種運維人員，增加了運維工作復雜度，延長了運維流程；需考慮兩種人員的職責劃分和人員比例，既要保證工作完成，又要讓自有運維人員得到充分鍛煉。

文檔管理

• 意義：
  1. 良好的文檔管理是系統工作連續進行的保障。
  2. 良好的文檔管理是信息系統維護的保證。
     • 理解別人精心設計的程序很難，文檔不全更難。
     • 系統維護時不能依賴系統開發人員。
     • 信息系統是一個龐大的系統，且兼容了計算機和業務兩方面的專業知識，了解、維護難。
  3. 良好的文檔管理是保證系統內部數據信息安全的關鍵環節。
  4. 良好的文檔管理是系統各種信息得以充分利用，更好地為管理服務的保證。
• 信息系統運行文檔管理的任務：
  1. 監督、保證按要求生成各種文檔。
  2. 保證文檔安全、保密。
  3. 保證各種文檔得到合理、有效利用。
• 文檔管理制度：
  • 運行文檔包括： 計算機打印輸出的各種報告、報表、憑證；存有數據的磁性介質及其他介質；信息系統開發的全套文檔資料。
  • 文檔管理制度的內容：
    1. 存檔手續。
    2. 安全保證措施。
    3. 文檔管理員的職責和權限。
    4. 文檔分類管理辦法。
    5. 文檔使用的審批手續。
    6. 保存期限、銷毀手續。
    7. 保密規定。

故障管理 (重點)

• 信息系統采取的恢復技術對系統可靠性起決定性作用。
• 種類：
  1. 硬件故障
  2. 軟件故障
  3. 網絡故障（網絡硬件故障、網絡軟件設置故障）
  4. 人為故障
  5. 不可抗力和自然災害
• 故障預防策略：
  1. 故障約束： 通過預防性約束措施，防止錯誤發生或在被檢測出來前錯誤的影響范圍繼續擴大。
  2. 故障監測： 對系統的信息處理過程和運行狀態進行監控與檢測，使已發生的錯誤在一定范圍或步驟內被發現。
  3. 故障恢復： 將系統從錯誤狀態恢復到某個已知的正確狀態，并為了減小數據損失而盡可能接近發生系統崩潰的時刻。

常見故障的處理

• 軟件故障與處理：
  1. 系統文件丟失：添加/卸載，重新安裝或復制。
  2. 文件版本不匹配：同一個 DLL 文件不同版本支持。
  3. 應用程序非法操作：兩個程序不同時使用同一段內存，下載補丁，卸載重裝。
  4. 藍屏錯誤信息：一般是安裝新軟件后與系統發生沖突，改變系統設置，更新驅動。
  5. 系統資源耗盡：重啟。
  6. 計算機病毒破壞：預防為主，安裝防火墻軟件和系統安全補丁。
• 硬件故障與處理：
  1. 電源電壓不穩定或經常斷電引起的故障：使用電源穩壓器或不間斷電源 UPS。
  2. 部件之間接觸不良引起的故障：更換插槽或擦金手指。
  3. 由 CMOS 引起的故障：進入 CMOS 裝載默認設置。
  4. 硬件本身的故障：更換新備件。
  • 利用以下方法定位： 直接觀察法、拔插法、交換法、比較法、原理分析法、高級診斷程序檢測法、測量法、綜合判斷法。(比起此處，第三章講述了 3 種設施故障診斷方法，記那個，此處熟悉即可)
• 網絡故障與處理：
  1. 分類為：
     • 網絡硬件故障：網絡設備故障、網絡設備沖突、設備驅動程序問題。
     • 網絡軟件設置故障：網絡協議設置問題、服務安裝問題、安裝相應的網絡用戶、網絡標識的設置問題、網絡應用中的其他故障（廣播風暴、網絡通訊阻塞等）。
  2. 網絡故障排除順序與解決辦法： 詢問網絡用戶、咨詢系統管理人員、整理分類找出若干可能、故障分析、故障點隔離。
  3. 

服務器相關故障的解決方案

• 服務器硬盤故障的解決方案：
  1. 磁盤冗余陣列（RAID）：通過其他硬盤備份，提高服務器對硬盤的容錯率，但增加了部分硬件資源的開銷，加重了主機系統自身負擔。
  2. 存儲子系統：數據存儲系統從主機系統中分離。
  3. 虛擬存儲技術：
     1. 存儲子系統可以根據用戶的實際數據量和實際配備的物理硬盤空間，自動選擇一種最佳的 RAID 組合方式進行配置；
     2. 日后隨數據量的增加，可對 RAID 設置自動優化；
     3. 利用虛擬技術，可將任意大小的物理硬盤先分割成若干細小的部分然后針對這些細小的部分進行優化 RAID 組合，得到精細、靈活的容錯和存儲性能。
• 服務器系統部件故障的解決方案：
  1. 采用全硬件冗余的主機硬件系統：兩套相同配件，雙倍代價一倍性能。
  2. 多機切換系統：主要為雙機備份系統。
     • 主機集中存放，雙主機連接同一個存儲子系統。
     • 主機異地存放，雙主機分別連接一個存儲子系統。
     • 其他靈活的設計方案：采用軟件的方式獲得數據同步。
  3. 

信息系統容災的解決方案

1. 企業業務數據必須存儲在不同地域。
2. 在不同地域之間必須建立穩定、冗余的高速網絡連接，以保證其網絡的可靠性。

故障的記錄與報告

• 故障信息搜集與記錄： 故障時間信息、故障現象信息、故障部位信息、故障性質信息（即種類）、故障處理信息。
• 故障分析：
  1. 根據故障的表征，分清故障的類型和性質，找出故障的根源。
  2. 通過對統計資料的分析，獲取有價值的信息。
• 故障報告： 按規定程序報主管部門，以便派人處理，得到技術支持。
  • 硬件故障——設備制造廠商。
  • 軟件故障——軟件開發部門或軟件廠商。
  • 網絡故障——網絡服務商。

2.3 信息系統運維的外包

概念

信息系統運維外包（信息系統代維）是指信息系統使用單位將全部或一部分的信息系統維護服務工作，按照規定的維護服務要求，外包委托給專業公司管理。

模式

• 完全外包模式
  • 
• 部分外包模式
  • 
• 混合運維模式（優點：發揮自主和外包優勢；缺點：管理復雜，職責劃分，人員比例）

好處

1. 有利于提高組織競爭力。
2. 提高服務質量、降低故障率。
3. 借助專業公司的管理流程和工具軟件，降低信息系統運維的成本。
4. 降低業務部門隱性成本。

內容

• 桌面支持外包： 涉及員工工作場所使用的信息處理、通信和計算設備的維護管理（辦公環境的維護）。
  • 業務包括系統初始檢查、硬件故障解決、硬件擴容升級、軟件系統支持、防病毒系統支持、網絡系統支持、日常維護管理、咨詢服務。
• 基礎設施外包 / IT基礎構架外包IaaS： 類似IaaS（基礎設施即服務），服務提供商提供硬件，客戶租用資源。能降低外部危險和數據損失風險，簡化內部人員結構，節省人員費用。
  • 業務包括系統/服務器維護支持、軟件/服務調試、網絡系統維護、系統遷移、數據庫維護支持、數據存儲和容災管理、安全系統支持、網站支持、咨詢服務。
• 應用系統外包SaaP： 與ASP（應用服務提供商）和SaaS（軟件即服務）接近，PaaS（平臺即服務）也是SaaS的一種。考題能分辨哪些業務屬于對應分類即可。

風險管理（考題：外包的好處、風險來源、分析、規避要記得，共16個點，上下午都有）

• 風險來源：
  • 外部環境的不確定性：政治，自然，市場風險等。
  • 運維外包決策的復雜性：可行性研究，外包方選擇，權責界定等。
  • 運維外包雙方的關系復雜性：文化差異，溝通不力，信息泄露，人力資源風險。
  • 運維工作本身的復雜性：技術，設備，安全，運維管理，驗收風險。
• 風險分析（帶來的問題）：
  • 組織成本有可能增加
  • 組織對服務商的依賴和外包合同缺乏靈活性可能降低組織的靈活性
  • 可能會泄露組織的商業機密
  • 對外包商缺乏恰當的監管。
• 風險評估： 風險矩陣法、層次分析法、蒙特卡羅法、關鍵風險指標法、壓力測試法等。
• 風險規避：
  • 核算外包成本，控制額外支出；
  • 組織仍需不斷學習；
  • 簽訂完整而靈活的外包合同；
  • 選擇合適的外包商。

2.4 信息系統運維管理標準

• ITIL（信息技術基礎設施庫）： 實施的最大意義在于IT與業務的緊密結合。ITIL V3是當前最佳實踐的精髓，引入了生命周期的概念（服務戰略、服務設計、服務轉換、服務運營、服務改進）。
• COBIT（信息系統和技術控制目標）： 重點關注組織需要什么，而非組織需要如何做，不包括具體實施指南和步驟，是控制架構而非具體過程架構。將信息技術過程歸并為四個控制域：計劃與組織、獲取與實施、發布與支持、檢測與評估。
• 

2.5 信息系統運維管理系統與專用工具

框架

信息系統運維管理系統是站在運維管理的整體視角，基于運維流程以服務為導向的業務服務管理和運維管理支撐平臺，提供統一管理門戶，最終幫助運維對象實現信息系統管理規范化、流程化和自動化的全局化管理。

運維管理系統的架構分為：（考點：圖中層次的順序、內容）

• 采集層
• 基礎層（資產管理）
• 通用服務層（監控管理）
• 對象服務層（流程管理）
• 管理分析層（外包管理、綜合管理）
• 表達層（管理門戶）。
• 

運維管理系統的主要功能模塊

• 資產管理： 實現對各種設備資產信息的維護、統計及資產生命周期管理。分為靜態資產信息管理和動態資產信息管理。
  • 靜態資產信息管理：資產信息維護、資產信息分析統計、資產?命周期管理、輔助決策
  • 動態資產信息管理：?動發現采集、?動同步更新
• 流程管理： 實現IT運維管理所需的流程并監控，確保服務質量，支持故障和服務申請的跟蹤。
  • 目標
    • 1）對運維流程進?管控，按照服務等級協議(SLA)調?必要的資源，保證處理時限，確保服務質量，?持對故障和服務申請的跟蹤，確保所有的故障和服務申請能夠以閉環?式結束;
    • 2）利?運維管理系統固化運維服務的?作流程，提供標準的、統?的服務規范，提供靈活的流程定制功能。
  • 包括事件管理、事故管理、問題管理、配置管理、變更管理、發布管理、知識管理。
• 監控管理： 包括對信息系統相關設備的監控管理。
  • 分為視圖管理、配置管理、故障管理、性能管理。
• 外包管理： 面向信息系統管理者，進行服務的結果控制管理和過程控制管理。
  • 分為：結果控制管理、過程控制管理
• 安全管理： 通過信息化手段實現安全管理支撐能力。
  • 分為通信及操作管理、訪問控制、信息安全事件管理、風險評估和等級保護。
• 綜合管理： 在其他管理功能基礎上，實現信息系統整體運維信息統計分析，并支持管理決策。
  • 分為 統計分析和決策支持（數據、模型、推理、人機交互）。

運維管理系統和專用工具示例

列舉了一些運維管理系統（如CA公司的USPSD、HP公司的運維管理平臺、北塔的BTIM、開源的Genome）

運維管理專用工具（如ITIL流程管理平臺Remedy及其應用、自動化運維操作管理平臺Opsware及其子系統SAS、NAS、PAS、配置管理系統及其作用）。

• 1）ITIL流程管理平臺Remedy
  • 六?應?程序：BMC Remedy Service Desk \ BMC Remedy Change and Release Management \ BMC Remedy Asset Configuration Management \ BMC Remedy level Management \ BMC Discovery \ BMC Remedy Configuration Management
• 2）?動化運維操作管理平臺Opsware
  • 三??系統：服務器?動化系統 SAS、?絡?動化系統 NAS、過程?動化系統 PAS
    （熟悉以上三個?系統，Server/network/process）
• 3）配置管理系統
  • 作?：信息整合、關系映射、流程?持、軟件庫與硬件庫（通過DHL和DSL）

2.6 云運維管理

云運維管理盡量實現自動化、流程化，提供個性化視圖。與傳統IT運維管理的區別在于集中化和資源池化。

功能

包括自服務門戶、身份與訪問管理、服務目錄管理、服務規則管理、資源調度管理、資源監控管理、服務合規審計、服務運營監控、服務計量管理、服務質量管理、服務交付管理、系統管理、管理集成、管理門戶。

云運維最終目標

IT能力的服務化供應，并實現云計算的各種特性（共享、自動化、按使用收費、自服務、可擴展等）。

---

第三章 信息系統設施運維

信息系統設施運維是指支撐信息系統業務活動的信息系統軟硬件和環境的運維。

3.1 管理體系

本節給出了設施運維的管理體系框架圖，并介紹了設施運維的對象、制度和人員。

• 設施運維對象： 包括基礎環境（通信應急設備系統，比較特殊，要記住）、網絡（通信線路、通信服務、網絡設備、網絡軟件）、硬件（最關鍵的是服務器設施）和基礎軟件（操作系統、數據庫系統、中間件、其他支撐系統）。
• 制度： 可以按運維對象（如機房管理制度.網絡基礎設置管理制度.子網管理制度.數據存儲設施管理制度.基礎軟件管理制度）和按運維過程管理（如設施運維人員和崗位職責管理制度.外來維護人員管理制度.運維記錄管理制度.設備巡檢.維護作業計劃管理制度）進行分類。
• 人員： 根據運維對象，列出了管理人員、技術支持人員和具體操作人員所需具備的經驗和技能。
  • 

3.2 環境管理

這部分詳細介紹了計算機機房的環境管理，包括選址、布局、建筑要求、室內裝飾要求以及溫度、濕度、照明、防塵、防靜電、防磁、防雷、防強光有害氣體、防水、防鼠等方面的具體要求和措施，并提供了相關的溫濕度、照度、眩光限制等級等標準表格。

• 計算機機房選址要求：

  • 選址要求： 水源充足、電力穩定可靠、交通通信方便、自然環境清潔，遠離粉塵、油煙、有害氣體、腐蝕性/易燃/易爆物品，遠離強振源和強噪聲源，避開強電磁場干擾。
  • 計算機機房：選擇堅固、寬敞、潔凈、通風、有防雷擊設施的房間，避開頂層和底層（第二、三層為佳），使用面積不低于60平方米，除主機房外還應該有附屬用房。
  • 布局要求：
    • 主機房、基本工作間、第一類輔助房間、第二類輔助房間、第三類輔助房間
    • 基本工作間和第一類輔助房間面積的總和，宜>主機房面積的1.5倍。
    • 上機準備室、外來用戶工作室、硬件及軟件人員辦公室等 可按每人3.5~4m2計算
    • 設備分區布置:主機區、存儲器區、數據輸入區、數據輸出區、通信區和監控調度區等。
    • 主機房內通道及設備間的距離規定:
      • 兩相對機距正面之間的距離不應小于1.5m
      • 機柜側面(或不用面)距墻不應小于0.5m，當需維修測試時，不應小于1.2m
      • 走道凈寬不應小于1.2m
  • 建筑要求：
    • 主機房的主體結構宜采用大開間大跨度的柱網，內隔墻宜有一定的可變性。
    • 主機房凈高，宜為2.4~3.0m
    • 機房的樓板荷載可按5.0~7.5KN/m2設計
    • 主體結構應具有耐久、抗震、防火、防止不均勻沉陷，變形縫和伸縮縫不應穿過主機房
    • 管線宜暗敷，當管線需穿樓層時，應設置技術豎井
    • 室內頂棚上安裝的燈具、風口、火災探測器及噴嘴應協調布置
    • 機房圍護結構的構造和材料應保溫、隔熱、防火等要求
    • 機房各門的尺寸均應保證設備運輸方便
    • 宜設單獨出入口，入口至主機房的通道凈寬不應小于1.5m
  • 室內裝飾要求： 選擇氣密性好、不起塵、易清潔、變形小的材料，墻壁和頂棚平整避免眩光，應鋪設活動地板，活動地板應符合現行國家標準<<計算機機房用活動地板技術條件>>。敷設高度宜為200~350mm，活動地板下地面和四壁可采用水泥砂漿抹灰，吊頂宜選用不起塵的吸聲材料，基本工作間和第一類輔助房間選用不起塵易清潔材料。
  • 其他措施： 防靜電、密閉、防止給排水漫溢和滲漏、消音隔音、隔振、避免陽光直射。
  • 溫度濕度：
    • 機房的溫度應保持在15~35°C
      • 溫度過低，會引起凝聚和結露現象，易生銹，材料變硬，易脆
      • 溫度過高，易使計算機系統工作不正常、死機;易燒毀
    • 機房的濕度應保持在20%~80%
      • 濕度過高，會引起電路板漲大變形，難以插拔
      • 高溫潮濕，易使金屬生銹、腐蝕，發生漏電、短路，可能會觸電
    • 開機時

      級別項目	A級		B級
      	夏季	冬季	全年
      溫度	23±2℃	20±2℃	18~28℃
      相對濕度	45%~65%		45%~70%
      溫度變化率	＜5℃/h 并不得結露		＜10℃/h 并不得結露

    • 停機時

      級別項目	A級	B級
      溫度	5~35℃	5~35℃
      相對濕度	40%~70%	20%~80%
      溫度變化率	< 5℃/h 并不得結露	< 10℃/h 并不得結露

    • 記錄介質庫的溫濕度

      級別項目	卡片	紙帶	磁盤（已記錄）	磁盤（未記錄）	磁帶（已記錄）	磁帶（未記錄）
      溫度	5~40℃	-	18~28℃	0~40℃	18~28℃	0~40℃
      相對濕度	30~70%	40~70%	20%~80%	20%~80%	20%~80%	20%~80%
      磁場強度	-	-	<3200A/m	<4000A/m	<3200A/m	<4000A/m

  • 照明：
    • 主機房的平均照度可按200、300、500Lx取值
    • 基本工作間、第一類輔助平均照度按100、150、200Lx取值
    • 第二、三類輔助間應按現行照明設計標準的規定取值

      • 	200(100)	300(150)	500(200)
        間歇運行	√
        持續運行		√
        連續運行			√
        無窗建筑		√	√

    • 工作區內一般照度的均勻度(最低照度與平均照度之比)不宜小于0.7，非工作區內一般照度的均勻度不宜小于0.2，計算機機房故障照明照度為一般照明的1/10，安全出口標志燈照度不低于0.5LX。

      • 眩光限制等級	眩光程度	適用場所
        I	無眩光	主機房、基本工作間
        II	有輕微眩光	第一類輔助房間
        III	有眩光感覺	第二、三類輔助房間

    • 主機房、基本工作間可以采用措施限制工作面上的反射眩光和作業面上的光幕反射:
      • 使視覺作業不處在照明光源與眼睛形成的鏡面反射角上
      • 采用發光表面積較大、亮度低、擴散性好的燈具
      • 視覺作業處家俱和工作房間內應采用無光光澤表面

      • 電光源種類	光源平均亮度l(×10cd/m)	眩光限制等級	遮光角
        管狀熒光燈	1<20	Ⅰ	20°
        		Ⅱ、Ⅲ	10°
        透明玻璃白熾燈	1>500	Ⅱ、Ⅲ	20°

  • 防塵： 灰塵會影響散熱和導致元件潮濕腐蝕。措施包括保持清潔、設吸塵器、不在操作時吸煙、使用防塵罩、定期清除灰塵。
  • 防靜電： 靜電會引起隨機故障、擊穿元器件（比如CMOS，mos電路，雙極性電路等）、影響人員健康。措施包括保持濕度、鋪設防靜電地板、設備接地、操作前釋放靜電、操作時避免穿尼龍衣物。
  • 防磁： 注意顯示器防磁。措施包括避開電磁場、遠離高壓線、金屬外殼接地屏蔽、定期對顯示器消磁。
  • 防雷： 安裝避雷針，聯成統一電氣整體并接地，計算機通信電纜芯線和電話線加裝避雷器。
  • 防強光、有害氣體： 反射系數控制在60%以內。
  • 防水： 設置套管、防滲漏措施、水封裝置。
  • 防鼠： 線路使用防鼠材料，禁止放食品飲料。

• 電氣系統：

  • 基本要求： 保證計算機系統運行可靠性、設計壽命、信息安全要求（計算機運行時頻率介于0.16·400MHZ）和操作人員工作環境。
  • 供配電系統：
    • ?機房容量較大時，應設置專用電力變壓器，容量較小時，可采用專用低壓饋電線路供電
      • 電子計算機電源設備應靠近主機房設置
      • 機房內其他電器的電力負荷不得由計算機主機電源和UPS供電
      • 單相負荷應均勻地分配在三相上，三相負荷不平衡度應小于20%
      • 計算機電源應限制接入非線性負荷，以保持電源的正弦性
      • （電子計算機房供配電系統應考慮系統擴展、升級的可能，并應預留備用容量）
    • UPS(Uninterruptible Power supply)不間斷電源
      • ?????作用:
        • 為計算機系統提供備用電源消除電網供電上的“污染”
        • (浪涌、波動、脈沖、噪聲等)，使計算機中的電子部件免受摧毀性損壞
      • 缺點:
        • 蓄電池組一起占地面積大，自重較大
        • 發熱量較大，噪音不小本身
        • 內部結構緊湊，清潔困難
  • 設備選型： 參考《低壓配電設計規范》GB50054-1995，對專用配電箱的保護和控制電器選型、備用回路、進線斷路器、電流電壓表、中線和接地端子等提出了要求。
  • 機房布線：
    • 電子計算機機房的電源進線應按照《建筑物防雷設計規范》采取過電壓保護措施，專用配電箱電源應采用電纜進線，不得不采用架空進線時，在低壓架空電源進線處或專用電力變壓器低壓配電母線處裝設低壓避雷器。
    • 主機房活動地板下部的低壓配電線路宜采用銅芯屏蔽導線或銅芯屏蔽電纜。
    • 主機房活動地板下部的電源線應盡可能地遠離計算機信號線，避免并排敷設，應采取相應的屏蔽措施。
    • 照明布線，照明配線宜穿鍍鋅薄壁鋼管保護。
  • 接地系統：
    • ???????????分為?系統接地，屏蔽接地

    • ★ 系統接地四種方式

      • 交流工作接地(中性線)，接地電阻不應大于4Ω
      • 安全保護接地，接地電阻不應大于4Ω
      • 直流工作接地(邏輯接地)，IBM ≤2Ω，DEC、太極系列≤1Ω，HP≤3Ω
      • 防雷接地，接地電阻不應大于10Ω

    • ★ 接地方法

      • 接地棒法，埋設銅板

• 空調系統：空調系統應設消聲裝置。主機房必須維持一定的正壓。主機房與其他房間、走廊間的壓差不應小于4.9Pa，與室外靜壓差不應小于9.8Pa。

  • ★ 空調系統的新風量應取下列3項中的最大值

    • 室內總送風量的5%
    • 按工作人員每人400/h（403/h）
    • 維持室內正壓所需風量

• 消防與安全系統： 主機房和基本工作間應設二氧化碳或鹵代烷滅火系統，吊頂及活動地板下應設置探測器和噴嘴，還應設空氣/氧氣呼吸器。還包括火災自動報警系統、滅火系統、門禁系統和閉路監控系統。

• 系統支撐環境的參照標準：

  IEEE802.3Ethernet

  IEEE802.5TokenRing

  EIA/TIA568 工業標準及國際商務建筑布線標準

  ANSI X3T9.5（美國標準）

  FDDI（光纖分布式數據接口）

• 建筑部分的參照標準：
  • ??????????????國家標準<<電子計算機機房設計規范>>(GB50174-1993)
  • 國家標準<<計算站場地技術要求>>(GB2887-1989)
  • 國家標準<<計算站場地安全技術>>(GB9361-1988)
  • 國家標準<<計算機機房用活動地板的技術要求>>(GB6650-1986)
  • 國家標準<<電子計算機機房施工及驗收規范>>(SJ/T30003)
• 其他標準

  • 電力保障部分參照標準

    • <<低壓配電設計規范>>(GB50054 - 1995)
    • <<電子計算機機房設計規范>>(GB50174 - 1993)
    • <計算站場地技術要求>>(GB2887 - 1989)
    • <<供配電系統設計規范>>(GB50052 - 1995)
    • <<高層民用建筑設計防火規范>>(GB50045 - 1995)
    • <<電氣裝置安裝工程接地裝置施工及驗收規范>>(GB50169 - 1992)

  • 綜合布線部分參照標準

    • 建筑與建筑群綜合布線系統工程設計規范(GB/T50311 - 2000)
    • Lucent SYSTIMAX結構化布線系統設計總則

3.3 設施運維的內容

這部分詳細介紹了設施運維的四種類型：例行操作運維、響應支持運維、優化改善運維和咨詢評估運維。考點大量為選擇題，下午題不多，以區分、理解為主。

• 例行操作運維： （24年考過，注意一下）預定的例行服務，獲取運維對象狀態，發現處理潛在故障，保證設施穩定運行。
  • 需要關注的要素及內容： 例行服務范圍/內容、指導手冊（任務清單、操作步驟、判定標準、記錄要求、異常處置流程、報告模板）、與其他服務內容的接口。
  • 成果分類： 無形成果（運行狀態、狀態恢復、潛在風險消除）和有形成果（運行狀態記錄、異常處理記錄、趨勢分析建議、其他報告）。
  • 例行操作分類： 設施監控、預防性檢查和常規操作。
    • 設施監控： 通過工具和技術記錄分析設備運行狀態，及時發現故障。內容包括設備狀態、運行狀況和變化情況。詳細介紹了基礎設施、網絡設施（拓撲監控、鏈路監控、端口監控）、硬件設施（狀態監控、性能監控、可用性監控）和基礎軟件（數據庫、中間件、應用服務）的監控內容。
    • 預防性檢查： 根據監控記錄和運行狀況進行檢查及趨勢分析，包括性能檢查和脆弱性檢查。詳細列出了基礎設施、網絡及網絡設備、服務器及存儲設備、數據庫、中間件等的性能檢查和脆弱性檢查內容。
    • 常規操作： 日常運行、維護和保養。詳細列出了服務器及存儲設備、數據庫、中間件等的常規操作內容。
• 響應支持運維： 針對服務請求、故障申報進行的響應性支持服務，包括故障管理、變更管理。
  • 需要關注的要素及內容： 明確受理渠道、實施過程記錄、有效申請分類和優先級判斷（緊急程度、影響范圍、重要程度），設置預警/告警機制及升級流程，及時通知進展信息，與其他服務內容的接口。
  • 成果分類： 無形成果（狀態恢復、運維知識傳遞）和有形成果（響應支持記錄、關鍵指標數據記錄、重大事件分析報告、滿意度分析、其他報告）。
  • 根據響應的前提不同，分為： 事件驅動響應（由不可預測原因導致，觸發條件包括外部事件、自主事件、安全事件）、服務請求響應（由各類服務請求引發的調整或修改）和應急響應。
  • 應急響應： 包含應急準備、監測與預警、應急處置、總結改進四個主要環節。詳細介紹了每個環節的重點任務，并與日常工作、故障響應、重點時段保證進行對應。同時詳細說明了應急準備（組織制度建立、風險評估與改進、事件級別劃分、預案制定、培訓與演練）、監測與預警（日常監測、記錄與報告、核實與評估、預案啟動）、應急處置（應急調度、排查與診斷、處理與恢復、升級與信息通報、持續服務與評價、事件關閉）、總結改進（應急事件總結、應急體系的保持、應急準備工作的改進）的具體內容。
• 優化改善運維： 通過調優改進，提高設備性能或管理能力。
  • 需要關注的要素及內容： 改善優化方案（目標、內容、步驟、人員、預算、進度、衡量指標、風險預案、回退方案）、方案評審、試運行觀察期、遺留問題改進措施、回顧總結、與其他服務內容的接口。
  • 成果分類： 無形成果（性能提升、管理水平提升）和有形成果（優化方案、評審記錄、變更和發布報告、其他報告）。
  • 包括： 適應性改進（偏向被動，在變化環境中可持續運行而實施的改造）、糾正性運維、改善性運維（偏向主動，根據需求或缺陷采取改進措施增強安全性、可用性和可靠性）和預防性運維（監測糾正潛在問題或缺陷，降低風險）。詳細列出了這些類型在基礎設施、網絡設施、硬件設施、基礎軟件等方面的具體內容。
• 咨詢評估運維： 根據系統運行需求，提供咨詢評估服務。
  • 需要關注的要素及內容： 制定咨詢評估計劃、編寫咨詢評估報告（現狀評估、訪談調研、需求分析、咨詢建議）、報告評審制度、持續跟蹤落地執行情況。
  • 成果類型： 無形成果（運維對象的衡量評價、規劃建議）和有形成果（咨詢評估計劃、方案和評審記錄、其他報告）。
  • 包括： 被動型咨詢服務和主動性咨詢服務。詳細列出了在基礎設施、網絡設備、硬件設備等方面的咨詢評估內容（如負荷與承載能力分析、架構變動建議、配置調優分析等）。

3.4 設施的故障判斷和修復

本節介紹了設施故障的分類、主要原因與現象、故障排除步驟以及故障診斷方法和修復原則。

• 分類： 按區域劃分（機房內故障、機房外故障）和按故障性質（鏈路故障、配置故障、協議故障、服務器故障）。
• 主要故障原因與現象： 網絡鏈路（通常是硬件或通信介質引起，可通過工具測試）、配置文件和選項、網絡協議、服務故障（服務器硬件故障、網絡操作系統故障、網絡服務故障）。提到了排除硬件故障后應重點檢查配置文件和選項故障，以及網絡內所有服務或個別服務故障時的檢查重點。
• 故障排除步驟： （上下午都考，要能背出內容和順序）識別故障現象、詳細描述故障現象、列舉可能原因、縮小搜索范圍（檢查LED指示燈、系統日志、利用管理軟件）、定位錯誤、故障分析。
• 故障診斷方法： 排除法、對比法、替換法。
• 故障診斷與修復原則： （上下午都考，要能背出內容和順序）先易后難、先軟后硬、先邊緣后核心、先鏈路后設備。
• 注意事項： 保證所有修復操作可恢復（備份、保存快照、留存日志），重視記錄。

3.5 信息系統設施運維系統與專用工具

• 系統功能： 資源管理（設備快照、設備視圖、設備活動及軟件信息、端口分布）、監控管理（基礎環境、網絡設備、硬件設備、基礎軟件監控）、故障預警管理（資源預警、網絡性能預警、基礎軟件性能預警）。
• 專業工具： 根據階段和類型，列舉了部署工具（如Kickstart, Cobbler）、配置工具（如Puppet, Chef）、監控工具（如Nagios, Zabbix）、日志分析工具（如Splunk, Graylog），并強調記住工具與類型的對應關系。還列舉了其他運維工具（如glpi, Network Notepad, Iometer, Netperf, Unicornscan）。

3.6 云環境下的信息系統設施運維

• 云計算特征： 資源配置動態化、需求服務自助化、網絡訪問便捷化、服務可計量化、資源虛擬化。
• 優勢： 設施運維工作更專業敏捷，設施運維單機故障影響更小，設備運維成本更低。
• 挑戰： 設施架構復雜度更高，設施故障可能造成更大范圍的損失，運維故障處理難度更大。
• 要求： 整體性要求、自動化規模化要求、數字化要求、智能優化要求。

第四章 信息系統軟件運維

信息系統軟件是信息系統運行的核心。

4.1 概述

概念

信息系統軟件運維是指信息系統軟件在開發完成投入使用后，對其進行的改正性維護、適應性維護、完善性維護、預防性維護等軟件工程活動。

可維護性

信息系統軟件維護工作直接受到軟件可維護性的影響。軟件可維護性指軟件產品被修改的能力，修改包括糾正、改進或軟件對環境、需求和功能規格說明變化的適應。

可維護性的度量可以從以下幾個方面進行：

1. 可理解性
2. 可靠性：表明軟件系統在給定時間內正確執行的概率，可通過錯誤統計或程序復雜性預測。
3. 可測試性：取決于系統的可理解性、復雜性和設計合理測試用例的難易程度等。
4. 可修改性
5. 可移植性

維護類型

（此處和設施運維中的優化改善運維差不多：適應性運維、糾正性運維、改善性運維、預防性運維）

1. 糾錯性維護： 針對發現的錯誤進行修復。
2. 適應性維護： （被動的）為適應硬件更新、系統使用壽命延長等環境變化而進行的維護。
3. 完善性維護： （主動的）根據用戶需求擴充功能、增加新特性、改進效率等。在系統維護工作中，完善性維護占比較高（達到50%）。
4. 預防性維護： 對尚能正常運行但可能發生變化的系統進行維護，為未來修改和調整奠定基礎。

信息系統軟件運維的體系

信息系統軟件運維體系包括需求驅動、運維流程、運維過程、運營支撐要素和運維管理原則。

• 需求驅動： 由用戶需求驅動，是軟件運維工作的起點，目的是滿足用戶的改正性、適應性、完善性、預防性需求。
• 運維流程： 運維策劃、運維實施、運維檢查、運維改進（迭代的循環過程，PDCA）。
• 運維過程： （考的多，重點）日常維護、缺陷診斷與修復、配置管理、變更管理、系統恢復管理、發布管理。
• 運營支撐要素： 應遵從ITIL、ISO20000、ISO27001等標準要求。包括運維管理制度、運維管理部門、運維管理人員（軟件運維工程師、系統管理員、技術服務經理）和運維管理設施。
• 運維管理原則： 遵守規章制度、與其他部門協同工作、遵守保密原則、保證數據和系統安全、及時上報無法解決的問題、詳細記錄運維過程和結果。

趨勢——DevOps

解釋了運維、開發產生鴻溝的原因（開發不考慮運維影響、溝通不及時、手動修改配置、工具集差異、操作系統差異），并介紹了DevOps的原則（基礎設施即代碼IaC、持續交付、協作）和價值（產品高效交付、改善組織文化、提高員工參與感）。還提到了DevOps的工具（版本控制軟件庫、深層模型系統、人工任務自動化）。

4.2 管理

運維的目的是保證信息系統軟件正常可靠運行并不斷改善提高，充分發揮作用。運維過程是不斷滿足用戶各種維護要求的PCDA循環，關鍵要素是人員、資源、技術、過程。

• 人員： 人員管理（規劃、培訓、績效考核）、崗位設置（管理、技術支持、操作崗位及其職責）、知識技能和經驗。
• 資源： 資源配置為運維服務提供保障。包括服務臺管理（單一接觸點、溝通橋梁、發起者/記錄者）、運維工具管理（監控工具、過程管理工具）、知識庫管理（技術技能積累、提升解決問題能力、降低依賴、提高團隊技能）。
• 技術： 需具備發現和解決問題、風險控制、技術儲備及研發、應用新技術和前沿技術的能力。
• 過程： 日常運維、缺陷診斷與修復、配置管理、變更管理、系統恢復管理、發布管理等，詳細見4.3。

運維策劃

對信息系統軟件運維活動的服務內容、組織、資源、標準、改進等進行全局策劃。

• 內容： 根據業務定位和管理范圍策劃運維服務對象的業務內容和要求，形成服務目錄。
• 組織： 由業務管理和信息系統運維管理部門共同組成，從功能和技術角度進行控制。
• 資源： 分析人力、環境、財務、技術、時間資源等。
• 標準： 制定運維流程、安全、文檔、考核評估體系等標準。
• 改進： 策劃如何管理、審核并改進運維服務質量，建立內部審核評估機制。

運維實施

按照整體策劃實施，保證制定并執行實施計劃，建立客戶溝通協調機制，按規范實施并記錄，提交滿足質量要求的交付物。

運維檢查

定期評審運維過程和管理體系，調查客戶滿意度，檢查指標達成情況。

運維改進

建立改進機制，總結分析不符合項，調查分析未達成指標，確定改進措施，制定改進計劃并監控評估有效性。

文檔管理

運維文檔是提供決策支持的載體，應注意文檔管理制度化、標準化規范化、落實管理人員、保持一致性和維護可追蹤性（按版本控制）。

4.3 過程

本節詳細介紹了信息系統軟件運維的幾個主要過程：

• 日常運維： 主要內容包括監控、預防性檢查、常規操作（同設施運維中的例行操作運維）。詳細列出了監控內容（CPU、內存、磁盤、進程、服務/端口、日志、資源消耗、數據庫連接等）、預防性檢查內容（響應時間、病毒查殺、口令安全、日志審計、進程及資源消耗分析等）和常規操作內容（日志清理、啟動/停止服務/進程、用戶賬號管理、密碼更新、備份等）。強調日常運行是常規活動，應按規范定時定點啟動。還介紹了日常運行、例行測試、例行維護、定期測試維護的流程和關鍵點。
• 缺陷診斷和修復： 介紹了軟件缺陷的嚴重性（微小、一般、嚴重、致命）和優先級（最高、較高、一般、低），并區分了與應急響應中事件級別劃分的不同。列出了軟件缺陷在處理過程中的多種狀態（新建、延后處理、已指派、已修復、無法重現、需要更多信息、重新打開、關閉、駁回）。根據軟件測試觀點，將軟件缺陷分為五大類：功能缺陷、系統缺陷、加工缺陷、數據缺陷、代碼缺陷，并詳細列出了各類缺陷的細分和內容。最后，介紹了缺陷診斷與修復的流程和關鍵點（初步診斷、異常修復/技術支持、重大缺陷處理申請、報告編制和文檔歸檔）。
• 配置管理： 應用于整個軟件工程過程的標識、組織和控制修改的管理技術。關鍵活動包括配置管理計劃、配置與配置項、版本控制、變更控制、配置審計（功能審計、物理審計）、狀態報告（區分第二章中的配置管理流程的關鍵活動）。
• 變更管理： 為適應項目運行過程中各種因素的變化，保證項目目標的實現而對項目計劃進行部分或全部變更，并按變更后要求實施的過程。重要用途是控制變更和進行變更度量分析。主要目標是標準化方法和程序、記錄配置項變更、降低風險、響應客戶需求、確保受控的記錄/評估/授權/實施/評審活動（區分第二章中的變更管理流程的目標）。詳細介紹了評審變更、評估變更、實施變更的關鍵點。
• 系統恢復管理： 當軟件不能正常工作時，對系統實施恢復安裝操作，使其盡快恢復正常穩定運行。屬于維修性質的服務管理。關鍵點包括系統操作員提出申請、維護工程師分析原因、恢復安裝前檢查/恢復系統后測試、技術服務經理跟蹤確認、過程文檔存檔。
• 發布管理： 變更的后繼過程，將變更實施到生產環境。目的是通過項目規劃實施變更，確保只有測試過的正確版本才能發布到運行環境，保證安全可靠，并控制發布風險，避免或減少失敗影響（區分第二章中的發布管理流程的目的）。

4.4 系統與專用工具

系統功能

信息系統運維系統是以流程、技術、服務為導向的業務服務管理和運維支撐平臺。信息系統軟件運維的管理內容包括信息系統軟件信息采集、信息系統軟件監控和信息系統軟件分發功能。

專用工具

列舉了軟件運維不同階段和類型的專用工具：

• 版本控制工具： 集中式的CVS、SVN，分布式的GIT、Mercurial。
• 構建工具： Ant、Gradle、Maven（將源代碼生成可執行程序的自動化工具）。
• 安裝部署工具： 自動化批量安裝工具（Kickstart、Cobbler、OpenQRM），自動化部署工具（Capistrano、CodeDeploy）。
• 配置管理工具： Ansible、Chef、Puppet、SaltStack。
• 系統監控工具： Datadog、Graphite、Icinga、Nagios、AppDynamics、New Relic。 強調需要記住工具與類型的對應關系，看到案例知道用哪一類工具。還列舉了其他運維工具（信息資源管理工具glpi、交互式拓撲繪制工具Network Notepad、存儲子系統讀/寫性能測試工具Iometer、網絡性能測試工具Netperf、端口掃描器Unicornscan）。

第五章 信息系統數據資源維護

數據是信息系統管理的對象與結果，是組織生存和發展的重要戰略資源。信息系統數據資源維護旨在保障數據資源處于高可用狀態，使信息系統可持續穩定高效地運行。

5.1 信息系統數據資源維護體系

本節介紹了信息系統數據資源維護體系的組成要素和管理類型。

• 信息系統數據資源維護包括： 建立管理制度、規范業務流程、開展運行監控與維護、故障診斷和排除、數據備份和恢復、數據歸檔和檢索等。

• 運維管理對象： 數據文件（物理表現形式）、數據管理系統（實現數據收集、更新、存儲的管理系統，如操作系統、數據庫）、存儲介質（存儲數據的物理載體）。

• 管理類型： 主要有三類：運行監控、故障響應和數據備份。

  • 運行監控： 數據維護人員周期性、預定義的維護活動，及時獲取數據資源狀態。包括實時監控（利用工具對存儲、傳輸狀態和相關設備進行記錄和監控，如數據合法性、備份有效性、安全事件等）、預防性檢查（根據監控記錄、運行條件和狀況進行的預先檢查和趨勢分析，包括數據完整性、數據冗余、數據脆弱性）、常規作業。
  • 故障響應： 系統維護管理人員針對服務請求或故障申報進行的響應性支持服務。根據前提不同，可分為事件驅動響應（外部事件、系統事件、安全事件觸發）、服務請求響應、應急響應（重大事件、自然災害、政府行政命令）。
  • 數據備份： 對數據產生、存儲、備份、分發、銷毀等過程的操作，或對數據的應用范圍、應用權限、數據優化、數據安全等內容按規定程序進行的例行性作業，如數據備份、數據恢復、數據轉換、數據分發、數據清洗等。
  • 歸檔檢索： 根據需求對歸檔數據進行查找，是開展提供利用工作的基本手段和開發歸檔數據資源的必要條件。
  • 數據優化： 通過優化改進提高設備性能或管理能力，如調整數據庫索引、空間，增強設備投入或調整備份恢復策略降低數據丟失風險。

• 管理內容：

  • 維護方案： 明確組織體系、職責任務、防范重點、關鍵環節及可能造成的破壞程度、經濟損失度。
  • 例行管理： 對數據資源載體（存儲介質）、傳輸轉儲設備、歷史數據進行管理，對數據庫管理系統和數據庫進行維護、監控、優化，對數據資源進行備份與恢復管理。
  • 應急響應： 主要目標是在面臨事故和災難時保障數據高可用性和系統可持續性。需要預先制定應急預案、配置保障措施，并在災難發生后執行保護與恢復工作。具體包括制定應急故障處理預案/小組/步驟方法、災難發生后及時采取措施、制定災難恢復計劃并定期演練。
  • 數據資源的開發和利用： 對數據資源進行整理分析，利用知識發現工具有目的地挖掘數據，獲取新的信息或知識。

5.2 信息系統數據資源例行管理

數據資源例行管理是一種預防性的維護工作，旨在通過周期性監控、檢測和保養，及時發現并消除系統運行缺陷或隱患，使系統長期安全、穩定、可靠運行。

• 例行管理計劃： 根據信息系統側重點不同制定，需列出監控檢測對象、重要性等級、常規操作方法、頻次或周期、正常狀態值和報警閾值等。
• 數據資源載體的管理： 存儲介質要有明確標識，使用統一命名規范，注明重要信息。管理包括借用、轉儲、銷毀等環節，文檔中提供了相應的流程圖（借用、轉儲、銷毀管理流程，注意可能考流程順序）。
• 數據庫例行維護（重點）： 一般包括健康檢查、數據庫監測管理、數據庫備份與恢復、數據庫性能優化等方面。
  • 健康檢查： 包括數據庫日志檢查（日志是數據恢復的重要基礎）和數據庫一致性檢查（物理和邏輯一致性，使用DBCC命令）。列出了DBCC語句分類及其執行的任務。
  • 數據庫監測管理： 從應用可用性、系統資源占用和數據庫性能指標三個方面監測數據庫應用相關服務。包括數據庫基本信息監測（文件系統、碎片、死鎖進程）、數據庫表空間監測、數據庫I/O監測。
  • 數據庫備份與恢復： 解釋了數據備份是將數據和結構等信息復制到其他存儲介質。介紹了數據庫故障類型及恢復：事務故障（內部邏輯錯誤或系統錯誤）、系統故障（軟故障，系統停止運轉但數據庫不破壞）、介質故障（硬故障，外存故障破壞數據庫）。
  • 數據庫性能優化（重點）： 空間釋放（事務日志文件管理）、表的重構（針對更新頻繁的表）、索引重建（針對頻繁插入/更新/刪除操作的表）、數據分片（將海量數據分布在多個存儲設備上實現并行讀寫）。
  • Oracle數據庫監控： 通過系統自帶語句或監控軟件進行監控。詳細列出了監控內容和相應的SQL語句/視圖名稱，包括：檢查數據庫基本狀況（實例狀態、在線日志狀態、表空間狀態、數據文件狀態、無效對象、回滾段狀態）、檢查相關資源使用情況（初始化參數值、數據庫連接情況、系統磁盤空間、表空間使用情況、擴展異常對象、system表空間內容、對象的下一擴展與表空間最大擴展值）、檢查數據庫備份結果（重點，檢查備份日志信息、備份卷文件產生時間、Oracle用戶的Email）、檢查數據庫性能（等待事件、性能差的SQL、等待時間最多的系統等待事件、運行很久的SQL、消耗CPU最高的進程、碎片程度高的表、表空間的I/O比例、文件系統的I/O比例、死鎖及處理）、檢查數據庫CPU、I/O、內存性能（使用top、free -m、iostat、uptime命令，檢查僵死進程、行鏈接/遷移、定期做統計分析、緩沖區命中率、共享池命中率、排序區、日志緩沖區）、檢查數據庫安全性（系統安全日志信息、用戶修改密碼）、其他檢查（crontab任務、Oracle Job失敗、數據量增長情況、失效索引、不起作用的約束、無效trigger）。
  • SQL Server 監控： 使用SQL事件探查器和性能監控工具診斷性能問題。SQL事件探查器用于分析和衡量TSQL性能，捕捉服務器事件，可用于查看耗時過多的存儲過程、排除性能問題（使用模板、捕捉TableScan和DeadLock事件、創建重放跟蹤和優化跟蹤、捕捉ShowPlan）。性能監視工具PerfMon用于收集硬件和軟件相關的統計數據。

5.3 信息系統數據資源備份（重點）

數據備份是防止數據丟失的重要措施。數據備份系統由硬件和軟件兩部分組成，選擇時需考慮容量、費用、速度、易保管性、可維護性、可操作性、可用性、管理策略、對系統性能影響、可擴充性、運行費用等。

• 備份類型：

  • 按數據備份模式分： 邏輯備份（備份簡單，不需要外部存儲設備）和物理備份（實現完整恢復，需運行在歸檔模式下，需要較大外部存儲空間，如冷備份和熱備份）。
  • 按備份過程中是否可接收用戶響應和數據更新分： 冷備份（系統停止運行情況下復制，最快最安全）和熱備份（系統運行情況下備份，占用資源多，投資大，恢復時間短）。
  • 按數據備份策略分： 完全備份（所有數據拷貝）、增量備份（針對完全或上次備份，恢復繁瑣但備份快，冗余小）、差異備份（針對上次完全備份，恢復只需完全和最近差異備份，備份較快，冗余小）。
  • 按備份的實現方式分： 遠程磁帶庫/光盤庫備份、遠程關鍵數據+磁帶備份、遠程數據備份、網絡數據鏡像、遠程鏡像磁盤。
  • 按數據備份的存儲方式分： 直接附加的存儲方式（DAS，直接連接到服務器）、存儲區域網絡方式（SAN，通過光纖通道連接，易擴展，需高帶寬）、網絡附加存儲方式（NAS，獨立存儲節點在網絡中，依賴網絡穩定性，有自己的服務器和操作系統）。注意中英文對照。

• 常用備份相關技術（重點）：

  • 磁盤陣列技術（RAID）： 通過多塊磁盤組合提升性能和可靠性，將數據切割成區段存放在不同磁盤。介紹了不同RAID等級（RAID 0、RAID 1、RAID 5、RAID 10）的特點、容量、性能、安全性和典型應用，并對比了RAID 10和RAID 01。
  • 雙機熱備： 廣義指兩臺服務器互相備份執行同一服務，一臺故障時另一臺接管，自動保證服務持續。狹義指基于主備（active/standby）方式，數據同時寫多臺或使用共享存儲，一臺故障時備用機激活。按切換方式分為主-備方式和雙活方式。組成方案包括基于共享存儲（磁盤陣列）和基于數據復制（不建議使用，可能導致數據不完整）的方式，以及磁盤數據攔截（分區攔截技術、磁盤攔截技術）。

5.4 云環境下的數據資源存儲及維護

• 云存儲： 采用網格技術、分布式文件系統、集群應用等將海量異構存儲設備通過軟件控制，共同提供數據存儲訪問處理功能的系統服務。是多種存儲技術的綜合集成。與傳統PC存儲區別在于通過寬帶網絡將數據存放在遠端并進行訪問管理。
• 云環境下的數據資源維護： 云計算以數據為中心，在數據存儲、管理和安全方面有獨特技術。采用分布式存儲和冗余存儲保證可靠性。云存儲系統一般有命名服務器、元數據服務器、內容數據服務器。主要體現在對海量數據高可用性、安全性、高效管理的要求，以及面向新型存儲技術的數據資源維護方法變革。注意可以考歸類題，熟悉即可。

5.5 信息系統數據資源的開發與利用

從信息系統對決策支持的程序可劃分為事務處理、分析處理和商務智能三個層次，應用層次越高，對數據管理和集成性要求越高。

• 事務處理： 圍繞基本業務自動化，加工處理數據和信息，回答“發生了什么”。

• 分析處理： 圍繞分析和控制功能，回溯、分維、切片和what-if分析，回答“為何會發生”。

• 商務智能： 圍繞經營策略和競爭優勢，挖掘整理數據信息獲取支持決策的知識，回答“將會發生什么”。

• 數據倉庫： 數據獲取、數據存儲、數據訪問。

• 數據挖掘： 通過挖掘數據倉庫中大量數據，發現有意義的新的關聯模式和趨勢的過程。

  • 根據知識類型分類： 概念描述（歸納或簡約，如按年齡分組觀察購買頻次和平均消費額）、關聯規則（發現數據間關聯性、相關性、因果關系，如超市商品關聯分析）、分類和預測（按類劃分數據，挖掘描述和模型預測未來值）、聚類（按標準匯總數據形成新類）、時間序列數據分析（統計方法應用，包括趨勢偏差分析、用戶定義模式匹配、周期數據分析）。主要掌握“例如”。
  • 數據挖掘在電子商務中的應用： 找到潛在客戶、實現客戶駐留、改進站點設計、進行市場預測。
  • 數據挖掘過程： 準備數據、發現模式（統計分析、知識發現、可視化方法）、分析解釋模式（關聯規則、分類、聚類、序列模式、路徑分析）。
  • 數據挖掘在應用中面臨的問題： 分析變量選擇、數據抽取方法選擇、數據趨勢預測、數據模型可靠性、數據私有性和安全性、結果不確定性。

• WEB數據挖掘技術：

  • 包括三種數據挖掘任務： 對WEB內容的挖掘、對WEB結構的挖掘、對WEB訪問的挖掘（研究最深入）。
  • WEB數據挖掘流程： 查找資源、模式發現、模式分析。
  • 數據來源： 服務器端數據收集、包監測技術、后臺數據庫原有數據。
  • 技術實現總體流程： 確立目標樣本、提取特征信息、網絡信息獲取、信息特征匹配。

第六章 信息系統安全

6.1 概述

概念

信息系統安全是指保障計算機及其相關設備、設施（含網絡）的安全，運行環境的安全，信息的安全，實現信息系統的正常運行。

信息系統安全包括實體安全、運行安全、信息安全和人員安全。

• 實體安全： 也稱物理安全，保護計算機設備、設施及其他載體免遭自然災害和環境事故破壞。包括環境安全、設備安全和媒體安全。
• 運行安全： 目標是保證系統連續正常運行。包括系統風險管理、審計跟蹤、備份與恢復、應急處理。
• 信息安全： 防止信息資產被非法泄露、更改、破壞或非法辨識、控制，確保信息的保密性、完整性、可用性、可控性、真實性、可審查性。包括操作系統安全、數據庫安全、網絡安全、病毒防護、訪問控制、加密和鑒別。
• 人員安全： 指計算機使用人員的安全意識、法律意識及安全技能等。

常見信息安全術語（重點）

文檔列舉并解釋了一些常見的信息安全術語，包括：備份、解密、加密、暴露、容錯、信息系統控制、風險、威脅、脆弱性、保密性、完整性（數據完整性和系統完整性）、可用性、惡意軟件。

影響信息系統安全的因素

包括故意威脅和非故意威脅。

• 故意威脅： 攻擊者執行非法操作，如作為另一用戶執行命令、訪問受限數據、偽裝身份、執行拒絕服務攻擊。產生因素包括盜取、操控、破壞、依賴、恐怖襲擊。
• 非故意威脅： 系統存在弱點導致能力喪失，或存在可被輕易訪問的登錄點。產生因素包括人為錯誤（與安全性相關的大部分問題由此產生）、環境災害、信息系統故障。

信息系統安全保護等級

根據國標GB/T22240-2008《信息系統安全保護等級定級指南》提出定級方法。

• 等級劃分： 第一級（對公民、法人和其他組織合法權益造成損害，但不損害國家安全、社會秩序和公共利益）、第二級（對公民、法人和其他組織合法權益造成嚴重損害，或對社會秩序和公共利益造成損害，但不損害國家安全）、第三級（對社會秩序和公共利益造成嚴重損害，或對國家安全造成損害）、第四級（對社會秩序和公共利益造成特別嚴重損害，或對國家安全造成嚴重損害）、第五級（對國家安全造成特別嚴重損害）。
• 定級要素： 等級保護對象受到破壞時所侵害的客體（公民、法人及其他組織合法權益；社會秩序、公共利益；國家安全）和對客體造成侵害的程度（一般損害、嚴重損害、特別嚴重損害）。
• 定級一般流程： 確定定級對象 → 確定業務信息安全受破壞時侵害客體 → 綜合評定侵害程度 → 確定業務信息安全等級；同時進行 確定系統服務安全受破壞時侵害客體 → 綜合評定侵害程度 → 確定系統服務安全等級 → 最終確定定級對象的安全保護等級。

6.2 硬件安全運維

信息系統硬件是信息系統運行的物質基礎。

概念

硬件安全運行是指保護支撐信息系統業務活動的硬件資產免遭自然災害、人為行為導致的破壞。主要包含環境安全、設備安全和介質安全。

• 環境安全： 指信息系統核心設備的運行環境安全，要素包括機房場地選擇、屏蔽、防火、防水、防雷、防鼠、防盜、防毀、供配電系統、空調系統、綜合布線、區域防護等。
• 設備安全： 保護設備（服務器/網絡設備等）正常運行，免受威脅。
• 介質安全： 包括介質自身安全及介質數據的安全。

硬件安全運行的影響因素

1. 自然及不可抗因素
2. 人為的無意失誤
3. 人為的惡意攻擊
4. 缺乏完整可靠的安全防線（安全措施不完善）。

硬件安全運行的措施

• 環境安全： 重點保證中心機房安全，涉及機房場地的選擇、內部安全防護措施、建筑材料防火安全措施（規定了耐火等級）、供配電安全、防水防潮、溫度控制、防靜電、接地防雷擊、電磁防護等。
• 設備安全： 應按照相關技術要求提供設備的防盜防毀、防止電磁信息泄露、防止線路截獲、抗電磁干擾及電源保護等措施。設備應提供基本的運行支持和必要的容錯故障恢復能力（如磁盤陣列技術、硬盤鏡像技術）。提及了內外網隔離（網閘物理隔離，防火墻邏輯隔離）。
• 記錄介質安全： 采取嚴格保護措施防止被盜、被毀、受損；對應該刪除銷毀的重要數據要有有效管理審批手續，防止非法復制；配備門衛、值班管理員、電子監控設備等，限制對網絡設備的物理接觸。

6.3 軟件安全運行

信息系統的正常運作依賴于信息系統軟件的正確運行。

概念

軟件包括系統軟件（操作系統、數據庫系統、中間件）和信息系統應用軟件（如ERP、SCM/CRM、OA等）。根據GB17859-1999《計算機信息系統安全保護等級劃分準則》進行分級（用戶自主保護級、系統審計保護級、安全標記保護級、結構化保護級、訪問驗證保護級）。

影響因素

主要有兩種：

1. 針對操作系統的安全漏洞實施攻擊。
2. 針對基于WEB的信息系統軟件的攻擊。

• 操作系統安全漏洞： 輸入輸出非法輸入、訪問控制混亂、不完全的中介、操作系統后門、操作系統型病毒。
• 基于WEB的信息系統軟件攻擊： 常見方法和技術包括修改Cookie、利用不安全證書、非法輸入獲取敏感信息、緩沖區溢出、強制訪問未授權網頁、修改隱藏變量、構造非法請求、提交非法腳本、SQL注入。
• 主要攻擊方式： 欺騙、數據篡改（常為內部人員）、病毒攻擊（使用頻率最高）、拒絕服務攻擊（影響最廣泛）、編程攻擊。
• 編程攻擊的方法（重點）： （概念和闡述的對應）病毒、蠕蟲、特洛伊木馬、邏輯炸彈、拒絕服務、嗅探器、偽裝欺騙、口令破解、后門、惡意小程序、數據包監測、ARP攻擊。

軟件安全運行的措施

1. 操作系統的安全： 構造安全模型（單級、多級、系統安全模型）和實施方法；采用隔離、核化、環結構等設計方法；建立完善的評估標準、評價方法和測量質量。對付后門的方法包括加強開發階段控制、實行科學使用控制、制定規范開發標準加強管理監督。
2. 服務器上的操作系統軟件、防病毒軟件和防火墻軟件的安全： 根據需求選擇合適操作系統并定期更新補丁；安裝防病毒軟件并定期更新補丁和病毒特征庫；安裝防火墻軟件并定期更新補丁、配置安全防護策略；定期對服務器操作系統進行安全檢查（建議每周一次）。
3. 防范病毒的策略（重點）： 制定完善的計劃是最佳方法。介紹了病毒的進入途徑和相應的防范策略（掃描下載程序文檔、每日掃描、充分備份、保留審計記錄、掃描軟盤、掃描上傳下載文件、頻繁備份、使用干凈啟動/恢復盤、不要信任外部PC、病毒掃描前制定策略、明確風險領域）。為將危害降到最小的防范措施包括安裝反病毒軟件、每周掃描硬盤、U盤寫保護和掃描、程序磁盤寫保護、完整頻繁備份、不信任外部PC、制定反病毒策略、明確風險領域。針對病毒的防范措施主要包括制定處理電子郵件規章制度、使用互聯網服務提供商的病毒檢測控制服務（可使用新技術、防止內部犯罪、轉嫁風險）、合同注明條款避免損失、指導員工掃描發送的電子郵件。
4. 信息系統軟件的安全： 劣質軟件導致安全問題是管理規范問題，可將責任交給特定小組（需要黑白帽子思維人員）。實施安全計劃可雇用外部咨詢人員，但此類人員稀少成本高。對大型系統可培養熟悉軟件操作的人員負責安全。應用系統服務器安裝了信息系統軟件，是業務處理平臺，用戶讀寫數據的橋梁，應有專人持有密碼并定期修改且符合復雜性要求。
5. Web應用系統上傳漏洞和SQL注入防范： 解決辦法包括服務器端路徑參數盡量使用常量、對用戶提交數據全面檢查（文件后綴名、禁止自定義文件名）、加強操作系統安全配置限制執行權限；SQL注入防范必須在軟件開發程序代碼上形成良好編程規范和代碼檢測機制。
6. Web應用系統漏洞檢測技術： 爬蟲技術（遍歷網頁分析系統）、Web應用系統軟件安全漏洞檢測技術（利用爬蟲分析架構，利用工具建立數據庫進行模式匹配找漏洞）、Web系統應用軟件安全漏洞驗證技術（對發現漏洞進行驗證）、代碼審計（檢查代碼找弱點）。
7. 防火墻技術： 主要由服務訪問政策、驗證工具、包過濾和應用網關組成。主要作用體現在排除未授權用戶、禁止脆弱服務進出、過濾不安全服務非法用戶、防止IP盜用路由攻擊、防止入侵者接近防御設施、限定用戶訪問特殊站點、為監視Internet安全提供方便（重點）。
8. 入侵檢測技術： 對計算機網絡資源的惡意使用行為（外部入侵和內部非授權行為）進行識別和相應處理。按檢測方法分基于行為和基于知識；按分析原始數據分來自系統日志和網絡數據包。常用手段包括監視分析用戶系統活動、系統構造和弱點審計、識別已知進攻活動模式并報警、異常行為模式統計分析、評估重要系統和數據文件完整性、操作系統審計跟蹤管理識別違反安全策略行為。

6.4 信息系統數據安全

數據是體系組織核心競爭力的重要資源。

概念

數據安全是指保護數據不會被意外或故意泄露給未經授權人員，以及免遭未經授權的修改或破壞。數據安全是信息系統安全保障的核心問題之一。

數據安全的兩個基本原則（重點）：

1. 最低特權： 用戶只能獲得執行任務必需的信息。
2. 最少透露： 用戶訪問敏感信息后，有責任保護信息，不向無關人員透露。

數據安全技術包括以保持數據完整性為目的的數據加密、訪問控制、備份等技術，也包括數據銷毀和數據恢復技術。

影響因素

1. 物理環境的威脅（硬件故障、自然災害、系統軟硬件不可知因素）。
2. 病毒與非法訪問的威脅。
3. 對數據庫的錯誤使用與管理不到位。
4. 數據庫系統自身的安全缺陷（數據庫基本特征是自主訪問控制）。

保護數據安全的措施

防御重點是預防。

1. 容災與數據備份：
   • 容災系統（業務處理連續能力最高）。
   • 高可用集群系統（業務連續性比容災系統低）。
   • 智能存儲系統（LAN自由備份、無服務器備份）。
   • 實施數據備份要做到3點：制定詳盡備份策略、定期檢查備份執行日志/情況、備份數據介質集中異地保管。
   • 備份系統。
2. 身份認證： 入網訪問控制（基于生物特征認證）。
3. 網絡的權限控制： 針對網絡非法操作的安全保護措施，根據訪問權限分特殊用戶（系統管理員）和一般用戶。對目錄和文件的訪問權限一般有八種（系統管理員權限、刪除權限、讀權限、寫權限、創建權限、修改權限、文件查找權限、存取控制權限）。
4. 數據加密： 實現數據存儲和傳輸保密的重要手段。實現了三個目的：驗證身份、控制和保護隱私。方法有對稱密鑰加密（雙方共享密鑰，加解密速度快，算法易實現，安全性好，用于孤立環境，缺點是密鑰短，密碼空間小）和非對稱密鑰加密（公開密鑰和私有密鑰對，私有密鑰加密，公開密鑰解密，即簽名過程，CA驗證）。

云環境下的數據安全

• 云環境下的數據安全策略： 建立以數據為中心的安全系統、重視加密方法和策略規則、完善認證與身份管理體系。
• 云環境下的數據安全： 數據生成階段（回避）、數據遷移階段（傳輸加密）、數據使用階段（靜態數據通常不加密，處理來自公共資源是漏洞）、數據共享階段（共享策略）、數據存儲階段（加密，對稱式加密算法更適合）、數據銷毀階段（硬盤擦寫、數據銷毀算法、物理銷毀）。

6.5 信息系統安全管理

信息安全管理體系

三要素：人、制度和技術。過程包括確定方針和范圍、進行風險分析（資產評估是前提）、根據風險分析建立體系（法律政策、規章制度、教育、技術措施、審計管理措施）、建立業務持續計劃并實施安全管理體系。指導思想是：技術產品是基礎，管理是關鍵，人員管理是核心，政策是指導原則。

災難備份與災難恢復

災難指人為或自然原因造成信息系統嚴重故障、癱瘓或數據嚴重受損，導致業務停頓或服務水平不可接受的突發事件。災難恢復是將信息系統從不可運行狀態恢復到可接受狀態的活動或流程。業務連貫性計劃（BCP）也叫災難恢復計劃（DRP）。災難備份是前提基礎，災難恢復是具體應用。

• 類型： 按距離遠近分同城災備（易實現同步鏡像，數據零丟失，防范火災、建筑物破壞、供電故障、人為破壞等）和異地災備（距離遠，異步鏡像，少量數據丟失，防范戰爭、地震、水災等）。按保障內容分（文檔中未詳細展開）。
• 制定災難恢復計劃的主要觀點： 目的在于災難發生后確保業務運轉，信息系統部門和職能經理參與制定，針對每項職能制定恢復計劃，首先關注全部功能喪失情況下的恢復，檢驗能力涉及假設分析，計劃必須書面并標明關鍵應用和恢復規程，放置安全地點，分發副本，定期審定，可使用專用軟件提高效率。
• 可能存在的缺陷： 不全面、不充分或效力不足、不現實、過于細致、未進行溝通、缺乏明確流程、未經測試、未經協調、過時、缺乏關于恢復的思考。
• 災難備份與恢復的衡量（重點）： 恢復點目標（RPO，丟失的數據量）、恢復時間目標（RTO，系統恢復時間）、恢復可靠性指標（RRO，恢復/切換成功率）、恢復完整性指標（RIO，恢復到正確完整邏輯狀態的能力）。
• 災難備份與恢復的等級（重點）： 按國際標準SHARE78分7個等級（0級至6級，6級為數據零丟失）；按國家標準GB/T20988-2007分6個等級（1級至6級，6級為零數據丟失和遠程集群支持）。國家機關、金融等重要部門數據中心級別要求4級以上。

涉密信息系統安全管理

• 級別劃分： 秘密級（三級要求）、機密級、機密級（增強）、絕密級（五級要求）。
• 管理要求： 集中管控、終端不存、個人不留（實現集中存儲、計算、管理）。
• 分級保護的管理過程： 系統定級階段、安全規劃方案設計階段、安全工程實施階段、信息系統測評階段、系統審批階段、安全運行及維護階段、定期評測與檢查階段、系統隱退終止階段。
• 安全運行的隱患與防范： 安全措施調整不影響定級時從安全運行及維護階段進入安全工程實施階段；改變安全分級時進入系統定級階段重新開始分級保護實施過程。

第七章 物聯網、云計算運維

本章探討物聯網和云計算環境下的信息系統運維。

7.1 物聯網運維

概念及特征

• 概念： 物聯網（IoT）是在計算機互聯網基礎上，通過信息傳感設備將物與物連接起來，按約定協議進行信息交換和通信，實現智能化識別、定位、跟蹤、感知、監控和管理的一種網絡概念。
• 特征：
  1. 全面感知： 利用條碼、RFID、傳感器等隨時隨地采集獲取物體信息。
  2. 充分互聯： 通過互聯網和各種無線網絡融合，實時準確傳遞物體信息。
  3. 智能處理： 利用模式識別、海量數據檢索、數據挖掘等技術分析優化處理海量數據信息，提取有用數據，實現智能化決策和控制。
• 以上三個特征要求物聯網相連的每件物品均可尋址、可通信和可控制。

體系結構（重點）

物聯網的體系結構分為四個層次，由下到上依次為：感知層、傳輸層、處理層、應用層。需要記住每個層次及其內容。

• 感知層： 位于最下層，是基礎，作用是采集各種物體設備的數據，采集設備包括RFID閱讀器、無線傳感器、GPS定位系統、智能設備等。在數據傳輸前進行預處理，只傳輸關鍵數據以減少傳輸負載。
• 傳輸層： 位于感知層和處理層之間，起到承上啟下的作用，負責穩定、高效、實時、安全地傳輸上下層數據，實現“全面、隨時、隨地”傳輸感知層數據。包括傳感網絡、短距離無線通信、移動網絡、有線網絡。
• 處理層： 位于傳輸層和應用層之間，是物聯網智能的源泉。包括智能處理、云計算、數據挖掘。
• 應用層： 物聯網的終極目標，各種關鍵技術最終落腳在智能應用。包括運營平臺、信息中心、內容服務、專家系統。

應用類型

• 監管控制型（如污染監控）
• 查詢檢索型（如智能電網遠程抄表）
• 智能控制型（如智能交通路燈控制、智能家居控制）
• 智能掃描型（如條碼/RFID標簽掃描、手機錢包、交通運輸碼ETC應用）

物聯網RFID關鍵技術

• 射頻識別技術（RFID）系統邏輯由EPC標簽、讀寫器、Savant中間件、ONS服務器、EPCIS等組成。
• RFID對物品進行信息檢索的部件是： Savant中間件、ONS服務器、EPCIS。
• ONS服務器： 解析EPCID與對應的EPCIS服務器，類似互聯網中的DNS。
• EPCIS： 提供與ID相關聯信息的服務器。
• 神經網絡系統（Savant中間件）： 分布式操作軟件，管理傳送EPC碼相關數據，處于讀寫器和局域網/Internet之間，負責數據緩存、過濾、處理等功能。
• EPC信息服務器（EPCIS）與物理標記語言（PML）： EPCIS由產品制造商維護，存放產品相關數據信息的PML文件。PML是由XML擴展而來的適合物聯網數據通信的語言，由PML核（記錄底層設備物品信息）和PML擴展（記錄其他附加信息）組成。
• 讀寫器： 對EPC標簽進行信息數據讀取或寫入的設備。按設置方式分（手持移動、固定），按讀寫功能分（閱讀器、編程器、讀寫器）。
• EPC標簽的分類（重點）： RFID系統的標識和部分數據載體，由標簽專用芯片和標簽天線組成。
  • 根據供電方式： 有源EPC標簽（主動，距離大，成本高）、無源EPC標簽（被動，距離小，成本低）、半有源EPC標簽（半主動）。
  • 根據頻率： 低頻、高頻、超高頻、微波EPC標簽。
  • 根據封裝形式： 紙狀、玻璃管、線形、圓形、信用卡標簽以及特殊用途的異性標簽等。

物聯網WSN關鍵技術（無線傳感器網絡）

• 物聯網的前提是為物體賦予獨特地址（RFID標簽、EPC編碼解決）。
• IPV6： IPV4更新版，支持地址數量遠大于IPV4。IPV4到IPV6過渡采用雙棧技術和隧道技術（將IPV6數據包打包成IPV4數據包傳輸）。
• 傳感器（Sensor）： 把物理量轉換為電信號的器件，物理世界與電氣設備世界的數據接口，選取應根據需測量物理量和傳感器性能。
• 無線傳感器網絡（WSN）： 部署在監測區域內大量傳感器節點通過無線通信形成的多跳自組織網絡，通過基站與其他網絡互聯，遵循IEEE802.15標準。WSN基于低速無線網絡，功耗低。

物聯網運維系統體系結構

物聯網運維系統基于ITIL理念。體系結構分為控制系統層、數據處理層和運維服務層。

• 控制系統層： 物聯網運維管理要集成的對象，包括RFID操作系統、傳感器管理系統、網絡管理系統、監控系統等，獨立運行，對外提供不同接口。

• 數據處理層： 提供運維管理系統所需的經邏輯處理后的數據。對運維系統數據進行處理、分類，選擇合適的數據存儲系統存儲到數據中心。包括數據采集轉換、高速緩存、優化整理、報警分析、聯動分析、業務流程、數據持久化。

• 運維服務層： 整個系統的對外展現窗口，包括各種監控、查詢、配置的功能界面模塊，如報警監控、實時監控、視頻監控、業務管理等通用功能組件和業務流程處理界面，提供個性化用戶界面。包括用戶管理、終端管理、實時監控、其他模塊。

• 實時監控： 直接提取顯示數據處理模塊采集處理的數據，或將高速緩存中的數據入庫前直接展示給用戶。

• 歷史數據查詢： 將高速緩存數據存儲到數據中心，用戶通過搜索引擎查詢歷史數據。

• 智能告警： 對數據處理層處理后的數據進行檢索，超過閾值則產生告警事件。功能包括閾值設置、自動報警、報警處理。

物聯網運維系統特點

1. 基于B/S模式，便于用戶通過網絡瀏覽器訪問。
2. 實時展示傳感節點信息，通過手動設置值產生告警事件并處理。
3. 物品跟蹤時，實時更新物品和標簽對應關系，設置物品運行路徑，維護讀寫器信息。
4. 支持分布式數據采集和處理。
5. 基于ITIL框架的業務流程設計。

7.2 云計算運維

概念

云計算是一種基于互聯網的計算新模式。Wiki定義是通過互聯網上異構、自治的服務提供按需即取的計算。Gartner定義是利用互聯網技術將大量可擴展彈性的相關能力作為服務提供給多個用戶。中國云計算網定義是分布式計算、并行計算和網格計算的發展或商業實現。

本質特征

分布式的計算和存儲特性、高擴展性、用戶友好性、良好的管理性、用時付費。

四個要素

1. 硬件、平臺、軟件和服務都是資源，通過互聯網以服務方式提供（改變了傳統自給自足模式）。
2. 資源可根據需要動態擴展和配置。
3. 資源物理上以分布式的共享方式存在，邏輯上以單一整體呈現（理解包括并行計算的地域集中和地域上的分布式）。
4. 用戶按需使用云中資源，不需要管理（即付即用模式）。

體系結構

云計算體系結構包括技術層次和服務層次。

• 云計算技術層次： IT基礎資源、虛擬化資源、中間件管理部分、服務接口。
  • 服務接口：統一規定服務接入點規范標準，形成客戶端與云資源交互接口，負責用戶注冊、查找、定制、使用功能。
  • 中間件管理：在云計算機服務與IT基礎資源之間提供管理和服務行為，包括資源、安全、用戶、鏡像管理等。
  • IT基礎資源：支持云計算系統正常運行的基礎設施及技術。
  • 虛擬化資源：對IT基礎資源進行虛擬化獲得更靈活可靠功能，如網絡/存儲/計算/數據庫資源池。
• 云計算服務層次： 可劃分成四個不同層級的服務集合，越往上客戶管理越少。
  1. 軟件即服務（SaaS）： 通過網絡提供程序服務，最接近用戶，用戶通過瘦客戶端訪問，不管理底層基礎設施。
  2. 平臺即服務（PaaS）： 提供開發語言和工具等部署到云計算基礎設施的服務。客戶不管理底層基礎設施，但能控制應用程序和托管環境設置。
  3. 基礎設施即服務（IaaS）： 出租基礎設施，提供虛擬集群計算能力和存儲能力。客戶不管理云計算基礎設施，但能控制操作系統、存儲空間、部署應用，可能獲得有限網絡組件控制。
  4. 硬件即服務（HaaS）： 將硬件資源作為服務提供給用戶，加速云計算客戶端向“瘦客戶端”發展。

云計算部署模式

• 公有云： 對外部客戶提供服務，優點是無須投資建設，問題是有數據安全風險，可用性不受使用者控制。
• 私有云： 企業自己使用，服務供內部人員或分支機構使用。優點是安全性、系統可用性可自己控制，問題是投資大。
• 混合云： 介于公有云和私有云之間。部署方式對提供者要求較高。

云計算的數據中心

發展歷史經歷了三個階段：大集中過程（解決分散管理和容災）、實施虛擬化（提升靈活性，提高資源利用率，降低成本）、云計算階段（解決動態需求和最終成本問題，IT部門專注于服務提供和業務運營）。大集中面向物理組件和業務模塊，虛擬化面向計算與存儲資源，云計算最終面向IT服務。

ITIL目前在國內主要應用V2版本，包括一個職能（服務臺）和六大模塊（服務管理、IT基礎設施管理、服務管理規劃與實施、應用管理、安全管理、業務視角）。服務管理是核心，分服務交付和服務支持兩部分。

關鍵技術

• 虛擬化技術（核心）： 允許將硬件視為資源池按需分配。優勢包括更高利用率、節省能耗成本、節約空間、災難恢復/業務連續性。
  • 虛擬化分類： 按實現層次分（平臺虛擬化、操作系統虛擬化、應用程序虛擬化），按應用領域分（計算、存儲、網絡、安全、桌面虛擬化等），按某類衍生劃分（CPU、文件虛擬化等）。
  • 不同實現層次上的虛擬化（重點）：
    • 平臺虛擬化：允許任意操作系統及應用環境運行于特定系統之上。虛擬機監控器（VMM）分完整虛擬化（硬件虛擬化）和準虛擬化（半虛擬化）。
    • 操作系統虛擬化：以母體系統為樣本克隆多個子系統，解決核心安全、隱私、管理問題。
    • 應用程序虛擬化：軟件免重裝，不怕系統重裝。
• 虛擬化管理： 包括虛擬化網絡管理（實現物理設備協同工作和統一管理）和虛擬化服務器管理（基于VMware架構管理虛擬資源和虛擬機遷移）。
• 資源管理技術
• 任務管理技術
• 應用管理IMC APM、統一數據管理平臺IMC UDM、iAR智能分析報表管理IMC IAR。

第八章 銀行信息系統運維

銀行信息系統在降低運營成本、促進金融產品發展以及突破時間和空間限制方面發揮著重要作用。

銀行信息系統目標（重點）

1. 數據實時處理
2. 支持對大規模數據的并發處理
3. 數據集中管理
4. 高度安全性

銀行信息系統功能

銀行信息系統通過多種渠道，以核心模塊和應用程序對客戶信息和賬戶信息進行輸入、處理、傳輸、存儲和輸出。處理對象是客戶資料和業務資料（客戶數據和賬務數據）。

根據業務性質，可分為：

1. 后臺處理系統：掌握營業狀況、防范金融犯罪、保存查閱業務檔案、分析挖掘潛在客戶數據。
2. 前置處理系統：面向各業務應用系統進行統一接入管理和判斷轉發，屏蔽核心賬務系統，減輕負荷，簡化開發維護。
3. 柜面業務系統
4. 自助服務系統

銀行信息系統結構（重點）

銀行信息系統結構通常分為五個層次：

1. 基礎框架層： 規定開發、運行和維護的基本規范和規章制度，包括存儲服務、容災備份策略、安全體系架構、標準管理、運維體系和系統管理等。
2. 數據層： 主要包括客戶數據和賬務數據，普遍采用總行數據大集中管理模式。包括客戶信息數據、綜合賬務數據、信用卡賬務數據（通常在總行數據大集中服務器上），中間業務的客戶數據、清算與對賬數據、地方性安全認證數據（通常在各地分行的前置平臺上）。
3. 應用系統層： 包括核心業務系統（總賬、客戶信息、信貸管理、現金管理系統）、業務輔助支持系統（財務管理、綜合報表、人力資源、知識管理系統）、經營管理系統（客戶關系管理、風險管理、績效管理、管理會計、審計管理系統）。
4. 渠道整合層： 連接應用系統層和客戶服務層，是數據交換樞紐和安全保障核心。包括綜合前置平臺和銀行統一門戶平臺。
5. 客戶服務層： 通過多種方式滿足客戶需求（自助服務設備、手機銀行、網上銀行系統、綜合前端服務平臺）。

實例架構

文檔中給出了一個實例架構，包括集中展現層（可視化展示、統一運維門戶、統計、權限管理、通知中心等）、數據匯聚層（監控性能、告警數據匯聚采集與集中存儲，提供統一事件平臺和性能管理）、監控工具層（面向各類設備的資源監控采集）、系統接口（與第三方系統的數據/功能接口、上線級聯接口、展現接口）。

網絡監控管理

1. 網絡設備管理：監控網絡、安全設備基本狀態和實時運行性能。
2. 網絡拓撲管理：自動計算網絡拓撲，采集設備運行狀態和性能參數，直觀反映網絡設備和線路整體狀態。
3. 網絡性能監控：監控網絡、安全設備基本狀態和實時運行性能。
4. 網絡故障監控：監測和定位網絡故障事件，實時采集故障信息，發現可能導致網絡運行異常的事件。

• 網絡設備可監控項： CPU利用率、內存利用率、并發連接數、風扇狀態、電源狀態、溫度、路由表、吞吐量、PING時延等。端口相關指標如ARP包率、單播包率、發送/接收利用率、發送/接收丟包率、發送/接收錯包率、發送/接收速率、廣播率、組播包率等。接口狀態、接口收發流量、接口廣播/組播、接口丟包率、帶寬、帶寬利用率等。
• 網絡協議監測： 包括STP、VTP、OSPF、BGP協議。

系統應用監控

1. 主機設備監控管理： 服務器硬件監控（電流、傳感器風扇/狀態/溫度、電源功率等，通過IPMI協議實現）和服務器操作系統監控。
2. 數據庫監控管理： 監控數據庫運行狀態和性能。
3. 應用與中間件監控管理： 對基礎應用平臺的基礎信息、連接測試、基本負載等重要信息進行監測，分析服務響應速度變化的技術原因和規律。列舉了常見的通用服務（如Apache, HTTP/HTTPS, IIS, Domino, POP3, SMTP, DNS, FTP）及其監測內容。
4. 虛擬化監控管理： 對虛擬化環境進行監控。

統一事件平臺

運維管理平臺的核心功能之一。將IT系統中各種設備或管理系統產生的事件作為原始事件，按預定義規則進行過濾、分類、分級、轉換等處理，形成有效預警或故障告警信息，按預定方式通知管理人員或自動響應。支持告警升級、自動或手動消除，用戶自定義故障類型升級策略。包括環節：事件接收、事件標準化、事件過濾、事件壓縮、告警消除、告警升級、告警豐富、告警根源分析、告警聯動通知。

統一性能管理PMDB

包括監控可視化（可視化設計工具、運行可視化展示）和綜合管理（統一門戶、通知中心、報表平臺、權限管理）。

系統接口與集成方案

• 系統接口設計原則： 開放性、先進性、標準性、高效性、安全性、穩定性、易實現性、易維護性。
• 二次開發擴展接口： 監控采集擴展、數據匯聚和管理擴展、事件接受處理擴展、運維流程擴展、報表展現擴展、數據倉庫、上下級聯接口。
• 系統擴展性設計： 監測能力擴展、事件處理擴展。

銀行災備系統

首先區分幾個概念：業務連續性管理、應急管理、災備管理。

• 業務連續性管理： 針對可能導致業務中斷的風險或已發生并導致業務中斷的事件進行管理。
• 應急管理： 關注各種突發事件的應急處置，不一定會導致業務中斷但會造成影響。
• 災備管理： 業務連續性管理和應急管理的交集中的特殊情況，專門針對IT災難。

文檔中用維恩圖示例說明了這三個概念的交叉關系，并給出了一些具體的例子（如營業所火災屬于災備管理、員工宿舍樓火災屬于應急管理、核心業務系統交易高峰CPU負載過高屬于業務連續性管理）。

• 框架： 災備體系建設需要從技術、管理、業務三個方面進行。
  • 技術體系： 包括恢復信息系統所需的數據、人員、系統、網絡、環境和預案等。數據和人員是前提，系統、網絡、環境是技術資源保障，預案是行動方案。包括數據備份、運行和技術保障、備用數據處理系統、備用網絡系統、備用基礎設施（最重要的是災備機房）、災難恢復預案。
  • 管理體系： 組織機構在日常和災難狀態下的管理工作。包括災難恢復組織機構、崗位和培訓管理、災難恢復預案管理與演練（演練是驗證預案有效性的最佳手段）、災備中心日常運維/災難響應與重續運行管理、外部資源管理（與合作對象、服務商等建立日常聯系或簽訂協議并測試支持能力）。
  • 業務體系： 主要指業務恢復預案。
• 災備體系建設步驟：
  1. 制定災難恢復策略（指導方針）。
  2. 按框架從技術、管理、業務三方面建設災備體系，實現災備恢復策略。
  3. 組織災難恢復演練。 這三個步驟是一個循環迭代、不斷完善演進的過程。策略調整需重新審視調整體系、組織演練、修訂管理制度。

第九章 大型網站運維

9.1 大型網站概述

定義與分類

• 定義： 大型網站基于運維復雜性角度，指的是網站運維相關的指標，如網站規模、知名度、服務器規模（大于1000臺）、頁面瀏覽量 PV（每天上億）等達到一定量級。
• 分類：
  • 按照發展階段劃分：
    • Web 1.0：以靜態、單向閱讀為主，信息可以直接與其他網站信息交換，能通過第三方平臺整合多家網站信息。
    • Web 2.0：以分享為特征的實時網絡，用戶擁有自己的數據并在不同網站使用。
    • Web 3.0：以網絡化和個性化為特征，提供更多人工智能服務，完全基于 web，瀏覽器即可實現復雜系統程序功能。強調微內容自由整合、適合多種終端平臺、良好人性化用戶體驗及個性化配置、有效有序的數字新技術。
  • 按照應用類型劃分：
    • 資訊類網站（新聞門戶）：信息量大、訪問群體多、功能相對簡單。
    • 交易類網站（電子商務）：以實現交易為目的，功能復雜，數據精確性要求高。
    • 社會性網站（SNS）：基于社會網絡關系，支持用戶高頻輸入，要求支持高并發寫入，數據一致性要求相對較弱。
    • 游戲類網站：投入取決于游戲復雜度。
    • 功能類網站：將廣泛需求的功能擴展到極致，如搜索引擎類。

大型網站的特點（重點）

1. 并發用戶數多、流量大。
2. 系統 24 小時不間斷服務的高可用性。
3. 需要使用大量服務器以存儲和管理海量數據。
4. 用戶分布廣泛、網絡情況復雜。
5. 層出不窮的安全問題。
6. 產品更新、需求變更快，發布頻繁，以適應不斷變化的用戶需求。
7. 系統架構由簡到繁的不斷變化。

大型網站架構的演進

大型網站的架構通常會經歷一個逐步演進的過程，以應對不斷增長的訪問量和數據量。

1. 最開始的網絡架構： 應用程序、數據庫、文件都部署在一臺服務器上。
2. 應用、數據、文件分離： 應用程序、數據庫、文件各自部署在獨立的服務器上。
3. 利用緩存改善網站性能（重點）：
   • 緩存實現常見方式：本地緩存、分布式緩存（還有 CDN 內容分發網絡、反向代理等）。
   • 本地緩存：數據緩存在應用服務器本地（內存或文件，如 OS catch），速度快，但空間有限。
   • 分布式緩存：可緩存海量數據，易擴展（常使用 Memcached、Redis），速度可能不如本地緩存。
   • 28 原則：80% 的訪問請求最終落在 20% 的數據上。
4. 使用集群改善應用服務器性能： 在應用服務器前部署負載均衡服務器調度用戶請求，分發到多個應用服務器節點。
   • 常見的負載均衡技術：硬件有 F5，軟件有 LVS（四層負載均衡）、Nginx（七層負載均衡）、HAProxy（四層、七層負載均衡）。
   • LVS 分發路徑優于 Nginx 和 HAProxy，性能更高；Nginx 和 HAProxy 更具配置性，可用于動靜分離。
5. 數據庫讀寫分離和分庫分表： 改善數據庫性能。
   • 讀寫分離：將數據庫分為讀庫和寫庫，通過主備功能實現數據同步。
   • 分庫分表：水平切分（拆分特大的表）和垂直切分（根據業務不同切分）。
6. 使用 CDN 和反向代理提高網站性能：
   • CDN：將內容緩存到運營商機房，用戶從最近運營商獲取數據，減少網絡訪問路徑。
   • 反向代理：部署在網站機房，用戶請求先訪問反向代理服務器，返回緩存數據，否則從應用服務器獲取（反向代理如 Squid、Nginx，其實是一種緩存）。
7. 使用分布式文件系統： 應對文件增多，單臺文件服務器無法滿足需求。
   • 常用的分布式文件系統：NFS、GFS（Google）、ZFS、Ceph、TFS（TAOBAO）、MFS、HDFS（hadoop）。
8. 使用 NoSQL 和搜索引擎： 針對海量數據查詢，提升性能（鍵值對映射）。
   • 常用的 NoSQL：Mongodb 和 Redis。
   • 搜索引擎：Lucene。
9. 將應用服務器進行業務拆分： 將應用程序拆分為獨立業務應用，通過消息通信或共享數據庫。
10. 搭建分布式服務： 抽取應用使用的基礎服務，利用分布式服務框架搭建。

文檔中還提供了常用軟件的分類和名稱列表（如本地緩存、分布式緩存、反向代理、分布式文件系統、NoSQL、搜索引擎、負載均衡技術硬件/軟件），需要記住這些工具與類型的對應關系。

9.2 大型網站運維背景知識

運維的技能及素質

運維是一個集多 IT 工種技能于一身的崗位，需要對系統、網絡、存儲協議、需求、開發、測試、安全等各環節有一定了解，對某些環節須熟悉甚至精通。

• 技能方面：
  1. 開發能力（需要開發運維工具）。
  2. 通用應用了解：操作系統（Linux、BSD）、WebServer（Nginx、PHP、Apache、JAVA、Lighttpd）、數據庫（MySQL）。
  3. 系統、網絡、安全、存儲、CDN、DB 等相關原理。
• 素質方面：
  1. 溝通能力、團隊協作。
  2. 工作中需膽大心細。
  3. 主動性、執行力、意志力。
  4. 做網站運維需要有探索創新精神。
• 合格的運維工程師：
  1. 保證服務達到要求的線上標準，保證線上穩定。
  2. 不斷提升應用的可靠性與健壯性、性能優化、安全提升。
  3. 網站各層面監控、統計的覆蓋度，避免監控死角，實時了解應用運轉情況。
  4. 通過創新思維解決運維效率問題。
  5. 運維知識的積累與沉淀、文檔的完備性。
  6. 計劃性和執行力。
  7. 自動化運維。

運維的關鍵技術點

• 大規模集群管理問題： 常規集群可分為高可用性集群（HA）、負載均衡集群（LVS）、分布式存儲、計算存儲集群（DFS，如 Google GFS、Yahoo Hadoop）、特定應用集群（如 DB、Cache 層等）。需要記住這些英文縮寫。
• 監控： 包括故障監控和性能、流量、負載等狀態監控，關系到集群健康運行及潛在問題發現干預。包括服務故障/狀態監控和集群狀態類監控或統計。
• 故障管理： 處理硬件故障和應用故障問題。
• 自動化： 自動化運維是運維工程師職業追求和核心重點工作之一，是價值體現。

大量高并發網站的設計方案

高可靠、高可伸縮性網絡架構設計；網站安全問題；南北互聯問題，動態 CDN 解決方案；海量數據存儲架構。

9.3 政府門戶網站運維案例分析

這部分通過政府門戶網站運維案例，介紹了運維服務總則、運維團隊組織、運維服務內容、應急處理流程以及一些常用的 Linux 命令。

運維服務總則

1. 安全性： 包括網站應用系統及內容管理平臺應用的安全性、數據安全性。
2. 穩定性：
   • IT 服務體系整體結構：客戶需求、響應體系、維護體系、質量監督體系（后三者對應 ITIL 中的事件管理、問題管理和運維管理）。
   • 響應體系：包括服務臺和突發事件管理。
   • IT 運維體系的建立：導入 ITIL 是一個長期過程，初期以“系統日常運行和支持”為主，重點解決服務支持流程；后期關注長期計劃和改進。針對政府門戶網站，初期主要實現“服務臺”、“事件管理”、“問題管理”和“配置管理”，并擴展加設“知識庫”以提高技術積累和利用。
3. 系統運維制度建設： 轉變運維觀念、樹立規范化意識，建立事件處理流程，強化規范執行力度。
4. 系統運維故障級別定義：
   • 一級故障：系統發生嚴重故障，業務中斷，或無法保證及時正確（對業務運行有嚴重影響）。
   • 二級故障：非嚴重故障，業務未中斷，但性能下降。
   • 三級故障：輕微故障，系統有警告信息，影響不大。
5. 故障級別對應的服務請求時間和響應方式： 文檔中提供了表格，規定了不同級別故障的服務請求時間和現場服務到達時間。

運維團隊組織

• 任務需求： 包括網站應用系統日常維護/監控/完善、網站內容監控/維護、網站欄目調整、數據統計、網站系統安全測試、網站信息系統調整、完成信息中心交辦的其他相關工作。
• 角色職責： 運維經理（管理崗），技術支持工程師、流媒體工程師、網站開發工程師、美工設計、中文編輯、英文編輯（技術崗）。
• 組織機構： 信息中心和運維公司共同組建“運維聯合領導小組”進行高層協調和戰略制定。政府門戶網站運維部通常派駐不少于 4 人在工作現場，形成一線（服務臺、現場）、二線（公司總部）、三線（外援）的支持體系。

運維服務內容

1. 網站內容保障服務。
2. 日常巡檢服務：包括日常巡檢安排、出具巡檢報告、硬件/虛擬機/軟件巡檢列表。
3. 網站安全服務：
   • 監控原則：7x24 不間斷監控，有人值守，每日巡檢并提交報告。
   • 監控方案：網站訪問監控（響應時間、連接數、流量、統計分析、頁面糾錯）、設備監控、應用服務監控、數據庫監控。
   • 網站安全性檢查：阻斷應用攻擊、屏蔽安全隱患、防止頁面篡改、網站服務器及網絡安全性檢查。
4. 數據庫備份及備份驗證。
5. 應對黑客攻擊和網站故障：工作時間內立即通知責任人；非工作時間值班人員先斷網、記錄，再通知責任人。
6. 災備演練：依據政府信息中心災難應急預案進行。規定了發生安全事件時人員到達現場時間和網站恢復正常瀏覽的時間。
7. 應急處理流程：文檔中提供了應急事件級別（一般 IV 級、較大 III 級、重大 II 級、特別重大 I 級）及其對應的處理故障時間。
8. 技術支持：系統優化、系統改造、二次開發等。
9. 網絡設備日常運行維護。
10. 主機系統日常運行維護：用戶權限、系統服務、系統狀態、文件空間、CPU/內存/I/O/網絡、錯誤日志、雙機熱備軟件、整體使用情況、系統備份、填寫報告。
11. 存儲設備日常運行維護。
12. 數據庫日常運行維護。

命令補充

文檔中列舉并解釋了一些常用的 Linux 命令及其用途：

• Netstat -an | grep :80 | wc -l：檢查服務器當前 tcp 連接情況，觀察對 80 端口的訪問請求。
• netstat：顯示各種網絡相關信息（連接、路由表、接口狀態等）。
• netstat -ntlp：查看當前所有 tcp 端口。
• netstat -ntulp | grep 80：查看所有 80 端口使用情況。
• grep：文本搜索工具。
• ps -ef | grep iguard：查看 iguard 服務進程（iguard 是網站防篡改系統）。
• ps：顯示所有進程（-e 顯示所有進程，-f 全格式）。
• top：實時監控系統運行狀態（CPU、內存、執行時間排序）。
• df -h：列出文件系統的整體磁盤空間使用情況。
• free -m：監控系統內存使用情況。
• More：逐屏顯示文件內容（只能向下滾動），用于查看日志文件。
• tail -f /...：顯示文件末尾內容，-f 實時追蹤文件變化（用于查看日志文件）。
• cat：連接一個或多個文件，并將結果輸出到終端或其他文件。
• vi：文本編輯器。
• mount：用于掛載 Linux 系統外的文件。

第十章 智能工廠

NOTE:考點固定 (4分)，記住常考的點即可。

10.1 智能工程的定義

概論

• 工業 4.0 概念： 以智能制造為主導的第四次工業革命，或革命性的生產方法。
• 智能工廠： 將是構成未來工業體系的一個關鍵特征。
• 技術基礎： 網絡物理系統 (CPS) 和物聯網。
• 2013 德國提出工業 4.0： 利用物聯信息系統 (CPS) 將生產中的供應、制造、銷售信息數據化、智慧化，最終達到快速、有效、個人化的產品供應。
• 2015年國務院 中國制造 2025： 中國企業采取的方法為：兩化融合、數字經濟（數字工廠）和智能制造（先進制造裝備）。

工業的發展階段

1. 工業 1.0： 標志是機械替代人工，蒸汽機的發明。
2. 工業 2.0： 標志是電力替代普通蒸汽的機械力。
3. 工業 3.0： 標志是利用電子和 IT 技術達到設備和制造過程的高度自動化，典型代表是 PLC 可編程邏輯控制器。這是目前大部分國家的制造業所處的狀態。
4. 工業 4.0： 最重要的框架是信息物理系統，核心理念是將原來自動化的元器件、工業以太網、數據分析建模仿真等技術進行系統化的整合。工業 4.0 不是創新某一項技術，是組合式的創新。

工業 4.0 的應用可以解決以下問題

1. 滿足個性化的需求
2. 柔性 (小批量多批次需求)
3. 策略優化
4. 資源的最佳利用
5. 形成新的服務架構
6. 應對人口結構變化

三個集成 (記住)

1. 價值網絡的橫向集成： 主要指公司外部商業模式和協作伙伴關系的集成。
2. 全價值鏈的端到端的工程數字化集成： 主要指的產品的生命周期過程的集成。
3. 垂直整合和網絡化制造系統的集成： 主要指企業內部的融合，打造柔性生產系統。

智能工廠的基本架構 (記住)

數字化工廠是實現智能制造的基礎和前提，分為企業層、管理層、操作層、控制層和現場層。

• 企業層： 對產品研發和制造準備進行統一管控，與 ERP 進行集成，建立統一的頂層研發制造管理系統。與生產計劃、物流、能源和經營相關的 ERP、SCR、CRM 等，和產品設計、技術相關的 PLM 處在最上層，與服務器緊緊相連。
• 管理層、操作層、控制層和現場層： 通過工業網絡進行組網，實現從生產管理到工業網底層的網絡連接，實現管理生產過程、監控生產現場執行、采集現場生產設備和物料數的業務要求。與制造生產設備和生產線控制、調度、排產等相關的 PCS、MES 功能通過 CPS 物理信息系統實現。這一層和工業物聯網緊緊相連。

物聯網和服務網是智能工廠的信息技術基礎。

智能工廠由許多智能制造裝備、控制和信息系統構成。

數字化工廠可理解為：

1. 在生產制造的維度發展基于制造智能化的自動化生產線和成套裝置。
2. 將這些裝置納入企業業務運營系統 (ERP) 和制造執行系統 (MES) 的管理之下。
3. 建立完善的 CAD、CAPP、CAM 基礎上的 PDM、PLM (product data/lifecyle management)，并延伸到產品售后的技術支持和服務。

10.2 智能工廠架構

智能工廠架構包括：

1. 智能計劃排產
2. 智能生產過程協同
3. 智能的設備互聯互通
4. 智能生產資源管理
5. 智能質量過程管控
6. 智能決策支持

智能工廠運維任務 (記住)

1. 網絡與應用系統的運行與維護
2. IT 架構規劃
3. 日常運維
4. 整體優化
5. 緊急故障救援等

智慧制造的特征 (記住)

1. 系統具有自主能力，可采集與理解外界及自身的信息，并以之分析判斷及規劃自身行為。
2. 整體可視技術的實踐，結合信息處理、推理預測、仿真及多媒體技術，將實時展示現實生活中的設計與制造過程。
3. 協調、重組及擴充特性，系統中各組可依據工作任務，自行組成最佳系統結構。
4. 自我學習及維護能力，透過系統自我學習功能，在制造過程中落實資料庫補充、更新，及自動執行故障診斷，并具備對故障排除與維護的能力。
5. 人機共存的系統，人機之間具備互相協調合作關系，各自在不同層次之間相輔相成。

第十一章 信息系統開發的用戶支持信息

NOTE: 占 5 分，分析 2 分，設計、測試、轉換 1 分。

11.1 用戶支持信息系統建設的意義

• 信息系統的最終用戶是各級各類系統運行及管理人員，滿足這些用戶的信息需求，支持他們的管理決策活動，是系統建設的直接目的。
• 信息系統建設的目標就是尋求使各類用戶都比較滿意的方案。
• 信息系統的建設關系到一個組織的信息處理能力和管理決策的水平是涉及該組織的全局、近期和長遠發展密切相關的戰略問題。
• 由于系統本身和系統建設工作的復雜性，用戶的需求往往不可能一次表達清楚，隨著建設進程的推進和工作的深入，用戶需求的表達和系統建設的專業人員對用戶需求的理解才能逐步明確、深化、細化。
• 包括系統運行管理人員在內的各類用戶必須作為信息系統主要建設者的一部分，在各個階段直接參與工作，為系統開發建設和運行維護各個階段提供必要的輔助支持工作。

11.2 對系統分析工作的支持

系統分析階段的目標和任務

• 系統分析是對需要用信息系統去解決的問題的分析， 包括對問題的定義、原因的確定、解決辦法的說明，以及解決該問題所需提供的信息的確定。
• 目標： 在信息系統規劃階段所設定的某個開發項目范圍內，明確信息系統開發的目標和用戶的信息需求，提出系統的邏輯方案。（也就是解決“做什么”的問題）
• 任務 (記住任務和對應目標和成果)：
  1. 系統初步調查： 目標是明確系統開發的目標和規模。主要成果是《系統開發建議書》。
  2. 系統可行性分析： 目標是進一步明確信息系統的目標、規模和主要功能，提出初步方案和計劃。關鍵內容是技術可行性分析、經濟可行性分析、營運可行性分析，以及初步方案和計劃。主要成果是《可行性分析報告》和《系統開發（設計）任務書》。
  3. 現行系統詳細調查： 目標是詳細調查現行系統的工作過程，建立現行邏輯模型，發現現行系統存在的主要問題。關鍵內容是詳細分析現行系統結構、功能和數據流。主要成果是《現行系統的調查報告》。
  4. 新系統邏輯方案的提出： 目標是明確用戶信息需求，提出滿足用戶需求的新系統邏輯方案。關鍵問題是用戶需求分析和建立新系統邏輯方案。主要成果是《用戶需求規格說明書》（補充的）和《系統分析說明書》。

系統用戶支持系統分析的重要性

• 對信息系統來說，需求分析是其中最困難的任務，需要確定滿足選擇方案的特定信息需求，并且在需求分析階段，用戶和系統分析員必須投入大量的精力。

系統用戶在系統分析階段的具體工作

• 在需求分析階段，信息系統用戶必須仔細定義新系統要達到的目標，詳盡地描述新系統的功能，并要考慮新系統可能受到的約束。

• 理解原系統和所屬組織是開發大型信息系統的關鍵之一。

• 系統分析工作涉及的主要系統用戶：

  1. 信息系統用戶單位決策層的主要領導成員。
  2. 信息系統用戶單位各級職能部門的負責人，尤其是信息系統將涉及到的那些部門的負責人。
  3. 信息系統用戶單位主管信息管理工作的高層負責人。
  4. 具體負責運行、維護信息系統的管理、技術、操作人員。

• 提供組織的信息： 關于組織、人、業務工作、工作環境的信息。提供信息的方法包括提供現有文件、面談、調查問卷、實地觀察和實踐。

• 對系統邏輯模型進行評價： 系統邏輯模型反映了組織對系統整體目標和功能的要求，反映了系統各級人員的具體信息需求。因此，對系統邏輯模型的評價必須遵循用戶直接參與的原則。

系統分析的注意點

• 明確原則： 系統分析工作追求的是有限目標。一次開發不可能解決現有所有問題，只能滿足部分信息需求，其他問題留待后續解決。
• 明確任務邊界： 哪些問題暫時不解決（不做什么）。

11.3 對系統設計工作的支持

系統設計階段的目標和任務

• 目標： 將系統分析階段提出的用戶需求邏輯方案轉換為可實施的物理（技術）方案。
• 任務： 根據系統分析提出的邏輯功能要求，考慮現有技術、設備的條件和標準法規要求，確定新系統的總體結構和各組成部分的技術方案，選擇軟硬件設備，提出實施計劃，以確保系統總體目標的實現。
• 主要依據： 系統分析階段的成果（系統分析說明書）、現有技術、標準法規、用戶需求、系統環境等。
• 主要活動：
  1. 系統總體結構設計（總體布局、軟件結構、硬件方案、數據存儲的確定）。
  2. 系統詳細設計（代碼設計、數據庫設計、輸出設計、輸入設計、用戶界面設計、處理過程設計）。
  3. 系統實施進度與計劃的制定。
  4. 編寫系統設計說明書。

系統用戶對系統設計的支持

• 信息系統設計不是僅由技術專家承擔，需要用戶的高度參與和控制。
• 系統用戶參與設計的程度越深，系統滿足其需求的程度越高。
• 就含糊不清的細節問題征求用戶意見，了解用戶對信息需求的解釋，做出修改和補充。
• 這一階段工作特點是管理環境和技術環境的結合。
• 用戶需求決定和推動開發工作，用戶必須控制設計過程，確保系統反映其業務和所需信息。
• 用戶參與設計增加了系統的理解度和可接受性，減少了因權力轉換、沖突、不熟悉新系統功能流程引發的問題。

用戶在系統設計階段的具體工作 (重點)

1. 參與系統總體結構設計。
2. 參與代碼設計： 提供和解釋現有代碼，或根據需要提出建議。
3. 參與數據庫設計： 核心是如何建立滿足用戶信息要求、反映工作環境、支持數據加工、與選用 DBMS 匹配的數據模式。
4. 參與用戶界面設計（輸入、輸出、人機對話）。

總體布局的分類

1. 按信息資源管理的集中程度分 (記住優點和缺點)：
   • 集中式系統： 設備、軟件、數據集中的管理系統。
     • 優點：管理維護控制方便、安全保密性好、人員集中使用、資源利用率高。
     • 缺點：應用范圍功能有限、可變性靈活性擴展性差。
   • 分布式系統： 地理位置分散、邏輯獨立處理能力、統一規范下工作通信控制、資源獨立的子系統。
     • 優點：資源分散管理與共享使用、主機壓力小、與應用環境配合好、節點機獨立自治、可變性靈活性擴展性好。
     • 缺點：安全性差、維護難度高、管理工作負擔重。
2. 按信息處理的方式分： 批處理系統、聯機處理系統。

11.4 對系統測試工作的支持

系統測試階段的目標和任務

• 系統測試是信息系統開發周期中重要階段，是質量與可靠性保證，是對整個開發過程的最終審查。
• 測試對象是整個軟件。
• 目的和任務是盡可能發現軟件錯誤（功能、系統、過程、數據、編碼錯誤等）。
• 測試類型 (記住層次和順序)：
  1. 單元測試 (Unit Testing)： 早期實施，核實最小可測試元素（模塊或子程序），通常由測試人員在模塊開發期間執行。
  2. 集成測試 (Integration Testing)： 確保多個模塊集成后正常運行，測試對象是模塊組成的包或一組包，目的是找出模塊間接口規約不足或錯誤。
  3. 系統測試 (System Testing)： 目標是整個待測試軟件系統。
  4. 驗收測試 (Acceptance Testing)： 部署軟件前的最后一步，確保軟件準備就緒供最終用戶使用。 （確認測試一般在模擬環境，系統測試在真實環境，都對系統整體測試）
• 系統測試的主要活動 (記住)：
  1. 成立專門的測試小組。
  2. 設計測試方案。
  3. 設計測試用例（包括合理有效數據和無效不合理數據）。
  4. 進行具體系統測試工作。
  5. 保留測試文檔。

用戶對系統測試的支持

1. 系統用戶對制定測試計劃的支持：
   • 目的是確定和描述要實施和執行的測試。
   • 主要包含測試需求和測試策略。
   • 制定測試計劃的步驟 (記住)：
     1. 確定測試需求。
     2. 評估風險。
     3. 制定測試策略。
     4. 確定資源。
     5. 創建時間表。
     6. 生成測試計劃。
   • 用戶能對測試計劃產生重大影響，需滿足不同需求。提供正確信息的方法有訪談、問卷、功能監測等。
2. 系統用戶對驗收測試的支持：
   • 可分為軟件配置審核和系統運行測試。
   • 大致順序：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、系統運行測試。
   • 軟件配置審核： 審核開發方提供的可執行程序、源代碼、腳本、文檔（開發類、管理類）。正式審核步驟：計劃、預備會議（可選）、準備階段、審核會議、問題追蹤。
   • 系統運行測試： 文檔審核等完成后進行。包括功能、性能等方面測試。每種測試包括目標、啟動標準、活動、完成標準、度量。具體測試內容包括安裝（升級）、啟動關機、功能測試（正例、算法、邊界、時序、反例、錯誤處理）、性能測試（正常負載、容量變化）、壓力測試（臨界負載、容量變化）、配置測試、平臺測試、安全性測試、恢復測試（在出現掉電、硬件故障或切換、網絡故障等情況時，系統是否能夠正常運行）、可靠性測試等。

11.5 對系統轉換工作的支持

系統轉換的任務

• 新系統開發完畢并經過測試后，并不能馬上投入運行，還存在一個新老系統轉換的問題。系統轉換就是指以新系統替換老系統的過程，即老系統停止使用，新系統開始使用。
• 這是整個系統建設周期中動用人力物力資源最多的一個步驟。
• 系統轉換的任務就是保證新老系統進行平穩而可靠的交接，最后使整個新系統正式交付使用。

系統轉換的方式 (固定選擇題)

1. 平行轉換方式： 最安全、最保險。新老系統同時運行一段時間。
   • 優點：安全、平穩可靠。
   • 缺點：開銷大、費用高、需要配備額外人員和資源運行另一套系統，業務工作量是正常情況的兩倍。
2. 直接轉換方式： 最簡單，成本低。老系統停用，新系統立即啟用。
   • 優點：簡單、成本低。
   • 缺點：風險很大，新系統發生問題，會給業務工作帶來混亂。
   • 通常使用于小型的不太復雜的信息系統，或對信息時效性要求不太高的系統，并且新系統應該已經經過了詳細完整的測試和模擬運行。
3. 分階段轉換方式： 分步轉換，逐步替換老系統。
   • 優點：風險較小、成本較低。
   • 缺點：轉換周期長、需要處理新老系統接口問題。
4. 試點轉換方式： 選擇部分業務或部門作為試點，在新系統運行成功后再全面推廣。
   • 優點：風險最小、用戶接受度高。
   • 缺點：轉換周期長、需要處理試點與非試點部門的數據同步問題。

系統轉換的實施

1. 系統轉換前的準備工作：

   1. 新系統的安裝部署
   2. 數據準備
   3. 文檔的準備
   4. 人員培訓：培訓工作關系到新系統的成敗。
   5. 本組織信息系統的操作方法

2. 系統轉換的實施：

   1. 系統的初始化工作： 包括對系統的運行環境和資源進行配置、系統運行和控制參數設定、數據轉換與加載、協調系統與業務工作同步等。在系統初始化工作中，工作量最大、時間耗費最多、要求緊迫的活動通常是數據轉換與加載。系統初始化中大量的數據加載工作是新系統啟動運行的先決條件。
   2. 轉換過程中的維護： 如果改動的工作量很大，甚至需要重新從系統分析或設計做起，那么留待下一個系統開發周期進行擴展升級。系統投入運行后，應該理解和允許系統存在某些不足。

3. 人員對系統轉換實施的影響： 信息系統失敗的主要原因，一是用戶拒絕使用新系統，二是目前工作環境比較舒適，有關管理人員安于現狀。要使新系統和新技術實施成功，組織的最高管理者和系統分析與設計人員就必須起到變化代理人的作用，用動態的觀點，采用變化的計劃實施策略來引導變化。

第十二章 標準化基本知識

NOTE: 5分左右,上午題章節,考點比較固定

12.1 標準化及其體系結構

標準化定義

標準化是對實際與潛在問題做出統一規定，供共同和重復使用。 標準化定義為：在經濟、技術、科學及管理等社會實踐中，對重復性事物和概念通過制訂、發布和實施標準，達到統一，以獲得最佳秩序和社會效益。 標準化是一項有組織的活動過程，主要活動就是制訂標準、貫徹標準，進而修訂標準、又實施標準，如此循環往復。 標準，是標準化活動的成果，也是標準化活動過程的結果，構成標準化系統的標準應組合成標準體系。

標準化的主要特性

1. 統一性
2. 政策性
3. 橫向綜合性：橫向深入到各個專業的技術領域

標準化學科

標準化工作研究的對象可分為兩類：

1. 具體對象：即各專業、各方面需要指定標準的對象。
2. 總體對象：即在各類具體對象基礎之上進行綜合、概括起來的總體對象。

二者之間的關系是，前者是制定標準的對象，后者是標準化學科要研究的任務和對象。

標準化層級 (重點)

標準化層級是指“從事標準化的地理、政治或經濟區域”。 根據 ISO/IEC 第二號指南分為六個層級：

1. 國際標準化
2. 區域標準化
3. 國家標準化：以下 4、5、6 都應該比國標嚴格
4. 行業標準化：是指某一國家內行業標準化組織開展的標準化活動，既要符合行業管理的需要，又是國家標準化的基礎與補充，并可有效指導本行業的企業標準化。
5. 地方標準化
6. 企業標準化

標準化系統

標準化系統是標準化事物按一定內在聯系組成的整體。與標準化相關的事物有問題、活動（標準化的主線）、標準（標準化活動的成果）、人（開展標準化活動的關鍵要素）、機構（開展標準化活動的組織保證）、法規或制度、資源（開展標準化活動的物質條件）。

定義：標準化系統是為開展標準化所需的課題、過程、組織、人、標準、法規制度及資源構成的有機整體。 分為：課題（依存主體對象）、標準體系、標準化工作體系。 課題是建立標準化系統的前提，標準化工作體系是標準化系統的運行主體，標準體系是標準化系統運行的結果。

現代標準化

現代標準化的主要內容是以系統最優為目標，運用經典數學、統計數學以及模糊數學等各種數學方法，依據系統工程、價值工程等各種現代管理科學，再應用電子計算機等各種現代工具，進行最佳控制和最佳協調，通過建立與經濟、技術發展水平相適應的標準體系，在包括經濟管理和人類社會活動生活在內的廣泛領域里發揮其功能。

現代標準化的特性：

1. 系統性
2. 國際性（國際標準化成為現代標準化的主流）
3. 動態性
4. 超前性
5. 經濟性

現代標準化的主要形式和方法：

1. 綜合標準化：就是標準化與系統工程相結合的科學方法。
2. 超前標準化：適應現代科技迅速發展的標準化方法。

信息資源管理的標準化

對于信息資源管理來說，標準化就是要在信息資源的生產和使用等一系列管理活動中，制定、發布和實施有關的標準和規范，合理、高效地利用和開發信息資源，以達到最佳經濟和社會效益。

信息資源管理標準化的意義：

• 是進行科學管理和組織生產的重要前提
• 是進行技術開發，提高技術水平的重要途徑
• 是保證信息產品質量，進行全面質量管理的重要基礎
• 是獲得最佳經濟效益的重要手段
• 是開拓市場，提高競爭能力的重要保證
• 是開展國際交流，進行國際合作的重要基礎

信息資源管理標準化的重要作用：

• 保證信息產品開發和使用各個環節的技術銜接和協調
• 改進、保證和提高信息資源的質量
• 合理發展信息產品的品種
• 促進科研成果和新技術的推廣應用
• 便于信息資源的使用和維護
• 縮短信息資源的開發周期，提高勞動生產率
• 保護用戶和消費者的利益

12.2 標準分類與分級

標準分類

1. 層級分類法： 將標準系統的結構要素，按照其發生作用的有效范圍劃分為不同的層次。世界范圍上，有國際標準、區域性或國家集團標準、國家標準、行業標準、地方標準和企業標準等。我國標準化規定，我國標準分為國家標準、行業標準、地方標準和企業標準四級。
2. 性質分類法： 按照標準本身的屬性加以分類。可以分為管理標準、技術標準、經濟標準、安全標準、質量標準等；按照法律的約束性分類，標準可以分為強制性標準和推薦性標準兩種類型。
3. 對象分類法： 按照標準化的對象進行分類。我國習慣上把標準按對象分為：產品標準、工作標準、方法標準和基礎標準等（也可以概括為“物”——產品、工程、設備、工具、原材料等，和“非物”——工作、程序、操作、方法等兩大類）。

我國的標準分級

根據我國標準法規的規定，我國的標準可以劃分為國家標準、行業標準、地方標準和企業標準四級。

• 國際標準：ISO、IEC 等國際標準化組織
• 區域標準（地區標準）：如 PASC（太平洋地區標準會議）、CEN（歐洲標準委員會）、ASAC（亞洲標準咨詢委員會）、ARSO（非洲地區標準化組織）
• 國家標準：GB（中國）、ANSI（美國）、BS（英國）、JIS（日本）
• 行業標準：GJB（中國軍用標準）、MIT-S（美國軍用標準）、IEEE（美國電氣電子工程師協會）
• 地方標準
• 企業標準

標準的代號與編號

• 國家標準： 我國的國家標準代號是以“國標”的大寫漢語拼音的第一個字母“GB”來表示的。強制性國家標準代號為“GB”，推薦性國家標準代號為“GB/T”。國家標準的編號由國家標準的代號、標準發布順序號和標準發布年代號（四位數組成）。例如：強制性國家標準 GB XXXXX XXXX，國家實物標準（樣品） GSB X XX XXX XXXX。
• 行業標準： 行業標準由漢字拼音大寫字母組成。行業標準的編號由行業標準代號、標準發布順序及標準發布年代號（四位數）組成。行業標準也分強制性行業標準和推薦性行業標準。文檔中列舉了部分行業標準代號及其名稱（如 NY-農業、LD-勞動和勞動安全、SC-水產、SL-水利、LY-林業、SJ-電子、YD-通信、GY-廣播電影電視、QB-輕工、DL-電力、FZ-紡織、YY-醫藥、HY-海洋、MZ-民政、DA-檔案、JY-教育、SN-商檢）。
• 地方標準： 地方標準代號以大寫漢語拼音字母“DB”加上省、自治區、直轄市行政區劃代碼前兩位數，再加斜線“/”組成強制性地方標準代號。再加“T”組成推薦性地方標準代號。例如：DB XX/XXXX - XXXX，其中 XX 是行政區劃代碼前兩位數，后跟標準順序號和批準年代。
• 企業標準： 企業標準的代號，一般以“Q”（企）字為分子，以免與國家標準和行業標準相混淆；企業標準代號前，一般應冠以所在省份的簡稱；企業標準代號的分母，一律采用漢語拼音字母表示。例如：Q/XX XXXX - XXXX，其中 Q/XX 是企業標準代號，XX 是某企業代號，后跟標準順序號和批準年代。

12.3 信息系統標準化

信息系統標準化工作是信息化建設中的一項基礎性的系統工程，具有十分重要的現實意義和深遠的歷史意義。 統一、規范和科學的標準體系，是實現跨地域范圍的業務數據交換、資源共享和對接的前提。 在信息系統開發過程中，必須要遵守統一的軟件工程設計規范，實現信息系統開發標準化，以提高信息系統和應用軟件的可靠性、易維護性。

1. 信息系統的代碼標準化： 信息分類編碼是信息化社會中對信息進行有效管理、加工處理、綜合利用的必要技術手段。信息系統的代碼標準化就是將信息按照一定的原則和方法進行分類，然后一一賦予代碼，使每一項具體信息與代碼形成唯一的對應關系，為數據記錄、存取、檢索提供一種簡短、方便的符號結構，從而便于實現信息處理和信息交換，提高數據處理的效率和準確性，且增強信息的保密性。
2. 信息系統數據交換標準化： 數據交換標準是為了實現不同信息系統之間信息共享和溝通而建立的一套通用的數據文件格式規范，以保證數據傳輸的完整、可靠和有效，并提高數據交換的速度。數據交換標準的主題是數據文件的格式。數據交換標準化是信息標準化的重要內容之一。信息交換標準化就是制訂在信息系統內部和信息系統之間各種接口方式以及信息系統輸入和輸出的格式制定規范和標準。目前經常采用的數據傳輸方式有 FTP, EMAIL, 中文短信, 網頁上傳等，經常使用的數據文件交換格式有 TXT, XML, EXCEL 以及通用數據庫。
3. 信息系統開發標準化： 主要指在系統開發中遵守統一的系統設計規范、程序開發規范和項目管理規范。
4. 信息系統文檔標準化： 主要是在信息系統開發、運行、維護和管理等過程中遵守統一的文檔編制規范，在統一標準制約下，建立和維護系統各種文檔資料。
5. 信息系統安全標準化： 是指在信息系統建設開發、運行維護和管理過程中，為保證信息系統的安全而必須建立和遵守統一的安全標準與安全規范。

12.4 標準化機構

• 國際標準化組織 (ISO)： 是目前世界上最大、最具權威性的國際標準化專門機構。
• 國際電工委員會 (International Electrotechnical Commission, IEC)： 成立于 1906 年，是世界上成立最早的國際性電工標準化機構，負責有關電氣工程和電子工程領域中的國際標準化組織。
• 國際電信聯盟 (International Telecommunication Union, ITU)： 是聯合國的一個專門機構，也是聯合國機構中歷史最長的一個國際組織，簡稱“國際電聯”“電聯”或“ITU”。
• 我國國家標準的制定： 由國務院標準化行政主管部門制定。
• 我國行業標準的制定： 由國務院有關行政主管部門制定。
• 我國地方標準的制定： 由省、自治區和直轄市標準化行政主管部門制定。
• 我國企業標準的制定： 由企業自行制定。

我國標準化工作實行統一管理與分工負責相結合的管理體制。

計算機網絡基礎知識 (補充)

這份文檔提供了計算機網絡的基礎知識，主要涵蓋了網絡的分類、拓撲結構、信息傳輸技術、網絡體系結構以及一些網絡相關的基礎概念和技術。

網絡基礎知識

• 局域網 (LAN - Local Area Network)
• 城域網 (MAN - Metropolitan Area Network): 使用標準分布式隊列雙總線 DQDB, IEEE802.6。
• 廣域網 (WAN - Wide Area Network): 使用分組交換技術。
• 國際互聯網 (Internet): 使用 TCP/IP 協議、路由器連接。

按網絡拓撲結構分類

1. 星形網絡：
   • 各站點通過點到點的方式與中心站連接。
   • 特點：易于擴展，安全性和優先級易于控制，易實現網絡監控。
   • 缺點：中心站出問題網絡就會崩潰。
2. 環形網絡：
   • 各節點通過環中繼轉發器與其左右的節點串行連接，所有節點形成一個環形。
   • 優點：網絡組件簡單和投資成本低。
   • 缺點：傳輸速度慢，不易于擴展，連接用戶少且固定。現在除了單環還有雙環的方式。
3. 總線形網絡：
   • 網絡所有站點連接到同一條傳輸介質上。
   • 特點：成本低，節點故障不會影響網絡故障。
   • 缺點：安全性低，監控困難，增加新站點不如星形網絡方便。

總線形網絡和星形網絡較為常見。

按信息傳輸技術分類

1. 廣播式網絡：
   • 在網絡中只有一個單一的通信信道，由這個網絡中所有的主機所共享。
   • 即多個計算機連接到一條通信線路上的不同分支點上，任意一個節點所發出的報文分組被其他所有節點接受。
2. 點對點網絡：
   • 是無中心服務器、依靠用戶群 (peers) 交換信息的互聯網體系。
   • 它的作用在于減低以往網絡傳輸中的節點，以降低資料遺失的風險。

計算機網絡體系結構 (重點)

為了解決異構計算機網絡互聯互通的問題，提出了網絡體系結構。

計算機網絡分層結構

采用分層的方法來描述網絡的結構。將一個很大的問題分解成若干較小的、易于處理的問題。

OSI/RM 七層參考模型 (重點)

國際標準化組織 ISO 于 1984 年提出。自下而上依次為：

1. 物理層 (Physical Layer)： 處于最底層。透明地傳輸原始比特流。功能有：機械特性、電氣特性、功能特性、規程特性。涉及的物理設備有中繼器、集線器。
2. 數據鏈路層 (Data Link Layer)： 在物理層提供比特流服務的基礎上，在通信實體間建立數據鏈路。主要解決：封裝成幀、透明傳輸、差錯控制（幀錯、位錯）、流量控制。涉及的物理設備有網橋、交換機（二層交換機）。
3. 網絡層 (Network Layer)： 主要解決異構網絡的互聯問題，實現路由選擇和擁塞控制。傳輸單位是數據報（IP 數據報）。涉及的物理設備有路由器、三層交換機。
4. 傳輸層 (Transport Layer)： 處于網絡層和會話層之間，是實現端到端互聯。功能有：差錯控制、流量控制、復用、分用。涉及協議 TCP、UDP。
5. 會話層 (Session Layer)： 建立、管理、終止會話，決定數據傳輸的模式。
6. 表示層 (Presentation Layer)： 處理用戶信息的表示問題，進行數據格式變換、數據加密解密、數據壓縮和恢復。
7. 應用層 (Application Layer)： 處于最高層。提供用戶與網絡的接口，實現各種分布式應用。涉及協議 DNS、FTP、TELNET、SMTP、HTTP、RIP、OSPF 等。

TCP/IP 四層模型 (重點)

互聯網事實上的標準體系結構。由下到上依次為：

1. 網絡接口層： 對應 OSI 的物理層和數據鏈路層。
2. 網際層 (Internet Layer)： 對應 OSI 的網絡層。核心協議 IP。
3. 傳輸層 (Transport Layer)： 對應 OSI 的傳輸層。主要協議 TCP、UDP。
4. 應用層 (Application Layer)： 對應 OSI 的會話層、表示層、應用層。

五層參考模型 (重點)

教學中常用的模型，綜合了 OSI 和 TCP/IP 的優點。由下到上依次為：

1. 物理層
2. 數據鏈路層
3. 網絡層
4. 傳輸層
5. 應用層

IP 地址與子網劃分 (重點)

• IP 地址： 用于在網絡中標識一臺主機。IPV4 地址是 32 位二進制，通常表示為點分十進制。
• IP 地址分類：
  • A 類：第一位 0，網絡號占 8 位，主機號占 24 位。網絡數少，每網絡主機數多。范圍 1.0.0.1 - 126.255.255.254。保留地址 127.x.y.z 用于本地環回測試。
  • B 類：前兩位 10，網絡號占 16 位，主機號占 16 位。網絡數和每網絡主機數適中。范圍 128.0.0.1 - 191.255.255.254。
  • C 類：前三位 110，網絡號占 24 位，主機號占 8 位。網絡數多，每網絡主機數少。范圍 192.0.0.1 - 223.255.255.254。
  • D 類：前四位 1110，用于多播 (Multicast)。范圍 224.0.0.0 - 239.255.255.255。
  • E 類：前四位 1111，保留。范圍 240.0.0.0 - 255.255.255.255。
• 特殊 IP 地址：
  • 網絡地址：主機號全為 0，代表整個網絡。
  • 廣播地址：主機號全為 1，用于向網絡中所有主機發送信息。
  • 127.0.0.1：本地環回地址 (Loopback)，用于測試本機網絡協議是否正常。
  • 0.0.0.0：通常指代本機或任意網絡。
  • 255.255.255.255：受限廣播地址，不能跨路由器轉發，發送給本地網絡所有主機。
• 私有 IP 地址 (重點)： 在組織內部使用，不能在 Internet 上直接路由。
  • A 類：10.0.0.0 - 10.255.255.255
  • B 類：172.16.0.0 - 172.31.255.255
  • C 類：192.168.0.0 - 192.168.255.255
• 子網掩碼 (Subnet Mask)： 用于標識 IP 地址的網絡號和主機號。與 IP 地址進行位與運算可得到網絡地址。
  • 默認子網掩碼：A 類 255.0.0.0，B 類 255.255.0.0，C 類 255.255.255.0。
• 子網劃分： 將一個大的網絡劃分成若干小的子網，減少廣播域，提高 IP 地址利用率。通過改變子網掩碼來實現。計算子網數和每子網主機數。
• 無類別域間路由 (CIDR - Classless Inter-Domain Routing)： 用于替代傳統的 A、B、C 類地址劃分，提高 IP 地址利用率。格式 IP 地址/網絡前綴的位數。

域名系統 DNS

• 域名 (Domain Name)： 用于方便記憶的 Internet 主機名。
• 域名系統 (DNS - Domain Name System)： 將域名解析為 IP 地址，或將 IP 地址解析為域名。采用分層結構：根域名服務器、頂級域名服務器、授權域名服務器。
• 解析過程： 遞歸查詢和迭代查詢。通常主機到本地 DNS 服務器是遞歸查詢，本地 DNS 服務器到其他 DNS 服務器是迭代查詢。

HTTP 協議 (重點)

• 超文本傳輸協議 (HTTP - Hypertext Transfer Protocol)： 用于傳輸超文本，是萬維網應用層協議。基于 TCP 協議。
• HTTP 狀態碼： 表示服務器對請求的處理結果。
  • 1xx：信息提示。
  • 2xx：成功。200 OK。
  • 3xx：重定向。301 永久移動，302 臨時移動。
  • 4xx：客戶端錯誤。403 Forbidden (服務器拒絕訪問)，404 Not Found (未找到資源)。
  • 5xx：服務器錯誤。500 Internal Server Error (服務器內部錯誤)，503 Service Unavailable (服務不可用)。
• HTTPS： 安全的 HTTP，在 HTTP 層與 TCP 層之間增加了 SSL/TLS 層進行加密。默認端口 443。

計算機網絡連接硬件

• 網線： 雙絞線（常用的五類、超五類、六類，RJ45 接頭）、同軸電纜、光纖。
• 網卡 (Network Interface Card, NIC)： 計算機連接到網絡的接口。
• 集線器 (Hub)： 物理層設備，廣播所有接收到的信號。
• 交換機 (Switch)： 數據鏈路層設備，根據 MAC 地址轉發幀。可分為二層交換機、三層交換機等。
• 路由器 (Router)： 網絡層設備，根據 IP 地址進行路由選擇和數據包轉發。
• 調制解調器 (Modem)： 模擬信號與數字信號轉換。
• 中繼器 (Repeater)： 物理層設備，放大信號延長傳輸距離。
• 網橋 (Bridge)： 數據鏈路層設備，連接兩個局域網，根據 MAC 地址轉發。

計算機網絡安全 (部分內容與第六章信息系統安全重復)

• 常見的網絡安全威脅： 木馬、蠕蟲、病毒、網絡釣魚、拒絕服務攻擊 (DoS/DDoS)、中間人攻擊、SQL 注入、跨站腳本 (XSS)、緩沖區溢出、網絡監聽、端口掃描、弱口令攻擊。
• 常見的網絡安全設備： 防火墻、入侵檢測系統 (IDS)、入侵防御系統 (IPS)、統一威脅管理 (UTM)、VPN 設備、安全審計系統。
• 網絡安全技術： 加密解密、數字簽名、訪問控制、身份認證、安全審計、漏洞掃描、滲透測試。

Linux 系統與網絡配置 (補充了一些 Linux 命令和文件路徑)

這部分提供了一些與 Linux 系統和網絡相關的命令和重要的配置文件路徑。

• /etc/rc 或 /etc/rc.d 或 /etc/rc?.d: 啟動或改變運行級時運行的腳本或腳本的目錄。
• /etc/passwd: 用戶數據庫，包含用戶名、真實姓名、用戶起始目錄、加密口令等。
• /etc/fdprm: 軟盤參數表。
• /etc/fstab: 指定啟動時需要自動安裝的文件系統列表。
• /etc/group: 組信息文件。
• /etc/inittab: init 的配置文件。
• /etc/issue: 登錄提示符前的輸出信息。
• /etc/magic: "file" 的配置文件。
• /etc/motd: 用戶成功登錄后自動輸出信息。
• /etc/profile: Bourne 或 C shell 的初始化文件。
• /etc/securetty: 決定哪些終端允許 root 用戶登錄。
• /etc/shells: 列出可信的 shell。
• /etc/termcap: 終端屬性數據庫。
• /etc/terminfo: 包含描述終端能力的目錄集。
• /etc/ttys: 包含端口名和 getty 參數。
• /etc/shadow: 影子口令文件（加密口令）。
• /etc/hostname: 存放主機名。
• /etc/hosts: 包含 IP 地址和主機名的對應關系，域名解析的早期方式。
• /etc/network/interfaces: 配置網絡接口。
• /etc/resolv.conf: DNS 客戶端配置文件，指定 DNS 服務器 IP 地址。
• /etc/sysconfig/network: 包含全局網絡參數。
• /etc/sysconfig/network-scripts/: 包含各種網絡接口的配置腳本。

常用的 Linux 網絡命令：

• ifconfig 或 ip addr: 查看或配置網絡接口信息（IP 地址、MAC 地址、狀態等）。
• ping: 測試網絡連通性。
• traceroute 或 tracert: 顯示數據包到達目標主機的路徑。
• netstat: 顯示網絡連接、路由表、接口統計等信息。
• route: 查看或操作路由表。
• nslookup 或 dig: DNS 查詢工具。
• ssh: 安全地遠程登錄到服務器。
• scp: 安全地復制文件。
• ftp: 文件傳輸協議客戶端。
• telnet: 遠程登錄工具（不安全）。
• tcpdump: 抓包工具，用于分析網絡流量。
• iptables: Linux 防火墻配置工具。
• nmap: 網絡掃描工具。
• lsof -i:端口號: 查看哪個進程在使用某個端口。

數據庫技術基礎 (補充)

Note:補充內容。18年考了15分下午題,19年未考,20年考了5個判斷。初級較少,但中級也要考。

數據模型

• 模型： 對現實世界特征的模擬和抽象。
• 數據模型： 對現實世界數據特征的模擬和抽象。
• 數據模型三要素：
  1. 數據結構
  2. 數據操作 (增刪改查)
  3. 數據約束條件
• 概念數據模型： 主要用于數據庫設計，E-R 模型，即實體關系模型。
• 基本數據模型： 主要用于實現 DBMS。
  • 層次模型 (樹狀，一對一或一對多)
  • 網狀模型 (多對多)
  • 關系模型 (二維表格形式，不能有表的嵌套)

關系模型的相關概念

• 關系： 可以理解成一張表格。
• 屬性： 列。
• 元組： 行。
• 分量： 元組中的一個屬性值。
• 關系模式： 對關系的描述，記為 R (A1, A2, A3, ..., An)。
• 候選碼/候選鍵： 可確立唯一記錄，可能有多個 (例如學生表里的學號和身份證號)。
• 主碼/主鍵 (key)： 候選碼只由一條屬性構成。
• 全碼： 候選碼由所有屬性構成。
• 外碼/外鍵： 非候選碼，但另一關系中是主碼，一般用于聯系兩個表格。
• 主屬性/非主屬性： 包含在候選碼里的是主屬性，不包含的是非主屬性。

DBMS 數據庫管理系統

• 功能：
  • 數據定義
  • 數據操作
  • 數據庫運行管理
  • 數據組織、存儲和管理
  • 數據的建立和維護
  • 數據結構化且統一管理
  • 有較高的數據獨立性
  • 數據控制功能 (數據庫的安全性、數據庫的完整性、并發控制、故障恢復)
• 三級模式：
  • 外模式 (視圖 view)
  • 模式 (基本表)
  • 內模式 (物理模式)
• 兩級映像：
  • 外模式-模式映像 (保障邏輯獨立性)
  • 模式-內模式映像 (保障物理獨立性)

數據庫設計

• 核心問題： 從系統的觀點出發，根據系統分析和設計的要求，結合選用的 DBMS，建立一個數據模式。
• 4 個階段 (最后加上實施和維護的話，一共 6 個階段)：
  1. 用戶需求分析： 對現實世界的調查和分析數據項、數據結構、數據流、數據存儲的描述。
  2. 概念結構設計： 從現實世界向信息世界的轉換——建立概念模型，獨立于具體的 DBMS，此處使用 ER 圖。
  3. 邏輯結構設計： 從信息世界向數據世界的轉換——建立數據模型，使用某種數據模型，如關系/非關系。
  4. 物理結構設計： 為數據模型選擇合適的存儲結構和存儲方法，考慮存儲安排、存儲方法選擇、存儲路徑建立。

E-R 模型

• 三要素：
  1. 實體
  2. 屬性：
     • 簡單屬性 - 沒有辦法拆分的屬性。
     • 復合屬性 - 是可以拆分的，比如家庭住址。
     • 單值屬性 - 值只允許填一個。
     • 多值屬性 - 可以填很多，比如電話可以有多個。
     • NULL 屬性。
     • 派生屬性 - 不需要手動更新，可以通過計算得出的，比如年齡可以由出生年計算得出。
  3. 聯系。
• 圖例：
  • 矩形 ?：表示實體集。
  • 菱形 ◇：表示聯系集。
  • 橢圓 ○：表示屬性。
  • 線段 ——：將屬性與相關的實體集連接，或將實體集與聯系集相連。
  • 虛橢圓 虛線圓：表示多值屬性。
  • 虛線橢圓 虛線圓：表示派生屬性。
  • 雙線 雙線：表示一個實體全部參與到聯系集中。
• 實體之間的聯系： 1 對 1 (1:1)，1 對多 (1:n)，多對多 (m:n)。
  • 三個不同實體聯系：只有兩端聯系同為 1 才能標 1，有 n 或者都是 n 則標注 n。

E-R 圖轉關系數據庫

1. 一對一聯系 (1:1)：
   • 可以將聯系轉換成一個獨立的關系模式： 關系模式的名稱取聯系的名稱，關系模式的屬性包括該聯系所關聯的兩個實體的碼及聯系的屬性，關系碼取任意一方實體的碼。
   • 可以將聯系歸并到關聯的兩個實體的任一方： 在待歸并的一方實體屬性中增加另一方實體的碼和該聯系的屬性即可，歸并后的實體碼保持不變。
2. 一對多聯系 (1:n)：
   • 可以將聯系轉換成一個獨立的關系模式： 關系模式的名稱取聯系的名稱，關系模式的屬性包括該聯系所關聯的兩個實體的碼及聯系的屬性，關系的碼是多方實體的碼。
   • 可以將聯系歸并到關聯的兩個實體的多方： 在待歸并的多方實體屬性集中增加一方實體的碼和該聯系的屬性即可，歸并后的多方實體碼保持不變。
3. 多對多的聯系 (m:n)：
   • 只可以將聯系轉換成一個獨立的關系模式： 關系模式的名稱取聯系的名稱，關系模式的屬性取該聯系所關聯的兩個實體的碼及聯系的屬性，關系的碼是多方實體的碼構成的屬性組 (不是任何一邊，兩個都要有)。

關系代數

• 是一種傳統的表達方式，用對關系的運算來表達查詢。
• 運算對象、運算結果都為關系。
• 運算符：
  • 集合運算： ∪ (并)，- (差)，∩ (交)，× (笛卡爾積)。
  • 專門的關系運算符： σ (選擇)，π (投影)，? (連接)，÷ (除)。
  • 比較運算符： > (大于)，≥ (大于等于)，< (小于)，≤ (小于等于)，= (等于)，≠ (不等于)。
  • 邏輯運算符： ∧ (與)，∨ (或)，? (非)。
• 廣義笛卡爾積： R × S。
• 連接： 關系運算————連接：是從兩個關系 R 和 S 的笛卡爾積中選取滿足條件的元組。
  • 等值連接： 當 θ 為 “=” 時，稱為等值連接。

數據庫設計規范化理論

• 冗余和異常：
  • 插入異常
  • 刪除異常
  • 更新異常
• 函數依賴： 若關系 R(U) 中，對于 U 中的非空屬性集 X 和 Y，有 X → Y，當且僅當對于 R 中任意兩個元組 t1 和 t2，若 t1[X] = t2[X]，則必有 t1[Y] = t2[Y]。稱 Y 函數依賴于 X。
  • 平凡函數依賴與非平凡函數依賴。
  • 完全函數依賴 (X → Y，且對于 X 的任何一個真子集 X'，都有 X' ? Y)。
  • 部分函數依賴 (X → Y，但對于 X 的某個真子集 X'，有 X' → Y)。
  • 傳遞函數依賴 (X → Y，Y → Z，且 Y ? X，Y ? Z)。
• 碼 (Key)： 設 K 為 R<U,F> 中的屬性集，若 K 滿足：
  • K → U (函數依賴 K → U)
  • 對于 K 的任何一個真子集 K'，都有 K' ? U。 則 K 為 R 的一個候選碼。
  • 包含在任何一個候選碼中的屬性，稱為主屬性。
  • 不包含在任何一個候選碼中的屬性，稱為非主屬性。
  • 若關系模式 R 的所有屬性是這個關系模式的候選碼，則稱 R 為全碼。
  • 外碼 (Foreign Key)： 關系模式 R 中屬性集 F 是外部碼當且僅當 F 不是 R 的碼，但 F 是另一個關系模式 S 的碼。
• 范式 (Normal Form, NF)： 是符合某一種級別的關系模式的集合。
  • 1NF (第一范式)： 如果關系模式 R 的所有屬性都是不可再分的原子值，則稱 R 屬于第一范式。所有關系模式至少是 1NF。
  • 2NF (第二范式)： 如果關系模式 R 屬于 1NF，且所有非主屬性都完全函數依賴于候選碼，則稱 R 屬于第二范式。
  • 3NF (第三范式)： 如果關系模式 R 屬于 2NF，且所有非主屬性都不傳遞函數依賴于候選碼，則稱 R 屬于第三范式。
  • BCNF (巴斯-科德范式)： 如果關系模式 R 屬于 3NF，且每個非平凡函數依賴的決定因素都包含 R 的碼，則稱 R 屬于 BCNF。簡單地說，R 屬于 BCNF 當且僅當 R 中每一個決定因素都包含候選碼。

數據庫安全

安全性控制

• 用戶身份鑒別：連接到數據庫的用戶是否合法。
• 存取控制：用戶對數據庫的存取權限。
  • 自主存取控制 (DAC)：用戶可以將自己擁有的權限授予其他用戶。
  • 強制存取控制 (MAC)：由系統統一管理用戶的權限。
• 視圖 (View)：數據庫的虛表，對數據庫的保護。
• 審計 (Audit)：記錄用戶對數據庫的操作，便于追溯。
• 數據加密：對敏感數據進行加密存儲或傳輸。

數據庫完整性約束

• 實體完整性約束：關系的主碼不能取空值。
• 參照完整性約束：外碼要么取空值，要么等于被參照關系中主碼的值。
• 用戶自定義完整性約束：用戶根據業務需求定義的約束條件。

數據庫并發控制

• 多個用戶同時操作數據庫時，保證數據的一致性和正確性。
• 引起并發控制的問題：
  • 丟失修改 (Lost Update)：兩個事務同時修改同一數據，后一個事務的修改覆蓋了前一個事務的修改。
  • 不可重復讀 (Nonrepeatable Read)：一個事務兩次讀取同一數據，數據的值不同。
  • 幻讀 (Phantom Read)：一個事務兩次執行同一查詢，第二次查詢的結果集包含新插入的行。
• 并發控制的主要技術：
  • 封鎖 (Locking)：最常用的并發控制技術。
    • 排他鎖 (Exclusive Lock, X Lock)：寫鎖，一個事務加 X 鎖后，其他事務不能讀寫。
    • 共享鎖 (Shared Lock, S Lock)：讀鎖，一個事務加 S 鎖后，其他事務可以加 S 鎖，但不能加 X 鎖。
  • 時間戳 (Timestamp)：基于事務開始時間的并發控制技術。
  • 樂觀控制法。
  • 多版本并發控制 (MVCC)。

數據庫故障與恢復

• 故障類型：
  • 事務故障：事務內部邏輯錯誤或系統錯誤引起。
  • 系統故障 (軟故障)：系統停止運轉，但數據庫未被破壞。
  • 介質故障 (硬故障)：外存故障，導致數據庫被破壞。
• 恢復策略： 備份、日志文件。
• 恢復技術：
  • 靜態轉儲與動態轉儲。
  • 登記日志文件 (重做 Redo 和撤銷 Undo)。
  • 檢查點 (Checkpoint)。

SQL 基礎知識

• SQL (Structured Query Language)： 結構化查詢語言，用于管理關系數據庫。
• 常用語句類型：
  • 數據定義語言 (DDL - Data Definition Language)： CREATE, ALTER, DROP (定義數據庫模式，包括表、視圖、索引、完整性約束等)。
  • 數據操縱語言 (DML - Data Manipulation Language)： SELECT, INSERT, UPDATE, DELETE (對數據庫中的數據進行增刪改查)。
  • 數據控制語言 (DCL - Data Control Language)： GRANT, REVOKE (控制用戶對數據的訪問權限)。
• 基本查詢語句 (SELECT)：
  • SELECT <列名> FROM <表名> [WHERE <條件>] [GROUP BY <列名> [HAVING <條件>]] [ORDER BY <列名> [ASC默認/ DESC]]
  • 連接查詢 (JOIN)。
  • 聚集函數 (AVG, MIN, MAX, SUM, COUNT)。
  • 字符串 LIKE 操作 (通配符 %，_；轉義符 )。
  • NULL 操作 (IS NULL / IS NOT NULL)。

---

易混知識點 (補充) - 優化格式版

這份文檔歸納了之前章節中一些容易混淆的知識點，通過對比和清晰的結構，幫助您更有效地記憶和區分。

第三章中設施運維要記的細碎知識點集合

這部分總結了設施運維中，針對不同運維對象（系統、服務器及存儲設備、網絡及網絡設備）的性能檢查內容、脆弱性檢查內容、監控內容和常規操作內容。

運維對象	檢查/監控/操作類型	具體內容
系統 / 服務器及存儲設備	性能檢查內容	檢查服務器非業務繁忙期 CPU/內存/磁盤 IOPS/網絡 IOPS 峰值情況；檢查服務器業務繁忙期 CPU/內存/磁盤 IOPS/網絡 IOPS 峰值情況。
	脆弱性檢查內容	檢查服務器設備生命周期與硬件可靠性評估；檢查服務器備件可用性、周期性檢查。
	監控內容	監控主機服務器 LED 面板運行錯誤碼；監控服務器電源/硬盤工作狀態指示燈；監控服務器 CPU 使用比例情況；監控操作系統重要文件系統空間使用情況；監控服務器內存使用情況等。
	常規操作內容	檢查設備是否正常啟動；檢查硬件設備是否有運行告警燈或故障燈；檢查設備運行日志是否有報錯信息；檢查業務系統運行是否正常；檢查應用系統是否有運行錯誤日志；檢查系統關鍵進程是否運行正常等。
網絡及網絡設備	性能檢查內容	檢查網絡設備非業務繁忙期 CPU/內存使用峰值情況；檢查設備板卡或模塊狀態；檢查設備機身工作使用情況；檢查主要端口的利用率；檢查鏈路的健康狀態 (包括 IP 包傳輸時延、IP 包丟失率、IP 包誤差率、虛假 IP 包率)。
	脆弱性檢查內容	檢查設備鏈路的冗余度要求；安全事件周期性整理分析；檢查設備生命周期與硬件可靠性評估；檢查備件可用性、周期性檢查。
	監控內容	文檔中該部分空白
	常規操作內容	文檔中該部分空白

運維系統與專用工具對比 (考工具對應類型)

這部分對比了設施運維、軟件運維和大型網站運維中常用的運維系統和專用工具，強調記憶工具與類型的對應關系。

設施運維專用工具

階段 / 類型	工具名稱
準備階段 / 部署工具	Kickstart, Cobbler, OpenQRM, SpaceWalk
過程階段 (配置管理與自動化) / 配置工具	Puppet, Func, Chef, Cfengine, Capistrano, ControlTiger
過程階段 (監控) / 監控工具	Nagios, Zabbix, Cacti, Gandia, Hyperic, OpenNMS
優化改善 / 日志分析工具	Splunk, Loggly, Airbrake, Graylog
其他運維工具	glpi (信息資源管理), Network Notepad (交互式拓撲繪制), Iometer (存儲子系統讀/寫性能測試), Netperf (網絡性能測試), Unicornscan (端口掃描器)

軟件運維專用工具

1. 版本控制工具：
   • 集中式：CVS、SVN
   • 分布式：GIT、Mercurial
2. 構建工具： Ant、Gradle、maven (將源代碼生成可執行應用程序的自動化工具，包括編譯、鏈接、打包)
3. 安裝部署工具：
   • 自動化批量安裝：Kickstart、Cobbler、OpenQRM
   • 自動化部署：Capistrano、CodeDeploy
4. 配置管理工具： Ansible、Chef、Puppet、SaltStark
5. 系統監控工具： Datadog、Graphite、Icinga、Nagios、AppDynamics、New Relic

大型網站運維專用工具

類別	軟件名稱	類別	軟件名稱
本地緩存	OS catch	負載均衡技術硬件	F5
分布式緩存	Memcached、Redis	負載均衡技術軟件	LVS (4 層), Nginx (7 層), HAProxy (4/7 層)
反向代理	Squid、Nginx	NoSQL	Mongodb、Redis
分布式文件系統	NFS (GFS、ZFS、Ceph、TFS、MFS、HDFS)	搜索引擎	Lucene

云運維管理與當前傳統 IT 運維管理的對比

• 主要不同表現為：集中化和資源池化。
• 云運維管理傾向于：盡量實現自動化、流程化、提供個性化視圖。

可維護性對比 (第三章設施 vs. 第四章軟件)

• 第三章 可維護性 (設施)： 指對系統進行維護難易程度的度量。
  • 影響因素： 可理解性、可測試性、可修改性。
  • 衡量可維護性的間接特征： 識別問題的時間、管理延遲時間、維護工具的收集時間、分析診斷問題的時間、修改設計說明書的時間、修改程序源代碼的時間、局部測試時間、系統測試和回歸測試的時間、復查時間、恢復時間。
• 第四章 可維護性 (軟件)： 指軟件產品被修改的能力，修改包括糾正、改進或軟件對環境、需求和功能規格說明變化的適應。
  • 度量方面： 可理解性、可靠性、可測試性、可修改性、可移植性。

RAID 級別區分

• RAID 0 (條塊化)： 性能最高，并行處理，無冗余，損壞無法恢復。
• RAID 1 (鏡像結構)： 可用性、可修復性好，僅有 50% 利用率。
• RAID 0+1 (RAID 10)： RAID 0 與 RAID 1 的結合，兼顧性能和冗余。

故障分類與故障診斷方法 (第三章，下午題重點)

• 故障分類：
  • 按區域分：機房內、機房外
  • 按性質分：鏈路、配置、協議、服務器
• 故障診斷方法： 排除法、對比法、替換法。

災備衡量指標 (重點)

• RPO (恢復點目標 - Recovery Point Object)： 代表災難發生時丟失的數據量。
• RTO (恢復時間目標 - Recovery Time Object)： 代表系統恢復的時間。
• RRO (恢復可靠性指標 - Recovery Reliability Object)： 指在系統切換或恢復過程中成功的可靠性。如一個業務連續性系統在10次恢復/切換中會有兩次失敗，則可性為80%。
• RIO (恢復完整性指標 - Recovery Integrity Object)： 反映系統恢復到某個正確完整的邏輯狀態的能力。RIO 指系統因為邏輯原因出現脫機或數據丟失時，即使系統恢復到最新時間點，系統仍可能處于邏輯不正確、不完整的狀態。

災備等級 (重點)

• 國際標準 SHARE 78 分為 7 個容災等級： 0 級（本地冗余備份）、1 級（數據介質轉移）、2 級（熱站方式）、3 級（電子傳送 + 熱站）、4 級（活動備用鏡像）、5 級（雙活數據訪問）、6 級（數據零丟失）。
• 國家標準 GB/T 20988-2007 分為 6 個等級： 1 級 ... 6 級（零數據丟失和遠程集群支持）。國家機關、金融等重要部門數據中心級別要求 4 級以上。

應急響應與缺陷診斷對比 (第三章設施 vs. 第四章軟件)

這部分對比了第三章設施運維中的應急響應和第四章軟件運維中的缺陷診斷，特別是事件級別和缺陷嚴重性、優先級。

• 第三章 應急響應中的事件級別： 一般 (IV 級)、較大 (III 級)、重大 (II 級)、特別重大 (I 級)。
• 第四章 軟件運維中的缺陷嚴重性： 微小、一般、嚴重、致命。
• 第四章 軟件運維中的缺陷優先級： 最高、較高、一般、低。

管理要素對比 (第二章 vs. 運維管理系統 vs. 運維支持要素)

這部分對比了第二章中的運維管理流程、運維管理系統的功能模塊和運維支持要素，幫助區分這些概念。

• 運維管理流程： 事件管理、事故管理、問題管理、配置管理、變更管理、發布管理、知識管理。
• 信息系統運維管理系統的主要功能模塊： 資產管理、流程管理、監控管理、外包管理、安全管理、綜合管理。
• 運維支持要素 (支撐運維工作的軟環境)： 運維管理部門、運維管理人員、運維管理制度、運維管理設施。

關鍵流程對比 (第二章流程 vs. 第四章過程)

這部分對比了第二章流程中的配置管理、變更管理、發布管理與第四章過程中的對應概念，突出它們在不同層面的關注點。

配置管理

• 第二章 配置管理流程的關鍵活動： 管理規劃、配置識別、配置控制、狀態記錄和報告、確認和審核。
• 第四章 配置管理過程的主要活動： 配置管理計劃、配置與配置項、版本控制、變更控制、配置審計（功能審計、物理審計）、狀態報告。

變更管理

• 第二章 變更管理流程的關鍵活動： 創建變更請求 (RFC)、記錄和過濾變更請求、評審變更、授權變更、變更規劃、協調變更實施、回顧和關閉變更。
• 第四章 變更管理過程的主要目標： 標準化方法和程序、記錄配置項變更、降低風險、響應客戶需求、確保受控的記錄/評估/授權/實施/評審活動。

發布管理

• 第二章 發布管理流程的關鍵活動： 發布規劃、發布設計、構建和配置、發布驗收、試運行規劃、溝通/準備/培訓、發布分發和安裝。
• 第四章 發布管理過程的目的： 通過項目規劃實施變更，確保只有測試過的正確版本才能發布到運行環境，保證安全可靠，并控制發布風險，避免或減少失敗影響。