信息系統(tǒng)基礎設施與安全

1、1信息系統(tǒng)基礎設施與安全信息系統(tǒng)基礎設施與安全尚邦治2011.09.26三級綜合醫(yī)院評審標準實施細則(2011年版)(衛(wèi)辦醫(yī)管發(fā)2011148號)6.5.4.2 加強信息系統(tǒng)運行維護。 C1.有信息網(wǎng)絡運行、設備管理和維護、技術文檔管理記錄；2.有信息系統(tǒng)變更、發(fā)布、配置管理制度及相關記錄3.有信息系統(tǒng)軟件更新、增補記錄；4.有信息值班、交接班制度，有完整的日常運維記錄和值班記錄，及時處置安全隱患。三級綜合醫(yī)院評審標準實施細則(2011年版)(衛(wèi)辦醫(yī)管發(fā)2011148號)B1.有信息系統(tǒng)運行事件(如系統(tǒng)癱瘓)相關的應急預案并組織演練，各部門各科室有相應的應急措施，保障全院運營，尤其是醫(yī)療工作在

2、系統(tǒng)恢復之前不受影響；2.有根據(jù)演練總結開展持續(xù)改進的方案和措施。A有完善的監(jiān)控制度與監(jiān)控記錄，及時處理預警事件，定期進行信息系統(tǒng)運行維護評價和改進方案，并組織落實。醫(yī)院信息平臺總體架構醫(yī)院信息平臺總體架構信息系統(tǒng)運行維護信息系統(tǒng)安全等級保護信息系統(tǒng)機房建設信息系統(tǒng)災備1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.1.1信息系統(tǒng)運維概念 信息系統(tǒng)生命周期中，信息系統(tǒng)建設時間約占生命周期的20%，信息系統(tǒng)運行時間約占生命周期的80%。醫(yī)院信息系統(tǒng)要求長期穩(wěn)定運行。要保障醫(yī)院信息系統(tǒng)要求長期穩(wěn)定運行，必須做好運行維護工作。信息系統(tǒng)運行維護工作的目的是通過日常的簡單工作，達到：減少信息

3、系統(tǒng)發(fā)生故障的次數(shù)；發(fā)生故障時快速排除故障；延長信息系統(tǒng)使用時間。1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述海恩法則海恩法則海恩法則是德國飛機渦輪機的發(fā)明者德國人帕布海恩法則是德國飛機渦輪機的發(fā)明者德國人帕布斯斯海恩提出一個在航空界關于飛行安全的法則海恩提出一個在航空界關于飛行安全的法則, ,海海恩法則指出恩法則指出: : 每一起嚴重事故的背后，必然有每一起嚴重事故的背后，必然有2929次次輕微事故和輕微事故和300300起未遂先兆以及起未遂先兆以及10001000起事故隱患。起事故隱患。海恩法則強調兩點：一是事故的發(fā)生是量的積累的海恩法則強調兩點：一是事故的發(fā)生是量的積累的結果

4、；二是再好的技術，再完美的規(guī)章，在實際操結果；二是再好的技術，再完美的規(guī)章，在實際操作層面，也無法取代人自身的素質和責任心。作層面，也無法取代人自身的素質和責任心。1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述墨菲定律墨菲定律墨菲定律源自一個名叫“墨菲”的美國上尉。墨菲定律：只要存在發(fā)生事故的原因，事故就一定會發(fā)生，墨菲定律：只要存在發(fā)生事故的原因，事故就一定會發(fā)生，而且不管其可能性多么小，但總會發(fā)生，并造成最大可能的而且不管其可能性多么小，但總會發(fā)生，并造成最大可能的損失。損失。這就告訴我們，對任何事故隱患都不能有絲毫大意，不能抱有僥幸心理，或對事故苗頭和隱患遮遮掩掩，而要想一切辦

5、法，采取一切措施加以消除，把事故案件消滅在萌芽狀態(tài)。 根據(jù)“墨菲定律”：一、任何事都沒有表面看起來那么簡單；二、所有的事都會比你預計的時間長；三、會出錯的事總會出錯；四，如果你擔心某種情況發(fā)生，那么它就更有可能發(fā)生。1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.1.1信息系統(tǒng)運維概念運維內(nèi)容可歸納為如下3個方面:1、信息化基礎設施運維：以硬件資產(chǎn)和軟件資產(chǎn)可用為目的，包括支撐系統(tǒng)正常運行的網(wǎng)絡系統(tǒng)、主機系統(tǒng)、安全系統(tǒng)、存儲系統(tǒng)和機房專用設施和數(shù)據(jù)庫等的運維服務； 1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.1.1信息系統(tǒng)運維概念運維內(nèi)容可歸納為如下3個方面:2、應

6、用系統(tǒng)運維：以系統(tǒng)整體可用和為業(yè)務提供可靠服務為目的，包括業(yè)務和應用的技術運維，以及信息內(nèi)容服務運維等；3、信息資源維護類：以深化信息資源共享利用為目的，包括信息資源獲取、處理、存儲、傳輸和共享使用等。 1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.1.2信息系統(tǒng)運維框架 1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.1.3 信息系統(tǒng)運維管理體系 1.1.信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.3 信息系統(tǒng)運維管理體系1.3.1管理目標層IT運維管理體系的建立要面向業(yè)務，以業(yè)務需求和目標為出發(fā)點，制定IT運維管理的遠景、目標和策略。確保在目標層面，IT與業(yè)務相融

7、合。 1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.1.3.2組織模式層基于IT運維管理目標，建立科學的IT運維管理機制。結合組織的實際，將IT服務相關的全部活動進行統(tǒng)一決策與規(guī)劃，確定和規(guī)范IT運維管理體系運行的管理方式和與之相配套的組織機構設置，形成集中統(tǒng)一的IT運維管理機制，合理配置IT運維管理資源，實現(xiàn)對客戶的端到端服務。1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.1.3 信息系統(tǒng)運維管理體系1.1.3.3制度規(guī)范層依據(jù)管理模式，從管理角度制定的用來規(guī)范IT運維和服務工作的準則，建立IT運維管理過程中各個參與要素（人、流程、工具）的管理制度與工作流程，建立

8、考核評價體系，規(guī)范運維費用，實現(xiàn)精細化管理。1.1 1.1 信息系統(tǒng)運行維護概述信息系統(tǒng)運行維護概述1.1.3 信息系統(tǒng)運維管理體系1.1.3.4技術支撐層技術支撐體系是IT運維管理的實現(xiàn)手段，制度規(guī)范體系的具體落實有賴于技術支撐體系的技術支持。需要建立針對面向業(yè)務客戶的IT服務請求響應窗口和面向技術支持人員的體系運行管理窗口；建立負責IT運維管理流程運行的流程管理平臺和負責IT基礎設施和業(yè)務應用系統(tǒng)運行監(jiān)控的集中監(jiān)控管理平臺；根據(jù)不同類型IT 基礎設施和業(yè)務應用系統(tǒng)的管理職能，建立技術管理子系統(tǒng)，建立知識庫、配置庫、報表及日常操作等共享支持子系統(tǒng)和為業(yè)務管理提供服務的業(yè)務運維管理子系統(tǒng)。 1

9、.2 1.2 運維管理要求運維管理要求IT運維的責任是什么？ 第一是要使現(xiàn)在的IT工具化，在用到IT的時候，它可以作為一個工具來提供給其他部門使用；第二是要安全，要讓所有人使用的時候，不需要擔心他的信息內(nèi)容會被人竊取或者遭到別人的惡意破壞；第三是要可靠，不要因為它的可靠性不夠而發(fā)生宕機或者系統(tǒng)崩潰；1.2 1.2 運維管理要求運維管理要求IT運維的責任是什么？（續(xù)）第四是可用，IT能夠被用戶所理解，能夠很容易地使用；第五是透明，這是一個很難做的工作，要做到人們只關心自己的業(yè)務，而不在乎IT系統(tǒng)；第六是可控可管理，這也就是資產(chǎn)要保值增值，最終目標要實現(xiàn)IT的充分利用，發(fā)揮IT的最大價值。1.2

10、1.2 運維管理要求運維管理要求 1.2.1運維管理制度 醫(yī)院需要建立完善而成熟的IT運維管理體制，通過運維管理的制度化、運維內(nèi)容的明細化、運維服務流程化，建立全新服務標準。使其根據(jù)院內(nèi)用戶的需求，建立能夠快速響應并適應醫(yī)院的規(guī)范化、高效性發(fā)展的運維模式，不斷提高IT運維質量，實現(xiàn)高效運維，提升醫(yī)院內(nèi)IT服務滿意度。 1.2 1.2 運維管理要求運維管理要求1.2.2 運維管理機構隨著醫(yī)院信息化的范圍不斷擴大，集中的運維管理需科學的劃分機構職責，并細化運維內(nèi)容。根據(jù)實際經(jīng)驗，醫(yī)院信息化系統(tǒng)的運維管理機構可劃分為五個部分：服務臺二線運維部三線運維部硬件維修部網(wǎng)絡部1.2 1.2 運維管理要求運維

11、管理要求1.2.3 運維人員管理運維管理崗位技能劃分如下：一線運維工程師二線運維工程師網(wǎng)絡工程師信息安全工程師維修工程師1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交 信息系統(tǒng)建設階段完成后，將轉入運行維護階段。為了做好運行維護工作，需要很多建設過程中產(chǎn)生的文檔材料。在信息系統(tǒng)建設階段完成后，需要做信息系統(tǒng)移交工作。信息系統(tǒng)移交的內(nèi)容主要是信息系統(tǒng)設計文檔，信息系統(tǒng)實施過程中產(chǎn)生的文檔，硬件子系統(tǒng)文檔，網(wǎng)絡子系統(tǒng)的文檔，系統(tǒng)軟件文檔，應用系統(tǒng)文檔等。 1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交1.3.11.3.1網(wǎng)絡系統(tǒng)網(wǎng)絡系統(tǒng)網(wǎng)絡拓撲圖網(wǎng)絡拓撲圖給出了網(wǎng)絡設備之間的邏輯關系。在了解一個網(wǎng)絡時，首先要

12、看網(wǎng)絡拓撲圖。通過網(wǎng)絡拓撲圖可以看出網(wǎng)絡交換機之間的關系，可以看出核心交換機，匯聚交換機，接入交換機?？梢钥闯龊诵慕粨Q機與匯聚交換機連接情況，可以看出匯聚交換機與接入交換機的連接情況。 1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交設計的拓撲圖1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交實際測試的拓撲圖1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交交換機命令配置清單交換機配置清單是配置交換機命令序列。每臺交換機都要有相應的交換機配置清單。交換機配置清單包括交換機初始化配置，基本功能配置，VLAN配置，交換機安全配置，路由配置等。端口對應表配線架表1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交IP地址表VLAN表設備

13、情況說明1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交設備標簽說明。按照標簽使用規(guī)范明確定義網(wǎng)絡設備標簽名并對應做好標簽標識工作。應急策略或方案1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交常見問題集。對網(wǎng)絡設備運行過程中出現(xiàn)的常見問題提供解決方法或技術支持。維護聯(lián)系方式。網(wǎng)絡設備維護單位及相應維護人員聯(lián)系方式，以及網(wǎng)絡設備相應維護等級及響應時間。防火墻配置清單路由器配置清單1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交1.3.21.3.2服務器與存儲設備服務器與存儲設備服務器與存儲設備配置說明。對服務器硬件生產(chǎn)廠家、型號、CPU核數(shù)、CPU芯片數(shù)量、內(nèi)存容量、硬盤單盤容量、硬盤數(shù)量、RAID卡情況、RAID方

14、式、HBA卡情況、電源功率及數(shù)量、BISO版本、服務器數(shù)量，存儲設備控制器緩存容量、存儲設備控制器數(shù)量、硬盤單盤容量、硬盤數(shù)量、對于FC SAN的光通道交換機配置情況等進行簡要說明。 1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交操作手冊或維護手冊。邏輯關系圖。服務器之間關系圖或簡易拓撲圖，服務器與存儲設備連接圖，服務器與交換機連接圖等，用于明確各設備之間依存關系。 1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交網(wǎng)口對應表。描述該服務器每塊網(wǎng)卡對端交換機連接情況，各網(wǎng)卡IP地址使用及路由信息。設備情況說明。設備硬件配置數(shù)據(jù)，設備硬件及軟件版本說明，購買日期，設備序列號，設備保修狀況，設備維保情況等。設備標

15、簽說明應急策略或方案常見問題集維護聯(lián)系方1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交1.3.31.3.3系統(tǒng)軟件系統(tǒng)軟件這里系統(tǒng)軟件主要是指操作系統(tǒng)、數(shù)據(jù)庫和開發(fā)工具。1.3.3.1 操作系統(tǒng)版本說明。描述操作系統(tǒng)主版本號、小版本號及相應補丁情況。用戶名及權限最大用戶數(shù)超級管理員名稱及口令加固說明。當前操作系統(tǒng)進行哪些加固工作。說明必須根據(jù)操作系統(tǒng)的變化隨時修改。配置環(huán)境說明 1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交1.3.3.2 數(shù)據(jù)庫版本號。描述數(shù)據(jù)庫版本號。配置路徑。描述數(shù)據(jù)庫配置路徑。數(shù)據(jù)庫日志文件增長規(guī)則。描述數(shù)據(jù)庫日志文件增長規(guī)則。日志文件路徑。描述數(shù)據(jù)庫日志文件訪問路徑。數(shù)據(jù)庫日志文

16、件增長限制情況說明數(shù)據(jù)庫參數(shù)配置情況說明1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交1.3.3.3 開發(fā)工具開發(fā)工具版本號開發(fā)工具訪問路徑。開發(fā)工具軟件適合在哪些平臺運行說明 1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交1.3.4應用系統(tǒng)軟件應用軟件主要指業(yè)務應用軟件。應用軟件模塊表。醫(yī)療行業(yè)的信息系統(tǒng)是由若干個軟件模塊組成。在該表中反應了所有軟件模塊的名稱、用途。應用軟件各模塊配置文件應用軟件占用的網(wǎng)絡傳輸層端口表正式庫名稱調試庫名稱 1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交數(shù)據(jù)庫表清單。一個數(shù)據(jù)庫是由若干個表組成。每個表有其用途。數(shù)據(jù)庫表清單描述了每張表的名稱和用途。字段說明。描述各字段名稱、數(shù)據(jù)

17、類型、數(shù)據(jù)長度，字段屬性相應說明以及特殊值含義說明等。后臺任務說明數(shù)據(jù)備份說明。數(shù)據(jù)庫備份說明給出備份任務名稱、備份文件存儲位置、備份任務啟動時間、備份策略、備份周期等。 1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交1.3.51.3.5安全工具安全工具安全工具分為硬件設備和軟件。1.3.5.1 硬件設備設備情況說明。對安全設備硬件型號、用途、功能、安全策略、電源功率及軟件版本進行簡要說明。系統(tǒng)必要性說明安全設計說明維護聯(lián)系方式常見問題集1.3 1.3 信息系統(tǒng)移交信息系統(tǒng)移交1.3.5.2 安全軟件軟件版本號。軟件大小說明。描述軟件占用存儲空間大小。軟件授權使用環(huán)境配置路徑1.4 1.4 信息系統(tǒng)

18、參數(shù)信息系統(tǒng)參數(shù) 信息系統(tǒng)參數(shù)反映了信息系統(tǒng)性能和運行狀態(tài)。在運維過程中，通過信息系統(tǒng)參數(shù)了解信息系統(tǒng)運行狀態(tài)；根據(jù)信息系統(tǒng)參數(shù)進行風險評估；根據(jù)信息系統(tǒng)參數(shù)對信息系統(tǒng)進行調試； 使得信息系統(tǒng)在一個穩(wěn)定狀態(tài)下運行。信息系統(tǒng)參數(shù)分為靜態(tài)參數(shù)和動態(tài)參數(shù)。靜態(tài)參數(shù)一般反映了信息系統(tǒng)的性能；動態(tài)參數(shù)一般反映了信息系統(tǒng)運行狀態(tài)。以服務器為例，服務器的CPU數(shù)量是一個靜態(tài)參數(shù)，它反映的服務器在處理能力方面的性能。CPU利用率是一個動態(tài)參數(shù)，它反映了服務器處理負荷的大小。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.1 1.4.1 服務器和存儲設備參數(shù)管理服務器和存儲設備參數(shù)管理1.4.1.1.物理服務

19、器參數(shù)服務器生產(chǎn)廠家、品牌、型號服務器序列號：每臺服務器有一個生產(chǎn)廠家給的唯一生產(chǎn)序列號。用作維修存檔。在需要原廠提供維修服務時，需要給維修部提供該序列號。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)服務器名稱服務器CPU芯片數(shù)量。反映CPU數(shù)量的單位有兩個，一個是CPU芯片的數(shù)量，一個是CPU內(nèi)核的數(shù)量。經(jīng)常有些人有意或無意的把CPU芯片數(shù)量與CPU內(nèi)核數(shù)量在概念上混肴。服務器CPU核數(shù)CPU利用率服務器內(nèi)存總容量服務器內(nèi)存條單條容量、內(nèi)存條數(shù)量1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.1.9、1.4.1.10服務器所連交換機名稱、端口號服務器物理網(wǎng)卡數(shù)量服務器所連交換機名稱、端口號物理

20、服務器IP地址群集IP地址。HBA板卡的通信速率。HBA卡數(shù)量。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)服務器物理硬盤容量服務器物理硬盤RAID方式服務器邏輯硬盤盤符和容量服務器管理IP信息對于小型機，一般都需要用另外的計算機對其進行管理。對小型機進行管理需要通過IP地址登錄到小型機上。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.2.2、存儲設備參數(shù)、存儲設備參數(shù) 1.4.2.4.控制器緩存容量控制器緩存容量存儲設備物理硬盤參數(shù)。包括單個硬盤容量、硬盤轉速、硬盤接口電路類型、硬盤數(shù)量等。存儲設備總裸容1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)存儲設備總有效容量。硬盤經(jīng)過格式化后其可使用的

21、存儲容量要小于標稱存儲容量。是硬盤的有效存儲容量。使用RAID 1模式的存儲設備有效存儲容量=單盤有效容量*硬盤數(shù)量/2。使用RAID 5模式的存儲設備有效存儲容量=單盤有效容量*(硬盤數(shù)量-1)。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)存儲容量劃分信息。存儲容量劃分信息指存儲設備劃分了幾個邏輯硬盤，每個邏輯硬盤的容量。物理鏈路圖物理鏈路圖光纖交換機的zone劃分。在一個光交換機連接多個服務器及多個存儲單元時，要給光交換機配置好那個服務器訪問哪個存儲單元?；蛘哒f是將交換機連接存儲的端口，和某個特定的端口劃分到一個區(qū)域里，以便實現(xiàn)從端口到存儲的連通性。使服務器能夠看到存儲。光纖交換機使用前應進

22、行zone設置。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)LUN劃分。lun的全稱是logical unit number，也就是邏輯單元號。scsi總線上可掛接的設備數(shù)量是有限的，一般為6個或者15個，可用target ID(也有稱為scsi id的)描述這些設備，設備只要一加入系統(tǒng)，就有一個代號，我們在區(qū)別設備的時候,只要說幾號就行了。而實際上我們需要用來描述的對象，是遠遠超過該數(shù)字的，于是我們引進了lun的概念，也就是說lun id的作用就是擴充了target id。每個target下都可以有多個lun device，我們通常簡稱lun device為lun，這樣就可以說每個設備的描述就

23、有原來的target x變成target x lun y了。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.2.11.LUN劃分（續(xù)）lun是一些虛擬的對象。比如一個陣列柜，主機那邊看作是一個target device，那為了某些特殊需要，我們要將磁盤陣列柜的磁盤空間劃分成若干個小的單元給主機來用，于是就產(chǎn)生了一些什么邏輯驅動器的說法，也就是比target device級別更低的邏輯對象，我們習慣于把這些更小的磁盤資源稱之為lun0,lun1,lun2等。對于操作系統(tǒng)，識別的最小存儲對象級別就是lun device，這是一個邏輯對象，所以很多時候被稱之為邏輯設備。 1.4 1.4 信息系統(tǒng)參

24、數(shù)信息系統(tǒng)參數(shù)1.4.4 .4 網(wǎng)絡運行參數(shù)網(wǎng)絡運行參數(shù)n網(wǎng)絡設備品牌、型號n交換機的光口數(shù)量n交換機光電模塊數(shù)量n交換機的電口數(shù)量n核心交換機下連端口n匯聚交換機、接入交換機上連端口1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)VLAN表。給出了所有VLAN的VLAN ID、VLAN名稱、VLAN使用說明等信息。VLAN使用的IP地址段說明核心交換機CPU利用率重要交換機端口數(shù)據(jù)傳輸率（流量）防火墻端口使用說明路由器端口IP地址 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.5 .5 布線參數(shù)布線參數(shù)1.4.5.1線纜橋架圖線纜橋架圖。線纜橋架圖標識了建筑物中橋架的走向和截面尺寸。樓層機房位置圖

25、。樓層機房表。標識了各樓層機房的面積、房間號等信息。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)配線架表。給出了樓號、樓層、房間號、工作區(qū)模塊號、配線架號、交換機名稱、交換機端口號等信息。一般情況下，一個配線架對應一張配線架表。光纜資料。光纜數(shù)量，每條光纜類型（OM1、OM3），光纜芯數(shù)等信息。光纜布線圖。標識了光纜在樓內(nèi)或園區(qū)內(nèi)的走向。1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.6 .6 系統(tǒng)軟件參數(shù)系統(tǒng)軟件參數(shù)1.4.6.1操作系統(tǒng)參數(shù)服務器群集狀態(tài)。這是一個動態(tài)參數(shù)。正常情況下服務器群集應該始終是群集中主服務器處于工作狀態(tài)。主服務器發(fā)生故障時，群集操作系統(tǒng)和數(shù)據(jù)庫自動從主服務器切換到備

26、用服務器上，這時群集備用服務器處于運行狀態(tài)。主服務器發(fā)生故障后，應該及時排除故障，然后將群集從備用服務器切換回主服務器上。1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)日志文件。有系統(tǒng)日志文件、安全日志文件、應用日志文件、域控日志文件。日志文件反應了操作系統(tǒng)運行情況。根據(jù)日志文件內(nèi)容可以發(fā)現(xiàn)操作系統(tǒng)的故障。1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.6.2數(shù)據(jù)庫參數(shù)全局數(shù)據(jù)庫名稱。本服務器上數(shù)據(jù)庫管理系統(tǒng)（DBMS）名稱。實例數(shù)據(jù)庫名稱。具體使用的數(shù)據(jù)庫名稱。實例名稱最好不使用全局數(shù)據(jù)庫名稱。1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)數(shù)據(jù)庫中索引BLEVEL值。BLEVEL是B-tree索引形式的

27、一部分，與Oracle為搜索某些紀錄而減少索引搜索的次數(shù)相關聯(lián)。在一些情況下，BLEVEL需要單獨的磁盤命中。如果 BLEVEL大于4，那么建議重建索引。這是一個動態(tài)參數(shù)。表空間利用率。對于表空間使用率超過90%以上的情況，需要防止應用將表空間漲滿。 1.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.7 .7 應用軟件參數(shù)應用軟件參數(shù)1.4.7.1應用軟件模塊表醫(yī)院的信息系統(tǒng)是由若干個軟件模塊組成。在該表中反應了所有軟件模塊的名稱、用途。1.4.7.2應用軟件各模塊配置文件1.4.7.3應用軟件占用的網(wǎng)絡傳輸層端口表有些應用軟件運行中要使用網(wǎng)絡傳輸層得端口號。該表反應了應用軟件使用端口情況。 1

28、.4 1.4 信息系統(tǒng)參數(shù)信息系統(tǒng)參數(shù)1.4.7.4數(shù)據(jù)庫表清單數(shù)據(jù)庫表清單給出了數(shù)據(jù)庫中所有用戶表的名稱和用途。1.4.7.5數(shù)據(jù)庫表結構數(shù)據(jù)庫表結構給出了數(shù)據(jù)庫中所有用戶表中的字段名、字段類型、字段長度、字段位置、字段用途、字段特殊取值范圍、字段屬性等。 1.5 1.5 配置管理配置管理1.5.1 配置管理的概念配置管理流程負責核實IT基礎設施和應用系統(tǒng)中實施變更以及配置項之間的關系是否已經(jīng)被正確記錄下來，確保配置管理數(shù)據(jù)庫能夠準確地反映現(xiàn)存配置項的實際版本狀態(tài)。其目的是提供IT基礎架構的邏輯模型，支持其它服務管理流程特別是變更管理和發(fā)布管理的運作。 1.5 1.5 配置管理配置管理1.5

29、.2 配置管理的功能：（1）支持對配置項的登記和管理；（2）支持對配置項屬性的記錄，如序列號、版本號、購買時間等；（3）支持配置項間關系的建立和維護；（4）支持配置項及其關系的可視化呈現(xiàn)；1.5 1.5 配置管理配置管理1.5.2 配置管理的功能（續(xù)）（5）支持對配置管理數(shù)據(jù)庫訪問權限的控制；（6）支持對配置項變更的歷史審計信息；（7）支持配置項的狀態(tài)管理；（8）支持針對配置項的統(tǒng)計報表；（9）支持與事件管理、問題管理、變更管理等其他管理流程的集成。 1.5 1.5 配置管理配置管理1.5.3 配置管理內(nèi)容（1）服務器參數(shù)（2）存儲設備參數(shù)（3）網(wǎng)絡設備參數(shù)（4）系統(tǒng)軟件參數(shù)（5）應用軟件參數(shù)

30、1.5.4 配置管理注意事項服務器、存儲設備、交換機等在配置前要先列出并明確配置參數(shù)清單。配置參數(shù)要及時進行更新1.6 1.6 事件與問題管理事件與問題管理 1.6.1 .1 事件管理事件管理 1.6.1.1 事件管理的概念1.6.1.1.1事件管理定義事件管理(Incident Management) 是IT運維過程中最基本的活動，可以說醫(yī)院IT運維部門的職責就是處理各類事件(Incidents)，事件管理指的是突發(fā)事件管理或意外事件管理，處理IT的危機并要從中恢復運轉。即在出現(xiàn)事故的時候，能夠盡可能地恢復服務的正常運作，避免業(yè)務中斷，以確保醫(yī)院IT運維管理最佳的服務可用性級別。 1.6 1

31、.6 事件與問題管理事件與問題管理1.6.1.1.2 事件管理相關術語（1）事件（incident），即在醫(yī)院IT服務中不屬于標準操作的，并且能夠導致、或者可能導致此醫(yī)院業(yè)務中斷或者服務質量下降的任何事件（event）。（2）服務請求（Service Requests）,用戶想要獲得遞送、支持、信息或建議的請求，并不屬于IT設施設備方面的故障。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.1.2 事件管理相關術語（續(xù)）服務請求的例子包括:（a）程序功能方面的請求或問題；（b）信息狀態(tài)查詢；（c）賬號口令重置；（d）數(shù)據(jù)提取。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.

32、1.2 事件管理相關術語（續(xù)）（3）影響度（impact），指就所影響的醫(yī)務人員或醫(yī)院業(yè)務數(shù)量而言，事件偏離正常服務級別的程度。重要事件是指那些對醫(yī)院業(yè)務帶來非常嚴重的事件。而有些時間上極度緊迫的需要解決的事件也應當作重要事件來處理。（4）緊急度（urgency）,指解決故障時，對醫(yī)務人員或醫(yī)院業(yè)務來說可接受的耽擱事件。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.1.2 事件管理相關術語（續(xù)）（5）優(yōu)先級（priority），主要基于緊急度和影響度來決定。而對于具有同樣優(yōu)先級事件，可按解決他們需要花費的精力的多少來安排順序。例如，對醫(yī)院業(yè)務影響不大且容易解決的故障，可先于一個影響

33、較大且需要大量精力解決的故障。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.2 事件管理的目標 1.6.1.2.1 事件管理的目標醫(yī)院IT運維部門事件管理的目的是在盡可能最小地影響醫(yī)院業(yè)務的情況下，使IT系統(tǒng)恢復到正常運行的狀況。事件管理需要保留時間的有效記錄便于能夠權衡并改進處理流程，以及正確提供報告進展情況，并給其他的服務流程提供合適的信息。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.2.2 事件管理在整個醫(yī)院IT服務管理中的作用（1）對整個醫(yī)院業(yè)務來說：更及時地解決事件可減少事件對醫(yī)院業(yè)務的影響；提高醫(yī)務人員的工作效率。（2）對醫(yī)院IT部門來說：更有效的使用運維

34、人力，合理安排二線運維任務；記錄醫(yī)院IT服務請求，事后進行運維數(shù)據(jù)統(tǒng)計分析，為進一步完善事件管理提供數(shù)據(jù)支持；完善配置信息庫；提高醫(yī)務人員對信息系統(tǒng)的滿意度。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.3 事件管理的流程 1.6 1.6 事件與問題管理事件與問題管理1.6 .1.3 事件管理的流程（續(xù)）事件管理流程首先對事件進行分類 ,確定該事件是否為已知事件作出判斷 ,并根據(jù)影響和緊急度判斷該問題的優(yōu)先級。通過調查和診斷 ,將服務臺不能處理的問題迅速轉至二線、三線技術支持 ,最后將處理結果反饋回服務臺，由服務臺告知用戶解決方案并關閉本次事件處理流程。在管理過程中，通過“審核”，

35、事件主管將重要或者嚴重的問題提交上會。在事件“升級”中，對于提交上來的問題分別進行處理。決定進入下一階段的“問題”、“變更”或“發(fā)布”，并指定處理計劃和方案。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.3.1 服務臺接收事件對事件的發(fā)現(xiàn)可有以下幾種方式 由臨床科室用戶發(fā)現(xiàn)：用戶將此事件報告給服務臺；自行發(fā)現(xiàn)：在運維工作中發(fā)現(xiàn)的事件；分配事件編號：系統(tǒng)會自動分配一個唯一的事件編號，在后續(xù)溝通過程中可使用通過提供的事件編號來引用事件。記錄基本信息：包括時間、用戶、地點、處理人員以及受影響的醫(yī)院業(yè)務或硬件配置等信息。1.6 1.6 事件與問題管理事件與問題管理1.6.1.3.2 事件匹

36、配在知識庫中檢查以前是否發(fā)生過類似的事件，如果發(fā)生過，則查看解決方案和應急措施。如果新事件與某一問題或某一已知錯誤內(nèi)容相匹配，那么就可將事件與這些已知的問題或錯誤進行關聯(lián)。1.6.1.3.3 事件轉線如果服務臺不能在事先規(guī)定的時間內(nèi)解決事件，就要決定應該由二線或三線人員來負責處理該事件。轉線時應準確地將事件轉到相關的負責人和部門。運維問題應轉給二線的維護、網(wǎng)絡或維修組，系統(tǒng)問題及程序BUG應轉給三線研發(fā)組；這種轉線是按已分配好的事件所屬的類別來進行的。合理的事件處理轉移機制對有效的事件管理非常重要。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.3.4 事件整理事件主管每天監(jiān)督事件記

37、錄的完整性和及時性，并對三級以下人員進行評分，對于不完整或者記錄不清楚的事件記錄，及時催促相關人員完成；事件主管在整理事件記錄的過程中，對于存在問題的事件或是有可能引起其他隱患的事件進行上會處理，并于次日早會匯報并討論解決方案。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.3.5 生成問題或變更無需上會的事件，每天由事件主管在進行事件整理的時候即對事件進行歸檔；上會的事件在早會討論后，事件主管應及時對上會事件進行相應處理，提交問題、變更或歸檔；對于需要給用戶回復或向用戶解釋的事件，根據(jù)早會討論的結果反饋給用戶。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.3.6 事件分

38、析定期對一段時間內(nèi)的事件記錄進行統(tǒng)計和分析，統(tǒng)計出該段時間內(nèi)事故頻發(fā)的事件和科室、以及找出有可能存在隱患的事件，分析事故頻發(fā)原因，商討解決方案，以減少事故發(fā)生率。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.4 事件管理中可能產(chǎn)生的問題 1.6.1.4.1 事件處理的堆積未能落實上會事件處理方案，及時轉入ITIL其他流程，雖然事件臨時得到解決。但類似事件在臨床業(yè)務中繼續(xù)出現(xiàn)，事件未能得到徹底解決，同時導致不能成功地對事件進行分配或轉交。1.5 1.5 事件與問題管理事件與問題管理1.5.1.4.2 事件未被完整的記錄缺乏事件及事故的記錄，不利于處理過程的跟蹤；如果醫(yī)務人員不經(jīng)過一系

39、列的處理過程而是自己解決錯誤或直接聯(lián)絡三線人員幫助他來解決。那么與此事件相關的信息不會被完整記錄。而遺漏的信息對問題管理、配置管理的成功實施非常重要。另外，服務臺也不能得到事件解決數(shù)量等信息。這會導致定期提交的事件管理報告不能充分反映當前情況。 1.6 1.6 事件與問題管理事件與問題管理1.6.1.4.3 知識庫等未及時更新新變更的信息未能與知識庫相關聯(lián)，導致知識庫、解釋口徑、配置庫等信息未能及時更新。導致查詢知識庫等信息時得到錯誤數(shù)據(jù)。 1.6 1.6 事件與問題管理事件與問題管理1.6.2 .2 問題管理問題管理1.6.2.1 問題管理的概念1.6.2.1.1 問題管理定義問題管理（Pr

40、oblem Management）是指從事件管理環(huán)節(jié)或自行發(fā)現(xiàn)的方式找到目前醫(yī)院信息系統(tǒng)中存的問題，并充分利用現(xiàn)有資源對問題進行調查、分析，查明問題產(chǎn)生的潛在原因，制定解決問題的方案和防止事件再次發(fā)生的措施，將問題對臨床業(yè)務產(chǎn)生的負面影響減小到最低。此外，問題管理還需對已知錯誤進行管理。1.6 1.6 事件與問題管理事件與問題管理1.6.2.1.2 問題管理相關術語已知錯誤（known error），對于那些已經(jīng)找到問題產(chǎn)生的根源，以及處理它的臨時解決方案，沒有進行最終解決的問題為已知錯誤。 1.6 1.6 事件與問題管理事件與問題管理1.6.2.2 問題管理的目標1.6.2.2.1 問題管理

41、的目標問題管理的目標是找到引起問題的根本原因，并依據(jù)實際情況制定臨時解決方案或最終解決方案，以將問題對臨床業(yè)務產(chǎn)生的負面影響降至最低，防止問題再次發(fā)生。1.6.2.2.2 問題管理在整個IT服務管理中的作用通過解決臨床信息系統(tǒng)中的存在的問題，提高IT服務質量、信息管理水平；將問題的解決方案及應急措施保存在知識庫中，為服務臺一線解決提供信息支持，提高解決效率。 1.6 1.6 事件與問題管理事件與問題管理1.6.2.3 問題管理的流程 1.6 1.6 事件與問題管理事件與問題管理問題管理的流程的主要節(jié)點1.6.2.3.1新增問題新增待審核問題：服務臺主管定期整理日常工作中發(fā)生的待處理事件、自行發(fā)

42、現(xiàn)的待處理問題、其他部門提交的書面申請、待處理的任務等事項，生成待審核的事件或問題，等待部門會議討論。新增問題需要記錄的內(nèi)容有：問題來源、啟動時間、申請部門、申請人、重要程度、緊急程度、問題類型、總負責人、終結時間、相關負責人、問題標題、問題描述，其中申請部門、申請人、重要程度、緊急程度、問題類型為必填內(nèi)容。 1.6 1.6 事件與問題管理事件與問題管理1.6.2.3.2 問題審核在問題審核會議上對待審核問題進行審核，未通過審核的事件將返回到事件管理流程進行處理；通過審核的事件則轉為待查明問題進入到問題管理流程，對于新生成的待查明問題需要設立其緊急重要度和問題負責人。 1.6 1.6 事件與問

43、題管理事件與問題管理1.6.2.3.3 待查明問題處理待查明問題處理方法：根據(jù)問題的緊急重要度安排問題解決的時間表，并按照問題的解決時間表展開工作，在問題處理記錄中記錄相關的工作內(nèi)容和解決進度。1.6.2.3.4待查明問題反饋方法每周的早會上匯報問題的解決進展或遇到的問題（同時修訂問題的緊急重要度）。 1.6 1.6 事件與問題管理事件與問題管理1.6.2.3.5制定問題解決方案制定臨時解決方案制定問題解決方案待方案問題1.6 1.6 事件與問題管理事件與問題管理1.6.2.3.6 已知錯誤管理對于那些已經(jīng)找到問題產(chǎn)生的根源，以及處理它的臨時解決方案，沒有進行最終解決的問題，可將其狀態(tài)調整為已

44、知錯誤，并生成知識庫內(nèi)容。當問題負責人制定出已知錯誤的最終解決方法，可將其轉至變更管理。 1.6 1.6 事件與問題管理事件與問題管理1.6.2.4 問題管理中可能產(chǎn)生的問題 1.6.2.4.1 記錄不完整問題相關信息記錄不明確，可能會造成線索的丟失，十分不利于找到問題原因和制定問題解決方案；問題解決進度記錄不詳盡，會造成重復工作的發(fā)生；問題解決方案描述不清晰，會造成給運維人員提供的信息不準確，影響問題處理效果。 1.6 1.6 事件與問題管理事件與問題管理1.6.2.4.2 事件管理與問題管理之間聯(lián)系不緊密若事件管理與問題管理流程之間沒有很好的信息溝通機制，那么問題管理很難及時了解到當前問題

45、在運維中的監(jiān)控情況，事件管理也很難及時了解到問題管理產(chǎn)生的知識庫信息，如臨時解決方案等。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理 1.7.1 .1 變更管理變更管理1.7.1.1 變更管理的概念變更管理定義變更可由事件、問題、自行增加等途徑引發(fā)。變更管理（Change Management）是確保臨床信息系統(tǒng)中的所有變更按照預定的流程和時間進行修改，即對變更的質量和時間進度進行管控，以保證變更修改的質量和效率，降低或消除因為變更所造成的問題。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.1.2 變更管理的目標1.7.1.2.1 變更管理的目標變更管理的目標是對變更項目進行管控，確

46、保變更安全有序進行。1.7.1.2.2 變更管理在整個IT服務管理中的作用對變更項目進行嚴格的管控，確保變更質量和時效性，有效將變更對臨床業(yè)務的影響控制在最小；通過變更可以進一步完善臨床信息系統(tǒng)，增加信息系統(tǒng)穩(wěn)定性，同時滿足臨床科室提出的新需求，增強系統(tǒng)可用性。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.1.3 變更管理的流程變更來自事件和問題管理，變更主管通過變更整理，確定變更方案，或是將變更轉為問題或歸檔。針對變更制定工作計劃，組織研發(fā)人員編寫程序，安排測試。具體負責人填寫變更日志，記錄任務實施的溝通協(xié)調進程。 1.7 1.7 變更與發(fā)布管變更與發(fā)布管理理1.7.1.3 變更管理

47、的流程（續(xù)）1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.1.3 變更管理的流程（續(xù)）變更管理的流程說明1.7.1.3.1新增變更新增待審核變更：待審核變更的來源有三種，分別是由事件直接轉為待審核變更、自行新增待審核變更、由問題直接轉為待審核變更，這些待審核變更需要會議中討論。新增變更需要記錄的內(nèi)容有：變更來源、申請部門、重要程度、緊急程度、申請人、總負責人、相關負責人、變更類型、申請報告、變更標題、變更描述、解決方案、關聯(lián)資源等，其中申請部門、重要程度、緊急程度、申請人、變更類型、變更標題為必填內(nèi)容。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.1.3.2 變更審核變更審核會議

48、上對待審核變更進行審核，未通過審核的變更將返回到事件管理流程或問題管理流程進行處理，抑或留存在未通過審核變更列表中；通過審核的變更則轉為待處理變更，由變更負責人進行處理。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.1.3.3 變更處理變更轉入待處理流程后，將依據(jù)變更實際處理情況歷經(jīng)“處理中”、“暫停中”、“已完成”、“已關閉”幾個狀態(tài)，只有高級用戶有“暫停中”狀態(tài)的設置權限。變更處理過程中需要對變更處理經(jīng)過進行記錄，記錄內(nèi)容包括：變更創(chuàng)建時間、通過審核時間、開始處理時間、處理完成時間、發(fā)布時間、解決時間、解決記錄等。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.1.3.3 變

49、更處理（續(xù)）變更修改完成后，如需進行測試，則進入到測試流程，測試完成后變更完成。變更完成后需要進行必要的知識庫記錄。如需發(fā)布，則進入到發(fā)布管理流程；如需修改配置信息，則進入到配置管理流程。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.1.4 變更管理中可能產(chǎn)生的問題變更拖延、堆積變更內(nèi)容沒能按照項目預計時間修改完成，造成變更拖延和堆積，影響變更質量，增大了發(fā)布風險。變更測試范圍的界定在變更管理環(huán)節(jié)，制定變更測試要求時，測試范圍比較難以界定，可能出現(xiàn)測試要求制定不全面的情況發(fā)生。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2 .2 發(fā)布管理發(fā)布管理1.7.2.1 發(fā)布管理的概念

50、1.7.2.1.1 發(fā)布管理定義發(fā)布管理（Release Management）是指對經(jīng)測試后導入實際應用的新增或修改后的變更項目或配置項進行分發(fā)的管理流程。即采用固定的發(fā)布流程來實施變更項目，使變更項目安全正確的分發(fā)到各個客戶端。發(fā)布管理與配置管理和變更管理密切配合，以確保每項發(fā)布都被更新到公用的配置管理數(shù)據(jù)庫（CMDB）中。發(fā)布管理還要確保發(fā)布的內(nèi)容軟件庫（DSL，Definitive Software Library）中也得到更新。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.1.2發(fā)布管理相關術語1.7.2.1.2.1最終軟件庫（DSL）：最終軟件庫是一個存儲所有軟件配置項

51、的最終批準版本的安全存儲庫，最終軟件庫中可能包括同一種軟件的多個版本，包括存檔版本、相應的文檔記錄和源代碼等。最終軟件庫需要定期進行備份和管理。1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.1.2.2最終硬件庫（DHS）最終硬件庫中包含了硬件的配置信息。1.7.2.1.2.3 配置管理數(shù)據(jù)庫（CMDB）存儲與管理信息系統(tǒng)設備的各種配置信息，它與所有服務支持和服務交付流程都緊密相聯(lián)，支持這些流程的運轉，發(fā)揮配置信息的價值，同時依賴于相關流程保證數(shù)據(jù)的準確性。在發(fā)布管理巡檢中，需對各配置項信息進行檢查，以便更新完善配置庫。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.2 發(fā)布

52、管理的目標1.7.2.2.1發(fā)布管理的目標發(fā)布管理的目標是按照標準的發(fā)布流程，將變更項目正確安全的發(fā)布，確保只有正確的版本可以進入到正式運行環(huán)境。 1.7 6 1.7 6 變更與發(fā)布管理變更與發(fā)布管理1.7.2.2.2 發(fā)布管理在整個IT服務管理中的作用發(fā)布管理制定了標準的發(fā)布流程來管控程序發(fā)布活動，確保了發(fā)布工作安全有序的進行；實現(xiàn)了對軟件版本的統(tǒng)一管理，解決了在用版本不統(tǒng)一的問題；建立了系統(tǒng)的發(fā)布培訓機制；發(fā)布管理會制定發(fā)布回滾方案，能夠在發(fā)布出現(xiàn)問題是將其對客戶端的影響降至最低；發(fā)布之前，開發(fā)和測試都在質量控制之下，以確保硬件和軟件質量；降低發(fā)布不正確版本的風險。 1.71.7變更與發(fā)布

53、管理變更與發(fā)布管理1.7.2.3 發(fā)布管理的流程 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3 發(fā)布管理的流程（續(xù)）發(fā)布管理的流程說明1.7.2.3.1新增發(fā)布測試組完成變更項目的測試工作后，由變更負責人提交發(fā)布申請，發(fā)布主管在ITIL中新增發(fā)布項，一般將相同程序在一次測試中涉及的變更內(nèi)容規(guī)劃為一次發(fā)布任務。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3.1 制定發(fā)布部署和規(guī)劃每次發(fā)布前，發(fā)布主管都須制定發(fā)布計劃，來定義一項發(fā)布怎樣以及在何時得以配置。在對一項發(fā)布進行規(guī)劃之前，需要收集有關發(fā)布的各項信息。通常在規(guī)劃一項發(fā)布時主要需要考慮下列問題：確定發(fā)布范圍，包括變

54、更內(nèi)容、使用科室、相關人員等；制定發(fā)布日程安排；制定培訓計劃，包括培訓內(nèi)容、培訓人員、受訓人員等；與其他相關流程做好前期溝通工作；制定回退計劃；進行發(fā)布前測試工作；向上級主管提交發(fā)布申請。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3.1 制定發(fā)布部署和規(guī)劃（續(xù)）制定發(fā)布計劃環(huán)節(jié)在ITIL中需要填寫的主要內(nèi)容有發(fā)布系統(tǒng)類型（常規(guī)/試運行/單機系統(tǒng)）、系統(tǒng)名稱、回滾方案、變更內(nèi)容、版本號、更新文件名、更新日期、回滾計劃、發(fā)布配置（版本號、更新文件名、配置項變更說明、數(shù)據(jù)庫變更）等。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3.2 發(fā)布測試由發(fā)布主管或變更負責人完成，

55、發(fā)布前的確認測試在真庫環(huán)境中進行，需根據(jù)變更項進行逐項確認（以真實庫數(shù)據(jù)安全為前提，考慮測試可行性），并記錄發(fā)現(xiàn)的問題。若發(fā)布測試通過，生成測試通過的測試記錄，并記錄測試人員的賬號和時間。此環(huán)節(jié)經(jīng)發(fā)布主管確認后方可進入下一環(huán)節(jié)，不可顛倒其與其他環(huán)節(jié)的先后順序。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3.3培訓1.7.2.3.3.1內(nèi)部培訓該環(huán)節(jié)需發(fā)布主管向變更負責人提供該次發(fā)布涉及的變更內(nèi)容，由變更負責人對服務臺和巡檢人員進行培訓，培訓中需特別指出須告知用戶的變更內(nèi)容并進行操作演示。變更中涉及告知項目時必須出現(xiàn)此環(huán)節(jié)的確認。1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.

56、2.3.3.2 外部培訓若在發(fā)布計劃中指明需要外部培訓，則必須出現(xiàn)此步驟的確認。培訓方式分為告知、小規(guī)模培訓和大規(guī)模培訓。若培訓方式為告知，則發(fā)布人員需按照內(nèi)部培訓時的告知內(nèi)容對用戶進行告知；若培訓方式為后兩者，則發(fā)布主管需聯(lián)系相關科室負責人提前做好培訓安排和計劃。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3.4 發(fā)布執(zhí)行由發(fā)布主管從測試組獲得最新更新包，記錄真庫中當前使用程序的版本號，隨后開啟自動更新機制。1.7.2.3.5 發(fā)布巡檢由發(fā)布主管提供巡檢表，巡檢人員需根據(jù)巡檢表上的信息和要求完成發(fā)布巡檢，巡檢結束后由巡檢人員填寫巡檢記錄，巡檢配置信息在系統(tǒng)中可自動生成，巡檢人員

57、只需勾選所巡客戶端IP即可完成巡檢記錄的填寫。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3.6 發(fā)布驗收根據(jù)變更內(nèi)容，發(fā)布主管需與變更主管溝通確定需要發(fā)布確認的變更項目，查看變更申請報告，填寫系統(tǒng)驗收報告單，無需驗收的變更條目，則無需填寫該報告單。對于有系統(tǒng)驗收報告單的發(fā)布任務，需要視具體情況在發(fā)布前或發(fā)布后（系統(tǒng)正常運行）前往申請科室進行系統(tǒng)驗收報告單的簽字確認，由申請人員或申請科室主管簽字確認皆可。一般由發(fā)布主管或巡檢人員完成此確認。對于沒有系統(tǒng)驗收報告單的發(fā)布任務可忽略此環(huán)節(jié)。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3.7配置更新每次發(fā)布完成后，發(fā)布主管

58、需將此次發(fā)布涉及的配置項變動提交給配置主管，進行配置庫信息的更新，包括程序版本、文件名、客戶端配置等信息的更新。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.3.8 發(fā)布回滾發(fā)布回滾計劃定義了在發(fā)布出現(xiàn)問題的情況下恢復服務所需進行的活動。若程序在發(fā)布之后出現(xiàn)問題，發(fā)布主管需視實際情況確定是否需要回滾，如需回滾則立即向主任匯報情況，得到主任確認后，發(fā)布主管應參考發(fā)布計劃中的回滾計劃執(zhí)行，并記錄回滾信息，包括回滾原因、問題發(fā)現(xiàn)部門、回滾執(zhí)行時間等。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.4 發(fā)布管理中可能產(chǎn)生的問題 1.7.2.4.1發(fā)布試用不到位發(fā)布試用過程中，由于

59、與試用科室溝通不及時，導致未能及時獲取到試用中暴露的程序問題，造成程序發(fā)布后無法正常使用。為了防止該情況的發(fā)生，需要發(fā)布負責人做好程序試用記錄，對試用情況進行實時監(jiān)控。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.4.2 發(fā)布人力占用過多為確保程序更新完成性和及時性，發(fā)布巡檢工作占用了大量人力和時間，為解決該問題，需要在發(fā)布管理中引用較好的軟件工具，以取代人工巡檢方式。 1.7 1.7 變更與發(fā)布管理變更與發(fā)布管理1.7.2.4.3 發(fā)布巡檢不完全發(fā)布過程中巡檢不完全的情況時有發(fā)生，造成程序在用版本不統(tǒng)一等問題。為解決該問題，需要從兩方面考慮，一是完善軟件配置庫，以便在發(fā)布巡檢前，

60、為巡檢人員提供完整的客戶端信息；二是在發(fā)布管理中引用較好的軟件工具，以便及時發(fā)現(xiàn)更新不完全的客戶端。 1.7 6 1.7 6 變更與發(fā)布管理變更與發(fā)布管理1.7.2.4.3 回滾計劃不周全由于制定回滾計劃的負責人對程序當前使用情況了解不全面，導致回滾計劃制定的不得當或不周全，如未考慮同一程序在不同科室的特異性，未對程序舊有版本進行登記和備份等情況。1.7.2.4.4 忽視發(fā)布管理未經(jīng)批準的版本可能會被發(fā)放的科室使用，從而對服務產(chǎn)生負面影響，即使是緊急修復的發(fā)布也應服從發(fā)布管理流程。 1.8 1.8 文檔管理文檔管理 文檔是信息系統(tǒng)設計、建設、使用和維護的必備資料。它能提高信息系統(tǒng)設計、建設的效