1. <tt id="5hhch"><source id="5hhch"></source></tt>
    1. <xmp id="5hhch"></xmp>

  2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

    <rp id="5hhch"></rp>
        <dfn id="5hhch"></dfn>

      1. 企業運維系統建立初探

        時間:2024-09-14 04:04:36 企業管理畢業論文 我要投稿
        • 相關推薦

        企業運維系統建立初探

        【摘要】隨著IT技術在企業的應用,很多企業已經建立了核心業務系統,企業的運作已經離不開IT系統了。如何保障信息系統安全可靠的運行已成為企業最為關注的題目,而傳統的運行維護治理模式已經不能適應目前環境下業務的需求。因此對IT系統需要一套治理系統來支撐,這就是運行維護系統。
          【關鍵詞】運維系統 運維服務 IT技術
          
          一、背景說明
          
          隨著IT技術在企業的應用,很多企業已經建立了核心業務系統,如ERP、OA、數據倉庫等,業務策略驅動IT策略的建立,IT策略支持業務策略,由此,很多企業的運作已經離不開IT系統了,因此任何一個故障造成的損失,影響面是比較大,甚至影響整個企業的業務。而傳統的運行維護治理模式比較被動, 即只有當系統出題目時, 才會引起留意和得到解決, 或者當業務受影響, 并被業務部分匯報投訴,才發現題目。 這種治理模式已經不能適應目前環境下業務的需求。
          其次,從生命周期的角度看,無論是硬件還是軟件,大致可分為規劃和設計、開發和測試、實施、運營和終止等5個階段。前面3階段從時間的角度看,只占生命周期的20%,其余80%的時間基本上是運維服務,假如整個IT的運維做得不好,那么這些花費大筆投資建立起來的系統,無法帶來預期的效益,甚至于無法使用,由于使用者無法順利使用他們。
          根據Gartner Group調查發現,在經常出現的題目中,源自技術和產品方面的實在只占了20%,流程失誤占40%,職員疏失占40%。流程失誤包括變更治理沒有做好、超載、沒有測試等流程上的失誤或不完整,職員疏失包括遺忘、練習不足、備份錯誤及安全疏忽等。這就說明IT運維方面的題目,更多的不是技術題目,而是來自治理方面,因此對IT系統需要一套治理系統來支撐,這就是運行維護系統。
          
          二、信息系統運行維護面臨的挑戰
          
          一般信息系統架構的層次如下:
          
          由此,我們可以看到,為了保證應用系統的可用性,不但要保證應用程序本身的正確性和健壯性,同時還要保證從網絡到應用程序端到真個可用性,為此,從運行維護的角度來看,必須從整體的角度來規劃,對與應用系統相關的IT基礎設施、支撐平臺進行集中監控,并與應用系統進行關聯,一旦出現故障,可以迅速定位并解決;同時定義相關的流程保證一個應用的變更不會對其他應用產生影響,對出現的題目從根源上找出原因,并進行解決,從而保證系統的高可用性;诒救藢T服務治理的理解,基于ITIL的框架,提出運行維護系統建立的一些想法。
          
          三、運行維護系統的設計
          
          那么如何設計IT運行維護系統呢?主要從兩方面著手,一是治理流程的設計,二是系統監控的設計。在治理流程方面,目前ITIL(IT Infrastruct Library)基本上成為事實上的標準,它是最佳實踐的結晶;在系統監控方面包括從IT基礎設施應用系統進行監控,并實現事件的關聯,以實現主動的監控,實現故障的快速定位和預警,下面具體說明。
          
          (一)運維系統的設計理念
          運維系統的設計理念基于ITIL-IT服務治理框架,ITIL 將IT 服務治理分為:
          ●信息和通訊基礎框架治理,這部份將更側重于技術視角。
          ●服務治理,包括“提供IT 服務” 和“支持IT ”服務兩部分,關注在提供IT 服務過程中,監控,治理,處理解決題目的整個過程。
          ●面向業務的治理,將從業務的視角來看治理,將治理IT 服務與IT 服務所支撐的業務關聯。
          1. 信息和通訊基礎框架治理
          IT 基礎框架的智能治理是服務保障的基礎,應該是一個可以全面治理IT 基礎框架中所有產品和技術的平臺,并通過提供以下能力達到真正的業務價值、真正的投資回報、保障安全生產,進步服務水平。
          IT 基礎框架的智能治理將覆蓋企業IT環境,提供包括廣域網,局域網,主機接進網絡,網絡安全設備,Internet 服務的全方位的IT 從網絡到系統,應用,業務的監控治理,以及面向IT運維的事件壓縮,事件相關性分析,故障診斷,根源故障分析,自動化的故障處理等一系列功能和工具。
          2. 服務治理
          今天,正進行著服務治理的革命。幾乎所有企業的IT 部分都正在向面向業務的服務提供者的轉變。IT部分就像一個合作伙伴一樣參與到企業的業務過程,主動的提供服務職能,并向它的客戶-業務部分負責。
          ITIL 將企業的IT 服務治理分為:
          提供IT服務,關注在提供IT 服務過程中和治理行為和手段;
          支持IT 服務, 關注在支持IT 服務過程中,處理題目,變更等的動作和流程。
         。1)提供IT 服務
          提供IT 服務包括:制定規劃,為業務部分按計劃和服務質量提供服務
          保障提供服務的持續性。
          在服務提供體系實現的主要任務是:
          ■服務水平治理
          ■可用性治理
          ■容量治理
          ■本錢治理
          ■應急方案
         。2)支持IT 服務
          支持IT 服務包括:為達到服務目標提供相關治理信息。為實現服務目標提供相應的支撐機制。
          服務支持體系實現的主要任務是:
          ■配置治理
          ■幫助臺治理
          ■題目治理
          ■變更治理
          ■軟件控制和分發治理
          3. 面向業務的治理
          面向業務的IT 治理是從客戶視角的端到端服務監控治理,它的特點是:
          提供直觀的監控視圖,能夠實時判定通訊和IT 基礎框架故障對業務的影響;
          在發生影響業務的故障時,IT服務保障部分能夠最快的獲知題目的發生,并迅速采取行動;
          根據故障對業務的影響情況,決定處理的優先級;
          當業務服務發生題目時能夠確定故障所在的基礎框架層次;
          通知相關客戶服務系統或大客戶,告知題目的狀況和解決進展;
          面向客戶業務服務,提供基于Web 的多種視圖,包括端到端服務監控層次模型,和監控構成服務系統的各個組件;
          面向業務治理的宗旨是通過全面的業務系統和IT 框架系統監控,增強治理,進步治理水平,并終極保障業務的成功運行。實現IT基礎框架端到真個監控和與業務的關聯。
          
         。ǘ┻\維系統的設計目標
          ●確保IT流程支撐業務流程, 整體進步業務運營的質量。
          ●進步用戶的滿足度, 提升企業的社會效益和經濟效益。
          ●實時實現對從IT的基礎架構到應用系統的端到真個運行情況進行監控。
          ●提供從業務角度分析IT基礎設施(包括系統、網絡、數據庫、應用服務器)的能力。
          ●建立完善的支持服務流程和支持模式。
          ●建立滿足服務水平要求的服務水平治理。
          
         。ㄈ┗贗TIL的理念建立規范的處理流程
          在ITIL中要建立很多治理流程,在實際應用中,我覺得至少需要建立下面幾個流程:
         。1)題目治理
          建立并應用題目處理程序,以實現對題目診斷和確定解決題目的方案, 并將解決方案記錄在配置數據庫中,針對服務水平治理確定并實現內部的題目升級時間標準。
          (2)資產治理
          對于天天發生的事件, 題目, 變更處理, 新服務的配置, 各個組件的信息,資產治理的職責就是提供和維護這些信息, 它是與服務治理相關的最重要的任務之一。
         。3)Help Desk治理
          擔當服務中與業務部分和客戶的主要接觸點(point-of-contac)。存儲事件, 確定題目嚴重級別, 綜合支持團隊的努力, 確保及時正確地解決題目, 并提供SLA統計, 證實能夠達到預期的服務級別。
          (4)變更治理
         保證清楚的了解變更針對一個服務中任何組件的影響, 并保證對服務水平的影響最小, 變更治理包括SLA文檔和服務目錄的變更, 以及組織變更和針對軟件和硬件的變更。
          (5)故障治理
          故障治理的主要目標是盡可能快地恢復服務至服務級別協議(SLA)要求的水準,盡可能減少故障對服務運營的不利影響,以確保最好的服務質量和可用性級別。
          
         。ㄋ模┻\維系統的組成
          在一般的運維系統中,需要一個大房間,在大房間中分成以下幾個部分,每個部分都扮演相應的角色:
          
          第一層:大屏幕分別顯示有,基于業務的視圖,基于IT基礎架構的視圖,基于網絡的視圖,當故障出現時能夠以特定的顏色顯示出來,同時可以顯示一些公司需要直觀顯示的數據。
          第二層:服務臺(Help Desk),主要提供:
          ●接受客戶的請求
          ●提供客戶使用上的題目咨詢
          ●提供客戶業務咨詢
          ●記錄并跟蹤故障和客戶意見
          ●根據知識庫,盡快解決題目
          ●及時通知客戶其請求確當前狀況和最新進展
          ●根據服務級別協議,初步評估請求,經歷解決它們或安排給一線工程師解決
          ●對客戶的故障從提出到驗證及終止的整個過程進行治理
          ●協調一線工程師和值班工程師
          第三層:一線支持工程師
          ●根據提供的監控界面迅速定位題目并解決
          ●對于臨時的解決辦法,還要把故障提交給題目處理流程
          ●根據服務級別,在題目未能及時解決時及時把題目提交給值班經理
          第四層:值班經理個人
          ●協調技術專家,根據服務協議的時間要求,解決題目
          ●協調供給商,根據維護協議要求,解決題目
          
         。ㄎ澹┻\維系統的功能設計
          基于ITIL設計理念,我們把ECC的實時監控部分設計成層次架構,如下圖:
          
          
          1. 事件采集層
          在最基本的層次上,需要從被治理的IT基礎設施中獲取廣泛的,實時的數據,能夠從網絡、系統和應用層中捕捉、匯聚并處理大量數據的能力,我們通常稱之為事件治理。
          事件治理是整個面向服務治理系統的核心,在數據采集階段(包括網絡、系統和應用層)采集的信息,只有經過事件治理服務器,轉變為同一的格式,再流進智能化的治理層,實現事件的相關性分析。
          數據采集層是整個治理系統進行信息處理和智能化分析的基礎,因此需要充分獲得正確、實時、完整的治理數據。在數據采集層,應該進行原始數據的過濾、分類、分級等預處理操縱,從中提煉出重要的治理信息。數據采集層獲取信息的實時和正確性,以及對原始信息的預處理能力,將在很大程度上影響整個治理系統的治理能力和效率。
          2.事件處理層
          數據收集僅僅是實現業務和通訊及IT基礎框架治理的基礎,需求最簡單的先決條件。實現真正的基礎框架智能化意味著能夠從整個基礎框架產生的大量數據中,通過采用一系列先進的過濾,事件壓縮,關聯和診斷的技術進行處理,抽取治理職員需要關注的重要信息。好的基礎框架監控治理系統能夠將網絡以至IT系統的專業化知識融進在治理系統中,根據基礎框架層各組成資源的特點,從原始的治理數據中智能分析系統的真實狀況,判定資源實際的運行狀態,分析故障發生的根源并提出解決建議,使運維職員解決題目更加正確和有效。一般包含以下功能:
         。1)事件的存儲
          將運行維護數據與歷史數據分開存儲, 以確保治理的效率. 一般治理信息需要保存6個月甚至更長的數據, 以進行統計分析和存檔, 而在日常運行治理中, 一般只需要查看最近一周甚至更短的信息, 一般采用運行數據與實時數據分開存儲, 運行數據采用高速的內存數據庫保證事件處理的實時性, 歷史數據采用穩定的關系型數據庫保證事件存儲的可靠性和容量,這種結構使事件的處理更加公道。
          (2)事件壓縮
          IT資源事件中有很多重復事件, 尤其在系統組件不穩定時, 有可能會產生事件風暴。過多的事件會使治理員的桌面上羅列大量事件條目,治理員無法獲取真正需要關注的重要事件,因此對重復事件進行合并使事件條目清楚, 幫助治理員快速找到需要處理的故障是非常重要的。重復事件壓縮就是這樣的一個過程: 通過將從下層數據源所報告的相似事件加以匯總,合并成一條事件,該事件的內容包含了該事件重復的次數以及發生的起止時間。
         。3)事件自動化處理
          可以對各類事件信息進行邏輯判定, 并做出相應的動作, 如及時刪除不必要的信息、完成不同事件之間的關聯、對嚴重事件采用明顯的聲音報警、自動升級警告級別假如嚴重事件在一段時間內沒有人響應、發送郵件進行自動通知等等。
         。4)可用性的計算方法
          根據故障樹分析FTA(Fault Tree Analysis)方法,結合可用性的計算方法,來計算服務的可用性。
          組件可用率的計算方法:組件可用率 = (AST-DT)/AST*100%
          AST——約定服務時間(Agreed service time)
          DT——在約定時間內的實際停機時間(Actual downtime)
         。5)可用性的評估指標
          通常我們采用下面幾個指標來對可用性進行評估:
         、倬鶆驘o故障時間(MTBF-Mean Time Between Falures),它指的是從某次事故修復到下次事故發生之間的均勻間隔時間,又稱為正常運營時間(Uptime),它是用來描述服務的可靠性。
         、诰鶆蛐迯蜁r間(MTTR-Mean Time To Repair),它指的是事故發生到服務恢復之間的均勻間隔時間,又稱為停機時間(Downtime),它是用來描述服務的可維護性和適用性。
          3.業務關聯層
          業務影響分析, 基于CFIA等分析法,定義事件和業務系統的關聯關系, 自動找到故障所影響的業務和服務, 并根據關聯結果創建新的服務事件報警。
          4.呈現層
          提供基于Web方式的監控視圖, 可以為不同的治理職員提供不同的監控窗口, 以實時監控相關的事件信息, 事件窗口可以通過分組顯示不同類型、級別、源、時間段內的事件信息, 治理員可以一目了然的看到目前是否有事件發生, 級別如何, 并對事件進行一系列的處理工作。
          5.報表處理層
          各種監控信息存儲在關系數據庫中,可以利用報表工具進行信息統計分析,天生各種格式的報表。
          報表應用可以與實時故障監視環境實現無縫集成,為運維提供一種長期的綜合視圖。報表應用幫助治理職員了解其各種基礎設施在各種不同期間的行為特點,從不同設備、系統和服務的層次上對各種基礎架構的長期行為特點進行查看和分析。
          
          (六)運維系統的設計要求
          1.基于ITIL框架設計, 結構先進
          運維系統的設計要求基于ITIL的框架, ITIL的框架是最佳實踐的結晶。
          2.可擴展性
          假如需要一個新的展示層或者事件關聯,必須能夠無縫擴充或集成到現有的治理框架中。為了保證隨著系統架構的延伸擴展而產生的越來越多的事件信息的處理性能,在任意一個層次增加都不會影響整體框架結構。
          3.集成性
          集成企業現有以及未來可能要擴充的設備和治理系統。假如需要增加新的監控對象,則最多只需簡單地增加一個探針,或增加一個新的關聯層 。
          4.集中化
          已經處理的事件(重復壓縮和事件關聯)集中在一個地方。因此治理員可以共享整個系統的事件信息。
          5.關聯
          由于事件關聯功能在整個系統治理中是分布的,因此為一個新服務增加新的事件關聯是非常輕易的。
          6.冗余
          數據顯示層和關聯層的設計將考慮冗余設計,當任何一個服務器失敗,數據采集層的探針將會自動切換到另一個服務器。
          綜上所述,運維系統的設計,主要從兩個方面來實現,一是治理流程的設計,二是系統監控的設計,通過上面的描述,我們看到,系統監控的作用:當系統出現故障時通過對系統各個層面的監控以及事件的關聯,能夠保證快速定位故障,從而快速解決故障,使得故障對業務的影響降到最小,同時通過對系統性能的監控,進行預警,可以做到防范于未然,防范故障于萌芽狀態,保證系統的可用性;而規范的治理流程,保證所有的題目在每一個階段得到有效的處理。

        【企業運維系統建立初探】相關文章:

        建立民營高科技企業的激勵體系初探03-25

        建立我國個人破產制度的法律初探03-25

        建立實時企業的策略分析03-20

        企業業績評價體系初探03-22

        企業環境成本管理初探03-20

        零售企業維系顧客忠誠策略研究03-22

        建立企業存貨內部控制淺析03-19

        如何建立企業的質量方針03-21

        企業推行全面預算管理初探03-07

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码

        1. <tt id="5hhch"><source id="5hhch"></source></tt>
          1. <xmp id="5hhch"></xmp>

        2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

          <rp id="5hhch"></rp>
              <dfn id="5hhch"></dfn>