第一篇：銀行IT運維管理的心得

銀行IT運維管理的心得

銀行運維的壓力非常大

? ? ? 隨著金融市場的開放，銀行業的風險控制會面臨挑戰，風險管控優先級要放到最高。尤其是系統風險的的防范，要使用先進的方法論和工具，須做到精細化的風險管理。銀行的科技部門壓力很大，業務不斷增長要求IT持續滿足業務需求,系統多，耦合多。一個新系統的建設往往要設計多個系統，各個廠家之間無法協調，問題經常出現。現在銀行的系統的建設非常困難。基本上所有需要的系統都了。但是可能不太好用。主要是系統升級，或者部分新的系統的建設。這些都涉及和其他很多部門，系統的關聯。系統的上線也需要非常長的時間。? 公司內部共有約上百個系統。系統越來越多。工作越來越多。不象以前可以簡單地上一個新的系統，幾個月搞定，很有成就感。現在不僅沒有，擔心的事情，調節的事情一大堆。? 現在有很多公司給銀行提供IT產品和服務，選擇看似很多，但實際看來做好一個系統確實越來越難，希望各個廠家要充分理解客戶和客戶的需求，有創新的想法和做法提供到用戶，而不是只是關注自己產品和服務本身，這樣雙方的合作才能可持續發展。? 開發商方面的人員變動非常快，營業和技術人員。剛剛熟悉了，找到了一個好的開發團隊，轉眼人不在了。現在上一個新的系統，不僅要確認這個公司如何，這個項目經理如何。如果這個公司或者這個項目經理不好，也不能用。? ? 數據集成和治理：系統復雜而分散造成數據分散和標準各異，經常無法得出一份權威的報表，矛盾凸顯。需要花大力氣進行數據的管理。

業務部門不理解科技工作，科技人員不大懂業務，往往會造成溝通困難，項目實施進度緩慢。一個經驗是讓科技人員到不同的業務部門輪崗，讓他們熟悉業務。做項目時，這個人就是部門協調人。? ?

但是運維系統很難上

? ? ? ? ? IT部門主要應對業務部門的要求，開發了很多的系統

IT部門對于自己的系統的自動化，運維管理的投入和開發確是很少。

隨著銀行的業務系統的膨脹，復雜度的增大，IT系統的風險在加大。

IT部門的高層對風險的認識比較高，但是他們不清楚具體的對應方法。

IT部門的底層，各個部門的認識不統一

開發部門：著眼于開發 銀監會要求銀行提供不間斷服務。在奧林匹克，萬博等重大活動時要求行長簽署保障書，軍令狀。

去年以來有幾個重大事故，都是運維人員的失誤造成。以下銀行事故：

– 華夏銀行，光大銀行系統，民生銀行系統事故。IT主管或被免職，或被警告

運維部門：希望能夠對系統進行統一的管理維護，但對開發完畢的系統

沒有修改的權利

具體操作人員：更多地關系自己的工作，對如何改進缺少想法

運維產品內容

? ITIL流程管理

運維管理流程控制，綜合服務臺。大中型銀行需要。但是千萬注意CMDB，這個東西真難搞，搞不好，一身問題。產品：BMC ? 綜合監控（各類銀行）

相對比較容易理解：網絡，硬件，中間件。

問題：應用的監控，需要開發。聯動太深，以后對應用程序的變動又會有影響。只能是淺層次的結合。

產品：IBM Tivoli，BMC，日立 JP1 ? 自動化（各類銀行）

一般這個概念還不太為人知道，國外應該是日本銀行做的比較好一些。國內做的相對比較早，比較好一點的是浦發銀行。

內容：批量處理的統一自動調度，災備切換流程自動化，各種手工作業的自動化。相對比較難以了解，但是很實用，可以一步拓展。其實就是流程化，但是和一般的流程不同，可以對系統自動進行操作。

問題：技術人員和開發廠商對這個概念還不太明確。產品：日立JP1，其他公司也有，但內容相對不太全面。

國內廠商：號稱什么都可以對應，但是產品不規范，小的政府部門還可以，銀行就算了。

第二篇：IT運維心得分享范文

360公司運維心得分享

在很多“外人”的眼中，運維工程師的工作不過是搬機器、調網絡、裝軟件、處理故障、7×24小時值班，簡單而又枯燥至極。但事實并非如此，運維工作涵蓋很多技術領域，運維工程師要掌握硬件、軟件、操作系統、開發等多方面的知識，核心目標是為億萬用戶使用的產品保駕護航。

當今互聯網行業的發展日新月異，新技術層出不窮。為了適應發展趨勢，運維工程師只有提升技術能力才能更好地完成艱巨的運維任務，必須要對傳統運維發出自我挑戰。

在360，運維團隊由基礎運維團隊、網絡運維團隊和應用運維團隊三部分組成。我們將運維從技術支持領域升級，進行產品化改進，核心目標是為了降低運維成本、縮短研發周期、讓產品試錯更廉價。理想很豐滿，現實很骨感，從最初服務少量項目、幾十臺服務器，發展到大量具有數億用戶的項目，我們也在不斷摸索，在試錯中成長。在這個過程中，我們經歷了兩次重要的升級。第一次升級：運維工具化

運維工作中有很多瑣碎的、重復的事情，初期我們只有兩個IDC，服務器數量有限，項目數量也較少，靠純手工勞作還可以應付。但隨著時間的推移，項目暴增，隨之IDC和服務器的數量也成倍增長，同時360各項目都是小團隊在做，開發風格不同、習慣各異，但極致要求響應速度，如果運維工作按照之前方式進行，很難滿足需求。大勢所趨，我們必須進行工具化升級，將重復的事情自動化。

在工具化過程中，我們秉著低成本、拿來即用的原則，借鑒業界成型的方案，同時將精力用在對開源軟件的研究中，有開源工具就絕不自己憑空創造。初期，我們只圍繞開源軟件做周邊腳本開發，不動核心代碼，在實踐中總結經驗。例如，在最基礎的部署軟件環境中，我們基于YUM搭建了自己的包管理系統，將常用軟件打包，同時根據項目做成模板，這樣無論是初始安裝還是擴容都能在分分鐘完成。配置文件管理利用Puppet完成，服務器批量操控依賴SaltStack。就這樣 我們的運維兵器譜在不斷地豐富。

另外，運維工作離不開監控報警，這是一件讓無數運維人苦不堪言的事情。而會休息才會工作，監控體系必須優化。

我們的監控大概分為系統級、應用級、項目邏輯和用戶體驗四部分。系統級主要監控硬件和網絡等；應用級主要監控常用軟件的健康狀況；項目邏輯監控主要模擬用戶行為探測項目功能點是否運行正常；用戶體驗監控主要聯動博睿和基調等第三方監控一起優化用戶體驗。我們用過的工具很多，開源工具有Nagios、Cacti、Ganglia、Zabbix等，同時自己也開發了一些針對項目場景的監控工具，但萬變不離其宗，都是圍繞上述幾個維度進行監控，然后再進行分級預警和報警。

為了減少報警騷擾，我們分級處理，將報警分為郵件預警、短信報警和瘋狂短信報警。以磁盤空間監控為例：每天下午6點，統計 磁盤使用率超過80%的機器，發出郵件預警，下班前解決；在預警的基礎上，超過85%觸發短信報警；超過90%就要持續報警，避免事故的發生。此外，隨著 服務器數量的增多，硬件故障在所難免，架構設計需要考慮高可用方案，冗余范圍內的服務器故障會以郵件預警的方式發出，避免對運維工程師的騷擾。

有了監控工具和分級機制，還需要有好的制度。為了大部分人可以安心休息，我們每天有專人負責處理常規報警，遇到無法解決的問題才要求他人協助。第二天的負責 人要針對第一天的報警找出根本原因，并盡力解決，因為如果無法根治，困擾將持續發生。所謂線上無小事，實際工作中復雜場景引發的問題數不勝數，所以可以寬 容第一次錯誤，但不能接受同樣問題發生第二次，要不斷地總結和完善。

工具化是運維的必經之路，是向更高層發展的基礎，面對運維這樣復雜的學科，這樣一個極其磨煉人意志的工種，運維工程師需要用聰明的方式解決復雜的問題，節省時間，去做更有意義的事情。

第二次升級：運維產品化

我剛提出運維產品化時，有朋友開玩笑說，你做后端運維吃苦受罪這么多年，看著產品經理吃香的喝辣的，羨慕嫉妒也想轉行做產品吧。也有人說，你是在偷換概念，不就是做自動化運維平臺嘛。其實提出這個概念，一方面是源于有了足夠的工具化積累；另一方面是想換一種思路做運維，培養產品觀，站在用戶的角度思考問題，讓處于后端的運維工程師主動挖掘需求，圍繞運維做更多的探索，提升團隊技術能力，解決海量用戶帶來的問題。有了這個想法，就需要將無形的技術轉變為有形的產品形態，同時要賦予它好的寓意。我們的產品取名為HULK——綠巨人，意在讓小伙伴們借助巨人的肩膀成長，輕點鼠標，運籌帷幄。

想到做這個平臺，源于對實際工作需求的觀察。產品經理有了創新點之后，開發工程師就想以最快的速度上線，但又會很痛苦，因為產品就好比寶塔明珠，塔基需要一 層層地蓋。而開發工程師是與運維工程師合作最緊密的兄弟，“兄弟有難得拔刀相助”，因此我們明確了開發工程師就是運維平臺的用戶，運維工程師在平臺的建設 中扮演了多重角色，是建設者也是使用者，但目標是為用戶解決問題，讓我們的用戶有極致的用戶體驗。基于這些想法，我們勾畫出了宏偉藍圖，提供一個塔基，第一層提供核心基礎服務，如Web、RDB、NoSQL等；第二層提供通用基礎服務，構造一個完美的平臺，讓開發工程師受益。但勾畫的平臺功 能大而全，需求都是我們替用戶假想的，這樣做的后果就是進展緩慢，但做出的功能沒人用。我們在失敗中反思，意識到需求還得從日常工作中去挖掘，平臺上每個功能模塊都必須解決用戶的痛點。互聯網精神唯快不破，要圍繞“快”找痛點。早期開發和運維的合作中，更多的是郵件、IM及當面溝通，跨團隊的溝通成本是第 一個痛點。初期平臺建設中，我們從加速流程開始進行摸索，以“需求任務流”為核心，將通用需求規范流程，統一需求提交頁面，同時盡量為用戶提供選項，而不是隨意填寫，盡量減少溝通成本，同時為完全自動化打好基礎。由于完整的自動化流程開發成本比較高，初期我們還“投機取巧”，用戶提交需求以后，只是把格式 化的郵件發送給運維工程師。運維工程師使用半自動化工具干活，完成后再通過平臺任務流告知用戶結果，手工操作的部分是隱藏在平臺后面的，用戶不得而知。就 用這種方式，我們的平臺積累了不少用戶和口碑。之后我們將日常需求分層、分類：主機類包括主機申請、賬號授權、軟件部署等；Web類包括配置文件管理、域名管理等；DB類包括建庫、建表、SQL審核、授權等。再攻克技術難點將一個個需求實現完全自動化，點點鼠標解決問題。

關于需求任務流，還有個小插曲，標準的任務流由提交、審核、駁回/通過組成。但這個流程太死板，例如用戶提交的一個需求，在審核的過程中有待商榷，運維工程師會和開發工程師 溝通，最終達成一致意見即可，而如果按標準流程需要駁回再提交。為了讓用戶少一次操作，我們增加了管理員可編譯功能。有些同事反對這樣做，覺得不符合常 理。不過有時候常理是需要結合實際場景打破的，就為了讓用戶使用更簡單。

近期為了進一步提升項目試錯階段的速度，我們在平臺上推出了一個新功能：“項目孵化器”。以典型的Web業務為例，以往，申請Web Server、賬號、數據庫實例、負載均衡等是提給運維最基本的需求，每一步都是時間成本。使用“項目孵化器”可以最大限度解決這個痛點，只需在平臺上進 行兩個步驟：第一步填寫業務名稱，預估峰值QPS；第二步選用MySQL、MongoDB、Redis等相關數據庫資源。兩步之后，Web Server、數據庫實例等所需資源會瞬間展示在用戶面前，同時包管理、配置文件管理、代碼發布系統、監控系統等配套輔助功能隨之開通。

與之前的模式相比，效率和規范化都有明顯提高。說起來很神奇，但實現理念很簡單，我們提煉日常項目中的通用方案，構建資源池，在項目發展初期最小量匹配資源。在孵化器的設計階段，我們聽到了很多不同的聲音。例如，讓用戶填信息不夠全面，架構太簡單不滿足全部需求，諸如此類問題，讓人頭痛欲裂。經過過往項目 分析及用戶調研，發現項目尚處于試錯階段，快速試錯是首要需求。至于項目發展中衍生出來的需求，可以再用平臺擴展功能去解決。當利用孵化器建立一個試錯項目之后，用戶進入平臺想看見什么？展現形式如何？還能做什么？這些問題隨之而來。

眾所周知，項目中的關聯關系是個復雜的問題，解決不好，就像一盤散沙無法聯動。為了解決此問題，首先我們確定平臺各功能模塊以項目名為主鍵，將項目的域名、負載均衡、Web Server、數據庫、通用基礎服務等相關聯。項目后期各功能模塊的擴容可以借助關聯關系自動化完成。例如增加一臺Web Server，即可自動部署軟件環境，完成相關節點授權、上傳代碼、測試上線。

展現形式上我們借鑒社交網站的實現方案，以“我的項目”為中心，用戶進入平臺以后默認頁展示項目在平臺中用到的各功能模塊信息，例如域名、主機數量、數據庫實例和監控指標等。做到信息清晰可見，操控簡單易用。

在平臺建設中，我們一直遵循兩個準則：第一，把事情由復雜變簡單；第二，給用戶極致的用戶體驗。所謂極致，就是要超出用戶的預期，但只有挖掘用戶潛在的需求，才能做出超出預期的功能。傳統的運維模式，大多是開發工程師提需求，運維工程師滿足需求，運維工程師主動推進的意識不夠。360的文化中有很重要的一點是Ownership，一個項目的成功與失敗，運維工程師是有責任的，因此需要在日常工作中時刻提醒自己“這個項目是我的，為了讓項目變得更好，我們需要主動思考，為開發工程師提供更多的增值服務”。例如一個項目上線前，會默認部署日志收集模塊，收集匯總后進行訪問日志自動化分析，以時間維度展示訪問量走勢，同時輔以IP地址分析模塊展示地域及運營商分布。同時基于訪問日志狀態碼做進一步的頁面分析，然后以日、周、月維度生成一份體檢報告，以及應對方案推送給開發工程師。這些增值服務是超出預期的，拉近了開發工程師和我們的距離，一起去探討、改進，做出更多有利于項目發展的功能。結束語

運維工作在一家公司中至關重要，但傳統的運維模式一定程度上限制了運維工程師的技術發展，更抑制了創新思維，我們需要利用運維“寬泛技術”定位的優勢開拓思路。例如運維工作需要和很多開發團隊合作，協助架構設計，在這個過程中會接觸到很多開發團隊的技術積累，可以把各家之所長進行聚合，將一些基礎服務進行平臺化改造，資源共享。也可以根據項目的需要，主動做技術研究，將基礎服務做成一個個小產品，提供給開發團隊使用，幫助項目縮短研發周期，穩定發展。在當今技術背景下，運維工程師應該在紅海中尋找藍海的思維模式，培養產品觀，由外至內地思考，突破傳統運維的壁壘，開拓創新。

第三篇：銀行IT運維職責

最佳答案檢舉IT運維是IT管理的核心和重點部分，也是內容最多、最繁雜的部分，該階段主要用于IT部門內部日常運營管理，涉及的對象分成兩大部分，即IT業務系統和運維人員，該階段的管理內容又可細分為七個子系統：

■ 設備管理：對網絡設備、服務器備、操作系統運行狀況進行監控

應用/服務管理：對各種應用支持軟件如數據庫、中間件、群件以及各種通用或特定服務的監控管理，如郵件系統、DNS、Web等的監控與管理

■ 數據/存儲/容災管理：對系統和業務數據進行統一存儲、備份和恢復

■ 業務管理：包含對企業自身核心業務系統運行情況的監控與管理，對于業務的管理，主要關注該業務系統的CSF（關鍵成功因素Critical Success Factors）和KPI（關鍵績效指標Key Performance Indicators）

■ 目錄/內容管理：該部分主要對于企業需要統一發布或因人定制的內容管理和對公共信息的管理

■ 資源資產管理：管理企業中各IT系統的資源資產情況，這些資源資產可以是物理存在的，也可以是邏輯存在的，并能夠與企業的財務部門進行數據交互

■ 信息安全管理：該部分包含了許多方面的內容，目前信息安全管理主要依據的國際標準是ISO17799，該標準涵蓋了信息安全管理的十大控制方面，36個控制目標和127中控制方式，如企業安全組織方式、資產分類與控制、人員安全、物理與環境安全、通信與運營安全、訪問控制、業務連續性管理等

■ 日常工作管理：該部分主要用于規范和明確運維人員的崗位職責和工作安排、提供績效考核量化依據、提供解決經驗與知識的積累與共享手段IT運行維護管理的每一個子系統中都包含著十分豐富的內容，實現完善的IT運維管理是企業提高經營水平和服務水平的關鍵。運行/維護階段與服務/支持階段的分界線為前者是面向IT部門內部的管理，而后者是面向業務部門、企業中的其它人員或直接面向客戶。

第四篇：IT運維項目管理心得—風險管理

IT運維項目管理心得—風險管理

過在PMP的學習，結合多年的IT運維項目實施管理工作經驗，我對項目管理中的風險管理有了進一步的學習和認識，我真正認識PMP項目管理在現實生活中的運用。

風險管理是預防、規避項目風險的主要手段，是完成項目計劃內的期限、預算內費用、規定的技術指標等的重要保障。在每個風險管理周期都應該做好從設計、合同、進度、質量、費用、溝通等管理工作中收集相關信息，并將這些信息反映在風險管理過程中的各環節工作中，并及時進行反饋。

現將我對項目風險管理的理解總結如下：

1、做好風險識別

在項目啟動階段，將對項目需求及項目實施過程中可能面對的風險進行全面的識別，結合公司已有的風險評估表，對識別出來的風險進行評分。

2、做好風險管控

在項目實施階段，對前期已識別的風險，按照不同的風險等級進行管控，針對高危等級的風險（如：客戶關鍵業務系統宕機）通過外包（購買原廠服務）或采取一定措施降低風險值的方式解決（提供專業人員提供24小時值班監控）；針對中等級的風險，則制定相應的風險解決方案（如：巡檢、定期保養、設備實時監控），來減少或緩解風險的發生概率；針對低等級風險，則采取定期監控方式。

3、做好風險監測

風險監測是持續不間斷進行的過程，主要包含跟蹤已識別的風險，監測殘余風險和識別新的風險，形成風險管理監控報告，對重新識別的風險進行排序形成風險評估表，為管理人員提供決策的量化依據。通過對風險的良好監測和控制并形成風險管理監控報告，在風險發生前做出有效決策，減少風險造成的損失。（慧翔天地廣州學員黃賢裕）

第五篇：運維管理定義

運維管理(IT Operations Management)幫助企業建立快速響應并適應企業業務環境及業務發展的IT運維模式，實現基于ITIL的流程框架、運維自動化。

核心思想隨著國內企業業務信息化的深入, IT運維部門所負責的IT設備及軟件的運行維護工作變得越來越復雜，技術難度也越來越高。傳統的IT工具和流程集中在技術上，而不是業務目標上。業務服務管理(Business Service Management)使IT能輕松滿足業務的需求，轉變企業的環境，使業務部門和IT部門領導者能夠擁有統一的語言，通過統一的界面面對挑戰，理解新變化所帶來的影響。

BSM主要強調從業務的視角來看待企業的IT運維，從而最大化發揮IT對企業業務的推動作用，這就IT運維的核心思想。

著眼點IT系統的業務服務管理主要著眼點

一、確立以業務價值為核心，業務驅動管理的管理思想面向業務要首先在IT管理的戰略層面上建立“業務驅動”的IT治理和管理思想，使得業務部門的目標和IT運維的目標一致，都是為了企業整體戰略目標的實現，把對業務的支撐能力和管理實效，作為評價IT系統效用和IT部門工作的首要指標。只有這樣，才能在全企業范圍內建立“技術服務于業務發展”的意識和文化，是真正實現IT與業務融合，共同為企業的戰略目標服務。

二、建立關鍵業務服務模型今天的業務部門對應用程序的依賴性比過去更強了。應用程序軟件可以實現關鍵業務流程的自動化 —自動化既包括付款、資金轉賬、下訂單和訂單履行。由于應用程序故障或性能問題可能導致嚴重的業務影響，因此業務部門迫切需要 IT 部門在發生問題時提供更高的應用程序服務級別和更快的問題解決方案。所以，必須結合企業戰略和目前業務運營情況，辨識企業業務服務，特別是關鍵業務應用。為這些核心業務系統服務，建立和企業未來發展愿景、目前IT架構、管理模式等相適應的業務服務模型，能夠清晰地描述業務與IT之間的關聯關系和IT服務的關鍵目標。

三、管理信息共享目前，出于對IT資源專業化、精細化管理的要求，企業部署了諸多的監控管理工具，如網絡監控、系統監控、數據庫監控工具等。一般來說，這些監控工具往往來自于不同的廠商，彼此之間缺乏信息共享的手段。而一個具體的業務是由網絡、主機、應用本身所組成，管理信息無法共享，這就造成了當一個故障出現時，無法通過系統直接自動分析并定位故障點，加大了IT故障的分析難度，降低了解決問題的效率。業務服務管理可以有效整合企業已經構建的眾多IT監控系統，將分散的IT管理信息集中到一個單點的管理平臺中，從而可以快速進行故障定位。

四、根源問題定位隨著企業業務的快速發展，IT環境越來越復雜，IT組件越來越多，同時各組件之間的關聯關系也更加紛亂和復雜。業務服務管理能夠提供有效的根源問題定位能力，它著眼于企業的核心業務系統，通過集中與業務相關的IT信息，根據業務邏輯和IT組件之間的關聯關系進行建模，企業可以在業務模型中的任何一點進行快速的根源問題分析和定位，大大提高了解決問題的速度和準確度。

五、故障影響范圍評估當我們發現IT故障時，我們不僅應該關注故障本身，更應該考慮該故障對業務系統的影響。通過建立業務服務影響拓撲，可以快速的了解企業的關鍵性業務及業務故障時的影響范圍，通過了解企業具體的業務環境，優先處理關鍵故障點。